summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-01-22mfd: axp20x: AXP717: Add type-C CC registersChen-Yu Tsai
The AXP717 has some extra registers related to type-C CC pin negotiation. They were missing from the original submission. Add them for completeness. Signed-off-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251225080241.3153453-1-wens@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: core: Simplify storing device_node in mfd_match_of_node_to_dev()Krzysztof Kozlowski
of_node_get() returns the same pointer it received and canonical form of storing device_node is to use of_node_get() in the assignment. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224124456.208529-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: core: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224124456.208529-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: tps65219: Implement LOCK register handling for TPS65214Kory Maincent (TI.com)
The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently. This approach is justified because: - Register locking is very uncommon in typical system operation - No code path is expected to lock the registers during runtime - Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently Cc: stable@vger.kernel.org Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Reviewed-by: Andrew Davis <afd@ti.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20251218-fix_tps65219-v5-1-8bb511417f3a@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: atmel-hlcdc: Add compatible for sama7d65 XLCD controllerRyan Wanner
Add compatible for sama7d65 XLCD controller. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://patch.msgid.link/20251218040521.463937-2-manikandan.m@microchip.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: max77759: Drop use of irqd_get_trigger_typeAndré Draszik
irqd_get_trigger_type() is meant for cases where the driver needs to know the configured IRQ trigger type and e.g. wants to change its behaviour accordingly. Furthermore, platform support code, e.g. DT handling, will configure the hardware based on that, and drivers don't need to pass the trigger type into request_irq() and friends. Drop the use from this driver, as it doesn't need to know the trigger type. Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20251217-max77759-mfd-irq-trigger-v1-1-e7d29f84d34f@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: macsmc: Wire up Apple SMC input subdeviceJames Calligeros
Add the new SMC input function to the mfd device Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Link: https://patch.msgid.link/20251215-macsmc-subdevs-v6-5-0518cb5f28ae@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: macsmc: Wire up Apple SMC hwmon subdeviceJames Calligeros
Add the SMC hwmon functionality to the mfd device Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Link: https://patch.msgid.link/20251215-macsmc-subdevs-v6-3-0518cb5f28ae@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: macsmc: Wire up Apple SMC RTC subdeviceJames Calligeros
Add the new SMC RTC function to the mfd device Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Link: https://patch.msgid.link/20251215-macsmc-subdevs-v6-2-0518cb5f28ae@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() ↵Haotian Zhang
failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources. Fixes: 1c1c6bba57f5 ("mfd: wm5102: Ensure we always boot the device fully") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20251214145804.2037-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: core: Add locking around 'mfd_of_node_list'Douglas Anderson
Manipulating a list in the kernel isn't safe without some sort of mutual exclusion. Add a mutex any time we access / modify 'mfd_of_node_list' to prevent possible crashes. Cc: stable@vger.kernel.org Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20251210113002.1.I6ceaca2cfb7eb25737012b166671f516696be4fd@changeid Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: core: Improve compile coverage of mfd_match_of_node_to_dev()Geert Uytterhoeven
As of commit c7fe3bbfd622b5ee ('mfd: core: Use of_property_read_reg() to parse "reg"'), all code in mfd_match_of_node_to_dev() compiles fine when CONFIG_OF is disabled. As the sole caller of this function is protected by IS_ENABLED(CONFIG_OF), the #ifdef inside the function can be removed to increase build coverage, without impacting code size. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/7b9a4a355c5da3fe812ead663285d05b64b84857.1764320964.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22Revert "mfd: da9052-spi: Change read-mask to write-mask"Marcus Folkesson
This reverts commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed. Almost every register in this chip can be customized via OTP memory. Somehow the value for R19, which decide if the flag is set on read or write operation, seems to have been overwritten for the chip the original patch were written for. Revert the change to follow the default behavior. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://patch.msgid.link/20251124-da9052-revert-v1-1-fbeb2c894002@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22Merge branches 'ib-mfd-clk-gpio-power-regulator-rtc-6.20', ↵Lee Jones
'ib-mfd-regulator-6.20' and 'ib-mfd-rtc-6.20' into ibs-for-mfd-merged
2026-01-22mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse()Zilin Guan
The function mtd_parser_tplink_safeloader_parse() allocates buf via mtd_parser_tplink_safeloader_read_table(). If the allocation for parts[idx].name fails inside the loop, the code jumps to the err_free label without freeing buf, leading to a memory leak. Fix this by freeing the temporary buffer buf in the err_free label. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 00a3588084be ("mtd: parsers: add TP-Link SafeLoader partitions table parser") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22mtd: jedec_probe: fix shift-out-of-bounds UB in JEDEC ID maskingChenxi Hou
UBSAN reports shift-out-of-bounds in jedec_read_mfr() and jedec_read_id():   UBSAN: shift-out-of-bounds in drivers/mtd/chips/jedec_probe.c:1924:13   shift exponent 32 is too large for 32-bit type 'int'   UBSAN: shift-out-of-bounds in drivers/mtd/chips/jedec_probe.c:1940:12   shift exponent 32 is too large for 32-bit type 'int' The JEDEC manufacturer/device ID masking uses:   (1 << (cfi->device_type * 8)) - 1 When cfi->device_type is 4, this evaluates to 1 << 32. Since the literal '1' has type int, this is a 32-bit shift and is undefined behavior. Fix it by using a 64-bit literal (1ULL) so the shift is performed in a 64-bit type. Co-developed-by: Hui Peng <benquike@gmail.com> Signed-off-by: Hui Peng <benquike@gmail.com> Co-developed-by: Zhihao Yao (Zephyr) <zhihao.yao@njit.edu> Signed-off-by: Zhihao Yao (Zephyr) <zhihao.yao@njit.edu> Signed-off-by: Chenxi Hou <ch395@njit.edu> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22i2c: designware: Remove an unnecessary conditionHeikki Krogerus
Writing also the high speed timing registers unconditionally. The reset value for these registers is 0, so this should always be safe. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-5-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Enable mode swappingHeikki Krogerus
The DesignWare I2C can not be operated as I2C master and I2C slave simultaneously, but that does not actually mean master and slave modes can not be supported at the same time. It just means an explicit mode swap needs to be executed when the mode is changed. The DesignWare I2C documentation actually describes a couple of cases where the mode is excepted to be changed. The I2C master will now always be supported. Both modes are now always configured in i2c_dw_configure(), but the slave mode will continue to be available only when the Kconfig option I2C_SLAVE is enabled. The driver will now start in master mode and then swap to slave mode when a slave device is registered. After a slave device is registered, the controller is swapped to master mode when a transfer in master mode is started and then back to slave mode again after the transfer is completed. The DesignWare I2C can now be used with protocols such as MCTP (drivers/net/mctp/mctp-i2c.c) and IPMI (drivers/char/ipmi/) that require support for both I2C master and I2C slave. It is now also possible to support the SMBus Host Notification Protocol as I2C master if needed. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-4-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Combine the init functionsHeikki Krogerus
Providing a single function for controller initialisation. The controller initialisation has the same steps for master and slave modes, except the timing parameters are only needed in master mode. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-3-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Combine some of the common functionsHeikki Krogerus
The adapter can be registered just in the core instead of separately in the master and slave drivers. The same applies to the interrupt. The dedicated "target only" (slave only) configuration for this controller will be removed so that host mode (master mode) will always be supported together with the target mode. Therefore the descrption for the "target only" configuration that appears in the "name" sysfs attribute file is also dropped while at it. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-2-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Use device_is_compatible() instead of custom approachAndy Shevchenko
We use MODEL_MSCC_OCELOT effectively as a flag for comparing against "compatible" property. Use device_is_compatible() directly to make it clear. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260114081954.252160-3-andriy.shevchenko@linux.intel.com
2026-01-22i2c: spacemit: drop IRQF_ONESHOT flag from IRQ requestYixun Lan
In commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler")[1], it will check IRQF_ONESHOT flag in IRQ request, and gives a warning if there is no threaded handler. Drop this flag to fix this warning. Link: https://lore.kernel.org/r/20260112134013.eQWyReHR@linutronix.de/ [1] Fixes: 5ea558473fa3 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Yixun Lan <dlan@kernel.org> Cc: <stable@vger.kernel.org> # v6.15+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260122-05-k1-i2c-irq-v1-1-9b8d94bbcd22@kernel.org
2026-01-22net: atp: drop ancient parallel-port Ethernet driverEthan Nelson-Moore
This driver is old and almost certainly entirely unused. The two other parallel port Ethernet drivers (de600/de620) were removed by Paul Gortmaker in commit 168e06ae26dd ("drivers/net: delete old parallel port de600/de620 drivers"), but this driver remained. Drop it - Paul's reasoning applies here as well. To quote him: "The parallel port is largely replaced by USB [...] Let us not pretend that anyone cares about these drivers anymore, or worse - pretend that anyone is using them on a modern kernel." Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Acked-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260121084532.60606-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22mmc: sdhci-of-dwcmshc: Fix DMA 128MB boundary for Eswin EIC7700Huan He
This DWC MSHC has a 128MB limitation where the data buffer size and start address must not exceed the 128MB boundary. Registering the missing 'adma_write_desc' callback function. Signed-off-by: Huan He <hehuan1@eswincomputing.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 32b2633219d3 ("mmc: sdhci-of-dwcmshc: Add support for Eswin EIC7700") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-01-22mmc: sdhci-of-dwcmshc: Fix init for AXI clock for Eswin EIC7700Huan He
Accessing the High-Speed registers requires the AXI clock to be enabled. Signed-off-by: Huan He <hehuan1@eswincomputing.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 32b2633219d3 ("mmc: sdhci-of-dwcmshc: Add support for Eswin EIC7700") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-01-22net: fec: account for VLAN header in frame length calculationsClemens Gruber
The MAX_FL (maximum frame length) and related calculations used ETH_HLEN, which does not account for the 4-byte VLAN tag in tagged frames. This caused the hardware to reject valid VLAN frames as oversized, resulting in RX errors and dropped packets. Use VLAN_ETH_HLEN instead of ETH_HLEN in the MAX_FL register setup, cut-through mode threshold, buffer allocation, and max_mtu calculation. Cc: stable@kernel.org # v6.18+ Fixes: 62b5bb7be7bc ("net: fec: update MAX_FL based on the current MTU") Fixes: d466c16026e9 ("net: fec: enable the Jumbo frame support for i.MX8QM") Fixes: 59e9bf037d75 ("net: fec: add change_mtu to support dynamic buffer allocation") Fixes: ec2a1681ed4f ("net: fec: use a member variable for maximum buffer size") Signed-off-by: Clemens Gruber <mail@clemensgruber.at> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260121083751.66997-1-mail@clemensgruber.at Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22xen/netfront: Use u64_stats_t with u64_stats_sync properlyDavid Yang
On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260121082550.2389249-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: ifb: use u64_stats_t with u64_stats_sync properlyDavid Yang
On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260121082348.2388314-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22drm/xe: Select CONFIG_DEVICE_PRIVATE when DRM_XE_GPUSVM is selectedThomas Hellström
CONFIG_DEVICE_PRIVATE is a prerequisite for DRM_XE_GPUSVM. Explicitly select it so that DRM_XE_GPUSVM is not unintentionally left out from distro configs not explicitly enabling CONFIG_DEVICE_PRIVATE. v2: - Select also CONFIG_ZONE_DEVICE since it's needed by CONFIG_DEVICE_PRIVATE. v3: - Depend on CONFIG_ZONE_DEVICE rather than selecting it. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260121091048.41371-3-thomas.hellstrom@linux.intel.com (cherry picked from commit 9386f49316074d2d76fd78d6bd359996de42fb7f) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-22net: bonding: add the READ_ONCE/WRITE_ONCE for outside lock accessingTonghao Zhang
Although operations on the variable send_peer_notif are already within a lock-protected critical section, there are cases where it is accessed outside the lock. Therefore, READ_ONCE() and WRITE_ONCE() should be added to it. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/c1dcc53442f4d0f67beb9e0a3e7a7a6a2c94c47f.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: bonding: skip the 2nd trylock when first one failTonghao Zhang
After the first trylock fail, retrying immediately is not advised as there is a high probability of failing to acquire the lock again. This optimization makes sense. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/9aba44f02163e8fe8dbaba63ff2df921bc2b114e.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: bonding: move bond_should_notify_peers, e.g. into rtnl lock blockTonghao Zhang
This patch tries to avoid the possible peer notify event loss. In bond_mii_monitor()/bond_activebackup_arp_mon(), when we hold the rtnl lock: - check send_peer_notif again to avoid unconditionally reducing this value. - send_peer_notif may have been reset. Therefore, it is necessary to check whether to send peer notify via bond_should_notify_peers() to avoid the loss of notification events. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/78cef328822b94638c97638b89011c507b8bf19e.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: bonding: use workqueue to make sure peer notify updated in lacp modeTonghao Zhang
The rtnl lock might be locked, preventing ad_cond_set_peer_notif() from acquiring the lock and updating send_peer_notif. This patch addresses the issue by using a workqueue. Since updating send_peer_notif does not require high real-time performance, such delayed updates are entirely acceptable. In fact, checking this value and using it in multiple places, all operations are protected at the same time by rtnl lock, such as - read send_peer_notif - send_peer_notif-- - bond_should_notify_peers By the way, rtnl lock is still required, when accessing bond.params.* for updating send_peer_notif. In lacp mode, resetting send_peer_notif in workqueue is safe, simple and effective way. Additionally, this patch introduces bond_peer_notify_may_events(), which is used to check whether an event should be sent. This function will be used in both patch 1 and 2. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> Suggested-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/f95accb5db0b10ce3ed2f834fc70f716c9abbb9c.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATEThomas Hellström
CONFIG_DEVICE_PRIVATE is not selected by default by some distros, for example Fedora, and that leads to a regression in the xe driver since userptr support gets compiled out. It turns out that DRM_GPUSVM, which is needed for xe userptr support compiles also without CONFIG_DEVICE_PRIVATE, but doesn't compile without CONFIG_ZONE_DEVICE. Exclude the drm_pagemap files from compilation with !CONFIG_ZONE_DEVICE, and remove the CONFIG_DEVICE_PRIVATE dependency from CONFIG_DRM_GPUSVM and the xe driver's selection of it, re-enabling xe userptr for those configs. v2: - Don't compile the drm_pagemap files unless CONFIG_ZONE_DEVICE is set. - Adjust the drm_pagemap.h header accordingly. Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.18+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/20260121091048.41371-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 1e372b246199ca7a35f930177fea91b557dac16e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-22PCI: dwc: Use multiple iATU windows for mapping large bridge windows and DMA ↵Samuel Holland
ranges The DWC driver tries to use a single iATU region for mapping the individual entries of the bridge window and DMA range. If a bridge window/DMA range is larger than the iATU inbound/outbound window size, then the mapping will fail. Hence, avoid this failure by using multiple iATU windows to map the whole region. If the region runs out of iATU windows, then return failure. Signed-off-by: Charles Mirabile <cmirabil@redhat.com> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Co-developed-by: Randolph Lin <randolph@andestech.com> Signed-off-by: Randolph Lin <randolph@andestech.com> [mani: reworded description, minor code cleanup] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Charles Mirabile <cmirabil@redhat.com> Link: https://patch.msgid.link/20260109113430.2767264-1-randolph@andestech.com
2026-01-22drm/i915/display: Fix color pipeline enum name leakChaitanya Kumar Borah
intel_color_pipeline_plane_init() allocates enum names for color pipelines, which are copied by drm_property_create_enum(). The temporary strings were not freed, resulting in a memory leak. Allocate enum names only after successful pipeline construction and free them on all exit paths. Fixes: ef105316819d ("drm/i915/color: Create a transfer function color pipeline") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260113102303.724205-5-chaitanya.kumar.borah@intel.com
2026-01-22drm/vkms: Fix color pipeline enum name leakChaitanya Kumar Borah
vkms_initialize_colorops() allocates enum names for color pipelines, which are copied by drm_property_create_enum(). The temporary strings were not freed, resulting in a memory leak. Allocate enum names only after successful pipeline construction and free them on all exit paths Fixes: c1e578bd08da ("drm/vkms: Add enumerated 1D curve colorop") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260113102303.724205-4-chaitanya.kumar.borah@intel.com
2026-01-22drm/amd/display: Fix color pipeline enum name leakChaitanya Kumar Borah
dm_plane_init_colorops() allocates enum names for color pipelines. These are eventually passed to drm_property_create_enum() which create its own copies of the string. Free the strings after initialization is done. Also, allocate color pipeline enum names only after successfully creating color pipeline. Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Alex Deucher <alexander.deucher@amd.com> #irc Link: https://patch.msgid.link/20260113102303.724205-3-chaitanya.kumar.borah@intel.com
2026-01-22drm/i915/color: Place 3D LUT after CSC in plane color pipelineChaitanya Kumar Borah
Move the 3D LUT block to its correct position in the plane color pipeline: [Pre-CSC] -> [CSC] -> [3DLUT] -> [Post-CSC] Fixes: 65db7a1f9cf7 ("drm/i915/color: Add 3D LUT to color pipeline") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260113102303.724205-2-chaitanya.kumar.borah@intel.com
2026-01-22fpga: dfl: fix typo in header fileMukesh Kumar Sisodiya
fix typo "definitons" ==> "definitions" in DFHv1 Register Offset comment. Signed-off-by: Mukesh Kumar Sisodiya <mukeshkumarsisodiya1981@gmail.com> Link: https://lore.kernel.org/r/20251226150408.2802-1-mukeshkumarsisodiya1981@gmail.com Reviewed-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
2026-01-22net: dsa: yt921x: Add LAG offloading supportDavid Yang
Add offloading for a link aggregation group supported by the YT921x switches. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260117162116.1063043-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22iommu/vt-d: Fix race condition during PASID entry replacementLu Baolu
The Intel VT-d PASID table entry is 512 bits (64 bytes). When replacing an active PASID entry (e.g., during domain replacement), the current implementation calculates a new entry on the stack and copies it to the table using a single structure assignment. struct pasid_entry *pte, new_pte; pte = intel_pasid_get_entry(dev, pasid); pasid_pte_config_first_level(iommu, &new_pte, ...); *pte = new_pte; Because the hardware may fetch the 512-bit PASID entry in multiple 128-bit chunks, updating the entire entry while it is active (Present bit set) risks a "torn" read. In this scenario, the IOMMU hardware could observe an inconsistent state — partially new data and partially old data — leading to unpredictable behavior or spurious faults. Fix this by removing the unsafe "replace" helpers and following the "clear-then-update" flow, which ensures the Present bit is cleared and the required invalidation handshake is completed before the new configuration is applied. Fixes: 7543ee63e811 ("iommu/vt-d: Add pasid replace helpers") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260120061816.2132558-4-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22iommu/vt-d: Clear Present bit before tearing down context entryLu Baolu
When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults. While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software. 2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU. 3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry. 4. Fully zero out the entry only after the invalidation is complete. Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible. Fixes: ba39592764ed2 ("Intel IOMMU: Intel IOMMU driver") Reported-by: Dmytro Maluka <dmaluka@chromium.org> Closes: https://lore.kernel.org/all/aTG7gc7I5wExai3S@google.com/ Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Dmytro Maluka <dmaluka@chromium.org> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260120061816.2132558-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22iommu/vt-d: Clear Present bit before tearing down PASID entryLu Baolu
The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes. Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults. Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry. Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set. Fixes: 0bbeb01a4faf ("iommu/vt-d: Manage scalalble mode PASID tables") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Dmytro Maluka <dmaluka@chromium.org> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260120061816.2132558-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22iommu/vt-d: Flush piotlb for SVM and Nested domainYi Liu
Besides the paging domains that use FS, SVM and Nested domains need to use piotlb invalidation descriptor as well. Fixes: b33125296b50 ("iommu/vt-d: Create unique domain ops for each stage") Cc: stable@vger.kernel.org Signed-off-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20251223065824.6164-1-yi.l.liu@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22iommu/vt-d: Flush cache for PASID table before using itDmytro Maluka
When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized. Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency") Signed-off-by: Dmytro Maluka <dmaluka@chromium.org> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20251221123508.37495-1-dmaluka@chromium.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable modeJinhui Guo
Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions. Fixes: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Link: https://lore.kernel.org/r/20251211035946.2071-3-guojinhui.liam@bytedance.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without ↵Jinhui Guo
scalable mode PCIe endpoints with ATS enabled and passed through to userspace (e.g., QEMU, DPDK) can hard-lock the host when their link drops, either by surprise removal or by a link fault. Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") adds pci_dev_is_disconnected() to devtlb_invalidation_with_pasid() so ATS invalidation is skipped only when the device is being safely removed, but it applies only when Intel IOMMU scalable mode is enabled. With scalable mode disabled or unsupported, a system hard-lock occurs when a PCIe endpoint's link drops because the Intel IOMMU waits indefinitely for an ATS invalidation that cannot complete. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(), which calls qi_flush_dev_iotlb() and can also hard-lock the system when a PCIe endpoint's link drops. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Sometimes the endpoint loses connection without a link-down event (e.g., due to a link fault); killing the process (virsh destroy) then hard-locks the host. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput pci_dev_is_disconnected() only covers safe-removal paths; pci_device_is_present() tests accessibility by reading vendor/device IDs and internally calls pci_dev_is_disconnected(). On a ConnectX-5 (8 GT/s, x2) this costs ~70 µs. Since __context_flush_dev_iotlb() is only called on {attach,release}_dev paths (not hot), add pci_device_is_present() there to skip inaccessible devices and avoid the hard-lock. Fixes: 37764b952e1b ("iommu/vt-d: Global devTLB flush when present context entry changed") Fixes: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Link: https://lore.kernel.org/r/20251211035946.2071-2-guojinhui.liam@bytedance.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22media: uvcvideo: Pass allocation size directly to uvc_alloc_urb_bufferRicardo Ribalda
The uvc_alloc_urb_buffer() function implicitly depended on the stream->urb_size field, which was set by its caller, uvc_alloc_urb_buffers(). This implicit data flow makes the code harder to follow. More importantly, stream->urb_size was updated within the allocation loop before the allocation was confirmed to be successful. If the allocation failed, the stream object would be left with a urb_size that doesn't correspond to valid, allocated URB buffers. Refactor uvc_alloc_urb_buffer() to accept the buffer size as an explicit argument. This makes the function's dependencies clear and improves the robustness of the error handling path. The stream->urb_size is now set only after a complete and successful allocation. This is a pure refactoring and introduces no functional changes. Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Itay Chamiel <itay.chamiel@q.ai> Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-2-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-22media: uvcvideo: Fix allocation for small frame sizesRicardo Ribalda
If a frame has size of less or equal than one packet size uvc_alloc_urb_buffers() is unable to allocate memory for it due to a off-by-one error. Fix the off-by-one-error and now that we are at it, make sure that stream->urb_size has always a valid value when we return from the function, even when an error happens. Fixes: efdc8a9585ce ("V4L/DVB (10295): uvcvideo: Retry URB buffers allocation when the system is low on memory.") Reported-by: Itay Chamiel <itay.chamiel@q.ai> Closes: https://lore.kernel.org/linux-media/CANiDSCsSoZf2LsCCoWAUbCg6tJT-ypXR1B85aa6rAdMVYr2iBQ@mail.gmail.com/T/#t Co-developed-by: Itay Chamiel <itay.chamiel@q.ai> Signed-off-by: Itay Chamiel <itay.chamiel@q.ai> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Itay Chamiel <itay.chamiel@q.ai> Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-1-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-08-19 22:00:10 +0000