From: Jan Hoffmann <jan@3e8.eu>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King <linux@armlinux.org.uk>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: sfp: add quirk for XikeStor SKT-2.5G-100M
Date: Tue, 22 Sep 2026 21:34:11 +0200 [thread overview]
Message-ID: <64e712bb-4c2a-4738-9f99-7c8496e2d4d9@3e8.eu> (raw)
In-Reply-To: <b4a42595-295e-456b-82a0-91076f72407d@lunn.ch>
Hi Andrew,
>> Note: The RTL8221B PHY in this module becomes stuck in a broken state
>> after attempting to read some registers on MMD 30 while it has already
>> established a link (this is a general issue with this PHY which happens
>> when it is configured for rate adaptation mode).
>
> This sounds like something which should be fixed in the PHY
> driver. Can you take a look at that. Is there an errata for it with a
> suggested workaround?
Unfortunately, the read access which can break the PHY happens already
in "get_phy_c45_ids", i.e. before the PHY driver is attached (and this
is the only place where such a read access occurs).
I am not sure if there is any errata or official documentation about
this issue.
What I do know is based on experimentation with mdio-tools (with some
clues from existing driver code):
If bit 0 of register 0x75f3 on MMD 30 is set, reading any register on
MMD 30 except for the actual SerDes registers (and also registers 5/6)
breaks the PHY. In the broken state, all registers on MMD 30 (as well as
registers 5/6 on all other MMDs) only read "0xdead". To make the PHY
work again properly, a hardware reset is necessary.
When the PHY is configured to use either 2500Base-X with rate matching
or HiSGMII only, it sets this bit as soon as a link is established. The
PHY doesn't set this bit when 2500Base-X+SGMII or HiSGMII+SGMII mode is
configured (i.e. dynamic switching depending on link speed).
(The driver unsets this bit when configuring the interface mode in
"rtl822x_set_serdes_option_mode". Otherwise I probably would have never
found the relation of that register to the issue.)
Some devices are unaffected by this issue, for example if the bootloader
already configures the PHY to use 2500Base-X+SGMII or HiSGMII+SGMII (or
at least can be made to do so).
Since the PHY takes about 4 seconds after hardware reset to establish a
link, any devices where the kernel can do a reset are also not affected
(like this SFP module, as long as the host supports TX_DISABLE).
I would really like to have a general fix for cases where neither of
these two workarounds happen to already be in place. But I'm not sure
how this could be done cleanly, as it requires special handling for
these PHYs in the function that reads the PHY ID (or even before that).
Downstream in OpenWrt, I added a patch for "get_phy_c45_ids" to avoid
reading MMD 30 from RTL8221B PHYs based on the PHY ID in MMD 1:
https://github.com/openwrt/openwrt/commit/88dcd8c303b688b344c8f22c24df6a49f6b6b707
But hardcoding it like this in the kernel core feels more like a hack
than a solution.
One idea I had is if it would be possible to make "get_phy_c45_ids"
change its behaviour based on a device tree property or a SFP quirk.
>> Signed-off-by: Jan Hoffmann <jan@3e8.eu>
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> Andrew
Thanks,
Jan
next prev parent reply other threads:[~2026-09-22 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 19:26 Jan Hoffmann
2026-09-22 12:06 ` Andrew Lunn
2026-09-22 19:34 ` Jan Hoffmann [this message]
2026-09-22 20:19 ` Andrew Lunn
2026-09-23 21:00 ` Jan Hoffmann
2026-09-23 23:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64e712bb-4c2a-4738-9f99-7c8496e2d4d9@3e8.eu \
--to=jan@3e8.eu \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®