linux-next.git/drivers/net/phy, branch master

net: phy: dp83848: check phy_read() return value in config_init()

2026-09-04T00:42:07+00:00

dp83848_config_init() reads BMCR to detect whether auto-negotiation is enabled, but does not check the phy_read() return value. On an MDIO read failure phy_read() returns a negative errno, which is then used directly in a bitwise test; the auto-negotiation state is left undefined while config_init() still reports success. Check the return value and propagate the error. Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Signed-off-by: Donggeun Yoo Reviewed-by: Maxime Chevallier Reviewed-by: Xuanqiang Luo Link: https://patch.msgid.link/20260902065828.1031113-1-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski

net: phy: air_en8811h: restore AN8811HB LED GPIO after MCU restart

2026-09-03T02:19:29+00:00

Commit 03b4702fc5e3 ("net: phy: air_en8811h: move LED GPIO configuration to config_init") moved the EN8811H LED GPIO setup from probe to config_init because an MD32 restart clears the output-enable bits. AN8811HB follows the same initialization sequence: an8811hb_probe() enables GPIO3/4/5, and later config_init() calls restart MD32. Move the AN8811HB GPIO setup to the end of an8811hb_config_init(), matching the current EN8811H path. Suggested-by: Jakub Kicinski Signed-off-by: Ziyou Xu Link: https://patch.msgid.link/20260829033844.1975-1-xuziyougm@gmail.com Signed-off-by: Jakub Kicinski

net: pcs: lynx: add support for 25GBASE-R

2026-09-03T02:13:03+00:00

The Lynx PCS never supported 25GBASE-R. Add it, so that a 25G DPMAC on LX2160A can be driven by phylink. The SerDes side had the mode since the commit 1cab8fba5073 ("phy: lynx-28g: add support for 25GBASER") and dpaa2-mac maps DPMAC_ETH_IF_CAUI to PHY_INTERFACE_MODE_25GBASER, but the PCS never handled it, so phylink_validate() failed with the interface. 25GBASE-R is a serial mode without clause-37 in-band autonegotiation, exactly like 10GBASE-R: it does not needs any configuration, its state is read with phylink_mii_c45_pcs_get_state(), and it reports LINK_INBAND_DISABLE. phylink_mii_c45_pcs_get_state() is extended in the same patch because without it the link comes up reporting Unknown/Unknown. Suggested-by: Ioana Ciornei Co-developed-by: Ioana Ciornei Signed-off-by: Ioana Ciornei Signed-off-by: Vincent Jardin Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260922-for-upstream-lynx-25gbaser-v1-v2-1-1e6cf79c7b52@free.fr Signed-off-by: Jakub Kicinski

net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus

2026-09-03T01:56:40+00:00

Some MDIO buses require programming PHY polling registers depending on the PHY type. RealTek switch SoCs are the most prominent example of a DSA switch which doesn't allow to program MAC speed, duplex and flow-control settings without using PHY polling to do so [1]. Avoid a half-baked solution in the MDIO bus driver because - it must reinvent the bus scanning to determine the PHYs and - it must anticipate the right point in time (e.g. deferred PHYs). Hence there is a need to inform the MDIO bus driver that a PHY is being attached or detached. Provide two hooks in struct mii_bus - notify_phy_attach(): called in phy_attach_direct() after PHY hardware has been initialized and just before PHY is resumed. - notify_phy_detach(): called in phy_detach() right after PHY has been suspended. Worth to notice: As of now phy_detach() is not 100% LIFO symmetric to phy_attach_direct(). E.g. sysfs links are torn down before suspend while being created before resume. Without reordering of the detach function the above mentioned notifier placement is the best possible symmetric implementation. An unconditional call of notify_phy_detach() was favoured [3]. Remark! A slightly different version of this patch was part of a former series [2]. The discussion already showed that an initialization hook should be placed somewhere late during the whole setup. This commit implants it right after phy_init_hw() as suggested. On top of this it adds the detach hook. [1] https://github.com/openwrt/openwrt/pull/21515#discussion_r2714069716 [2] https://lore.kernel.org/netdev/cover.1769053496.git.daniel@makrotopia.org/ [3] https://lore.kernel.org/netdev/9e40f50b-357a-4a93-9f59-94847850835d@lunn.ch/#t Signed-off-by: Daniel Golle Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-6-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: phy: add phy_detach_internal() helper

