| Age | Commit message (Collapse) | Author |
|---|
|
Cross-merge networking fixes after downstream PR (net-7.3-rc3).
Conflicts:
drivers/net/dsa/mt7530.c
3c18e3c9a54e ("net: dsa: mt7530: populate lpi_interfaces to fix EEE support")
10d9d8328e8a ("net: dsa: mt7530: replace mt7530_read with regmap_read")
Adjacent changes:
drivers/net/bonding/bond_alb.c
1746ef2e2df2 ("bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()")
4cef95f72bbd ("bonding: fix u32 overflow in compute_gap()")
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: 5b281fe7e396 ("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 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 <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 AN8811HB comes in two package variants, AN8811HBCN and AN8811HBN,
which use different GPIO pins to drive LED outputs. AN8811HBCN uses
GPIOs 0, 1, and 15, while AN8811HBN uses GPIOs 3, 4, and 5. Using a
fixed GPIO assignment causes incorrect LED behavior on one of the
variants.
Read the package variant from the read-only silicon identification bits
in AN8811HB_HWTRAP2 at probe time and store it in priv->is_an8811hbcn.
Add an8811hb_led_gpio_setup() to configure the correct GPIO output pins
and select lines based on the detected variant, and call it from
config_init.
Signed-off-by: Weiting Lee <weiting.lee@airoha.com>
Link: https://patch.msgid.link/20260907015638.2875763-1-weiting.lee@airoha.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
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 <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: 96969b132bf1 ("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 YT6801 PCIe NIC includes the dwmac-motorcomm IP for the MAC part, as
well as a YT8531S PHY, configured in GMII mode.
It seems this PHY requires the Analog Front-end (AFE) DAC clock to be
enabled for link to reliably establish, otherwise the link just doesn't
come up.
Let's enable it at config_init() whenever the PHY is in GMII mode.
This logic has been extracted from the vendor driver provided by
Motorcomm.
It's really unclear if this is specific to the integrated version of
that PHY, and how this potentially interacts with the fiber mode this
PHY supports, so this configuration is only enabled when the interface
is GMII, i.e. the PHY is integrated.
With this, the PHY reliably establishes link and the YT6801 PCIe card
becomes fully functional. Supend/Resume was also tested, the link
stays operational after resume.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-4-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The YT8531S PHY configuration logic is similar to the YT8521, but with
some extra steps for the RGMII configuration. In preparation for
improvements in the YT8531S configuration for the version found
integrated with the YT6801 PCIe NIC, let's split the logic out by
extending the YT8521 configuration sequence.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In preparation for separate .config_init() implementations for YT8521
and YT8531S, let's split the yt8521_config_init() into a high-level
helper that deals with page handling, and another one that implements
the logic. This will ease splitting the YT8531S-specific logic out.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://patch.msgid.link/0e869f49c910ce054aa22ae84480aab69420bb92.1788425654.git.geert+renesas@glider.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The issue was discovered via smatch static analyzer:
make CHECK="smatch -p=kernel" C=2 drivers/net/phy/microchip_t1.o
CHECK scripts/mod/empty.c
DESCEND objtool
CHECK drivers/net/phy/microchip_t1.c
drivers/net/phy/microchip_t1.c:1295 lan887x_phy_init() warn: 'priv->clock' can also be NULL
mchp_rds_ptp_probe() returns NULL when CONFIG_MICROCHIP_PHY_RDS_PTP or
CONFIG_PTP_1588_CLOCK is disabled. However, lan887x_phy_init() only checks
for an error pointer before using the returned clock to configure the
periodic output pin, which can result in a NULL pointer dereference.
Handle the NULL return as PTP being unavailable and skip the event pin
configuration in that case. Smatch no longer reports the NULL dereference
warning after the change.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Reviewed-by: Divya Koppera <Divya.Koppera@microchip.com>
Signed-off-by: Henry Hu <huhai@kylinos.cn>
Link: https://patch.msgid.link/20260903113046.163630-1-15815827059@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The download loop streams the blob into the MCU as 32-bit words and
reads the last word past the end of a blob whose size is not a multiple
of four. The shipped blobs happen to be aligned, so the overread never
showed; a truncated or foreign file would carry up to three bytes of
whatever follows it into the MCU. Reject it before the first write
instead.
Cc: stable+noautosel@kernel.org # needs real net-admin (non-ns)
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20260903123650.23855-1-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
RTL8127atf is also a fiber mode card, but its sds reg base addr is
0x0080, which is different from RTL8116af. Add 10g and 1g support for
RTL8127atf in this patch.
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831053745.1197-6-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
For Realtek nics, when we enable jumbo, pause are not supported. So we
must check the pause capabilities from ourself and lp.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260831053745.1197-3-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <donggeunyoo.kernel@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260902065828.1031113-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <kuba@kernel.org>
Signed-off-by: Ziyou Xu <xuziyougm@gmail.com>
Link: https://patch.msgid.link/20260829033844.1975-1-xuziyougm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <ioana.ciornei@nxp.com>
Co-developed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260922-for-upstream-lynx-25gbaser-v1-v2-1-1e6cf79c7b52@free.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <daniel@makrotopia.org>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-6-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-5-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-7-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <maxime.chevallier@bootlin.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-6-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-5-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
phy_probe() uses one cleanup path for failures at every initialization
stage. This runs cleanup for resources that have not been initialized.
After a successful probe and remove, phy_led_triggers_unregister() can
leave phy_num_led_triggers non-zero after freeing the trigger array. If a
subsequent probe fails before LED trigger registration, the common error
path calls phy_led_triggers_unregister() with a NULL array and stale count,
causing a NULL dereference.
Split the cleanup by initialization stage so each failure path unwinds only
the resources that may have been initialized. Unregister LED triggers
before releasing the SFP upstream and ports, because the LED triggers are
initialized after those resources and must be unwound first.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-2-xuanqiang.luo@linux.dev
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: 71e79430117d ("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: df874f9e52c3 ("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 42e2a9e11a1d ("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>
|
|
Cross-merge networking fixes after downstream PR (net-7.2-rc8).
No conflicts.
Adjacent changes:
drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling")
d661abdc30c2 ("net: ngbe: correct misleading interrupt comment")
drivers/net/ipvlan/ipvlan_main.c
e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev")
00a40d809207 ("ipvlan: Support per-netns netdev unregistration.")
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: da681ed73fb9 ("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>
|
|
Cross-merge networking fixes after downstream PR (net-7.2-rc7).
No conflicts, or adjacent changes.
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: 7f9c320c98db ("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 42310a24389c ("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>
|
