Realtek Otto PHY hardware polling

Realtek Otto PHY hardware polling

[Markus Stockhausen]

Hi Andrew,

> Von: Andrew Lunn <andrew@lunn.ch> 
> Gesendet: Dienstag, 2. Juni 2026 22:30
> An: Markus Stockhausen <markus.stockhausen@gmx.de>
> Betreff: Re: [PATCH net-next 6/8] net: mdio: realtek-rtl9300: relocate
topology setup
> 
> > The hardware polling in these devices is very important for the DSA
> > driver. Especially as a port can be either PHY or SerDes driven. Some
> > MAC operations simply do not work if a wrong state is reported.
> 
> And you will get the wrong state if the timing of the poll is in the
> middle of the PHY driver swapping the page to read/write something.
> 
> I've not looked at what PHYs you plan to support, but code like
> 
>
https://elixir.bootlin.com/linux/v7.0.10/source/drivers/net/phy/realtek/real
tek_main.c#L907
> 
> could be called every 50ms to blink the LEDs. That changes the page,
> writes a register, and then changes back to the original page. If the
> HW polling happens in the middle of that, it will read from the wrong
> place. If that HW poll actually changes the page, without restoring
> it, the write made in that function could go to the wrong page.
> 
> So, in order to be able to use the Linux PHY drivers, you need to
> ensure the Linux PHY drivers has exclusive access to the bus when it
> needs it.

Thank you for the journey we are on together. Today I took a a lot of
time to get a better picture of this. First of all the hardware polling
is tightly coupled with the MDIO bus access. So by design the software 
access to the PHYs is automatically synchronized with the polling. 
Basically there is no need to disable/enable polling for an access. 
We are running OpenWrt with polling enabled all the time without 
major issues. 

As advised I hammered the bus of the RTL9300 with several 
access patterns over a few hours. I took the upstream driver that
writes directly to the PHY and does not cache the page like downstream
. So even more stress and chances of wrong pages on the PHY. 
No issue occured. 

While doing so I checked the Realtek SDK regarding enabling and 
disabling of hardware polling. What I found [1]:

- enabling/disabling polling is more often in RTL838x and RTL839x
- It is only used for special functions (fiber, EEE, hard reset, SerDes
  calibration).
- Usage is mostly for the RTL8218B / RTL8214FC PHY
- And another twist: RTL839x can only configure polling for all ports
  at once with a global flag.

From the not yet ported SDK code snippets I read today, I'm even 
more convinced that we only need some sort of controlled polling 
enabling/disabling for specific access sequences. 

That said and from over a year of downstream driver evolution I can
only say that in its current form it fits our needs. I'm even unsure if
this is only some kind of safety for engeneering samples or older
chip revisions. So I will try to stay with the lockless approach as long as 
possible and only use it during bus setup when the PHYs are probed
and spooky initialization sequences are running.

Will give this another test on the RTL83xx when upstreaming that code.

Once again thank you and best regards.

Markus

[1]
https://github.com/reyalo/Realtek/blob/31ad7755468e4b72cd9473b4a545513de8288
f47/sources/rtk-dms1250/src/hal/mac/miim_common_drv.c#L1054

Re: Realtek Otto PHY hardware polling

[Andrew Lunn]

> Basically there is no need to disable/enable polling for an access. 
> We are running OpenWrt with polling enabled all the time without 
> major issues. 

> - It is only used for special functions (fiber, EEE, hard reset, SerDes
>   calibration).

One obvious question is, why are these special? Hard reset i can
understand, you need to know the reset is complete before trying to
use the registers. But the others?

Either we need some documentation from Realtek, or we need to reverse
engineer the hardware to understand what it does.

Can you snoop the bus with a bus pirate, or similar? Can you see the
transactions it does for polling? Does it read the page register
first, do what it needs to do, and then restore the page register? If
the timing of the poll and driver accesses overlaps, do you see it
correctly defer the driver access until after the poll completes?

And if EEE needs to be special, how are you going to implement that in
the kernel?

	Andrew

AW: Realtek Otto PHY hardware polling

[Markus Stockhausen]

> Von: Andrew Lunn <andrew@lunn.ch> 
> Gesendet: Sonntag, 7. Juni 2026 08:39
> An: Markus Stockhausen <markus.stockhausen@gmx.de>
> Cc: netdev@vger.kernel.org; chris.packham@alliedtelesis.co.nz;
daniel@makrotopia.org; 'Jonas Jelonek' <jonas.jelonek@protonmail.ch>
> Betreff: Re: Realtek Otto PHY hardware polling
> 
> > Basically there is no need to disable/enable polling for an access. 
> > We are running OpenWrt with polling enabled all the time without 
> > major issues. 
> 
> > - It is only used for special functions (fiber, EEE, hard reset, SerDes
> >   calibration).
> 
> One obvious question is, why are these special? Hard reset i can
> understand, you need to know the reset is complete before trying to
> use the registers. But the others?
> 
> Either we need some documentation from Realtek, or we need to reverse
> engineer the hardware to understand what it does.

Just out of curiosity I ordered a logic analyzer. Lets see
if it tells us more.

Markus