2026-09-03T01:56:40+00:00

For the upcoming MDIO bus notification enhancements the PHY detach path needs to inform the bus about these actions. Until now phy_detach() is used for the regular detach path as well as from the phy_attach_direct() error paths So in the future there must be a clear indication if a notification is needed (normal path) or not (cleanup path). Carve out the phy_detach() code into a new helper phy_detach_internal() and make phy_detach() a short stub that calls the new helper. Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-5-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: phy: avoid double-free after LED trigger registration failure

2026-08-31T00:01:07+00:00

phy_led_triggers_register() frees phy_led_triggers when a speed trigger registration fails, but leaves the pointer set to the freed allocation before clearing phy_num_led_triggers. phy_probe() ignores the registration error. If a later probe step fails, its error path calls phy_led_triggers_unregister(); normal teardown during an unbind or MDIO bus removal calls the same helper from phy_remove(). In either case, the trigger count is zero, so the per-trigger unregister loop is skipped, but the dangling pointer is still freed unconditionally. Clear the pointer when partial registration cleanup frees the array, and make phy_led_triggers_unregister() free the array only when its pointer is non-NULL. Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260823035600.188864-7-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski

net: phy: propagate errors from default port setup

2026-08-31T00:01:04+00:00

phy_default_setup_single_port() ignores errors from phy_add_port() and always reports success. If a PHY driver attach_mdi_port() callback fails, the phy_port is leaked and PHY probing continues without the expected default port. Destroy the port and return the error. Reviewed-by: Maxime Chevallier Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260823035600.188864-6-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski

net: phy: call driver remove when core initialization fails

2026-08-31T00:01:01+00:00

phy_probe() may fail while querying features or completing other core initialization after the PHY driver probe callback has succeeded. The driver core does not run the remove path after a probe error, so resources that the PHY driver releases in its remove callback are leaked. Call the PHY driver remove callback on these failures. Reviewed-by: Andrew Lunn Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260823035600.188864-5-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski

net: phy: set PHY_READY after LED setup

2026-08-31T00:00:59+00:00

phy_probe() sets PHY_READY before calling of_phy_leds(). If LED setup fails, the error path releases the initialized resources while the PHY state remains READY even though probing failed. Set PHY_READY only after LED setup succeeds. Reviewed-by: Andrew Lunn Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260823035600.188864-4-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski

net: phy: unregister SFP upstream before port cleanup

2026-08-31T00:00:56+00:00

Commit 4497f5028675 ("net: phy: Clean the phy_ports after unregistering the downstream SFP bus") established that an SFP upstream must be unregistered before its phy_ports are destroyed because SFP callbacks may access these ports. phy_setup_ports() does not follow this order when a later port setup step fails after phy_sfp_probe() succeeds. It destroys the SFP phy_port and leaves phy_probe() to unregister the upstream later, creating a race between port destruction and SFP upstream callbacks. The error unwind is also split across three functions. If phy_setup_sfp_port() fails, phy_sfp_probe() leaves the upstream registered and relies on phy_probe() to remove it after phy_setup_ports() returns. Make each layer unwind the resources it successfully set up. Unregister only the upstream in phy_sfp_probe() when SFP port setup fails, since the failed port has already been destroyed. Add phy_sfp_release() for a successful SFP probe, and make phy_setup_ports() use it before cleaning up the remaining ports. Once phy_setup_ports() has rolled back all port setup, make phy_probe() skip this cleanup. Reviewed-by: Andrew Lunn Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260823035600.188864-3-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski