linux-stable.git/drivers/net/phy, branch v6.18.48

net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path

2026-08-23T12:27:08+00:00

[ Upstream commit 202fef9bbbf5784487eec27581389c6fb97c350d ]

In rtlgen_write_mmd(), the MDIO_AN_EEE_ADV case swaps the arguments to
rtlgen_write_vend2(): it passes the MMD register number as the OCP address
and the OCP address constant as the value. The caller's value is discarded
and the write lands on the wrong register, so the EEE advertisement cannot
be configured on the affected PHYs.

Mirror rtlgen_read_mmd() and write the value to RTL_MDIO_AN_EEE_ADV.

Fixes: da681ed73fb9 ("net: phy: realtek: improve mmd register access for internal PHY's")
Signed-off-by: Oleksij Rempel 
Reviewed-by: Andrew Lunn 
Reviewed-by: Nicolai Buchwitz 
Link: https://patch.msgid.link/20260806134716.3511821-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: phy: mediatek: fix TX blink masks using the RX bits

2026-08-19T16:18:17+00:00

commit f684c514f7965385dae21f2535f99938e73ec1af upstream.

MTK_GPHY_LED_TX_BLINK_SET and MTK_2P5GPHY_LED_TX_BLINK_SET are built
from the RX blink bits instead of the TX ones, so both TX masks are
identical to their RX counterparts. The TX bits they should be using,
MTK_PHY_LED_BLINK_{10,100,1000,2500}TX, are otherwise only referenced
by the per-speed branch of mtk_phy_led_hw_ctrl_set().

A TX trigger selected without a link trigger therefore programs the RX
blink bits, and the LED blinks on received traffic. The masks are also
used to decode the blink register in mtk_phy_led_hw_ctrl_get(), which
as a result cannot tell the two triggers apart: an RX-only
configuration reads back as RX and TX, and a TX-only configuration
reads back as neither.

Fixes: 7f9c320c98db ("net: phy: mediatek: Move LED helper functions into mtk phy lib")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Naseef 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/20260804113511.3371248-1-naseefkm@gmail.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

net: phylink: put link_gpio if phylink_create fails

2026-08-09T18:25:07+00:00

[ Upstream commit 0fe1e3e8f3380d7862296a73b528d164e96c76b8 ]

In phylink_create() if phylink_register_sfp() returns an error, link_gpio
obtained by phylink_parse_fixedlink() is never released. While this is a
very unlikely scenario, it's worth to fix/handle this.

