kernel/git/next/linux-next.git/drivers/net/phy, branch stable

net: phy: dp83td510: handle the active-high LED polarity mode

2026-09-10T15:47:22+00:00

dp83td510_led_polarity_set() only recognizes PHY_LED_ACTIVE_LOW, so PHY_LED_ACTIVE_HIGH falls through to the default case and returns -EINVAL. of_phy_led() propagates the error, of_phy_leds() drops the LEDs registered so far and passes it on, and phy_probe() returns it. A device tree marking a DP83TD510 LED as 'active-high', which leds/common.yaml allows and ethernet-phy.yaml references for led@N nodes, thus leaves the mdio device unbound, so phy_attach_direct() falls back to the genphy driver, which cannot drive this 10BASE-T1L single-mode PHY, so the interface has no usable link. The callback initializes polarity to DP83TD510E_LED_POLARITY(index), which is the active-high setting, so the request is already satisfied and only the case label is missing. Cc: stable@vger.kernel.org Fixes: 5b281fe7e396 ("net: phy: dp83td510: introduce LED framework support") Signed-off-by: Donggeun Yoo Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260908105959.70453-3-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski

net: phy: dp83867: handle the active-high LED polarity mode

2026-09-10T15:02:06+00:00

Commit a274465cc3be ("net: phy: support 'active-high' property for PHY LEDs") added PHY_LED_ACTIVE_HIGH and made of_phy_led() set the matching bit in the modes mask when a LED node carries the 'active-high' property. dp83867 was not part of that series. dp83867_led_polarity_set() only recognizes PHY_LED_ACTIVE_LOW, so PHY_LED_ACTIVE_HIGH falls through to the default case and returns -EINVAL. of_phy_led() propagates the error, of_phy_leds() drops the LEDs registered so far and passes it on, and phy_probe() fails. A device tree marking a DP83867 LED as 'active-high', which leds/common.yaml allows and ethernet-phy.yaml references for led@N nodes, thus stops the PHY from probing. Active high is what the function programs when no polarity mode is requested at all, so the initial value of polarity already satisfies the request and only the case label is missing. The same series updated mxl-gpy in commit eb89c79c1b8f ("net: phy: mxl-gpy: correctly describe LED polarity") and aquantia in commit 9d55e68b19f2 ("net: phy: aquantia: correctly describe LED polarity override"). Fixes: a274465cc3be ("net: phy: support 'active-high' property for PHY LEDs") Signed-off-by: Donggeun Yoo Link: https://patch.msgid.link/20260903022839.4006614-1-donggeunyoo.kernel@gmail.com Signed-off-by: Jakub Kicinski

net: phy: mediatek-ge: disable EEE on the MT7530 PHY

2026-09-10T12:48:21+00:00

The MT7530 internal GE PHY advertises EEE by hardware default, but its EEE support is defective: with EEE advertised, some link partners fail to establish a stable link. On a 2-pair (4-wire) cable where both ends advertise gigabit, 1000BASE-T training cannot succeed, and instead of falling back to 100 Mbps the port loops, so no link or DHCP lease is ever obtained. MediaTek confirms the hardware is the root cause (Landen Chao, 2021): "EEE of the 10-year-old MT7530 internal gephy has many IOT problems, so it is recommended to disable its EEE." mtk_gephy_config_init() used to clear the EEE advertisement early, but commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement") removed that on the rationale that the DSA subdriver already performs an early disable. That holds for MT7531, whose mt7531_setup() clears MDIO_AN_EEE_ADV on each switch PHY, but not for the MT7530 PHY: neither the MT7621 integrated switch nor the dedicated MT7530 IC ever had such a loop, so removing it left those boards without any working early EEE disable and the link flapping came back. Since the broken hardware is the PHY, fix it in the PHY driver so it covers all users of this PHY, integrated in a switch or standalone: - clear MDIO_AN_EEE_ADV in probe(), as early as possible, before anything can negotiate EEE with the link partner; - clear it again in config_init() and call phy_disable_eee() there. config_init() is what phy_init_hw() replays after a PHY reset, when the register is back at its EEE-advertising hardware default, and it runs after of_set_phy_eee_broken() in phy_probe(), so the eee_disabled_modes mask survives and neither phylib nor userspace can re-enable EEE. dp83867 disables broken EEE from config_init() the same way. Auto-negotiation then falls back to a stable 100 Mbps link instead of looping at gigabit. Tested on ASUS RT-AX53U (MT7621): with a 2-pair cable on the WAN port, a single clean 100 Mbps link comes up and a DHCP lease is obtained, where the unpatched driver loops. Fixes: af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement") Suggested-by: Andrew Lunn Signed-off-by: Vladislav Karmanov Link: https://patch.msgid.link/20260908145213.3976508-1-vladislav.karmanov.dev@gmail.com Signed-off-by: Paolo Abeni

net: phylink: initialise link_state before a forced major config

2026-09-10T01:47:16+00:00

phylink_resolve() leaves link_state on the stack unpopulated on its disable and link-failed branches, which set only link_state.link. phylink_apply_manual_flow() then reads the struct's advertising on every mode but MLO_AN_FIXED, and has done so since long before force_major_config existed. force_major_config turns that into a write to the hardware. It is the only trigger for the major-config block that does not require mac_config, so phylink_major_config() programs the MAC for whatever the stack held, a zeroed interface is PHY_INTERFACE_MODE_NA, and the write-back stores it in pl->link_config.interface. phylink_replay_link_end() is the only in-tree setter, and sja1105_static_config_reload() calls it for every port that has a phylink instance, regardless of admin state. On a stopped port phylink_run_resolve() no-ops, so the flag outlives the call. The next resolve consumes it whatever branch it takes; an unpopulated branch is where that does damage. Found while developing a series that attaches a late PHY from a delayed work item and sets this flag there, so the PHY attached after its port was already up. The link stayed down until the port was cycled 29 minutes later. With this patch on the same board the same attach programs the MAC for 2500base-x rather than unknown, and the PHY's interrupt fires without a port bounce where it had stayed at zero throughout the failure. Fixes: 96969b132bf1 ("net: phylink: introduce helpers for replaying link callbacks") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260904185540.2844261-1-f@lex.la Signed-off-by: Jakub Kicinski

net: phy: air_en8811h: move LED GPIO configuration to config_init

2026-08-27T09:47:01+00:00

The LED GPIO pins (GPIO3/4/5, mapped to LED2/LED1/LED0) are only ever configured as outputs once, in .probe(). But .config_init() restarts the MD32 MCU via en8811h_restart_mcu() on every call after the first (priv->mcu_needs_restart), and that restart resets buckpbus-mapped MCU state, including EN8811H_GPIO_OUTPUT. As a result the LED GPIOs fall back to inputs after the first event that re-triggers .config_init() (link renegotiation, ifdown/ifup, resume), and the PHY's LEDs stop reflecting link/activity state even though they worked right after probe. Move the GPIO-as-output configuration from .probe() to the end of .config_init(), so it is reapplied every time the MCU may have been restarted. Fixes: 71e79430117d ("net: phy: air_en8811h: Add the Airoha EN8811H PHY driver") Suggested-by: Mikhail Zhilkin Signed-off-by: Vitaliy Sochnev Link: https://patch.msgid.link/20260823130638.1166453-2-sochnev.v.74@gmail.com Signed-off-by: Paolo Abeni

net: phylink: correctly validate returned PCS in phylink_inband_caps

2026-08-20T21:07:43+00:00

In phylink_inband_caps(), the PCS returned by mac_select_pcs is only checked if NULL but mac_select_pcs can also return an error pointer. This can cause a kernel panic as phylink_pcs_inband_caps() only checks if passed PCS is not NULL and directly dereference ops from the phylink_pcs struct. Use the IS_ERR_OR_NULL macro to address both case where the returned PCS can be NULL or an error pointer and prevent a kernel panic. Cc: stable@vger.kernel.org Fixes: df874f9e52c3 ("net: phylink: add pcs_inband_caps() method") Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260817213009.13924-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski

net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs

2026-08-18T13:50:13+00:00

