kernel/linux.git/drivers, branch v5.4.292

mmc: sdhci-pxav3: set NEED_RSP_BUSY capability

2025-04-10T12:29:43+00:00

commit a41fcca4b342811b473bbaa4b44f1d34d87fcce6 upstream. Set the MMC_CAP_NEED_RSP_BUSY capability for the sdhci-pxav3 host to prevent conversion of R1B responses to R1. Without this, the eMMC card in the samsung,coreprimevelte smartphone using the Marvell PXA1908 SoC with this mmc host doesn't probe with the ETIMEDOUT error originating in __mmc_poll_for_busy. Note that the other issues reported for this phone and host, namely floods of "Tuning failed, falling back to fixed sampling clock" dmesg messages for the eMMC and unstable SDIO are not mitigated by this change. Link: https://lore.kernel.org/r/20200310153340.5593-1-ulf.hansson@linaro.org/ Link: https://lore.kernel.org/r/D7204PWIGQGI.1FRFQPPIEE2P9@matfyz.cz/ Link: https://lore.kernel.org/r/20250115-pxa1908-lkml-v14-0-847d24f3665a@skole.hr/ Cc: stable@vger.kernel.org Signed-off-by: Karel Balej Acked-by: Adrian Hunter Tested-by: Duje Mihanović Link: https://lore.kernel.org/r/20250310140707.23459-1-balejk@matfyz.cz Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP

2025-04-10T12:29:43+00:00

commit 2da31ea2a085cd189857f2db0f7b78d0162db87a upstream. Like the ASUS Vivobook X1504VAP and Vivobook X1704VAP, the ASUS Vivobook 14 X1404VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh breaking the keyboard. $ sudo dmidecode […] System Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS Vivobook 14 X1404VAP_X1404VA […] $ grep -A 30 PS2K dsdt.dsl | grep IRQ -A 1 IRQ (Level, ActiveLow, Exclusive, ) {1} Add the X1404VAP to the irq1_level_low_skip_override[] quirk table to fix this. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Cc: All applicable Signed-off-by: Paul Menzel Reviewed-by: Hans de Goede Tested-by: Anton Shyndin Link: https://patch.msgid.link/20250318160903.77107-1-pmenzel@molgen.mpg.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ntb_perf: Delete duplicate dmaengine_unmap_put() call in perf_copy_chunk()

2025-04-10T12:29:43+00:00

commit 4279e72cab31dd3eb8c89591eb9d2affa90ab6aa upstream. The function call “dmaengine_unmap_put(unmap)” was used in an if branch. The same call was immediately triggered by a subsequent goto statement. Thus avoid such a call repetition. This issue was detected by using the Coccinelle software. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Cc: stable@vger.kernel.org Signed-off-by: Markus Elfring Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman

can: flexcan: only change CAN state when link up in system PM

2025-04-10T12:29:43+00:00

[ Upstream commit fd99d6ed20234b83d65b9c5417794343577cf3e5 ] After a suspend/resume cycle on a down interface, it will come up as ERROR-ACTIVE. $ ip -details -s -s a s dev flexcan0 3: flexcan0: mtu 16 qdisc pfifo_fast state DOWN group default qlen 10 link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 can state STOPPED (berr-counter tx 0 rx 0) restart-ms 1000 $ sudo systemctl suspend $ ip -details -s -s a s dev flexcan0 3: flexcan0: mtu 16 qdisc pfifo_fast state DOWN group default qlen 10 link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000 And only set CAN state to CAN_STATE_ERROR_ACTIVE when resume process has no issue, otherwise keep in CAN_STATE_SLEEPING as suspend did. Fixes: 4de349e786a3 ("can: flexcan: fix resume function") Cc: stable@vger.kernel.org Signed-off-by: Haibo Chen Link: https://patch.msgid.link/20250314110145.899179-1-haibo.chen@nxp.com Reported-by: Marc Kleine-Budde Closes: https://lore.kernel.org/all/20250314-married-polar-elephant-b15594-mkl@pengutronix.de [mkl: add newlines] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

arcnet: Add NULL check in com20020pci_probe()

2025-04-10T12:29:43+00:00

[ Upstream commit fda8c491db2a90ff3e6fbbae58e495b4ddddeca3 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated. Fixes: 6b17a597fc2f ("arcnet: restoring support for multiple Sohard Arcnet cards") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250402135036.44697-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: dsa: mv88e6xxx: propperly shutdown PPU re-enable timer on destroy

2025-04-10T12:29:43+00:00

[ Upstream commit a58d882841a0750da3c482cd3d82432b1c7edb77 ] The mv88e6xxx has an internal PPU that polls PHY state. If we want to access the internal PHYs, we need to disable the PPU first. Because that is a slow operation, a 10ms timer is used to re-enable it, canceled with every access, so bulk operations effectively only disable it once and re-enable it some 10ms after the last access. If a PHY is accessed and then the mv88e6xxx module is removed before the 10ms are up, the PPU re-enable ends up accessing a dangling pointer. This especially affects probing during bootup. The MDIO bus and PHY registration may succeed, but registration with the DSA framework may fail later on (e.g. because the CPU port depends on another, very slow device that isn't done probing yet, returning -EPROBE_DEFER). In this case, probe() fails, but the MDIO subsystem may already have accessed the MIDO bus or PHYs, arming the timer. This is fixed as follows: - If probe fails after mv88e6xxx_phy_init(), make sure we also call mv88e6xxx_phy_destroy() before returning - In mv88e6xxx_remove(), make sure we do the teardown in the correct order, calling mv88e6xxx_phy_destroy() after unregistering the switch device. - In mv88e6xxx_phy_destroy(), destroy both the timer and the work item that the timer might schedule, synchronously waiting in case one of the callbacks already fired and destroying the timer first, before waiting for the work item. - Access to the PPU is guarded by a mutex, the worker acquires it with a mutex_trylock(), not proceeding with the expensive shutdown if that fails. We grab the mutex in mv88e6xxx_phy_destroy() to make sure the slow PPU shutdown is already done or won't even enter, when we wait for the work item. Fixes: 2e5f032095ff ("dsa: add support for the Marvell 88E6131 switch chip") Signed-off-by: David Oberhollenzer Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250401135705.92760-1-david.oberhollenzer@sigma-star.at Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

ntb: intel: Fix using link status DB's

2025-04-10T12:29:42+00:00

[ Upstream commit 8144e9c8f30fb23bb736a5d24d5c9d46965563c4 ] Make sure we are not using DB's which were remapped for link status. Fixes: f6e51c354b60 ("ntb: intel: split out the gen3 code") Signed-off-by: Nikita Shubin Reviewed-by: Dave Jiang Signed-off-by: Jon Mason Signed-off-by: Sasha Levin

ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans

2025-04-10T12:29:42+00:00

[ Upstream commit de203da734fae00e75be50220ba5391e7beecdf9 ] There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative. [ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative Ensuring xlate_pos is a positive or zero before BIT. Fixes: 1e2fd202f859 ("ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()") Signed-off-by: Yajun Deng Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason Signed-off-by: Sasha Levin

hwmon: (nct6775-core) Fix out of bounds access for NCT679{8,9}

2025-04-10T12:29:42+00:00

[ Upstream commit 815f80ad20b63830949a77c816e35395d5d55144 ] pwm_num is set to 7 for these chips, but NCT6776_REG_PWM_MODE and NCT6776_PWM_MODE_MASK only contain 6 values. Fix this by adding another 0 to the end of each array. Signed-off-by: Tasos Sahanidis Link: https://lore.kernel.org/r/20250312030832.106475-1-tasos@tasossah.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

wifi: iwlwifi: fw: allocate chained SG tables for dump

2025-04-10T12:29:42+00:00

[ Upstream commit 7774e3920029398ad49dc848b23840593f14d515 ] The firmware dumps can be pretty big, and since we use single pages for each SG table entry, even the table itself may end up being an order-5 allocation. Build chained tables so that we need not allocate a higher-order table here. This could be improved and cleaned up, e.g. by using the SG pool code or simply kvmalloc(), but all of that would require also updating the devcoredump first since that frees it all, so we need to be more careful. SG pool might also run against the CONFIG_ARCH_NO_SG_CHAIN limitation, which is irrelevant here. Also use _devcd_free_sgtable() for the error paths now, much simpler especially since it's in two places now. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250209143303.697c7a465ac9.Iea982df46b5c075bfb77ade36f187d99a70c63db@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin