aboutsummaryrefslogtreecommitdiff
path: root/drivers/mmc
AgeCommit message (Collapse)AuthorFilesLines
12 daysmmc: cavium-thunderx: destroy slot platform devices on removeGuangshuo Li1-1/+4
thunder_mmc_probe() creates host->slot_pdev[i] with of_platform_device_create(), while thunder_mmc_remove() does not destroy the child platform devices. The probe failure path removes each MMC slot and destroys its associated platform device, but the normal remove path only removes the MMC slot. As a result, the child platform devices remain registered after the ThunderX MMC controller is removed. Destroy each slot platform device during removal after cleaning up the corresponding MMC slot, matching the probe failure cleanup path. Keep an extra device reference around of_platform_device_destroy() as done in the existing error path. This issue was found by manual code inspection. Fixes: 166bac38c3c56 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
12 daysmmc: cavium-octeon: destroy slot platform devices on removeGuangshuo Li1-1/+4
octeon_mmc_probe() creates host->slot_pdev[i] with of_platform_device_create(), while octeon_mmc_remove() does not destroy the child platform devices. The probe failure path removes each MMC slot and destroys its associated platform device, but the normal remove path only removes the MMC slot. As a result, the child platform devices remain registered after the Octeon MMC controller is removed. Destroy each slot platform device during removal after cleaning up the corresponding MMC slot, matching the probe failure cleanup path. This issue was found by manual code inspection. Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
12 daysmmc: sdhci-sprd: disable runtime PM on removeGuangshuo Li1-0/+4
sdhci_sprd_probe() enables runtime PM, while sdhci_sprd_remove() does not perform the corresponding runtime PM cleanup. The probe failure path disables runtime PM before disabling the clocks, but the normal remove path directly disables clocks that are also managed by the runtime PM callbacks. If the device is runtime suspended, those clocks may already be disabled. Resume the device before removal, disable runtime PM and drop the temporary runtime PM reference before disabling the clocks. This issue was found by manual code inspection. Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
12 daysmmc: mtk-sd: Cancel request timeout work on removeYibo Tan1-0/+1
The driver queues req_timeout while a request is active. msdc_request_done() uses cancel_delayed_work(), which does not wait for a timeout callback that has already started. The timeout callback calls mmc_request_done(), which wakes the request waiter, and then continues to use host->dev_comp and check the SDIO IRQ. During unbind, msdc_drv_remove() can return and the managed mmc_host can be freed before the callback finishes. KASAN reported use-after-free accesses in msdc_request_done() and msdc_recheck_sdio_irq() in each of three unbind tests. The same tests completed without a kernel diagnostic after this change. Call cancel_delayed_work_sync() after mmc_remove_host() has stopped new requests and before the driver releases the host resources. Fixes: 208489032bdd ("mmc: mediatek: Add Mediatek MMC driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan <lhfff@tju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-14mmc: sdhci-of-aspeed: Remove children before releasing SDC resourcesMyeonghun Pak1-1/+4
Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse order before disabling the parent clock on both paths. Use of_platform_device_destroy() because manual child creation does not set the flag required by of_platform_depopulate(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Assisted-by: OpenAI:GPT-5.6 Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-11mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interruptRunyu Xiao1-2/+1
The threaded IRQ handler can run before devm_request_threaded_irq() returns, but thread_lock was initialized afterwards. Initialize it before requesting either interrupt. Fixes: 8047310ee984 ("mmc: sh_mmcif: fix a race, causing an Oops on SMP") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-10mmc: core: Fix OF node reference leak on card add failureZhu Ling1-1/+1
mmc_of_find_child_device() returns a device node with its reference count incremented. mmc_add_card() stores the reference before calling device_add(), while the card is marked present only after device_add() succeeds. If device_add() fails, the callers release the card through mmc_remove_card(). However, mmc_remove_card() only drops the OF node reference for a present card, leaking the reference on this error path. Move of_node_put() outside the present-card conditional so the reference is released for both registered cards and card-add failures. Fixes: 25185f3f31c9 ("mmc: Add SDIO function devicetree subnode parsing") Cc: stable@vger.kernel.org Signed-off-by: Zhu Ling <zhuling0805@qq.com> Reviewed-by: Shawn Lin <shawn.lin@linux.dev> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-10mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260Florian Maillard1-0/+5
The Realtek RTS522A card reader in the Lenovo ThinkPad X260 (subsystem 17aa:504a) incorrectly reports inserted SD cards as write-protected. This causes the MMC core to expose the card as read-only: mmcblk0: mmc0:aaaa SN256 238 GiB (ro) and /sys/block/mmcblk0/ro reports 1. Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again. Limit the quirk to the affected Lenovo subsystem. Assisted-by: ChatGPT:GPT-5.6 Sol Signed-off-by: Florian Maillard <florian.maillard@mailoo.org> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-09mmc: sdio_uart: fix xmit_fifo leak when the port table is fullFelix Gu1-0/+3
sdio_uart_add_port() allocates the transmit fifo before claiming a slot in sdio_uart_table[]. When all UART_NR slots are taken, it returns -EBUSY with the fifo still allocated, but the probe error path only kfree()s the port, leaking the transmit fifo. Free the fifo in the failure path of sdio_uart_add_port() itself so the function retains nothing on error. Fixes: 8b197a5ce7a7 ("sdio_uart: Use kfifo instead of the messy circ stuff") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-08mmc: spi: reset bytes_xfered before retrying CRC failuresXu Rao1-0/+1
mmc_spi_data_do() updates data->bytes_xfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytes_xfered may therefore contain the number of bytes completed before the failing block. mmc_spi_request() has a private recovery path for such CRC failures. It sends STOP_TRANSMISSION, clears data->error and jumps back to crc_recover to issue the same command and data request again. However, it does not clear data->bytes_xfered before the retry. If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytes_xfered. For a multi-block request this can make the completed request report more bytes than were transferred by the successful retry, and can even exceed the request size when most blocks completed before the CRC error. This is most likely to be observed on MMC-over-SPI systems where long multi-block transfers occasionally hit a data CRC error but the mmc_spi-internal retry succeeds. The data itself is retried, but the completion accounting is not. Clear data->bytes_xfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt. Fixes: 061c6c847eeb ("mmc_spi: Recover from CRC errors for r/w operation over SPI.") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: sdhci_am654: Fallback to DT-provided itap delay on DDR50 tuning failureDiogo Ivo (Schneider Electric)1-5/+21
DDR50 mode is not required to support the tuning command CMD19, meaning that calibration may fail on cards that do not implement it, in which case a known-good itap delay value should be programmed into the host controller. Do this by reading the (already defined) itap delay DT property for DDR50 and, if tuning fails for this mode, fall back to the DT-provided itap delay value. If the DT does not provide a value for DDR50 fallback then this simply disables using itapdly. Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Judith Mendez <jm@ti.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: sdhci_am654: Clear ITAPDLY on tuning failureDiogo Ivo (Schneider Electric)1-5/+7
When tuning fails, stale ITAPDLY values can persist and interfere with subsequent I/O accesses, for example in DDR50 mode in cards with no tuning support. Move the ITAPDLY enable setting out of the tuning loop to after successful tuning, and explicitly clear ITAPDLY (delay and enable) when tuning fails so that we are sure only working values are actually left in hardware. Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com> Reviewed-by: Judith Mendez <jm@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: sdhci_am654: Reset command and data lines on failed tuningDiogo Ivo (Schneider Electric)1-3/+1
The CMD/DATA reset after tuning should be performed regardless of whether tuning succeeded or failed, since tuning data may remain in the buffer in either case. Move the error return after the reset so that the controller is always cleaned up. Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com> Reviewed-by: Judith Mendez <jm@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: sdhci_am654: Move tuning_loop to local variableDiogo Ivo (Schneider Electric)1-5/+2
The tuning_loop field in struct sdhci_am654_data is only used within sdhci_am654_platform_execute_tuning() as a loop counter that is initialized to 0 in sdhci_am654_init(). Since it shouldn't persist across function calls, otherwise every failure expends its "budget", move it to a local variable and remove the struct field along with the now-unnecessary initialization. Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com> Reviewed-by: Judith Mendez <jm@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: hsq: Fix use-after-free in retry workFan Wu1-1/+7
mmc_hsq_pump_requests() queues retry_work when request_atomic() returns -EBUSY; today sdhci-sprd is the only consumer that implements request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but is never cancelled during driver removal. Work still pending at unbind can therefore run after the devm allocation has been released and dereference hsq->mmc and hsq->mrq. Use devm_work_autocancel() to cancel and drain retry_work before the devm allocation is released. By the time devres cleanup begins, mmc_remove_host() has already stopped the host, so no new requests can arm the work. This issue was found by an in-house static analysis tool. Fixes: 6db96e5810e0 ("mmc: host: Introduce the request_atomic() for the host") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: mxcmmc: cancel data work and watchdog on removeFan Wu1-0/+4
mxcmci_remove() frees the host through the devm tail, but neither it nor mmc_remove_host() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(), is deleted only by the DMA- and IRQ-complete paths, which the remove path does not explicitly drain; it can therefore fire after the host is freed and dereference it in mxcmci_watchdog(). host->datawork, armed from the IRQ handler on the PIO path, is not cancelled by the remove path either. Free the devm-registered IRQ, then cancel datawork and delete the watchdog in mxcmci_remove(), before dma_release_channel(). Freeing the IRQ first keeps a trailing handler from re-arming datawork between the cancel and the host free. Both callbacks are non-self-rearming. This issue was found by an in-house static analysis tool. Fixes: f6ad0a481342 ("mmc: mxcmmc: fix bug that may block a data transfer forever") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: mmci: Fix use-after-free in busy-timeout workFan Wu1-0/+3
ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b command, but mmci_remove() never cancels it. The work can subsequently dereference the devm-allocated mmci_host after it has been released. Mask the controller interrupts and disable the delayed work during removal. This drains any queued instance and stops an IRQ handler that is still in progress from queueing the work again once it has been disabled. This issue was found by an in-house static analysis tool. Fixes: b1a665932dc2 ("mmc: mmci: Add support for SW busy-end timeouts") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-09-04mmc: core: Cancel SDIO IRQ work before freeing hostFan Wu1-0/+1
A host controller that uses sdio_signal_irq() schedules host->sdio_irq_work from its interrupt handler. That work is only cancelled on the suspend path (mmc_sdio_suspend()), not on the remove/free path, so a worker armed just before the controller freed its IRQ can run after mmc_host_classdev_release() has freed the host and dereference it through container_of(). Cancel host->sdio_irq_work in mmc_free_host(), like the existing host->detect drain added by commit 1036f69e2513 ("mmc: core: Cancel delayed work before releasing host"). This issue was found by an in-house static analysis tool. Fixes: 682696605c70 ("mmc: sdio: Add API to manage SDIO IRQs from a workqueue") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-21Merge tag 'mmc-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds33-224/+186
Pull MMC updates from Ulf Hansson: "MMC core: - Reject invalid perdev_minors for the block device before division - Document DT fixed-layout NVMEM provider support for eMMC cards MMC host: - Convert a couple of plain text DT bindings to the yaml format - bcm2835: DMA mapping improvements - cqhci: Fix sparse warnings for endian conversions - dw_mmc: Stop and complete DMA also in busy state - dw_mmc-rockchip: Add support for the RV1106 variant - litex_mmc: Add dynamic bus width support - moxart: Propagate error for DMA completion timeout - pxamci: Remove PXA remnants for the PXA93x support - rtsx_usb_sdmmc: Avoid USB I/O in runtime autosuspend - rtsx_usb_sdmmc: Suppress false CD after init timeout - sdhci_am654: Add Judith Mendez as maintainer - sdhci-esdhc-mcf: Do not use readl()/writel() on ColdFire - sdhci-msm: Extend the DT bindings for ICE - sdhci-tegra: Add support for Tegra264/Tegra238 variants - sunxi: Add support for the Allwinner A733 variant - via-sdmmc: Clean up card detect work at remove and in probe error path" * tag 'mmc-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (35 commits) ARM: PXA: Fix build error for PXA93x dt-bindings: mmc: sunxi: add compatible string for Allwinner A733 MMC0/1/2 dt-bindings: mmc: Document fixed-layout NVMEM provider support mmc: sdhci-tegra: Add Tegra264 SoC data dt-bindings: mmc: tegra: Document Tegra264 SDHCI mmc: sdhci-tegra: Add Tegra238 SoC data dt-bindings: mmc: tegra: Document Tegra238 SDHCI mmc: omap_hsmmc: use platform_get_irq_optional for wake IRQ mmc: via-sdmmc: cancel card-detect work on remove mmc: via-sdmmc: stop card-detect handling on probe failure mmc: moxart: use platform helpers for resource and IRQ mmc: host: Remove redundant dev_err()/dev_err_probe() mmc: bcm2835: DMA mapping improvements mmc: dw_mmc: move declaration of dw_mci_pmops dt-bindings: mmc: rockchip-dw-mshc: Add RV1106 compatible mmc: rtsx_usb_sdmmc: suppress false CD after init timeout misc: rtsx_usb: avoid USB I/O in runtime autosuspend mmc: sdhci-of-dwcmshc: Log eMMC reset calls mmc: block: reject invalid perdev_minors before division mmc: sdhci-of-ma35d1: add missing MODULE_DEVICE_TABLE() ...
2026-08-20Merge tag 'net-next-7.3' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from Jakub Kicinski: "One of the 'small improvements all over the place' releases for us. It's hard to draw any direct comparisons because summer vacations disrupted our patch processing (and presumably - generation) quite a bit. Quick and dirty count suggests we (Paolo and I) merged a very similar number of net (632) and net-next (648) patches. This is not telling the full story either because 1/3 to 1/2 of the net-next patches also *seem* like AI-driven low priority fixes, cleanups and clarifications. We are completely overwhelmed, of course. The glimmer of hope is that we secured sufficient LLM budget and access (thank you Meta!) to run reviews with multiple frontier models on each patch. This eliminates some hallucinations. That said, in terms of review, the LLMs can only do so much. The sad truth is that our APIs (especially for rare events like PCIe errors, timeouts etc) have always been racy, and now LLMs don't let us ignore that. I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got "reviewed-by" tags from people we trust... Core & protocols: - A few steps lowering rtnl_lock dependence: - per-netns netdev unregistration for select SW drivers (e.g. veth, ipvlan, tunnels) - rtnl_lock-less FIB rule changes (RTM_NEWRULE and RTM_DELRULE) - prepare software drivers and TC qdiscs for rtnl_lock-less GET - Support BIG TCP (>64kB TSO) in UDP tunnels (vxlan, geneve) - Support buffers larger than PAGE_SIZE in devmem zero-copy API - Improve MPTCP handling of extreme memory pressure handling, when out-of-order queue had to be pruned - Report the per-group user count via RTM_GETMULTICAST - Expose the route deletion reason in RTM_DELROUTE - Add a SO_RIGHTS_NOTRUNC option to UNIX sockets to enable more useful handling of LSM denials when receiving SCM_RIGHTS messages: instead of truncating the message at the first blocked fd, keep every fd slot and store the LSM errno in the blocked slot - IPv6 Segment Routing - support looking up the post-encap SID (address) in a different/specified routing table - Support PRP RedBox (interlink) creation - Support per-nexthop UDP dst port in VXLAN - Continue converting getsockopt callbacks in a number of protocols to iov_iter Ethernet: - Merge initial CXL support for AMD/Solarflare NICs (shared branch with the CXL tree) - New drivers: - ADIN1140 10BASE-T1S MACPHY - Initial skeleton of Intel iXD and ZTE Dinghai drivers - High-speed NICs: - AMD/Pensando: - support firmware flashing - Cisco (enic): - SR-IOV V2 admin channel and MBOX protocol - Huawei (hns3): - support for ethtool pfc_prevention_tout - nVidia/Mellanox: - support sharing bandwidth control across interfaces of the same device - Marvell (octeontx2-pf): - link RQ page pools to netdev for Netlink stats - Google vNIC: - XDP metadata support for DQ RDA - Microsoft vNIC: - support forcing full-page RX buffers - Other NICs: - Synopsys IP: - eic7700: support for eth1 - Microchip (lan743x): - support for RMII interface - Wangxun: - support for ethtool -G and -C for VFs - add Tx timeout and PCIe error handling - Intel (igb/igc): - RSS key get/set support - support for forcing link speed without auto-negotiation - Switches: - NXP (dpaa2): - support bonding/LAG offload - Mediatek: - mt7530: EN7528 support - initial support for MT7628 - Micrel (ksz8/9): - refactoring work to move towards library model - PTP support for KSZ8463 - nVidia/Mellanox: - support rtnl-lock-less ethtool callbacks - Realtek: - rtl8366rb: use generic RTL83xx code - support SGMII and HSGMII for RTL8367S - PHYs: - Airoha: - EcoNet EN7528 PHY support - DAPU Telecom - DAPU Telecom DAP8211R(I) Gigabit PHY support - Realtek: - support RTL8261C_CG - support RTL8261D Wireless: - nl80211: per-link statistics support for multi-link operation - mac80211: AQL/airtime-fairness support for multicast - Merge Peripheral Authentication Service (PAS) / TEE support for ath12k (shared branch with the firmware/qcom tree) - New drivers: - mm81x for Morse Micro Long-Range S1G devices - nxpwifi for NXP devices (mostly forked off from mwifiex) - Driver changes: - Broadcom (brcmfmac): - DPP support, some Cypress part update - MediaTek (mt76): - mt7928 support - mt7925 NAN support - mt7996 AP powersave improvements - Qualcomm (ath12k): - much kernel infrastructure integration work - AHB platform MultiPD support - Realtek (rt89): - LED support - RTL8922DE support - dual-BT coex for RTL8922D - Intel: - new FW version support Bluetooth: - HCI: add support for Shorter Connection Interval (SCI) feature - af_bluetooth: add minimal context analysis annotations - Driver changes: - Intel: - add Bluetooth SAR revision 2 support - add vendor_reset PCI sysfs for PLDR - Mediatek: - add USB IDs for MT7902 and MT7922 devices - Realtek: - add USB IDs for 8761CU and 8852BE devices - NXP: - add M.2 Bluetooth device support using pwrseq Misc: - DPLL support for manual/numerical oscillator control (NCO) (implement in zl3073x) - MCTP support for MCTP over USB v1.1 (DMTF DSP0283) - Power-over-Ethernet: support Realtek PSE controllers - Remove the IBM EHEA driver - Remove tulip/xircom_cb driver" * tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1433 commits) net/mlx5e: do not HW-GRO coalesce small frames net: openvswitch: fix nf_connlabels leak in ovs_ct_init net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() net: openvswitch: fix flow mask use-after-free on flow deletion sctp: stop processing a packet once its association is deleted dpll: zl3073x: add PTP clock support dpll: zl3073x: add channel ToD, phase step and TIE operations dpll: zl3073x: scale poll interval proportionally to timeout ptp: vmclock: prevent read-only mappings from becoming writable ipv4: reject undersized MTUs in ip_do_fragment() bonding: initialize err for empty target lists net: dsa: initial support for MT7628 embedded switch net: dsa: initial MT7628 tagging driver net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs dt-bindings: net: dsa: add MT7628 ESW net: pse-pd: realtek-pse-mcu: add UART transport net: pse-pd: realtek-pse-mcu: add I2C transport net: pse-pd: add Realtek PSE MCU core dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU vsock: use sock_error() to consume sk_err after a failed connect ...
2026-08-04mmc: Merge branch fixes into nextUlf Hansson5-6/+24
Merge the mmc fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the mmc changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: loongson2: Fix sg iteration in data reorder functionsBinbin Zhou1-4/+4
In ls2k0500_mmc_reorder_cmd_data() and ls2k2000_mmc_reorder_cmd_data(), the for_each_sg() macro already iterates over the scatterlist entries, with 'sg' pointing to the current entry. However, the code incorrectly uses '&sg[i]' and 'sg_dma_len(&sg[i])' inside the loop, which treats 'sg' as an array base and indexes it again, leading to access of wrong sg entries (or out-of-bounds if the list is not an array). Cc: stable@vger.kernel.org Fixes: d0f8e961deae ("mmc: loongson2: Add Loongson-2K2000 SD/SDIO/eMMC controller driver") Fixes: 2115772014bd ("mmc: loongson2: Add Loongson-2K SD/SDIO controller driver") Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bitZhan Xusheng1-1/+1
omap_hsmmc_prepare_data() converts the command busy timeout to nanoseconds with: timeout = req->cmd->busy_timeout * NSEC_PER_MSEC; busy_timeout is an unsigned int (milliseconds) and timeout is a u64, but NSEC_PER_MSEC is 1000000L. On 32-bit builds the multiplication is performed in 32-bit arithmetic and wraps for busy_timeout values above ~4294 ms, before the result is assigned to the u64. The driver does not set mmc->max_busy_timeout, so the core does not cap the busy timeout, and commands such as erase or SANITIZE (MMC_SANITIZE_TIMEOUT_MS is 240000 ms) can pass a busy_timeout far larger than 4294 ms. The wrapped, much smaller ns value is then programmed via set_data_timeout(), so the data timeout is set too short and the operation can time out prematurely. Cast busy_timeout to u64 before the multiplication so the conversion is done in 64-bit arithmetic. Fixes: 8cc9a3e73de1 ("mmc: host: omap_hsmmc: use generic_cmd6_time to program timeout value for CMD6") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: atmel-mci: Fix use-after-free in atmci_remove due to race conditionPei Xiao1-0/+2
In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove. Fixes: 7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers") Assisted-by: Codex:deepseek-v4-flash Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: sdhci: unmap the bounce buffer before device releaseMyeonghun Pak1-0/+16
sdhci_allocate_bounce_buffer() allocates its buffer with devm_kmalloc() but maps it with dma_map_single(). The buffer is therefore released by devres without the streaming DMA mapping being unmapped. Register a managed action after dma_map_single() succeeds so the mapping is removed before devres releases the buffer. The action is registered only for buffers allocated and mapped by the SDHCI core, leaving buffers provided by host drivers under their existing ownership. Fixes: bd9b902798ab ("mmc: sdhci: Implement an SDHCI-specific bounce buffer") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-04mmc: sdhci: make tuning_err a signed intHaibo Chen1-1/+1
Coverity report INTEGER_OVERFLOW for host->tuning_err. The tuning_err field in struct sdhci_host is used to store an error code for re-tuning, but it was declared as unsigned int. Several call sites store negative error codes into it and later compare against negative values: - sdhci.c, sdhci-of-dwcmshc.c and sdhci-pci-gli.c assign it the return value of __sdhci_execute_tuning()/__sdhci_execute_tuning_9750(), both of which return a signed int (possibly a negative errno); - sdhci-of-esdhc.c assigns host->tuning_err = -EAGAIN and later does "ret = host->tuning_err; if (ret == -EAGAIN ...)"; - sdhci-of-dwcmshc.c prints it with the %d (signed) conversion. Storing a negative errno in an unsigned int and reading it back as a signed int only happens to work because of two's-complement, same-width integer conversions. It is misleading and triggers sign-conversion warnings. All users treat the value either as a signed error code or as a boolean (zero / non-zero), so changing the type to a signed int is safe and makes the intent explicit. Fixes: 7d8bb1f46e13 ("mmc: sdhci: add tuning error codes") Assisted-by: Cline:claude-sonnet [read_file, search_files, git] Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-03mmc: sdhci-tegra: Add Tegra264 SoC dataPrathamesh Shete1-0/+15
Add a new SoC data structure for Tegra264 platforms and register the nvidia,tegra264-sdhci compatible string. Configure the supported features and tap delay values for the Tegra264 SDHCI controller. Signed-off-by: Prathamesh Shete <pshete@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-08-03mmc: sdhci-tegra: Add Tegra238 SoC dataPrathamesh Shete1-0/+15
Add a new SoC data structure for Tegra238 platforms and register the nvidia,tegra238-sdhci compatible string. Configure the supported features and tap delay values for the Tegra238 SDHCI controller. Signed-off-by: Prathamesh Shete <pshete@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27Merge tag 'wireless-2026-07-26' of ↵Jakub Kicinski1-0/+3
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless-next-2026-07-26 Mostly driver changes this time: - new driver mm81x for an S1G device - new driver nxpwifi for NXP devices (mostly forked off from mwifiex) - ath12k: much kernel infrastructure integration work - brcmfmac: DPP support, some Cypress part update - nl80211: per-link statistics support ==================== Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-27mmc: omap_hsmmc: use platform_get_irq_optional for wake IRQRosen Penev1-4/+7
Replace irq_of_parse_and_map() with platform_get_irq_optional() to get the wake IRQ. This is a more portable approach that works with both DT and non-DT platforms, and follows the modern platform API conventions for optional IRQ resources. The wake IRQ is now fetched earlier in the probe function alongside the main IRQ, and the -EPROBE_DEFER case is handled properly before the deferred probe can be triggered. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27mmc: via-sdmmc: cancel card-detect work on removeFan Wu1-0/+4
Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory. Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the interrupt through via_reset_pcictrl(); mask it again afterwards. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: f0bf7f61b840 ("mmc: Add new via-sdmmc host controller driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27mmc: via-sdmmc: stop card-detect handling on probe failureFan Wu1-1/+7
request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: e4e46fb61e3b ("mmc: via-sdmmc: fix return value check of mmc_add_host()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27mmc: moxart: use platform helpers for resource and IRQRosen Penev1-19/+10
Replace of_address_to_resource() and the following devm_ioremap_resource() with a single devm_platform_get_and_ioremap_resource() call in moxart_probe(). This requests the register region and maps it once, which is equivalent to the previous devm_ioremap_resource() behavior, and drops the now-redundant separate resource lookup. Similarly replace irq_of_parse_and_map() with platform_get_irq(), which returns a negative errno on failure (including -EPROBE_DEFER) instead of 0, and tighten the error check to irq < 0. Both substitutions are equivalent for a DT-backed platform device. The remaining OF usage (mmc_of_parse() and the of_device_id table) is covered by already-included headers, so linux/of_address.h and linux/of_irq.h are dropped. No functional change; the MMC register window is requested and mapped exactly once, so there is no overlapping region claim. Built for ARM (allmodconfig + CONFIG_MMC_MOXART) with LLVM=1; drivers/mmc/host/moxart-mmc.o compiles cleanly. Assisted-by: opencode:hy3-free Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-27mmc: host: Remove redundant dev_err()/dev_err_probe()Pan Chuang8-33/+10
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq() automatically log detailed error messages on failure. Remove the now-redundant driver-specific dev_err() and dev_err_probe() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-16mmc: bcm2835: DMA mapping improvementsJohn Garry1-18/+19
As pointed out by sashiko bot in [0], recent proposed changes to dma_max_mapping_size() may affect the driver. While the issue reported may be a false positive, Robin pointed out some other DMA-related issues in the driver which are addressed here: - the DMA max mapping size is irrelevant for the programmed IO mode of operation - we should not call dma_max_mapping_size() on the MMC host platform device, but rather the DMA engine device In addition, it's better to use the device returned from dmaengine_get_dma_device() for dma_umap_sg() and dma_unmap_sg(), and not reference the DMA channel device directly. [0] https://lore.kernel.org/linux-scsi/d82926fe-4557-401d-ae58-4302fef5657c@oracle.com/#t Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: Merge branch fixes into nextUlf Hansson1-33/+58
Merge the mmc fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the mmc changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: dw_mmc: move declaration of dw_mci_pmopsBen Dooks2-1/+2
The dw_mci_pmops is exported out of dw_mmc.c so move the declaration of ton dw_mmc.h from dw_mmc-pltfm.h to fix the following sparse warning: drivers/mmc/host/dw_mmc.c:3512:25: warning: symbol 'dw_mci_pmops' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: fix resume error handlingLuke Wang1-4/+4
Check pm_runtime_force_resume() return value in resume. If it fails (clock enable failure), return immediately since accessing hardware registers on an unclocked device would cause a kernel panic. The early return intentionally skips enable_irq() and sdhci_disable_irq_wakeups() because the IRQ handler reads SDHCI_INT_STATUS, which would also fault without clocks. The PM runtime usage counter leak only affects this already-broken device instance and is an acceptable tradeoff to preserve system stability. Remove the return value check for mmc_gpio_set_cd_wake(host->mmc, false) since disable_irq_wake() called internally always returns 0. Also return 0 explicitly on the success path instead of propagating stale return values. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspendLuke Wang1-7/+6
Make pinctrl_pm_select_sleep_state() and mmc_gpio_set_cd_wake() failures non-fatal in the suspend path. These failures only mean slightly higher power consumption or missing CD wakeup capability, but should not block system suspend. Also change the function to always return 0 on the success path instead of propagating non-fatal warning return values. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspendLuke Wang1-1/+3
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() to simplify error handling. pm_runtime_resume_and_get() automatically drops the usage counter on failure, avoiding the need for a separate pm_runtime_put_noidle() call. If it fails, the device is unclocked and accessing hardware registers would cause a kernel panic, so return the error immediately. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interruptLuke Wang1-5/+6
When using WIFI out-of-band wakeup, an "irq xxx: nobody cared" warning occurs. This happens because the usdhc interrupt is not disabled during system suspend when device_may_wakeup() returns false. The sequence of events leading to this issue: 1. System enters suspend without disabling usdhc interrupt (because device_may_wakeup() returns false for usdhc device) 2. WIFI out-of-band wakeup triggers system resume via GPIO interrupt 3. WIFI sends a Card interrupt before usdhc has fully resumed 4. usdhc is still in runtime suspend state and cannot handle the interrupt properly 5. The unhandled interrupt triggers "nobody cared" warning Fix this by unconditionally disabling the usdhc interrupt during suspend and re-enabling it during resume, regardless of the wakeup capability. This ensures no interrupts are processed during the suspend/resume transition. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on resumeLuke Wang1-0/+6
SDIO devices such as WiFi may keep power during suspend, so the MMC core skips full card re-initialization on resume and directly restores the host controller's ios timing to match the card. For DDR mode, pm_runtime_force_resume() sets DDR_EN before the pin configuration is restored from sleep state. This is related to the SoC IP integration: switching pinctrl setting (changing alt from GPIO to USDHC) impacts the internal loopback path. If pinctrl configures the pad to GPIO function, once DDR_EN is set, the DLL delay will be fixed based on the GPIO function loopback path. When the pinctrl is later changed to USDHC function, the internal loopback path changes, making the original fixed sample point no longer suitable for the current loopback path. This causes persistent read CRC errors on subsequent data transfers. SD/eMMC running in DDR mode are unaffected as they are fully re-initialized from legacy timing after resume. Fix this by restoring the pinctrl state based on current timing mode using esdhc_change_pinstate() before pm_runtime_force_resume(). This ensures the correct pin configuration (e.g., 100/200MHz for UHS modes) is applied before DDR_EN is set. Only restore for non-wakeup devices since wakeup devices kept their active pin state during suspend. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15