AW: [PATCH net-next v5 2/8] net: mdio: realtek-rtl9300: Add polling documentation

["Markus Stockhausen" <markus.stockhausen@gmx.de>]

Hi Andrew,

> Von: Andrew Lunn <andrew@lunn.ch> 
> Gesendet: Mittwoch, 22. Juli 2026 21:09
> An: Markus Stockhausen <markus.stockhausen@gmx.de>
>  Betreff: Re: [PATCH net-next v5 2/8] net: mdio: realtek-rtl9300: Add
polling documentation
>
> > + * Each device has a SMI_POLL_CTRL register. A per-port bitmask decides
if the hardware polling of
> > + * the associated bus/address is active or not. The hardware runs a
tight loop over this and for
> > + * each set polling bit it issues a status check for the PHY. Attaching
a logic analyzer to the
> > + * MDIO bus of an RTL8380 and RTL8393 gives the following commands (in
kernel notation):
> ...
> 
> I've not seen anything about what you intend to do with the fact the
> hardware is polling the wrong registers.
>
> The link speed is in register 0x1a, which the polling is not looking
> at. The PHY will indicate the media side is doing 100Mbps, but the MAC
> polling register 10 probably thinks it is 1G. I expect bad things will
> then happen.
>
> I know it is not possible to configure the MAC, but can you at least
> see how it has configured the MAC? You can then make the mac_link_up()
> callback check what the phylib driver says against what the broken
> polling says, and when they are different force the interface down and
> report the hardware design is broken.

Appreciate your feedback. I will sum up the situation and my point of 
View about the C22 PHYs in this single answer.

Regarding speed detection: I ran a quick test and MAC side 100Mbit 
detection works fine. So we have no issues there. Assumption is: I only 
took some snippets from the tons of data the logic analyzer produced. 
So either the access to 0x1a runs not every poll cycle or the device 
simply derives the link speed from the default registers. From looking at 
genphy_read_status() I understand that regardless of autonegotiation 
any C22 link speed can be derived from registers 0, 1, 4, 5, 9 & 10. 
Maybe Realtek implemented that part of polling in a generic way.

Regarding hardware designs and page handling: I do not know where 
your information about non-Realteak C22 PHY is from. Maybe some 
noise about the C45 Aquantia PHYs. We have

- C22 access is only enabled for 1G PHYs [1]
- All known devices run RTL8218 (B/D/E) or RTL8214FC on 1G [2]
- RTL839x gives link flapping when deactivating polling for a port [3]
- otto_emdio_notify_phy_attach() errors out for non Realtek PHYs [4]
- RTL838x polling unconditionally resets register 31 to zero [4]

So we look at a Realtek-only ecosystem. The downstream-proven 
driver-only page handling patch without any new MDIO callbacks 
is the lowest common denominator.

Other feedback will be integrated into v6 or I will respond individually.

Best regards.

Markus

[1]
https://elixir.bootlin.com/linux/v7.2-rc4/source/drivers/net/mdio/mdio-realt
ek-rtl9300.c#L531
[2] https://github.com/openwrt/openwrt/tree/main/target/linux/realtek/dts
[3]
https://lore.kernel.org/netdev/20260629152336.2239826-9-markus.stockhausen@g
mx.de/ 
[4]
https://lore.kernel.org/netdev/20260722062356.12291-6-markus.stockhausen@gmx
.de/