summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-15Linux 6.16-rc2v6.16-rc2Linus Torvalds
2025-06-15Merge tag 'kbuild-fixes-v6.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Move warnings about linux/export.h from W=1 to W=2 - Fix structure type overrides in gendwarfksyms * tag 'kbuild-fixes-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: gendwarfksyms: Fix structure type overrides kbuild: move warnings about linux/export.h from W=1 to W=2
2025-06-16gendwarfksyms: Fix structure type overridesSami Tolvanen
As we always iterate through the entire die_map when expanding type strings, recursively processing referenced types in type_expand_child() is not actually necessary. Furthermore, the type_string kABI rule added in commit c9083467f7b9 ("gendwarfksyms: Add a kABI rule to override type strings") can fail to override type strings for structures due to a missing kabi_get_type_string() check in this function. Fix the issue by dropping the unnecessary recursion and moving the override check to type_expand(). Note that symbol versions are otherwise unchanged with this patch. Fixes: c9083467f7b9 ("gendwarfksyms: Add a kABI rule to override type strings") Reported-by: Giuliano Procida <gprocida@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-06-16kbuild: move warnings about linux/export.h from W=1 to W=2Masahiro Yamada
This hides excessive warnings, as nobody builds with W=2. Fixes: a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") Fixes: 7d95680d64ac ("scripts/misc-check: check unnecessary #include <linux/export.h> when W=1") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com>
2025-06-14net: stmmac: qcom-ethqos: add ethqos_pcs_set_inband()Russell King (Oracle)
Add ethqos_pcs_set_inband() to improve readability, and to allow future changes when phylink PCS support is properly merged. Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # sa8775p-ride-r3 Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/E1uPkbO-004EyA-EU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-14net: sysfs: Implement is_visible for phys_(port_id, port_name, switch_id)Yajun Deng
phys_port_id_show, phys_port_name_show and phys_switch_id_show would return -EOPNOTSUPP if the netdev didn't implement the corresponding method. There is no point in creating these files if they are unsupported. Put these attributes in netdev_phys_group and implement the is_visible method. make phys_(port_id, port_name, switch_id) invisible if the netdev dosen't implement the corresponding method. Signed-off-by: Yajun Deng <yajun.deng@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250612142707.4644-1-yajun.deng@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-14net: ti: icssg-prueth: Read firmware-names from device treeMD Danish Anwar
Refactor the way firmware names are handled for the ICSSG PRUETH driver. Instead of using hardcoded firmware name arrays for different modes (EMAC, SWITCH, HSR), the driver now reads the firmware names from the device tree property "firmware-name". Only the EMAC firmware names are specified in the device tree property. The firmware names for all other supported modes are generated dynamically based on the EMAC firmware names by replacing substrings (e.g., "eth" with "sw" or "hsr") as appropriate. Example: Below are the firmwares used currently for PRU0 core EMAC: ti-pruss/am65x-sr2-pru0-prueth-fw.elf SW : ti-pruss/am65x-sr2-pru0-prusw-fw.elf HSR : ti-pruss/am65x-sr2-pru0-pruhsr-fw.elf All three firmware names are same except for the operating mode. In general for PRU0 core, firmware name is, ti-pruss/am65x-sr2-pru0-pru<mode>-fw.elf Since the EMAC firmware names are defined in DT, driver will read those directly and for other modes swap the mode name. i.e. eth -> sw or eth -> hsr. This preserves backwards compatibility as ICSSG driver is supported only by AM65x and AM64x. Both of these have "firmware-name" property populated in their device tree. Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250613064547.44394-1-danishanwar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-14net: amt: convert to use secs_to_jiffiesYuesong Li
Since secs_to_jiffies()(commit:b35108a51cf7) has been introduced, we can use it to avoid scaling the time to msec. Signed-off-by: Yuesong Li <liyuesong@vivo.com> Reviewed-by: Joe Damato <joe@dama.to> Reviewed-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250613102014.3070898-1-liyuesong@vivo.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-14Merge tag 'v6.16-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull smb client fixes from Steve French: - SMB3.1.1 POSIX extensions fix for char remapping - Fix for repeated directory listings when directory leases enabled - deferred close handle reuse fix * tag 'v6.16-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: smb: improve directory cache reuse for readdir operations smb: client: fix perf regression with deferred closes smb: client: disable path remapping with POSIX extensions
2025-06-14Merge tag 'iommu-fixes-v6.16-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fix from Joerg Roedel: - Fix PTE size calculation for NVidia Tegra * tag 'iommu-fixes-v6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/tegra: Fix incorrect size calculation
2025-06-14Merge tag 'block-6.16-20250614' of git://git.kernel.dk/linuxLinus Torvalds
Pull block fixes from Jens Axboe: - Fix for a deadlock on queue freeze with zoned writes - Fix for zoned append emulation - Two bio folio fixes, for sparsemem and for very large folios - Fix for a performance regression introduced in 6.13 when plug insertion was changed - Fix for NVMe passthrough handling for polled IO - Document the ublk auto registration feature - loop lockdep warning fix * tag 'block-6.16-20250614' of git://git.kernel.dk/linux: nvme: always punt polled uring_cmd end_io work to task_work Documentation: ublk: Separate UBLK_F_AUTO_BUF_REG fallback behavior sublists block: Fix bvec_set_folio() for very large folios bio: Fix bio_first_folio() for SPARSEMEM without VMEMMAP block: use plug request list tail for one-shot backmerge attempt block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work block: Clear BIO_EMULATES_ZONE_APPEND flag on BIO completion ublk: document auto buffer registration(UBLK_F_AUTO_BUF_REG) loop: move lo_set_size() out of queue freeze
2025-06-14Merge tag 'io_uring-6.16-20250614' of git://git.kernel.dk/linuxLinus Torvalds
Pull io_uring fixes from Jens Axboe: - Fix for a race between SQPOLL exit and fdinfo reading. It's slim and I was only able to reproduce this with an artificial delay in the kernel. Followup sparse fix as well to unify the access to ->thread. - Fix for multiple buffer peeking, avoiding truncation if possible. - Run local task_work for IOPOLL reaping when the ring is exiting. This currently isn't done due to an assumption that polled IO will never need task_work, but a fix on the block side is going to change that. * tag 'io_uring-6.16-20250614' of git://git.kernel.dk/linux: io_uring: run local task_work from ring exit IOPOLL reaping io_uring/kbuf: don't truncate end buffer for multiple buffer peeks io_uring: consistently use rcu semantics with sqpoll thread io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo()
2025-06-14Merge tag 'rust-fixes-6.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fix from Miguel Ojeda: - 'hrtimer': fix future compile error when the 'impl_has_hr_timer!' macro starts to get called * tag 'rust-fixes-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: time: Fix compile error in impl_has_hr_timer macro
2025-06-14Merge tag 'mm-hotfixes-stable-2025-06-13-21-56' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "9 hotfixes. 3 are cc:stable and the remainder address post-6.15 issues or aren't considered necessary for -stable kernels. Only 4 are for MM" * tag 'mm-hotfixes-stable-2025-06-13-21-56' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm: add mmap_prepare() compatibility layer for nested file systems init: fix build warnings about export.h MAINTAINERS: add Barry as a THP reviewer drivers/rapidio/rio_cm.c: prevent possible heap overwrite mm: close theoretical race where stale TLB entries could linger mm/vma: reset VMA iterator on commit_merge() OOM failure docs: proc: update VmFlags documentation in smaps scatterlist: fix extraneous '@'-sign kernel-doc notation selftests/mm: skip failed memfd setups in gup_longterm
2025-06-13Merge branch 'net-stmmac-rk-much-needed-cleanups'Jakub Kicinski
Russell King says: ==================== net: stmmac: rk: much needed cleanups This series starts attacking the reams of fairly identical duplicated code in dwmac-rk. Every new SoC that comes along seems to need more code added to this file because e.g. the way the clock is controlled is different in every SoC. The first thing to realise is that the driver only supports RMII and RGMII interface modes. So, the first patch adds a .get_interfaces() implementation which reports this for phylink's usage, thus ensuring that we error out during initialisation should something that isn't supported be specified. Note that there is one case where there are a pair of interfaces, one supports only RMII the other supports RMII and RGMII, but we report both anyway - something that the existing driver allows. A future patch may attempt to fix this. Rather than writing code, let's realise that there are two major implementations here: 1. a struct clk that needs to be set. 2. writing a register with settings for RGMII and RMII speeds. Provide implementations for these, Also realise that as a result of doing this, we can kill off the .set_rgmii_speed() and .set_rmii_speed() methods by combining them together - indeed, this is what later SoCs already do by pointing both these methods at the same function. Overall, this patch series shrinks the file LOC by almost 8.7% by removing 175 lines from over 2000 lines. Apart from the error reporting changing and restricting interface modes to those that the driver supports, no functional change is anticipated with this patch. However, I have no hardware to test this. ==================== Link: https://patch.msgid.link/aEr1BhIoC6-UM2XV@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: remove obsolete .set_*_speed() methodsRussell King (Oracle)
Now that no SoC implements the .set_*_speed() methods, we can get rid of these methods and the now unused code in rk_set_clk_tx_rate(). Arrange for the function to return an error when the .set_speed() method is not implemented. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk3O-004CFx-Ir@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: convert px30_set_rmii_speed() to .set_speed()Russell King (Oracle)
Convert px30_set_rmii_speed() to use the common .set_speed() method, which eliminates another user of the older .set_*_speed() methods. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk3J-004CFr-FE@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: simplify px30_set_rmii_speed()Russell King (Oracle)
px30_set_rmii_speed() doesn't need to be as verbose as it is - it merely needs the values for the register and clock rate which depend on the speed, and then call the appropriate functions. Rewrite the function to make it so. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk3E-004CFl-BZ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: combine .set_*_speed() methodsRussell King (Oracle)
As a result of the previous patches, many of the .set_rgmii_speed() and .set_rmii_speed() implementations are identical apart from the interface mode. Add a new .set_speed() function which takes the interface mode in addition to the speed, and use it to combine the separate implementations, calling the common rk_set_reg_speed() function. Also convert rk_set_clk_mac_speed() to be called by this new method pointer, rather than having these implementations called from both .set_*_speed() methods. Remove all the error messages from the .set_speed() methods, as these return an error code which is propagated up to stmmac_mac_link_up() which will print the error. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk39-004CFf-7a@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: combine clk_mac_speed rate setting functionsRussell King (Oracle)
rk3568_set_gmac_speed() and rv1126_set_clk_mac_speed() are now identical. Combine these so we have a single copy of this code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk34-004CFZ-3y@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: combine rv1126 set_*_speed() methodsRussell King (Oracle)
Just like rk3568, there is no need to have separate RGMII and RMII methods to set clk_mac_speed() as rgmii_clock() can be used to return the clock rate for both RGMII and RMII interface modes. Combine these two methods. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk2z-004CFT-0e@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: add struct for programming register based speedsRussell King (Oracle)
There is a common pattern in the driver where many SoCs need to write a single register with a value dependent on the interface mode and speed. Rather than having a lot of repeated code, add some common functions and a struct to contain the values to be written to a register to select the RGMII and RMII speeds. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk2t-004CFN-Td@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: simplify set_*_speed()Russell King (Oracle)
Rather than having lots of regmap_write()s to the same register but with different values depending on the speed, reorganise the functions to use a local variable for the value, and then have one regmap_write() call to write it to the register. This reduces the amount of code and is a step towards further reducing the code size. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk2o-004CFH-Q4@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: rk: add get_interfaces() implementationRussell King (Oracle)
RK platforms support RGMII and/or RMII depending on the SoC. Detect whether support for a SoC exists by whether the interface specific set_to functions have been populated, and set the appropriate bits in phylink's bitmap of interfaces. This assumes all dwmac interfaces on a SoC have identical support, but it should be noted that this is not true for RK3528 which only supports RGMII on GMAC1. However, the existing code structure permits RGMII to be configured on GMAC0 without complaint, so preserve this behaviour even though it is incorrect to avoid functional change. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPk2j-004CF6-Mf@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13Merge branch 'dpll-add-all-inputs-phase-offset-monitor'Jakub Kicinski
Arkadiusz Kubalewski says: ==================== dpll: add all inputs phase offset monitor Add dpll device level feature: phase offset monitor. Phase offset measurement is typically performed against the current active source. However, some DPLL (Digital Phase-Locked Loop) devices may offer the capability to monitor phase offsets across all available inputs. The attribute and current feature state shall be included in the response message of the ``DPLL_CMD_DEVICE_GET`` command for supported DPLL devices. In such cases, users can also control the feature using the ``DPLL_CMD_DEVICE_SET`` command by setting the ``enum dpll_feature_state`` values for the attribute. Once enabled the phase offset measurements for the input shall be returned in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute. Implement feature support in ice driver for dpll-enabled devices. Verify capability: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --dump device-get [{'clock-id': 4658613174691613800, 'id': 0, 'lock-status': 'locked-ho-acq', 'mode': 'automatic', 'mode-supported': ['automatic'], 'module-name': 'ice', 'type': 'eec'}, {'clock-id': 4658613174691613800, 'id': 1, 'lock-status': 'locked-ho-acq', 'mode': 'automatic', 'mode-supported': ['automatic'], 'module-name': 'ice', 'phase-offset-monitor': 'disable', 'type': 'pps'}] Enable the feature: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --do device-set --json '{"id":1, "phase-offset-monitor":"enable"}' Verify feature is enabled: $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --dump device-get [ [...] {'capabilities': {'all-inputs-phase-offset-monitor'}, 'clock-id': 4658613174691613800, 'id': 1, [...] 'phase-offset-monitor': 'enable', [...]] v6: - rebase. ==================== Link: https://patch.msgid.link/20250612152835.1703397-1-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13ice: add phase offset monitor for all PPS dpll inputsArkadiusz Kubalewski
Implement a new admin command and helper function to handle and obtain CGU measurements for input pins. Add new callback operations to control the dpll device-level feature "phase offset monitor," allowing it to be enabled or disabled. If the feature is enabled, provide users with measured phase offsets and notifications. Initialize PPS DPLL with new callback operations if the feature is supported by the firmware. Reviewed-by: Milena Olech <milena.olech@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250612152835.1703397-4-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13dpll: add phase_offset_monitor_get/set callback opsArkadiusz Kubalewski
Add new callback operations for a dpll device: - phase_offset_monitor_get(..) - to obtain current state of phase offset monitor feature from dpll device, - phase_offset_monitor_set(..) - to allow feature configuration. Obtain the feature state value using the get callback and provide it to the user if the device driver implements callbacks. Execute the set callback upon user requests. Reviewed-by: Milena Olech <milena.olech@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250612152835.1703397-3-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13dpll: add phase-offset-monitor feature to netlink specArkadiusz Kubalewski
Add enum dpll_feature_state for control over features. Add dpll device level attribute: DPLL_A_PHASE_OFFSET_MONITOR - to allow control over a phase offset monitor feature. Attribute is present and shall return current state of a feature (enum dpll_feature_state), if the device driver provides such capability, otherwie attribute shall not be present. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Milena Olech <milena.olech@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250612152835.1703397-2-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: stmmac: improve .set_clk_tx_rate() method error messageRussell King (Oracle)
Improve the .set_clk_tx_rate() method error message to include the PHY interface mode along with the speed, which will be helpful to the RK implementations. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/E1uPjjx-0049r5-NN@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: improve rgmii_clock() documentationRussell King (Oracle)
Improve the rgmii_clock() documentation to indicate that it can also be used for MII, GMII and RMII modes as well as RGMII as the required clock rates are identical, but note that it won't error out for 1G speeds for MII and RMII. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uPjjk-0049pI-MD@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: pfcp: fix typo in message_priority field nameRubenKelevra
The field is spelled "message_priprity" in the big-endian bit-field definition. Nothing in-tree currently references the member, so the typo does not break kernel builds, but it is clearly incorrect. Signed-off-by: RubenKelevra <rubenkelevra@gmail.com> Link: https://patch.msgid.link/20250612145012.185321-1-rubenkelevra@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13Merge branch 'dp83tg720-reduce-link-recovery'Jakub Kicinski
Oleksij Rempel says: ==================== dp83tg720: Reduce link recovery This patch series improves the link recovery behavior of the TI DP83TG720 PHY driver. Previously, we introduced randomized reset delay logic to avoid reset collisions in multi-PHY setups. While this approach was functional, it had notable drawbacks: unpredictable behavior, longer and more variable link recovery times, and overall higher complexity in link handling. With this new approach, we replace the randomized delay with deterministic, role-specific delays in the PHY reset logic. This enables us to: - Remove the redundant empirical 600 ms delay in read_status() - Drop the random polling interval logic - Introduce a clean, adaptive polling strategy with consistent behavior and improved responsiveness As a result, the PHY is now able to recover link reliably in under 1000_ms ==================== Link: https://patch.msgid.link/20250612104157.2262058-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: dp83tg720: switch to adaptive polling and remove random delaysDavid Jander
Now that the PHY reset logic includes a role-specific asymmetric delay to avoid synchronized reset deadlocks, the previously used randomized polling intervals are no longer necessary. This patch removes the get_random_u32_below()-based logic and introduces an adaptive polling strategy: - Fast polling for a short time after link-down - Slow polling if the link remains down - Slower polling when the link is up This balances CPU usage and responsiveness while avoiding reset collisions. Additionally, the driver still relies on polling for all link state changes, as interrupt support is not implemented, and link-up events are not reliably signaled by the PHY. The polling parameters are now documented in the updated top-of-file comment. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250612104157.2262058-4-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: dp83tg720: remove redundant 600ms post-reset delayDavid Jander
Now that dp83tg720_soft_reset() introduces role-specific delays to avoid reset synchronization deadlocks, the fixed 600ms post-reset delay in dp83tg720_read_status() is no longer needed. The new logic provides both the required MDC timing and link stabilization, making the old empirical delay redundant and unnecessarily long. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250612104157.2262058-3-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: dp83tg720: implement soft reset with asymmetric delayDavid Jander
Add a .soft_reset callback for the DP83TG720 PHY that issues a hardware reset followed by an asymmetric post-reset delay. The delay differs based on the PHY's master/slave role to avoid synchronized reset deadlocks, which are known to occur when both link partners use identical reset intervals. The delay includes: - a fixed 1ms wait to satisfy MDC access timing per datasheet, and - an empirically chosen extra delay (97ms for master, 149ms for slave). Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250612104157.2262058-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: arp: use kfree_skb_reason() in arp_rcv()Qiu Yutan
Replace kfree_skb() with kfree_skb_reason() in arp_rcv(). Signed-off-by: Qiu Yutan <qiu.yutan@zte.com.cn> Signed-off-by: Jiang Kun <jiang.kun2@zte.com.cn> Link: https://patch.msgid.link/20250612110259698Q2KNNOPQhnIApRskKN3Hi@zte.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "All fixes for drivers. The core change in the error handler is simply to translate an ALUA specific sense code into a retry the ALUA components can handle and won't impact any other devices" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: error: alua: I/O errors for ALUA state transitions scsi: storvsc: Increase the timeouts to storvsc_timeout scsi: s390: zfcp: Ensure synchronous unit_add scsi: iscsi: Fix incorrect error path labels for flashnode operations scsi: mvsas: Fix typos in per-phy comments and SAS cmd port registers scsi: core: ufs: Fix a hang in the error handler
2025-06-13Merge branch 'net-phy-improve-mdio-boardinfo-handling'Jakub Kicinski
Heiner Kallweit says: ==================== net: phy: improve mdio-boardinfo handling This series includes smaller improvements to mdio-boardinfo handling. ==================== Link: https://patch.msgid.link/6ae7bda0-c093-468a-8ac0-50a2afa73c45@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: directly copy struct mdio_board_info in mdiobus_register_board_infoHeiner Kallweit
Using a direct assignment instead of memcpy reduces the text segment size from 0x273 bytes to 0x19b bytes in my case. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/af371f2a-42f3-4d94-80b9-3420380a3f6f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: improve mdio-boardinfo.hHeiner Kallweit
There's no need to include phy.h and mutex.h in mdio-boardinfo.h. However mdio-boardinfo.c included phy.h indirectly this way so far, include it explicitly instead. Whilst at it, sort the included headers properly. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/86b7a1d6-9f9c-4d22-b3d8-5abdef0bb39a@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: move definition of struct mdio_board_entry to mdio-boardinfo.cHeiner Kallweit
Struct mdio_board_entry isn't used outside mdio-boardinfo.c, so remove the definition from the header file. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/0afe52d0-6fe6-434a-9881-3979661ff7b0@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13net: phy: simplify mdiobus_setup_mdiodev_from_board_infoHeiner Kallweit
- Move declaration of variable bi into list_for_each_entry_safe() - The return value of cb() effectively isn't used, this allows to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/f6bbe242-b43d-4c2b-8c51-2cb2cefbaf59@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-13Merge tag 'drm-fixes-2025-06-14' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Quiet week, only two pull requests came my way, xe has a couple of fixes and then a bunch of fixes across the board, vc4 probably fixes the biggest problem: vc4: - Fix infinite EPROBE_DEFER loop in vc4 probing amdxdna: - Fix amdxdna firmware size meson: - modesetting fixes sitronix: - Kconfig fix for st7171-i2c dma-buf: - Fix -EBUSY WARN_ON_ONCE in dma-buf udmabuf: - Use dma_sync_sgtable_for_cpu in udmabuf xe: - Fix regression disallowing 64K SVM migration - Use a bounce buffer for WA BB" * tag 'drm-fixes-2025-06-14' of https://gitlab.freedesktop.org/drm/kernel: drm/xe/lrc: Use a temporary buffer for WA BB udmabuf: use sgtable-based scatterlist wrappers dma-buf: fix compare in WARN_ON_ONCE drm/sitronix: st7571-i2c: Select VIDEOMODE_HELPERS drm/meson: fix more rounding issues with 59.94Hz modes drm/meson: use vclk_freq instead of pixel_freq in debug print drm/meson: fix debug log statement when setting the HDMI clocks drm/vc4: fix infinite EPROBE_DEFER loop drm/xe/svm: Fix regression disallowing 64K SVM migration accel/amdxdna: Fix incorrect PSP firmware size
2025-06-13rust: devres: do not dereference to the internal RevocableDanilo Krummrich
We can't expose direct access to the internal Revocable, since this allows users to directly revoke the internal Revocable without Devres having the chance to synchronize with the devres callback -- we have to guarantee that the internal Revocable has been fully revoked before the device is fully unbound. Hence, remove the corresponding Deref implementation and, instead, provide indirect accessors for the internal Revocable. Note that we can still support Devres::revoke() by implementing the required synchronization (which would be almost identical to the synchronization in Devres::drop()). Fixes: 76c01ded724b ("rust: add devres abstraction") Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250611174827.380555-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-13rust: devres: fix race in Devres::drop()Danilo Krummrich
In Devres::drop() we first remove the devres action and then drop the wrapped device resource. The design goal is to give the owner of a Devres object control over when the device resource is dropped, but limit the overall scope to the corresponding device being bound to a driver. However, there's a race that was introduced with commit 8ff656643d30 ("rust: devres: remove action in `Devres::drop`"), but also has been (partially) present from the initial version on. In Devres::drop(), the devres action is removed successfully and subsequently the destructor of the wrapped device resource runs. However, there is no guarantee that the destructor of the wrapped device resource completes before the driver core is done unbinding the corresponding device. If in Devres::drop(), the devres action can't be removed, it means that the devres callback has been executed already, or is still running concurrently. In case of the latter, either Devres::drop() wins revoking the Revocable or the devres callback wins revoking the Revocable. If Devres::drop() wins, we (again) have no guarantee that the destructor of the wrapped device resource completes before the driver core is done unbinding the corresponding device. CPU0 CPU1 ------------------------------------------------------------------------ Devres::drop() { Devres::devres_callback() { self.data.revoke() { this.data.revoke() { is_available.swap() == true is_available.swap == false } } // [...] // device fully unbound drop_in_place() { // release device resource } } } Depending on the specific device resource, this can potentially lead to user-after-free bugs. In order to fix this, implement the following logic. In the devres callback, we're always good when we get to revoke the device resource ourselves, i.e. Revocable::revoke() returns true. If Revocable::revoke() returns false, it means that Devres::drop(), concurrently, already drops the device resource and we have to wait for Devres::drop() to signal that it finished dropping the device resource. Note that if we hit the case where we need to wait for the completion of Devres::drop() in the devres callback, it means that we're actually racing with a concurrent Devres::drop() call, which already started revoking the device resource for us. This is rather unlikely and means that the concurrent Devres::drop() already started doing our work and we just need to wait for it to complete it for us. Hence, there should not be any additional overhead from that. (Actually, for now it's even better if Devres::drop() does the work for us, since it can bypass the synchronize_rcu() call implied by Revocable::revoke(), but this goes away anyways once I get to implement the split devres callback approach, which allows us to first flip the atomics of all registered Devres objects of a certain device, execute a single synchronize_rcu() and then drop all revocable objects.) In Devres::drop() we try to revoke the device resource. If that is *not* successful, it means that the devres callback already did and we're good. Otherwise, we try to remove the devres action, which, if successful, means that we're good, since the device resource has just been revoked by us *before* we removed the devres action successfully. If the devres action could not be removed, it means that the devres callback must be running concurrently, hence we signal that the device resource has been revoked by us, using the completion. This makes it safe to drop a Devres object from any task and at any point of time, which is one of the design goals. Fixes: 76c01ded724b ("rust: add devres abstraction") Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://lore.kernel.org/lkml/aD64YNuqbPPZHAa5@google.com/ Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250612121817.1621-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-13rust: revocable: indicate whether `data` has been revoked alreadyDanilo Krummrich
Return a boolean from Revocable::revoke() and Revocable::revoke_nosync() to indicate whether the data has been revoked already. Return true if the data hasn't been revoked yet (i.e. this call revoked the data), false otherwise. This is required by Devres in order to synchronize the completion of the revoke process. Reviewed-by: Benno Lossin <lossin@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250612121817.1621-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-13rust: completion: implement initial abstractionDanilo Krummrich
Implement a minimal abstraction for the completion synchronization primitive. This initial abstraction only adds complete_all() and wait_for_completion(), since that is what is required for the subsequent Devres patch. Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ben Segall <bsegall@google.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Valentin Schneider <vschneid@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250612121817.1621-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-13io_uring: run local task_work from ring exit IOPOLL reapingJens Axboe
In preparation for needing to shift NVMe passthrough to always use task_work for polled IO completions, ensure that those are suitably run at exit time. See commit: 9ce6c9875f3e ("nvme: always punt polled uring_cmd end_io work to task_work") for details on why that is necessary. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-06-13nvme: always punt polled uring_cmd end_io work to task_workJens Axboe
Currently NVMe uring_cmd completions will complete locally, if they are polled. This is done because those completions are always invoked from task context. And while that is true, there's no guarantee that it's invoked under the right ring context, or even task. If someone does NVMe passthrough via multiple threads and with a limited number of poll queues, then ringA may find completions from ringB. For that case, completing the request may not be sound. Always just punt the passthrough completions via task_work, which will redirect the completion, if needed. Cc: stable@vger.kernel.org Fixes: 585079b6e425 ("nvme: wire up async polling for io passthrough commands") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-06-13Merge tag 'acpi-6.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix an ACPI APEI error injection driver failure that started to occur after switching it over to using a faux device, address an EC driver issue related to invalid ECDT tables, clean up the usage of mwait_idle_with_hints() in the ACPI PAD driver, add a new IRQ override quirk, and fix a NULL pointer dereference related to nosmp: - Update the faux device handling code in the driver core and address an ACPI APEI error injection driver failure that started to occur after switching it over to using a faux device on top of that (Dan Williams) - Update data types of variables passed as arguments to mwait_idle_with_hints() in the ACPI PAD (processor aggregator device) driver to match the function definition after recent changes (Uros Bizjak) - Fix a NULL pointer dereference in the ACPI CPPC library that occurs when nosmp is passed to the kernel in the command line (Yunhui Cui) - Ignore ECDT tables with an invalid ID string to prevent using an incorrect GPE for signaling events on some systems (Armin Wolf) - Add a new IRQ override quirk for MACHENIKE 16P (Wentao Guan)" * tag 'acpi-6.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: resource: Use IRQ override on MACHENIKE 16P ACPI: EC: Ignore ECDT tables with an invalid ID string ACPI: CPPC: Fix NULL pointer dereference when nosmp is used ACPI: PAD: Update arguments of mwait_idle_with_hints() ACPI: APEI: EINJ: Do not fail einj_init() on faux_device_create() failure driver core: faux: Quiet probe failures driver core: faux: Suppress bind attributes