summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-02nvme-multipath: require exact iopolicy names for module parameterliyouhong
The iopolicy module parameter uses strncmp prefix matching, so values like "numax" are accepted as "numa". The per-subsystem sysfs attribute already requires an exact match via sysfs_streq(). Parse both through a shared helper so invalid values are rejected consistently. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: liyouhong <liyouhong@kylinos.cn> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-02nvme-multipath: pass NS head to nvme_mpath_revalidate_paths()John Garry
In nvme_mpath_revalidate_paths(), we are passed a NS pointer and use that to lookup the NS head and then use that same NS pointer as an iter variable. It makes more sense pass the NS head and use a local variable for the NS iter. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-02USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()Adrian Korwel
build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel <adriank20047@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-06-02USB: serial: io_ti: fix heap overflow in get_manuf_info()Adrian Korwel
get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel <adriank20047@gmail.com> [ johan: amend commit message; also check for short descriptors ] Signed-off-by: Johan Hovold <johan@kernel.org>
2026-06-02ata: pata_ep93xx: add COMPILE_TEST supportRosen Penev
Now that the build failures have been fixed, we can add COMPILE_TEST so the buildbots can find potentially more problems. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-02ata: pata_ep93xx: use unsigned long for dataRosen Penev
An int is being encoded as a void pointer but that breaks on 64-bit systems as the type needs to match pointer size. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-02ata: pata_ep93xx: avoid asm on non ARMRosen Penev
The raw ARM asm delay loop prevents COMPILE_TEST builds on non-ARM architectures. Guard it with CONFIG_ARM and provide a cpu_relax() fallback for compilation on other architectures. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-02pps: generators: Use ktime_get_real_ts64() instead of ktime_get_snapshot()Thomas Gleixner
There is no reason to use the more complex ktime_get_snapshot() for retrieving CLOCK_REALTIME. Just use ktime_get_real_ts64(), which avoids the extra timespec64 conversion as a bonus. No functional change intended. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Rodolfo Giometti <giometti@enneenne.com> Link: https://patch.msgid.link/20260529195557.074439049@kernel.org
2026-06-02iommu/amd: Don't split flush for amd_iommu_domain_flush_all()Weinan Liu
We have observed multiple full invalidations occurring during device detach when we are done using the vfio-device. blocked_domain_attach_device() -> detach_device() -> amd_iommu_domain_flush_all() -> amd_iommu_domain_flush_pages(..., CMD_INV_IOMMU_ALL_PAGES_ADDRESS) while (size != 0) { -> __domain_flush_pages( flush_size /* power of 2 flush_size */) -> domain_flush_pages_v1() -> build_inv_iommu_pages() -> build_inv_address() } build_inv_address() will trigger a full invalidation if the chunk size > (1 << 51). Consequently, the guest will issue multiple full invalidations for a single call to amd_iommu_domain_flush_all() Without this patch, we will see 10 time instead of 1 time full invalidations for every amd_iommu_domain_flush_all(). Cc: stable@vger.kernel.org Fixes: a270be1b3fdf ("iommu/amd: Use only natural aligned flushes in a VM") Suggested-by: Josef Bacik <josef@toxicpanda.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Weinan Liu <wnliu@google.com> Reviewed-by: Wei Wang <wei.w.wang@hotmail.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-02iommu/rockchip: disable fetch dte time limitSimon Xue
Disable the Bit 31 of the AUTO_GATING iommu register, as it causes hangups with the RGA3 (Raster Graphics Acceleration 3) peripheral. The RGA3 register description of the TRM already states that the bit must be set to 1. The vendor kernel sets the bit unconditionally to 1 to fix VOP (Video Output Processor) screen black issues. This patch squashes the 2 vendor kernel commits with the following commit messages: Master fetch data and cpu update page table may work in parallel, may have the following procedure: master cpu fetch dte update page tabl | | (make dte invalid) <- zap iotlb entry | | fetch dte again (make dte invalid) <- zap iotlb entry | | fetch dte again (make dte invalid) <- zap iotlb entry | | fetch dte again (make iommu block) <- zap iotlb entry New iommu version has the above bug, if fetch dte consecutively four times, then it will be blocked. Fortunately, we can set bit 31 of register MMU_AUTO_GATING to 1 to make it work as old version which does not have this issue. This issue only appears on RV1126 so far, so make a workaround dedicated to "rockchip,rv1126" machine type. iommu/rockchip: fix vop blocked and screen black on RK356X and RK3588 RK3568 and RK3588 has the same issue as RV1126/RV1109 that caused by dte fetch time limit, So we can set BIT(31) of register 0x24 default to 1 as a workaround. Signed-off-by: Simon Xue <xxm@rock-chips.com> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de> Acked-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-02HID: Input: Add battery list cleanup with devm actionRafael Passos
The batteries list (hdev->batteries) is not cleaned up during hidinput_disconnect(), but struct hid_battery entries are allocated with devm_kzalloc. When a driver is unbound (e.g. during devicereprobe), devm frees those entries while their list_head nodesremain dangling in hdev->batteries, which persists across rebinds. Link: https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/ Fixes: 4a58ae85c3f9 ("HID: input: Add support for multiple batteries per device") Signed-off-by: Rafael Passos <rafael@rcpassos.me> Acked-by: Lucas Zampieri <lcasmz54@gmail.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-06-02drm/imx: Fix three kernel-doc warnings in dcss-scaler.cYicong Hui
Fix the following W=1 kerneldoc warnings by adding the missing parameter descriptions for @phase0_identity and @nn_interpolation in dcss_scaler_filter_design() and @phase0_identity in dcss_scaler_gaussian_filter() Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:173 function parameter 'phase0_identity' not described in 'dcss_scaler_gaussian_filter' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'phase0_identity' not described in 'dcss_scaler_filter_design' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'nn_interpolation' not described in 'dcss_scaler_filter_design' Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by: Yicong Hui <yiconghui@gmail.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patch.msgid.link/20260406180013.2442096-1-yiconghui@gmail.com Signed-off-by: Liu Ying <victor.liu@nxp.com>
2026-06-02clk: spacemit: k3: Add PCIe DBI clockYixun Lan
Add PCIe DBI (Data Bus Interface) clock which was missing, This will support PCIe driver to explicitly request and enable all clocks that needed. Link: https://patch.msgid.link/20260511-06-pci-clk-fix-v2-4-c9a5e563bab3@kernel.org Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-06-02clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clockYixun Lan
According to SpacemiT updated docs, the PCIe master and slave clock's parent is the pll2_d6 clock, so fix it. Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Link: https://patch.msgid.link/20260511-06-pci-clk-fix-v2-1-c9a5e563bab3@kernel.org Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-06-02accel/ivpu: Add buffer overflow check in MS get_info_ioctlAndrzej Kacprowski
Add validation that the info size returned from the metric stream info query is not exceeded when checked against the allocated buffer size. If the firmware returns a size larger than the buffer, reject the operation with -EOVERFLOW instead of proceeding with an incorrect buffer copy. Fixes: cdfad4db7756 ("accel/ivpu: Add NPU profiling support") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20260529120841.135852-1-andrzej.kacprowski@linux.intel.com
2026-06-02accel/ivpu: Add bounds checks for firmware log indicesAndrzej Kacprowski
Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices. Fixes: 1fc1251149a7 ("accel/ivpu: Refactor functions in ivpu_fw_log.c") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20260529115842.135378-1-andrzej.kacprowski@linux.intel.com
2026-06-02accel/ivpu: Add bounds check for firmware runtime memoryAndrzej Kacprowski
Validate that the firmware runtime memory specified in the image header is properly aligned and sized to hold the firmware image. This prevents errors during memory allocation and image transfer. Fixes: 2007e210b6a1 ("accel/ivpu: Split FW runtime and global memory buffers") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20260529120853.135876-1-andrzej.kacprowski@linux.intel.com
2026-06-01Input: userio - allow setting other id valuesVicki Pfau
Previously, only the type value was settable. The proto value is used internally for choosing the right drivers, so we should expose it. The other values make sense to expose as well. Signed-off-by: Vicki Pfau <vi@endrift.com> Link: https://patch.msgid.link/20260522015040.3953472-2-vi@endrift.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-01Input: userio - update maintainer nameVicki Pfau
She's been committing under the name Lyude Paul for a while Signed-off-by: Vicki Pfau <vi@endrift.com> Link: https://patch.msgid.link/20260522015040.3953472-1-vi@endrift.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-02platform/chrome: Prevent build for big-endian systemsThomas Weißschuh
Both ARM and ARM64 which are a dependency for CHROME_PLATFORMS have seldomly used big-endian variants. The ChromeOS EC framework and drivers are written under the assumption that they will be running on a little-endian systems. Code which would be broken on big-endian can be found trivially. Some examples: cros_ec.c: suspend_params.sleep_timeout_ms = ec_dev->suspend_timeout_ms cros_ec_debugfs.c: resp->time_since_ec_boot_ms cros_ec_wdt.c: arg.req.reboot_timeout_sec = wdd->timeout Prevent the build for big-endian systems. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20260531-cros-big-endian-v1-2-0cc90f39c636@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-06-02platform/chrome: Remove superfluous dependencies from CROS_ECThomas Weißschuh
CROS_EC depends on CHROME_PLATFORMS which already declares these dependencies. Remove the duplication. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20260531-cros-big-endian-v1-1-0cc90f39c636@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-06-01net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flagMinda Chen
Add default disable split header flag in all the starfive soc. Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260527084108.121416-5-minda.chen@starfivetech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: stmmac: starfive: Add jhb100 SGMII interfaceMinda Chen
Add jhb100 compatible and SGMII support. jhb100 soc contains 2 SGMII interfaces and integrated with serdes PHY. SGMII with split TX/RX MAC clock and need to set 2.5M/25M/125M TX/RX clock rate in 10M/100M/1000M speed mode. Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Reviewed-by: Sai Krishna <saikrishnag@marvell.com> Link: https://patch.msgid.link/20260527084108.121416-4-minda.chen@starfivetech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01Merge tag 'for-7.1/dm-fixes-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fix from Mikulas Patocka: - fix race condition in dm-cache-policy-smq * tag 'for-7.1/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm cache policy smq: check allocation under invalidate lock
2026-06-01net: lan743x: avoid netdev-based logging before netdev registrationDavid Thompson
This patch updates the lan743x driver to prevent the use of netdev-based logging APIs (such as netdev_dbg) before the network device has been successfully registered. Using netdev-based logging prior to registration results in log messages referencing "(unnamed net_device) (uninitialized)", which can be confusing and less informative. The driver must use netif_msg_ APIs and device-based logging (e.g. dev_dbg) until netdev registration is complete. This ensures log entries are associated with the correct device context and improves log clarity. After registration, netdev-based logging APIs can be used safely. Signed-off-by: David Thompson <davthompson@nvidia.com> Link: https://patch.msgid.link/20260528165017.421576-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01Merge tag 'auxdisplay-v7.2-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay Pull auxdisplay updates from Andy Shevchenko: - Fix potential out-of-bound access in line-display library - Miscellaneous refactoring and cleaning up [ Andy says this could easily be delayed until 7.2, but it's _so_ tiny that it's more work for me to schedule it for later than to just take it now, and just doesn't seem worth delaying - Linus ] * tag 'auxdisplay-v7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay: auxdisplay: Kconfig: drop unneeded quotes in PANEL_BOOT_MESSAGE dep auxdisplay: line-display: fix OOB read on zero-length message_store() auxdisplay: max6959: use regmap_assign_bits() in max6959_enable()
2026-06-01net: txgbe: fix phylink leak on AML init failureChenguang Zhao
Destroy the phylink instance when fixed-link setup fails. Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20260528013258.129146-1-zhaochenguang@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: fec_mpc52xx_phy: Add missing MODULE_DESCRIPTION()Rosen Penev
Fixes error during modpost: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/net/ethernet/freescale/fec_mpc52xx_phy.o Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260527025139.10188-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: wwan: t7xx: Add delay between MD and SAP suspendJose Ignacio Tornos Martinez
SAP (Service Access Point) suspend occasionally times out with error -110 (ETIMEDOUT), followed by modem port errors and complete modem failure requiring a system reboot to recover. Error symptoms: mtk_t7xx 0000:72:00.0: [PM] SAP suspend error: -110 mtk_t7xx 0000:72:00.0: can't suspend (...returned -110) mtk_t7xx 0000:07:00.0: Failed to send skb: -22 mtk_t7xx 0000:07:00.0: Write error on MBIM port, -22 The modem firmware needs time after receiving the MD (modem) suspend request to complete internal operations before it is ready to accept the SAP suspend request. Without this delay, if runtime PM attempts to suspend while the firmware is busy, the SAP suspend command times out, leaving the modem in an unrecoverable state. Root cause and userspace interaction: ModemManager 1.24+ includes changes that reduce the likelihood of this issue by ensuring the modem is in a low-power state before the kernel attempts runtime suspend. However, the kernel driver should not depend on specific userspace behavior or ModemManager versions. Older versions (1.20-1.22) are still widely deployed, and the kernel should be robust regardless of userspace implementation details. There appears to be no hardware status register or other mechanism available to query whether the firmware is ready for SAP suspend. A delay between the two suspend requests is the most reliable solution found through testing. Add a 50ms delay between MD suspend and SAP suspend. This gives the firmware adequate time to complete internal operations without adding significant latency to the suspend path. This makes the driver robust across all ModemManager versions and system conditions. Testing: 96+ hours of continuous operation with ModemManager 1.20.2 and Fibocom FM350-GL modem. Zero SAP suspend timeouts observed across 2000+ successful suspend/resume cycles. Previously failed within 24 hours with 100% reproducibility. Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260527061451.12710-1-jtornosm@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2cPetr Wozniak
The "OEM"/"SFP-10G-T" quirk entry in sfp_fixup_rollball_cc() unconditionally forces MDIO_I2C_ROLLBALL for all modules matching that vendor/part-number combination. This works for modules that genuinely implement a RollBall I2C-to-MDIO bridge, but silently breaks modules that share the same EEPROM strings without having such a bridge. The Realtek RTL8261BE-CG is one such module: a pure copper 10G SFP+ media converter with no I2C-to-MDIO bridge. Its EEPROM reports vendor="OEM", part="SFP-10G-T-I", and -- critically -- Vendor OUI 00:00:00, making OUI-based differentiation impossible. With MDIO_I2C_ROLLBALL forced, the module silently ACKs the unlock password write, the MDIO bus is created, but no PHY responds; the SFP state machine cycles through the RollBall PHY-probe retry window before reporting no PHY. Move the probe into i2c_mii_init_rollball() in mdio-i2c.c, where the RollBall protocol constants are already defined. After sending the unlock password, issue a CMD_READ and poll for CMD_DONE up to 200 ms (10 x 20 ms, matching the existing rollball poll tolerance). A genuine RollBall bridge asserts CMD_DONE within that window; modules without a bridge never do, so i2c_mii_init_rollball() returns -ENODEV. mdio_i2c_alloc() propagates -ENODEV to the caller to signal that no bridge is present and PHY probing should be skipped. sfp_sm_add_mdio_bus() catches -ENODEV and transitions sfp->mdio_protocol to MDIO_I2C_NONE so the rest of the state machine skips PHY probing for this module. Any I2C-level error (NACK, timeout) during the probe is also treated as -ENODEV: if the module does not respond at I2C address 0x51 at all, there is certainly no RollBall bridge there, and SFP initialization should not abort. The probe writes are safe with respect to SFP EEPROM integrity: only modules explicitly listed in the quirk table enter this path, and the RollBall password unlock write to 0x51 was already issued by i2c_mii_init_rollball() before the probe for all such modules. Any module without a device at 0x51 NACKs the transfer and is treated as -ENODEV. Add "OEM"/"SFP-10G-T-I" to the quirk table so RTL8261BE modules enter the probe path; genuine RollBall modules continue to work as before. Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260527053909.2118-1-petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01mv88e6xxx: Add SERDES Support for mv88e6321Fidan Aliyeva
Add serdes and pcs_ops functions for mv88e6321. In mv88e6321 2 ports support serdes functionality; port 0 and port 1. These ports are serdes-only ports. Changes: 1. Add a function support to return the lane address for the port based on cmode. 2. Reuse mv88e6352's serdes_get_regs* and pcs_init functions for mv88e6321. Tested on mv88e6321 switch port 0. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260528210310.1365858-4-fidan.aliyeva.ext@ericsson.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01mv88e6xxx: Refactor 6352's serdes functionsFidan Aliyeva
Changes: 1. Replace serdes check by mv88e6352_g2_scratch_port_has_serdes in mv88e6352_pcs_init function by mv88e6xxx_serdes_get_lane function making it more generic. 2. Replace serdes checks in mv88e6352_serdes_get_* functions with mv88e6xxx_serdes_get_lane making them more generic. 3. Add lane argument to mv88e6352_serdes_read so it can be reused later for 6321. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260528210310.1365858-3-fidan.aliyeva.ext@ericsson.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01mv88e6xxx: Add mv88e6352_serdes_get_laneFidan Aliyeva
Changes: 1. Add mv88e6352_serdes_get_lane function which checks if the port supports SERDES by calling mv88e6352_g2_scratch_port_has_serdes. Then returns the address of the SERDES lane. 2. Add this function as .serdes_get_lane member to all the chip versions which use mv88e6352_pcs_init. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260528210310.1365858-2-fidan.aliyeva.ext@ericsson.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: mdio: realtek-rtl9300: use command runner for read_c22()Markus Stockhausen
Convert the final missing read_c22() path to the new read enabled command runner. Do it the same way as other implementations. - bus calls otto_emdio_read_c22() - this hands over to SoC specific otto_emdio_9300_read_c22() - finally the registers are filled and the runner issued With this cleanup remove the obsolete helper otto_emdio_wait_ready() Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260527163449.1294961-5-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: mdio: realtek-rtl9300: use command runner for read_c45()Markus Stockhausen
Convert the read_c45() path to the new command runner. This needs the additional helper otto_emdio_read_cmd() that can issue the command runner and process a read operation. It is basically nothing more than - run the command - read the command result thorugh the I/O register With this in place convert the read_c45() like the alread existing write C22/C45 implementation. - bus calls otto_emdio_read_c45() - this handed over to SoC specific otto_emdio_9300_read_c45() - the registers are filled - the otto_emdio_read_cmd() is issued - that calls the command runner Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260527163449.1294961-4-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: mdio: realtek-rtl9300: use command runner for write_c22()Markus Stockhausen
Now that the driver has a generic command runner make use of it in the write_c22() path. For this. - add generic otto_emdio_write_c22() helper that will be called by bus - convert otto_emdio_9300_write_c22() to new command runner logic Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260527163449.1294961-3-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01net: mdio: realtek-rtl9300: provide generic command runnerMarkus Stockhausen
The current bus read/write commands for C22/C45 are RTL930x specific. Avoid to duplicate those 200 lines of code for the RTL838x, RTL839x and RTL931x targets. Instead provide a generic command runner that is SoC independent. The implementation works as follows: The runner will take a prepared list of the four MDIO registers. It will feed the data into the registers. This generic write to all registers (or to say "a little bit too much") is no issue. The hardware looks at the to be executed command and will only take the pieces of data that are really required. No side effects have been observed on any of the four SoCs during the time this mechanism exists in downstream OpenWrt. The last fed register is the C22/command register. This will be enriched with the proper command flags from the caller. The hardware issues the command and the runner will wait for its finalization. Besides from feeding all registers the runner emulates the behaviour of the old code as best as possible - check defensively for a running command in advance - Before this commit the driver had different MMIO timeout values. 1000s for command preparation, 100us after writes and 1000us after reads. The new version uses a consistent 1000us timeout for all of these. - return -ENXIO in case of hardware failure (fail bit) As a first consumer of this runner convert the write_c45() function. This is realized in a multi stage approach - a generic otto_emdio_write_c45() will be called by the bus - this will forward the request to the device specific writer. In this case otto_emdio_9300_write_c45(). - There the command data is filled in and the additional helper otto_emdio_write_cmd() will be called - That adds the write flag and issues the generic command runner. With all the above mentioned in place, there is not much left to do in otto_emdio_9300_write_c45(). It just fills the register fields and calls the write helper with the right command bits. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260527163449.1294961-2-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-01scsi: ufs: Remove redundant vops NULL check and trivial wrapperChanwoo Lee
ufshcd_variant_hba_init/exit() check 'if (!hba->vops)' before calling vops wrappers, but the wrappers already do NULL check internally. Remove the redundant checks. Also remove ufshcd_variant_hba_exit() entirely since it only wraps ufshcd_vops_exit() with no added value. Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260529061623.301291-1-cw9316.lee@samsung.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: ufs: Remove unnecessary return in void vops wrappersChanwoo Lee
ufshcd_vops_exit(), ufshcd_vops_setup_task_mgmt(), and ufshcd_vops_hibern8_notify() use 'return hba->vops->xxx()' while other void vops wrappers call without return. Remove the unnecessary return keywords for consistency. Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260529061503.301182-1-cw9316.lee@samsung.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: ufs: Fix wrong value printed in unexpected UPIU response caseChanwoo Lee
In ufshcd_transfer_rsp_status(), the default case of the inner switch statement prints the UPIU response code when an unexpected response is received. However, the code was printing 'result' variable which is always 0 at that point, making the error message useless for debugging. Fix this by printing the actual UPIU response code returned by ufshcd_get_req_rsp(). Fixes: 08108d31129a ("scsi: ufs: Improve type safety") Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260527092134.275887-1-cw9316.lee@samsung.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: ufs: core: Fix NULL pointer dereference in scsi_cmd_priv() callsChanwoo Lee
ufshcd_tag_to_cmd() may return NULL if no command is associated with the given tag. However, several callers dereference the returned cmd pointer via scsi_cmd_priv() without checking for NULL first, leading to a potential NULL pointer dereference. Fix this by adding NULL checks for cmd before calling scsi_cmd_priv() and moving the lrbp initialization after the NULL check. Signed-off-by: Chanwoo Lee <cw9316.lee@samsung.com> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260529010739.295391-1-cw9316.lee@samsung.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: megaraid_mbox: Avoid double kfree()Arnd Bergmann
Smatch found a double-free after my recent change: drivers/scsi/megaraid/megaraid_mbox.c:3474 megaraid_cmm_register() error: double free of 'adp' (line 3468) Since the object is no longer allocated in megaraid_cmm_register(), remove the kfree() as well. Fixes: c1f7275b613b ("scsi: megaraid_mbox: Reduce stack usage in megaraid_cmm_register()") Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260601210216.846809-1-arnd@kernel.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: pm8001: Fix error code in non_fatal_log_show()Dan Carpenter
The non_fatal_log_show() function is supposed to return negative error codes on failure. But because the error codes are saved in a u32 and then cast to signed long, they end up being high positive values instead of negative. Remove the intermediary u32 variable to fix this bug. Fixes: dba2cc03b9db ("scsi: pm80xx: sysfs attribute for non fatal dump") Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Jack Wang <jinpu.wang@ionos.com> Link: https://patch.msgid.link/ahs-bEsBJH0KhnsX@stanley.mountain Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: lpfc: Turn lpfc_queue q_pgs into a flexible arrayRosen Penev
The q_pgs pointer was assigned to point at the trailing memory allocated past the struct. Convert it to a proper C99 flexible array member and use struct_size() for the allocation. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Justin Tee <justin.tee@broadcom.com> Link: https://patch.msgid.link/20260523050241.190239-1-rosenp@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: ufs: core: Skip link param validation when lanes_per_direction is unsetDaejun Park
ufshcd_validate_link_params(), added by commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link"), is called unconditionally from ufshcd_link_startup() and fails link startup with -ENOLINK when the connected lane count read from the device differs from hba->lanes_per_direction. lanes_per_direction is only set by ufshcd-pltfrm (default 2, or the "lanes-per-direction" devicetree property); ufshcd-pci controllers (e.g. Intel) leave it 0. As the device always reports >= 1 connected lanes, the check can never match and link startup always fails. Reproduced with QEMU's UFS device. Skip the check when lanes_per_direction is unset: with no expected value to validate against, restore the behaviour from before that commit. Fixes: e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link") Signed-off-by: Daejun Park <daejun7.park@samsung.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260520070009epcms2p6542f3abb7660839e9d8140b3f2f145c3@epcms2p6 Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: sas: Skip opt_sectors when DMA reports no real optimization hintIonut Nechita
sas_host_setup() unconditionally sets shost->opt_sectors from dma_opt_mapping_size(). When the IOMMU is disabled or in passthrough mode and no DMA ops provide an opt_mapping_size callback, dma_opt_mapping_size() returns min(dma_max_mapping_size(), SIZE_MAX) which equals dma_max_mapping_size() — a hard upper bound, not an optimization hint. On a Dell PowerEdge R750 with mpt3sas (Broadcom SAS3816, FW 33.15.00.00) and intel_iommu=off the following values are observed: dma_opt_mapping_size() = dma_max_mapping_size() (no real hint) shost->max_sectors = 32767 opt_sectors = min(32767, huge >> 9) = 32767 optimal_io_size = 32767 << 9 = 16776704 → round_down(16776704, 4096) = 16773120 The SAS disk (SAMSUNG MZILT800HBHQ0D3) does not report an Optimal Transfer Length in VPD page B0, so sdkp->opt_xfer_blocks remains 0. sd_revalidate_disk() then uses min_not_zero(0, opt_sectors) = opt_sectors, propagating the bogus value into the block device's optimal_io_size (visible as OPT-IO = 16773120 in lsblk --topology). mkfs.xfs picks up optimal_io_size and minimum_io_size and computes: swidth = 16773120 / 4096 = 4095 sunit = 8192 / 4096 = 2 Since 4095 % 2 != 0, XFS rejects the geometry: SB stripe unit sanity check failed This makes it impossible to create XFS filesystems (e.g. for /var/lib/docker) during system bootstrap. Fix this by introducing a sas_dma_setup_opt_sectors() helper that sets opt_sectors only when dma_opt_mapping_size() is strictly less than dma_max_mapping_size(), indicating a genuine DMA optimization constraint. The helper computes min(opt_sectors, max_sectors) first, then rounds down to a power of two so that filesystem geometry calculations always produce clean results. When the two DMA values are equal, no backend provided a real hint, so opt_sectors stays at 0 ("no preference"). [mkp: implemented hch's suggestion] Fixes: 4cbfca5f7750 ("scsi: scsi_transport_sas: cap shost opt_sectors according to DMA optimal limit") Cc: stable@vger.kernel.org Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Ionut Nechita <ionut.nechita@windriver.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260519135238.373784-2-ionut.nechita@windriver.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: Revert "scsi: Fix sas_user_scan() to handle wildcard and multi-channel ↵Martin Wilck
scans" This reverts commit 37c4e72b0651e7697eb338cd1fb09feef472cc1a. Said commit causes excessive resource usage and even system freeze with some controllers, e.g. smartpqi and hisi_sas. The justification provided by the patch authors [1] was supporting a special mode of the mpi3mr and mpt3sas, so-called "Tri-mode", in which NVMe drives are exposed as SCSI devices on a separate channel. While that's useful for these drivers, it seems wrong to cause major breakage for other drivers for the sake of this feature. [1] https://lore.kernel.org/linux-scsi/CAFdVvOwjy+2ORJ6uJkspiLTPF05481U7gcS4QohFOFGPqAs8ig@mail.gmail.com/ Fixes: 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans") Signed-off-by: Martin Wilck <martin.wilck@suse.com> Cc: Don Brace <don.brace@microchip.com> Cc: storagedev@microchip.com Cc: Ranjan Kumar <ranjan.kumar@broadcom.com> Cc: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Sumit Saxena <sumit.saxena@broadcom.com> Cc: mpi3mr-linuxdrv.pdl@broadcom.com Cc: MPT-FusionLinux.pdl@broadcom.com Cc: Yihang Li <liyihang9@h-partners.c> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260513174236.430465-3-mwilck@suse.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()Martin Wilck
shost_to_hba() is used everywhere except to obtain pqi_ctrl_info from shosti, except in pqi_scan_finished(), where shost_priv() is used. This causes one pointer dereference to be missed, as shost->hostdata is a pointer in smartpqi. Fix it. Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver") Signed-off-by: Martin Wilck <martin.wilck@suse.com> Reviewed-by: Don Brace <don.brace@microchip.com> Cc: Don Brace <don.brace@microchip.com> Cc: storagedev@microchip.com Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260513174236.430465-2-mwilck@suse.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-06-01RDMA/core: Validate the passed in fops for ib_get_ucaps()Jason Gunthorpe
Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs. Link: https://patch.msgid.link/r/0-v1-fd9482545e37+1e25-ib_ucaps_fd_ops_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: 61e51682816d ("RDMA/uverbs: Introduce UCAP (User CAPabilities) API") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-01nvdimm: Use sysfs_emit() for cpumask show callbackYury Norov
nvdimm_pmu_cpumask_show() is a sysfs show callback. Use sysfs_emit() and cpumask_pr_args() to emit the mask. This prepares for removing cpumap_print_to_pagebuf(). Signed-off-by: Yury Norov <ynorov@nvidia.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260528183625.870813-12-ynorov@nvidia.com Signed-off-by: Alison Schofield <alison.schofield@intel.com>