MaxLinear GSW12x/GSW14x Ethernet Switch Errata Sheet states:
"An issue has been sporadically observed after device power-on on the first
link-up attempt in 100BASE-TX mode resulting in either the link-up taking a
long time, or failing to link-up altogether...
Workaround:
After power-on, enable Cable Diagnostic Mode for all ports and disable
it..."
Implement the proposed workaround unconditionally in the Intel XWAY driver
(MaxLinear GSW1xx switches incorporate Intel XWAY PHYs) because the
diagnostic bits have the same meaning even in older integral PHYs such as
GPY111/PEF7071/PHY11G. So it's not clear how to distinguish the affected
newer integrated PHYs, but the workaround should not hurt the older PHYs.
Cc: stable@vger.kernel.org
Fixes: 22335939ec ("net: dsa: add driver for MaxLinear GSW1xx switch family")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260922075251.23386-1-alexander.sverdlin@siemens.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phylink_bringup_phy() stores the PHY in pl->phydev before its last
fallible step: on a MAC whose phylink ops implement LPI,
phy_eee_rx_clock_stop() can fail with a real MDIO error. The callers
unwind with phy_detach(), which knows nothing about pl->phydev, so a
pointer to a PHY that is no longer attached outlives the failed
connect.
What that costs depends on how the caller got here.
phylink_connect_phy() goes through phylink_attach_phy(), which refuses
to attach while pl->phydev is set, turning a transient MDIO error into
a permanent -EBUSY. The SFP path is worse than that: sfp_sm_probe_phy()
answers the failure with phy_device_remove() and phy_device_free(), and
it assigns sfp->mod_phy only past that error return, so nothing clears
pl->phydev and it is left pointing at a freed phy_device that
phylink_resolve() and the ethtool helpers go on reading.
phylink_fwnode_phy_connect() has no such check, so a later connect
overwrites the stale pointer and hides the problem. A disconnect does
not: phylink_disconnect_phy() hands that pointer to phy_disconnect(),
and the second phy_detach() on the same PHY drops references the first
one already released.
Found while making a DSA port survive a PHY whose driver arrives after
the switch probes: keeping the port across a failed connect and
retrying is what makes this window reachable.
Publish the pointer after the last call that can fail instead of
unwinding it afterwards. Nothing between the two points reads
pl->phydev, and the registration that follows cannot fail:
phy_request_interrupt() falls back to polling on its own. The PHY-side
state keeps the order it had, so no MDIO operation moves relative to
another.
Fixes: 03abf2a7c6 ("net: phylink: add EEE management")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20260920222044.1752860-1-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
lanphy_write_reg_data() does not advance the data pointer while iterating
over the register table. As a result, it writes the first entry num times
and leaves the remaining errata registers unconfigured.
Single-entry tables are unaffected, but tables with multiple entries
leave every entry after the first unapplied.
Advance the data pointer after each successful write so every table entry
is applied in order.
Fixes: c8732e9339 ("net: phy: micrel: lan8842 errata")
Cc: stable@vger.kernel.org
Signed-off-by: Abhishek Ojha <abhishek.ojha@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260916231928.1336305-1-abhishek.ojha@savoirfairelinux.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mtk_phy_led_hw_ctrl_get() reports TRIGGER_NETDEV_LINK whenever any of the
speed bits in on_set is on, and in addition reports every individual
TRIGGER_NETDEV_LINK_* bit that is set. The netdev trigger refuses that
combination: netdev_led_attr_store() rejects TRIGGER_NETDEV_LINK together
with any per-speed rule, and it validates the whole resulting mode rather
than just the bit being written. Once the hardware has any link bit
programmed, every write to the trigger attributes of that LED therefore
fails with -EINVAL and the LED can no longer be configured.
The rules are also fed back into the hardware: the trigger stores what is
read back, and a later write of device_name programs it again, expanding
TRIGGER_NETDEV_LINK to every speed in on_set. An LED configured for a
single speed is thereby silently widened to "on at any link speed".
Both are easy to see on the EcoNet EN7528, whose four PHYs share one LED
block. The first LED programs the block correctly, the second reads those
rules back and rewrites them widened, and the remaining two then read the
widened value, so an LED configured for "link_10 link_100" ends up lit on a
1000 Mbps link.
on_set holds every speed the LED can indicate and is exactly what
mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so report the
speed independent rule only when all of them are on, and the individual
speeds otherwise. The mapping is then the inverse of the one used when
programming the LED and round trips without changing the register.
Fixes: c66937b0f8 ("net: phy: mediatek-ge-soc: support PHY LEDs")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260912134306.3544329-1-naseefkm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: 5b281fe7e3 ("net: phy: dp83td510: introduce LED framework support")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260908105959.70453-3-donggeunyoo.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit a274465cc3 ("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 eb89c79c1b ("net: phy:
mxl-gpy: correctly describe LED polarity") and aquantia in
commit 9d55e68b19 ("net: phy: aquantia: correctly describe LED
polarity override").
Fixes: a274465cc3 ("net: phy: support 'active-high' property for PHY LEDs")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Link: https://patch.msgid.link/20260903022839.4006614-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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 af3b4b0e59 ("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: af3b4b0e59 ("net: phy: mediatek-ge: do not disable EEE advertisement")
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Vladislav Karmanov <vladislav.karmanov.dev@gmail.com>
Link: https://patch.msgid.link/20260908145213.3976508-1-vladislav.karmanov.dev@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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: 96969b132b ("net: phylink: introduce helpers for replaying link callbacks")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20260904185540.2844261-1-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: 71e7943011 ("net: phy: air_en8811h: Add the Airoha EN8811H PHY driver")
Suggested-by: Mikhail Zhilkin <csharper2005@gmail.com>
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://patch.msgid.link/20260823130638.1166453-2-sochnev.v.74@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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: df874f9e52 ("net: phylink: add pcs_inband_caps() method")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://patch.msgid.link/20260817213009.13924-1-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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 <joey@tinyisr.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/20260813190241.789323-3-joey@tinyisr.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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 <tillo@tillo.ch>
Link: https://patch.msgid.link/20260812154708.2201266-3-tillo@tillo.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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 <tillo@tillo.ch>
Link: https://patch.msgid.link/20260812154708.2201266-2-tillo@tillo.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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 <sandeepsondagar@gmail.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260809-phylink-psgmii-v3-1-908dcd3a9e3d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 42e2a9e11a ("net: phy: dp83640: improve phydev and driver
removal handling") moved per-bus clock cleanup from module exit to the
remove path. This leaves two lifetime problems.
dp83640_clock_get_bus() publishes a newly allocated clock before the
driver allocates its per-PHY data and registers the PTP clock. If either
operation fails, no PHY is bound and the remove callback cannot release
the clock, leaking the clock and the MII bus device reference.
The remove path can also free a clock after dropping clock_lock. A
concurrent probe may already have found the clock under
phyter_clocks_lock and be waiting for clock_lock, allowing it to acquire
a freed mutex and access the freed clock.
Use the PHY package infrastructure for the per-bus clock. PHY packages
are tracked per MII bus, and the driver uses BROADCAST_ADDR as the
package key so the DP83640 PHYs on the same bus share the same clock
storage. Call phy_package_join() during probe and phy_package_leave() on
probe errors and in remove.
Serialize the one-time clock initialization with the package lock because
phy_package_probe_once() elects an initializer but does not wait for
initialization to finish.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-5-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dp83640_probe() publishes its per-PHY state through phydev before
registering the PTP clock. If registration fails, the private data is
freed while phydev->mii_ts and phydev->priv still point to it, and
default_timestamp remains set.
Clear the published PHY state and reset the PTP clock pointer before
freeing the private data.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The DP83640 has a fixed number of PTP pins, and its pin configuration
has the same lifetime as the per-bus clock. Allocating the configuration
separately adds an allocation failure path and requires a separate free.
Embed the pin configuration in struct dp83640_clock and point the PTP
clock information at the embedded array. This changes only the storage;
the pin functions remain configurable at runtime. It also allows all
per-bus clock storage to be managed as one allocation.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The PHY package API provides private data shared by all PHYs in a
package. Drivers are responsible for synchronizing access to this data,
but the API does not provide a lock for that purpose.
Add phy_package_lock() and phy_package_unlock() for drivers to serialize
access to package-private data, including its initialization.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
hwmon_sanitize_name() allocates sfp->hwmon_name before
hwmon_device_register_with_info() is called. If the registration
fails, sfp->hwmon_dev is left pointing to an error while
sfp->hwmon_name remains allocated.
Later, when the SFP module is removed, sfp_hwmon_remove() only frees
hwmon_name when hwmon_dev is valid. As a result, hwmon_name is leaked
if hwmon_device_register_with_info() fails.
Free hwmon_name independently of hwmon_dev. Continue to unregister the
hwmon device only when hwmon_dev was successfully registered.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Krishan Singh <krishanmohan298@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260809064504.70579-1-krishanmohan298@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: da681ed73f ("net: phy: realtek: improve mmd register access for internal PHY's")
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260806134716.3511821-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a new PHY driver for the DAPU Telecom DAP8211R(I) Gigabit
Ethernet PHY, which is commonly used in enterprise and industrial
networking applications.
The driver implements extended register access via indirect addressing
through corresponding registers, and provides comprehensive device tree
support for RGMII delay configuration. The rx-internal-delay-ps and
tx-internal-delay-ps properties allow precise tuning of clock delays in
150 ps steps from 0 to 2250 ps.
Signed-off-by: Artem Shimko <a.shimko.dev@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260805085540.452260-4-a.shimko.dev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The EcoNet EN7528 MIPS SoC embeds four Gigabit Ethernet PHYs (PHY ID
0x03a29491) behind its built-in MT7530 switch. They use the same LED
register layout as the other SoC PHYs handled by this driver, but their
LED controller powers up with its external control disabled, so the LED
pins stay dark regardless of what is programmed into the LED control
registers.
Add a phy_driver entry for it, modelled on the Airoha AN7583 one. Its
config_init callback enables the LED controller through the LED basic
control register, which this driver does not program for its other
PHYs, but which the air_en8811h driver already handles as
AIR_PHY_LED_BCR. LED behaviour is then controlled through the phylib
LED operations shared with the other PHYs of this driver.
The LED block is shared by the four PHYs of the EN7528: the LED
configuration programmed through any one of them applies to all four,
while each PHY still drives its own LED pin from its own link state.
The EN7528 PHYs need no efuse calibration data, so relax the
MEDIATEK_GE_SOC_PHY dependencies to allow building the driver on the
ECONET platform.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260804103321.3331802-1-naseefkm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: 7f9c320c98 ("net: phy: mediatek: Move LED helper functions into mtk phy lib")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260804113511.3371248-1-naseefkm@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
tja1102_p0_probe() schedules work to register the second port. That work
uses the Port 0 private data and phydev. The private data is
devm-allocated, but the driver does not wait for the pending work on
remove.
Store the Port 0 private data in phydev->priv and add a remove callback.
The callback cancels the registration work before devres teardown frees
the state.
This issue was found by a static analysis tool.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://patch.msgid.link/20260801140643.1871-1-getshell@seu.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 42310a2438 ("net: phy: motorcomm: Enable optional clock for
YT8531") enables the SoC-provided reference clock for the YT8531 in its
probe. The YT8521 has the same need on crystal-less boards but goes
through yt8521_probe(), so enable it there too. The clock is optional,
so crystal-clocked boards are unaffected.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Gavin Gao <attinagaoxu@gmail.com>
Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
Link: https://patch.msgid.link/20260731013807.1488843-1-gahing@gahingwoo.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that we have proper decision making for inband mode support which
makes it a "best efforts" feature based on the capabilities of the PHY
and PCS, we can relax whether we expect and permit a PHY to be
attached. This is especially true for the 2500BASE-X case which some
PHYs use without inband on their host side interface for 2.5G speeds,
but use inband for slower speeds switching to SGMII on their host side
interface.
We already have such a case for some qcom-ethqos setups, although
qcom-ethqos overrides phylink's inband settings by accessing the PCS
directly at the moment. This should allow qcom-ethqos to transition to
defaulting to inband when 2500BASE-X or SGMII is specified in its DTS.
Allow PHYs to be attached when inband mode has been specified, which
will be necessary to allow inband mode to be used on qcom-ethqos.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260729074237.2624940-3-zxyan0222@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RTL8261D is also 10g phy. It's sub_phy_id is 0x81. And it does not need
any firmware.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260728073106.1515-6-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds support for loading firmware. Download some parameters
for RTL8261C_CG.
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260728073106.1515-5-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds support for Realtek phy chip RTL8261C_CG. Its PHY ID is
0x001cc898.
This patch introduces a distinct family of handlers (probe, get_features,
config_aneg, read_status, config_intr, handle_interrupt).
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260728073106.1515-4-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds two static helpers in drivers/net/phy/phy-c45.c to
configure and read back master-slave roles for non BASE-T1 Clause 45
PHYs via the 10GBASE-T AN control/status registers.
These helpers are wired into genphy_c45_config_aneg() and
genphy_c45_read_status(). This changes the observable ethtool output
for drivers using the generic c45 read path.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260728073106.1515-3-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a generic Clause 45 software reset helper. The helper sets the reset
bit in the PMA/PMD control register and waits until the bit is cleared by
hardware.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260728073106.1515-2-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ksz9131 is configured for local loopback in a similar fashion as the
ksz9031, with a need for full-duplex operation, but with some extra
steps to take as specified in section 4.13.1 :
1. Configure the following registers:
- MMD 1C, Register 15 = EEEE
- MMD 1C, Register 16 = EEEE
- MMD 1C, Register 18 = EEEE
- MMD 1C, Register 1B = EEEE
These 4 registers are marked as "Reserved" in the register map.
When setting loopback up without configuring these 4 registers, the PHY
appears to shut its RXC down, which can trigger failures on MACs that
require it, such as stmmac.
The datasheet does not specify to which state the registers must be
reset when disabling loopback, so let's restore them to their measured
initial values.
This was discovered when trying to use stmmac selftests on imx8mp with a
ksz9131 connected in RGMII.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260728075222.956780-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260725150852.859188-4-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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 ce0aa27ff3 ("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: ce0aa27ff3 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260726150806.2437-1-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cross-merge networking fixes after downstream PR (net-7.2-rc5).
Conflicts:
drivers/net/amt.c
3656a79f94 ("amt: re-read skb header pointers after every pull")
586c4dcf28 ("amt: no longer rely on RTNL in amt_fill_info()")
https://lore.kernel.org/amIaJr3aOQNS_Fvl@sirena.org.uk
Adjacent changes:
drivers/net/geneve.c
8efb8f8bbb ("geneve: require CAP_NET_ADMIN in the device netns for changelink")
0ba269933f ("geneve: convert config to RCU-protected pointer")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some boards feed the YT8531 PHY from an SoC-provided external
reference clock described by the common ethernet-phy "clocks" property.
Enable the optional PHY clock during probe so boards can model this
clock as a PHY input instead of keeping the clock alive from the MAC
driver.
This is needed on the Alientek DLRV1126, where the PHY reference clock
is provided by CLK_GMAC_ETHERNET_OUT.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
Link: https://patch.msgid.link/20260714-motorcomm-yt8531-clk-v3-1-10dc303ef1a5@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add quirk for a copper SFP+ module that identifies itself as "OEM"
"HC-10GE-113C". It uses RollBall protocol to talk to the PHY.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260719100158.874882-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
During a tree-wide gpio include cleanup, the linux/gpio.h include was
replaced with linux/gpio/consumer.h.
mdio-device.c was already including that header, resulting in a
duplicated inclusion. Let's drop it.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260715201213.206180-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a driver for the ADIN1140's internal 10BASE-T1S PHY. The device
doesn't implement autonegotiation, so the link is always reported as
being up.
The device implements both C22 and C45 MDIO access methods, but can only
be discovered over C22, since the C45 MMD devices lack the MDIO_DEVID1 and
MDIO_DEVID2 registers. The indirect C45 over C22 feature is not
supported.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Link: https://patch.msgid.link/20260708-adin1140-driver-v5-12-4aca7b51a58b@analog.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace the driver specific lan865x_phy_read_mmd() and
lan865x_phy_write_mmd() with the shared genphy_read_mmd_c45() and
genphy_write_mmd_c45() helpers.
No functional change.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Link: https://patch.msgid.link/20260708-adin1140-driver-v5-11-4aca7b51a58b@analog.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Some PHYs support direct C45 register access but not C22 indirect MMD
access (registers 0xD and 0xE). When discovered via C22, phylib routes
MMD access through the indirect path, which won't work on these
devices.
Add genphy_read_mmd_c45() and genphy_write_mmd_c45() as read_mmd/
write_mmd callbacks that bypass the C22 indirect path and use the bus
C45 accessors directly.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Link: https://patch.msgid.link/20260708-adin1140-driver-v5-10-4aca7b51a58b@analog.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Return the correct error code, not the value written to the register.
Fixes: a219912e0f ("net: phy: marvell: implement config_inband() method")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260706120637.1947685-1-mwalle@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The at803x family of devices are subjected to an errata that requires
hard-reseting the PHY upon link change.
That can only work if there's a physical reset line wired to the PHY,
which the driver checks by looking if there's a reset GPIO configured
for the MDIO device.
The reset may however be controlled through a reset controller, which
isn't accounted for in the errata handling.
Besides that, PHY drivers aren't expected to directly access the
mdiodev's resources directly, let's therefore wrap this with a phylib
helper, that uses a similar mdio helper to check for reset existence.
This was found in preparation for bus-level resource management for
better mdio scan support.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260715101355.88536-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Cross-merge networking fixes after downstream PR (net-7.2-rc2).
No conflicts.
Adjacent changes:
MAINTAINERS:
56114690ff ("MAINTAINERS: Update Marvell octeontx2 driver maintainers")
eb56577ae9 ("ehea: remove the ehea driver")
net/core/netpoll.c:
45f1458a85 ("netpoll: fix a use-after-free on shutdown path")
84c0ff1efb ("netpoll: do not warn when the best-effort pool refill fails")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The phylink_mac_ops '.validate()' has been removed in:
commit da5f6b80ad ("net: phylink: remove .validate() method")
There are still a few comments around in phylink that references that,
related to the ports fields as well as the Pause configuration. Let's
drop these references and update the comments related to Pause handling.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260630083700.2041915-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
linux/gpio.h should no longer be used, change these in drivers/net to
linux/gpio/consumer.h where possible, with b53 being the only one still
using linux/gpio/legacy.h.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260629132633.1300009-7-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This reverts commit 8fe125892f ("net: phy: sfp: probe for RollBall
I2C-to-MDIO bridge in mdio-i2c").
That commit added a RollBall bridge probe at MDIO bus creation time, in
i2c_mii_init_rollball(), to avoid a multi-minute PHY probe retry loop on
modules without a bridge (e.g. RTL8261BE). The probe runs in SFP_S_INIT,
before genuine RollBall modules have finished their firmware/bridge
initialization, so the bridge does not yet answer CMD_READ/CMD_DONE. The
probe times out, mdio_protocol is set to MDIO_I2C_NONE, and PHY detection
is then skipped for genuine RollBall modules that worked before the commit.
This was confirmed on hardware by Maxime Chevallier and Aleksander
Bajkowski: their RollBall modules no longer detect a PHY, and work again
on v7.0 (before the bridge probing was introduced). The Sashiko static
review flagged the same path.
Deferring the probe to PHY discovery time does not fix it either: at that
point a slow module may still be initializing, so the probe still returns
-ENODEV. A proper fix needs per-module init timing (a longer module_t_wait
or a per-module quirk, per SFF-8472 the host must also wait at least 300 ms
after insertion), which requires genuine RollBall hardware to develop and
validate. Revert to restore the previous, working behaviour in the meantime.
The RTL8261BE retry-loop latency that the reverted commit addressed is
handled in our downstream tree, so reverting upstream is safe on our side.
Fixes: 8fe125892f ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c")
Reported-by: Aleksander Bajkowski <olek2@wp.pl>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/23e3931915c3ed2a14cec95f1490e43d30b225e8.1782581445.git.petr.wozniak@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