This was present from the very first implementation of phylink but got
relevant only with the introduction of ce0aa27ff3f6 ("sfp: add sfp-bus to
bridge between network devices and sfp cages") where additional function
were added after phylink_parse_fixedlink() making the release of link_gpio
needed if such additional function errored out.

While at it, restructure the exit condition of phylink_create() with the
goto pattern to reduce code duplication on handling error conditions.

Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
Signed-off-by: Christian Marangi 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/20260726150806.2437-1-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: phy: marvell: fix return code

2026-08-03T09:21:40+00:00

[ Upstream commit 7d8ca62d6a9ef593780161586b4efc811ac094fe ]

Return the correct error code, not the value written to the register.

Fixes: a219912e0fec ("net: phy: marvell: implement config_inband() method")
Signed-off-by: Michael Walle 
Reviewed-by: Maxime Chevallier 
Link: https://patch.msgid.link/20260706120637.1947685-1-mwalle@kernel.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy

2026-07-24T14:16:42+00:00

[ Upstream commit 8f31efff9206f9f0adb853cad6916086aac4d5ef ]

sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.

This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.

Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create().

Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release")
Signed-off-by: Petr Wozniak 
Reviewed-by: Maxime Chevallier 
Reviewed-by: Larysa Zaremba 
Link: https://patch.msgid.link/312bde8176fc429aa89524e3be250137f034ba84.1782581445.git.petr.wozniak@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit

2026-07-24T14:16:39+00:00

[ Upstream commit 510a283f4d12367a3f811f382a2c89202954bbd1 ]

On RTL8127A connected to a link partner that advertises 10000baseT
speed cannot be changed to anything other than 10000baseT as 10GbE
is always advertised regardless of any setting. Fix this by
clearing MDIO_AN_10GBT_CTRL_ADV10G bit in rtl822x_config_aneg()'s
call to phy_modify_mmd_changed().

Fixes: 83d962316128 ("net: phy: realtek: add RTL8127-internal PHY")
Reviewed-by: Maxime Chevallier 
Signed-off-by: Jan Klos 
Link: https://patch.msgid.link/20260620011956.37181-1-honza.klos@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: sfp: initialize i2c_block_size at adapter configure time

2026-06-19T11:44:09+00:00

commit 56d0885514491e5ed8f7593400879ab77c52504c upstream.

sfp->i2c_block_size is only assigned in sfp_sm_mod_probe(), which runs
from the state machine timer after SFP_F_PRESENT has been set. Between
those two points, sfp_module_eeprom() (the ethtool -m callback) gates
only on SFP_F_PRESENT and can be entered with i2c_block_size still at
its kzalloc'd value of 0.

On a pure-I2C adapter, sfp_i2c_read() then issues an i2c_transfer()
with msgs[1].len = 0 inside a loop that subtracts this_len from len
each iteration; on adapters that succeed a zero-length read the loop
never advances, spinning while holding rtnl_lock.

This was previously addressed by initializing i2c_block_size in
sfp_alloc() (commit 813c2dd78618), but the initialization was dropped
when i2c_block_size was split from i2c_max_block_size.

Initialize sfp->i2c_block_size from sfp->i2c_max_block_size in
sfp_i2c_configure(), so the field is valid as soon as the adapter is
known. sfp_sm_mod_probe() still reassigns it on each module insertion
to recover from a per-module clamp to 1 (sfp_id_needs_byte_io).

Fixes: 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access")
Cc: stable@vger.kernel.org
Signed-off-by: Jonas Jelonek 
Link: https://patch.msgid.link/20260528205242.971410-2-jelonek.jonas@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: phy: clean the sfp upstream if phy probing fails

2026-06-19T11:43:58+00:00

[ Upstream commit 48774e87bbaa0056819d4b52301e4692e50e3252 ]

Sashiko reported that we don't call sfp_bus_del_upstream() in the probe
failure path, so let's add it, otherwise the sfp-bus is left with a
dangling 'upstream' field, that may be used later on during SFP events.

This issue existed before the generic phylib sfp support, back when
drivers were calling phy_sfp_probe themselves.

Reviewed-by: Nicolai Buchwitz 
Fixes: 298e54fa810e ("net: phy: add core phylib sfp support")
Signed-off-by: Maxime Chevallier 
Link: https://patch.msgid.link/20260604092819.723505-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: phy: micrel: fix LAN8814 QSGMII soft reset

2026-06-09T10:28:52+00:00

[ Upstream commit e027c218c482c6a0ae1948129ccda3b0a2033368 ]

LAN8814 QSGMII soft reset was moved into the probe function to avoid
triggering it for each of 4 PHY-s in the package.

However, that broke QSGMII link between the MAC and PHY on most LAN8814
PHY-s, specificaly for us on the Microchip LAN969x switch.
Reading the QSGMII status registers it was visible that lanes were only
partially synced.

It looks like the reset timing is crucial, so lets move the reset back
into the .config_init function but guard it with phy_package_init_once()
to avoid it being triggered on each of 4 PHY-s in the package.
Change the probe function to use phy_package_probe_once() for coma and PtP
setup.

Fixes: 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface")
Signed-off-by: Robert Marko 
Link: https://patch.msgid.link/20260428134138.1741253-1-robert.marko@sartura.hr
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X

2026-06-09T10:28:32+00:00

[ Upstream commit 1bc80d673087e5704adbb3ee8e4b785c14899cce ]

As the PHYs VSC8584, VSC8582, VSC8575 and VSC856X exists only as rev B,
we can use PHY_ID_MATCH_EXACT to match exactly on revision B of the PHY.
Because of this change then there is not need the check if it is a
different revision than rev B in the function vsc8584_probe() as we
already know that this will never happen.
These changes are a preparation for the next patch because in that patch
we will make the PHYs VSC8574 and VSC8572 to use vsc8584_probe() and
these PHYs have multiple revision.

Reviewed-by: Maxime Chevallier 
Signed-off-by: Horatiu Vultur 
Link: https://patch.msgid.link/20251023191350.190940-2-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin