aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-06-07drm/mipi-dbi: Add support for DRM_FORMAT_RGB888Noralf Trønnes1-4/+25
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it on the SPI bus using a 24 bits per word transfer. The problem with this is that not all SPI controllers support 24 bpw. Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI bus is big endian we use 8 bpw to always get the same pixel format on the bus: b8g8r8. The MIPI DCS specification lists the standard commands that can be sent over the MIPI DBI interface. The set_address_mode (36h) command has one bit in the parameter that controls RGB/BGR order. This means that the controller can be configured to receive the pixel as BGR. RGB888 is rarely supported on these controllers but RGB666 is very common. All datasheets I have seen do at least support the pixel format option where each color is sent as one byte and the 6 MSB's are used. All this put together means that we can send each pixel as b8g8r8 and an RGB666 capable controller sees this as b6x2g6x2r6x2. v4: - s/emulation_format/pixel_format/ (Dmitry) Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Noralf Trønnes <[email protected]>
2024-06-07drm/mipi-dbi: Make bits per word configurable for pixel transfersNoralf Trønnes1-4/+10
MIPI DCS write/set commands have 8 bit parameters except for the write_memory commands where it depends on the pixel format. drm_mipi_dbi does currently only support RGB565 which is 16-bit and it has to make sure that the pixels enters the SPI bus in big endian format since the MIPI DBI spec doesn't have support for little endian. drm_mipi_dbi is optimized for DBI interface option 3 which means that the 16-bit bytes are swapped by the upper layer if the SPI bus does not support 16 bits per word, signified by the swap_bytes member. In order to support both 16-bit and 24-bit pixel transfers we need a way to tell the DBI command layer the format of the buffer. Add a write_memory_bpw member that the upper layer can use to tell how many bits per word to use for the SPI transfer. v4: - Expand the commit message (Dmitry) Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Noralf Trønnes <[email protected]>
2024-06-07drm/mipi-dbi: Remove mipi_dbi_machine_little_endian()Noralf Trønnes1-16/+19
mipi_dbi_machine_little_endian() should really have been called mipi_dbi_framebuffer_little_endian() because that's the function it performs. When I added support for these SPI displays I thought that the framebuffers on big endian machines were also big endian, but I have later learned that this is not the case. There's a bit in the fourcc code that controls this: DRM_FORMAT_BIG_ENDIAN. Just remove the function to avoid confusion. We can add big endian support later should the need arise and we have hardware to test on. Instead of just amending the docs, expand it to explain the endianness handling. Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Noralf Trønnes <[email protected]>
2024-06-07regmap: kunit: Use array_size() and sizeof(*ptr) consistentlyAndy Shevchenko1-6/+6
Some of the allocations use explit sizeof(type) instead of sizeof(*ptr), which is fragile. In particular, stress_insert() allocates double of memory without obvious need for a test. Convert all allocations to use array_size() and sizeof(*ptr) to eliminate similar mistakes or wrong memory sizes. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-07drm: have config DRM_WERROR depend on !WERRORJani Nikula1-0/+1
If WERROR is already enabled, there's no point in enabling DRM_WERROR or asking users about it. Reported-by: Linus Torvalds <[email protected]> Closes: https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=VEOjn6GW8GK4j2V+BiDUntZKAQ@mail.gmail.com Fixes: f89632a9e5fa ("drm: Add CONFIG_DRM_WERROR") Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-06-07regmap: maple: Switch to use kmemdup_array()Andy Shevchenko1-7/+6
Let the kememdup_array() take care about multiplication and possible overflows. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-07regmap: cache: Switch to use kmemdup_array()Andy Shevchenko1-2/+2
Let the kememdup_array() take care about multiplication and possible overflows. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-07regmap: cache: Use correct type of the rb_for_each() parameterAndy Shevchenko1-1/+1
Compiler is not happy: regcache.c:410:9: warning: Using plain integer as NULL pointer Replace integer 0 by NULL. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-07regmap: Switch to use kmemdup_array()Andy Shevchenko1-1/+1
Let the kememdup_array() take care about multiplication and possible overflows. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-07spi: cs42l43: Drop cs35l56 SPI speed down to 11MHzCharles Keepax1-2/+2
Some internals of the cs35l56 can only support SPI speeds of up to 11MHz. Whilst some use-cases could support higher rates, keep things simple by dropping the SPI speed down to this avoid any potential issues. Signed-off-by: Charles Keepax <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-07liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packetAleksandr Mishin1-6/+5
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC") Signed-off-by: Aleksandr Mishin <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-07net: ti: icssg-prueth: Add multicast filtering supportMD Danish Anwar1-4/+34
Add multicast filtering support for ICSSG Driver. Multicast addresses will be updated by __dev_mc_sync() API. icssg_prueth_add_macst () and icssg_prueth_del_mcast() will be sync and unsync APIs for the driver respectively. To add a mac_address for a port, driver needs to call icssg_fdb_add_del() and pass the mac_address and BIT(port_id) to the API. The ICSSG firmware will then configure the rules and allow filtering. If a mac_address is added to port0 and the same mac_address needs to be added for port1, driver needs to pass BIT(port0) | BIT(port1) to the icssg_fdb_add_del() API. If driver just pass BIT(port1) then the entry for port0 will be overwritten / lost. This is a design constraint on the firmware side. To overcome this in the driver, to add any mac_address for let's say portX driver first checks if the same mac_address is already added for any other port. If yes driver calls icssg_fdb_add_del() with BIT(portX) | BIT(other_existing_port). If not, driver calls icssg_fdb_add_del() with BIT(portX). The same thing is applicable for deleting mac_addresses as well. This logic is in icssg_prueth_add_mcast / icssg_prueth_del_mcast APIs. Signed-off-by: MD Danish Anwar <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-07platform/x86: dell-pc: avoid double free and invalid unregistrationThomas Weißschuh1-1/+3
If platform_profile_register() fails it does kfree(thermal_handler) and leaves the pointer value around. Any call to thermal_cleanup() will try to kfree(thermal_handler) again. This will happen right away in dell_init(). In addition, platform_profile_remove() will be called although no profile is registered. NULL out the thermal_handler, so thermal_cleanup() avoids the double free. Fixes: 996ad4129810 ("platform/x86: dell-pc: Implement platform_profile") Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Lyndon Sanche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
2024-06-07pinctrl: renesas: rzn1: Use for_each_child_of_node_scoped()Geert Uytterhoeven1-2/+1
Use the scoped variant of for_each_child_of_node() to simplify the code. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/c0a28f466c42d5d59c7fadfa1fd05fd512d43b6f.1717060708.git.geert+renesas@glider.be
2024-06-07clk: renesas: rcar-gen2: Use DEFINE_SPINLOCK() for static spinlockGeert Uytterhoeven1-3/+1
A static spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Suggested-by: Ye Bin <[email protected]> Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/8da2c908f00043f05f7e26e3c26400aea0cfe8bc.1716975021.git.geert+renesas@glider.be
2024-06-07clk: renesas: cpg-lib: Use DEFINE_SPINLOCK() for global spinlockGeert Uytterhoeven3-5/+1
A global spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Suggested-by: Ye Bin <[email protected]> Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/9073a6bfb7791e492156331fa8a0ea87a7c7cef6.1716975021.git.geert+renesas@glider.be
2024-06-07clk: renesas: r8a77970: Use common cpg_lockGeert Uytterhoeven1-4/+1
R-Car Gen3 Socs use the common CPG/MSSR library functions in rcar-cpg-lib.c, so the R-Car V3M sub-driver can use the common cpg_lock instead of a driver-private lock. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/0cd9b5ffbe986bd7dc4ffb3f13492123432ee2e1.1716975021.git.geert+renesas@glider.be
2024-06-07thermal: ACPI: Invalidate trip points with temperature of 0 or belowRafael J. Wysocki1-1/+7
It is reported that commit 950210887670 ("thermal: core: Drop trips_disabled bitmask") causes the maximum frequency of CPUs to drop further down with every system sleep-wake cycle on Intel Core i7-4710HQ. This turns out to be due to a trip point whose temperature is equal to 0 degrees Celsius which is acted on every time the system wakes from sleep. Before commit 950210887670 this trip point would be disabled wia the trips_disabled bitmask, but now it is treated as a valid one. Since ACPI thermal control is generally about protection against overheating, trip points with temperature of 0 centigrade or below are not particularly useful there, so initialize them all as invalid which fixes the problem at hand. Fixes: 950210887670 ("thermal: core: Drop trips_disabled bitmask") Closes: https://lore.kernel.org/linux-pm/[email protected] Reported-by: Tibor Billes <[email protected]> Tested-by: Tibor Billes <[email protected]> Cc: 6.7+ <[email protected]> # 6.7+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-06-07thermal: core: Do not fail cdev registration because of invalid initial stateRafael J. Wysocki1-2/+11
It is reported that commit 31a0fa0019b0 ("thermal/debugfs: Pass cooling device state to thermal_debug_cdev_add()") causes the ACPI fan driver to fail probing on some systems which turns out to be due to the _FST control method returning an invalid value until _FSL is first evaluated for the given fan. If this happens, the .get_cur_state() cooling device callback returns an error and __thermal_cooling_device_register() fails as uses that callback after commit 31a0fa0019b0. Arguably, _FST should not return an invalid value even if it is evaluated before _FSL, so this may be regarded as a platform firmware issue, but at the same time it is not a good enough reason for failing the cooling device registration where the initial cooling device state is only needed to initialize a thermal debug facility. Accordingly, modify __thermal_cooling_device_register() to avoid calling thermal_debug_cdev_add() instead of returning an error if the initial .get_cur_state() callback invocation fails. Fixes: 31a0fa0019b0 ("thermal/debugfs: Pass cooling device state to thermal_debug_cdev_add()") Closes: https://lore.kernel.org/linux-acpi/[email protected] Reported-by: Laura Nao <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Tested-by: Laura Nao <[email protected]>
2024-06-07hwrng: omap - add missing MODULE_DESCRIPTION() macroJeff Johnson2-0/+2
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/hw_random/omap-rng.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/hw_random/omap3-rom-rng.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: xilinx - add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/crypto/xilinx/zynqmp-aes-gcm.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Michal Simek <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: sa2ul - add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/crypto/sa2ul.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: keembay - add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/crypto/intel/keembay/keembay-ocs-hcu.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: atmel-sha204a - add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/crypto/atmel-sha204a.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: hisilicon/zip - optimize the address offset of the reg query functionChenghai Huang1-28/+20
Currently, the reg is queried based on the fixed address offset array. When the number of accelerator cores changes, the system can not flexibly respond to the change. Therefore, the reg to be queried is calculated based on the comp or decomp core base address. Signed-off-by: Chenghai Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: hisilicon/qm - adjust the internal processing sequence of the vf ↵Chenghai Huang1-8/+3
enable and disable When the vf is enabled, the value of vfs_num must be assigned after the VF configuration is complete. Otherwise, the device may be accessed before the virtual configuration is complete, causing an error. When the vf is disabled, clear vfs_num and execute qm_pm_put_sync before hisi_qm_sriov_disable is return. Otherwise, if qm_clear_vft_config fails, users may access the device when the PCI virtualization is disabled, resulting in an error. Signed-off-by: Chenghai Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07hwrng: stm32 - use sizeof(*priv) instead of sizeof(struct stm32_rng_private)Marek Vasut1-1/+1
Use sizeof(*priv) instead of sizeof(struct stm32_rng_private), the former makes renaming of struct stm32_rng_private easier if necessary, as it removes one site where such rename has to happen. No functional change. Signed-off-by: Marek Vasut <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Acked-by: Gatien Chevallier <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07hwrng: stm32 - cache device pointer in struct stm32_rng_privateMarek Vasut1-18/+13
Place device pointer in struct stm32_rng_private and use it all over the place to get rid of the horrible type casts throughout the driver. No functional change. Acked-by: Gatien Chevallier <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07hwrng: stm32 - use pm_runtime_resume_and_get()Marek Vasut1-1/+3
include/linux/pm_runtime.h pm_runtime_get_sync() description suggests to ... consider using pm_runtime_resume_and_get() instead of it, especially if its return value is checked by the caller, as this is likely to result in cleaner code. This is indeed better, switch to pm_runtime_resume_and_get() which correctly suspends the device again in case of failure. Also add error checking into the RNG driver in case pm_runtime_resume_and_get() does fail, which is currently not done, and it does detect sporadic -EACCES error return after resume, which would otherwise lead to a hang due to register access on un-resumed hardware. Now the read simply errors out and the system does not hang. Acked-by: Gatien Chevallier <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: ccp - Move message about TSME being enabled later in initMario Limonciello2-8/+15
Some of the security attributes data is now populated from an HSTI command on some processors, so show the message after it has been populated. Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: ccp - Add support for getting security attributes on some older systemsMario Limonciello6-3/+67
Older systems will not populate the security attributes in the capabilities register. The PSP on these systems, however, does have a command to get the security attributes. Use this command during ccp startup to populate the attributes if they're missing. Closes: https://github.com/fwupd/fwupd/issues/5284 Closes: https://github.com/fwupd/fwupd/issues/5675 Closes: https://github.com/fwupd/fwupd/issues/6253 Closes: https://github.com/fwupd/fwupd/issues/7280 Closes: https://github.com/fwupd/fwupd/issues/6323 Closes: https://github.com/fwupd/fwupd/discussions/5433 Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: ccp - Move security attributes to their own fileMario Limonciello5-56/+89
To prepare for other code that will manipulate security attributes move the handling code out of sp-pci.c. No intended functional changes. Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: ccp - Represent capabilities register as a unionMario Limonciello5-42/+42
Making the capabilities register a union makes it easier to refer to the members instead of always doing bit shifts. No intended functional changes. Acked-by: Tom Lendacky <[email protected]> Suggested-by: Yazen Ghannam <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: stm32/cryp - call finalize with bh disabledMaxime Méré1-1/+5
The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process. Signed-off-by: Maxime Méré <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: stm32/cryp - add CRYPTO_ALG_KERN_DRIVER_ONLY flagMaxime Méré1-9/+9
This flag is needed to make the driver visible from openssl and cryptodev. Signed-off-by: Maxime Méré <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: stm32/cryp - increase priorityMaxime Méré1-9/+9
Increase STM32 CRYP priority, to be greater than the ARM-NEON accelerated version. Signed-of-by: Maxime Méré <[email protected]> Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07crypto: stm32/cryp - use dma when possibleMaxime Méré1-26/+651
Use DMA when buffer are aligned and with expected size. If buffer are correctly aligned and bigger than 1KB we have some performance gain: With DMA enable: $ openssl speed -evp aes-256-cbc -engine afalg -elapsed The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 120.02k 406.78k 1588.82k 5873.32k 26020.52k 34258.94k Without DMA: $ openssl speed -evp aes-256-cbc -engine afalg -elapsed The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 121.06k 419.95k 1112.23k 1897.47k 2362.03k 2386.60k With DMA: extract of $ modprobe tcrypt mode=500 testing speed of async cbc(aes) (stm32-cbc-aes) encryption tcrypt: test 14 (256 bit key, 16 byte blocks): 1 operation in 1679 cycles (16 bytes) tcrypt: test 15 (256 bit key, 64 byte blocks): 1 operation in 1893 cycles (64 bytes) tcrypt: test 16 (256 bit key, 128 byte blocks): 1 operation in 1760 cycles (128 bytes) tcrypt: test 17 (256 bit key, 256 byte blocks): 1 operation in 2154 cycles (256 bytes) tcrypt: test 18 (256 bit key, 1024 byte blocks): 1 operation in 2132 cycles (1024 bytes) tcrypt: test 19 (256 bit key, 1424 byte blocks): 1 operation in 2466 cycles (1424 bytes) tcrypt: test 20 (256 bit key, 4096 byte blocks): 1 operation in 4040 cycles (4096 bytes) Without DMA: $ modprobe tcrypt mode=500 tcrypt: test 14 (256 bit key, 16 byte blocks): 1 operation in 1671 cycles (16 bytes) tcrypt: test 15 (256 bit key, 64 byte blocks): 1 operation in 2263 cycles (64 bytes) tcrypt: test 16 (256 bit key, 128 byte blocks): 1 operation in 2881 cycles (128 bytes) tcrypt: test 17 (256 bit key, 256 byte blocks): 1 operation in 4270 cycles (256 bytes) tcrypt: test 18 (256 bit key, 1024 byte blocks): 1 operation in 11537 cycles (1024 bytes) tcrypt: test 19 (256 bit key, 1424 byte blocks): 1 operation in 15025 cycles (1424 bytes) tcrypt: test 20 (256 bit key, 4096 byte blocks): 1 operation in 40747 cycles (4096 bytes) Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Maxime Méré <[email protected]> Signed-off-by: Nicolas Toromanoff <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07hwrng: amd - Convert PCIBIOS_* return codes to errnosIlpo Järvinen1-1/+3
amd_rng_mod_init() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is then returned as is but amd_rng_mod_init() is a module_init() function that should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 96d63c0297cc ("[PATCH] Add AMD HW RNG driver") Cc: [email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-06-07drm/i915/bios: Define the "luminance and gamma" sub-struct of block 46Ville Syrjälä1-0/+12
Since BDB version 211 block 46 has included more luminance and gamma related information. Define it fully. The data is semi-based on DisplayID v2.0 apparently. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-06-07drm/i915/bios: Define block 46 chromaticity coordinates properlyVille Syrjälä1-10/+17
The VBT spec does a very poor job of defining how the chromaticity coordinates in block 46 are laid out. After double checking the Windows implementation it turns out these more or less match the EDID definition, where the 10bit values are split into 2bit + 8bit chunks. Adjust our struct definition to reflect that. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-06-07drm/xe: do not select ACPI_BUTTONJani Nikula1-1/+0
The xe driver has never needed ACPI button. Selecting the kconfig is just copy-paste from i915, which no longer needs it either. Stop selecting ACPI_BUTTON. Cc: Ville Syrjälä <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1872adc6b20ce4c5ef55ba60a7233b31ace776fb.1717747542.git.jani.nikula@intel.com
2024-06-07drm/i915: do not select ACPI_BUTTONJani Nikula1-1/+0
We stopped using ACPI button in commit 05c72e77ccda ("drm/i915: Nuke the LVDS lid notifier"). Also stop force enabling the ACPI_BUTTON config. Cc: Ville Syrjälä <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/060d687c3a80cd94f065e637200dd10fea7b979f.1717747542.git.jani.nikula@intel.com
2024-06-07net: hns3: add cond_resched() to hns3 ring buffer init processJie Wang2-0/+6
Currently hns3 ring buffer init process would hold cpu too long with big Tx/Rx ring depth. This could cause soft lockup. So this patch adds cond_resched() to the process. Then cpu can break to run other tasks instead of busy looping. Fixes: a723fb8efe29 ("net: hns3: refine for set ring parameters") Signed-off-by: Jie Wang <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-07net: hns3: fix kernel crash problem in concurrent scenarioYonglong Liu1-5/+16
When link status change, the nic driver need to notify the roce driver to handle this event, but at this time, the roce driver may uninit, then cause kernel crash. To fix the problem, when link status change, need to check whether the roce registered, and when uninit, need to wait link update finish. Fixes: 45e92b7e4e27 ("net: hns3: add calling roce callback function when link status change") Signed-off-by: Yonglong Liu <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-07coresight: Fix ref leak when of_coresight_parse_endpoint() failsJames Clark1-1/+3
of_graph_get_next_endpoint() releases the reference to the previous endpoint on each iteration, but when parsing fails the loop exits early meaning the last reference is never dropped. Fix it by dropping the refcount in the exit condition. Fixes: d375b356e687 ("coresight: Fix support for sparsely populated ports") Signed-off-by: James Clark <[email protected]> Reported-by: Laurent Pinchart <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-06-07drm/xe/guc: Allow CTB G2H processing without G2H IRQMichal Wajdeczko2-0/+45
During early initialization, in the xe_guc_min_load_for_hwconfig() function, we are successfully enabling CTB communication, but it will only allow us to send non-blocking H2G messages, as due to not yet enabled IRQs, including G2H IRQs, we will not notice any new G2H message sent by the GuC, including replies to our blocking H2G request messages. And those successful replies are mandatory for the VF drivers to continue normal operations. As attempt to workaround this driver initialization ordering issue, introduce special safe-mode CTB worker, that will periodically trigger G2H processing, like original IRQ handler, in case no MSI/MSIX IRQs were enabled on the driver yet. Once we detect that IRQ were enabled, we will stop this worker. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-07drm/xe/guc: Split g2h worker functionMichal Wajdeczko1-2/+8
In the next patch we will want to perform the same steps that g2h worker function is doing but from the different worker. Suggested-by: Matthew Brost <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-07hwmon: (cros_ec) Fix access to restricted __le16Guenter Roeck1-2/+3
0-day complains: drivers-hwmon-cros_ec_hwmon.c:sparse:sparse:cast-to-restricted-__le16 Fix by using a __le16 typed variable as parameter to le16_to_cpu(). Fixes: bc3e45258096 ("hwmon: add ChromeOS EC driver") Cc: Thomas Weißschuh <[email protected]> Cc: Tzung-Bi Shih <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Acked-by: Thomas Weißschuh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-07hwmon: (cros_ec) Prevent read overflow in probe()Dan Carpenter1-1/+1
The "resp.sensor_name" comes from cros_ec_cmd() and it hasn't necessarily been NUL terminated. We had not intended to read past "sensor_name_size" bytes, however, there is a width vs precision bug in the format string. The format needs to be precision '%.*s' instead of width '%*s'. Precision prevents an out of bounds read, but width is a no-op. Fixes: bc3e45258096 ("hwmon: add ChromeOS EC driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Thomas Weißschuh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-07HID: i2c-hid: elan: fix reset suspend current leakageJohan Hovold1-12/+47
The Elan eKTH5015M touch controller found on the Lenovo ThinkPad X13s shares the VCC33 supply with other peripherals that may remain powered during suspend (e.g. when enabled as wakeup sources). The reset line is also wired so that it can be left deasserted when the supply is off. This is important as it avoids holding the controller in reset for extended periods of time when it remains powered, which can lead to increased power consumption, and also avoids leaking current through the X13s reset circuitry during suspend (and after driver unbind). Use the new 'no-reset-on-power-off' devicetree property to determine when reset needs to be asserted on power down. Notably this also avoids wasting power on machine variants without a touchscreen for which the driver would otherwise exit probe with reset asserted. Fixes: bd3cba00dcc6 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens") Cc: <[email protected]> # 6.0 Cc: Douglas Anderson <[email protected]> Tested-by: Steev Klimaszewski <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.