The Fast Ethernet PHYs present in the MT7628 SoCs require an undocumented bit to be set before they can establish 100mbps links. This commit adds the Kconfig option MEDIATEK_FE_SOC_PHY and the corresponding driver mtk-fe-soc.c. Signed-off-by: Joris Vaisvila Reviewed-by: Andrew Lunn Reviewed-by: Daniel Golle Link: https://patch.msgid.link/20260813190241.789323-3-joey@tinyisr.com Signed-off-by: Paolo Abeni

net: sfp: add quirks for OEM XGSPONST2001 and FS XGS-SFP-ONT-MACI

2026-08-17T20:28:38+00:00

Cheap XGS-PON ONT sticks identifying as vendor "OEM", PN "XGSPONST2001" have broken TX_FAULT and LOS indicators (driven by the ONU serial passthrough wires) and need a longer T_START_UP than the SFF-8472 default. The Fiberstore XGS-SFP-ONT-MACI MAC-mode ONT stick has the same ONT-class TX_FAULT/LOS wiring and startup behaviour. Apply the existing sfp_fixup_potron handler to both, which masks both signals and bumps T_START_UP to T_START_UP_BAD_GPON. The XGSPONST2001 returns the 12 legitimate PN characters followed by non-printable garbage on cold power-up reads (the same module reads back clean and space-padded after a warm reseat), which defeats exact-length matching precisely on the boot where the quirk must apply: the kernel honors the spurious TX_FAULT and the SFP state machine eventually disables the module. Match its part as a prefix using SFP_QUIRK_F_PREFIX. The XGS-SFP-ONT-MACI PN is the product name (XGS-SFP-ONT-MAC-I) truncated at the 16-byte field width, so the field is fully occupied by legitimate characters and a plain exact-match SFP_QUIRK_F entry is correct. Signed-off-by: Martino Dell'Ambrogio Link: https://patch.msgid.link/20260812154708.2201266-3-tillo@tillo.ch Signed-off-by: Jakub Kicinski

net: sfp: allow prefix matching in quirk lookup

2026-08-17T20:28:38+00:00

Some clone SFP modules return EEPROM reads where the vendor PN field contains non-printable garbage past the trailing legitimate characters instead of the SFF-8472 mandated space padding. The current sfp_match() requires an exact full-field length match: sfp_strlen() returns 16 (no trailing spaces or NULs to strip), but strlen() of the quirk string is shorter, so the length comparison rejects the entry before strncmp() is even called and the quirk silently never applies. Add a part_prefix_match flag to struct sfp_quirk and a SFP_QUIRK_F_PREFIX macro. When set, sfp_match() compares only strlen() leading bytes of the quirk part string, ignoring trailing field bytes. The vendor name comparison always stays exact. Existing exact-match quirks are unaffected (part_prefix_match defaults to false via zero-init in the existing SFP_QUIRK macros). This patch only adds the mechanism; the first user is added by the following patch. Signed-off-by: Martino Dell'Ambrogio Link: https://patch.msgid.link/20260812154708.2201266-2-tillo@tillo.ch Signed-off-by: Jakub Kicinski

net: phylink: treat PSGMII as an inband capable interface

2026-08-14T01:21:31+00:00

PSGMII (the Qualcomm 5-port SGMII) conveys the link negotiation result from the PHY back to the MAC through per-channel in-band SGMII words, exactly like SGMII and QSGMII. However, PHY_INTERFACE_MODE_PSGMII is missing from phylink_get_inband_type(), so phylink reports INBAND_NONE for it and phylink_pcs_neg_mode() falls back to PHYLINK_PCS_NEG_NONE. The PCS is then programmed in force mode and its control-register speed bits (which default to 1000base) are used, so a slower copper link - e.g. 100base-T - is reported as 1Gbps and cannot pass traffic. Classify PSGMII alongside SGMII and QSGMII as INBAND_CISCO_SGMII so the PCS negotiates in-band and the resolved link speed comes from the PHY in-band word. Also add PSGMII to the generic clause 22 PCS helper functions which handle the SGMII in-band word. Without this, a PCS using these helpers would still fall through to the default handling and force the link state to false in phylink_mii_c22_pcs_decode_state(), fail to encode the SGMII advertisement, and get rejected by phylink_get_link_timer_ns(). Signed-off-by: Sandeep Sondagar Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260809-phylink-psgmii-v3-1-908dcd3a9e3d@gmail.com Signed-off-by: Jakub Kicinski