AW: [PATCH net-next 6/8] net: mdio: realtek-rtl9300: relocate topology setup

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

> Von: Andrew Lunn <andrew@lunn.ch> 
> Gesendet: Dienstag, 2. Juni 2026 17:18
> An: Markus Stockhausen <markus.stockhausen@gmx.de>
> Betreff: Re: [PATCH net-next 6/8] net: mdio: realtek-rtl9300: relocate
topology setup
> 
> > With the next series I want to deactivate/activate hardware polling 
> > during the whole probing process (besides other things). This avoids
> > that hardware polling fills wrong MAC register states during
> > bus/PHY setup.
> > 
> > Are you thinking about this? If yes I can add that to this series.
>
> No, i mean during normal operation. When the core takes the mdio bus
> lock, you need to disable polling until the lock is released. That is
> going to need some additional API calls in struct mii_bus.

I have always tried to avoid kernel hacks downstream and never
thought about enhancing the mii_bus. But as this seems to be 
some kind of invitation I will shortly explain the situation here.

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.

Hardware polling and PHY access coexist without any issues. The
MDIO controller coordinates the different requests and the kernel 
does not need to take care about that. 

However we have rare cases where polling should be disabled.
There is no evidence about any issues in the OpenWrt ecosystem 
but vendor SDK disables polling for certain sequence of operations. 
These include

- PHY Firmware patching
- Switching the port on a dual Fibre/Copper PHY
- Enabling/disabling EEE on a port

So we can benefit from some kind of bus enhancement that 
allows to "isolate" a PHY on a bus from any hardware interfering. 
Best case would be to allow the PHY to access these functions.

As said no idea at the moment because never thought about it.
So any guidance is appreciated.

Markus