Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Aug 14, 2023 at 04:12:40PM +0100, Russell King (Oracle) wrote:
> > > +		__set_bit(PHY_INTERFACE_MODE_RGMII, interfaces);
> > 
> > also, I guess that this should allow all 4 variants of RGMII.
> 
> I'm not sure - looking at what's available, the RTL8366 datasheet (not
> RB) says that there's pinstrapping for the RGMII delays. It also suggests
> that there may be a register that can be modified for this, but the driver
> doesn't appear to touch it - in fact, it does nothing with the interface
> mode. Moreover, the only in-kernel DT for this has:

> Whether that can be changed in the RB version of the device or not, I
> don't know, so whether it makes sense to allow the other RGMII modes,
> again, I don't know.
> 
> Annoyingly, gmac0 doesn't exist in this file, it's defined in
> gemini.dtsi, which this file references through a heirarchy of nodes
> (makes it very much less readable), but it points at:
> 

> So that also uses "rgmii".

... so one of them must be wrong..

> 
> I'm tempted not to allow the others as the driver doesn't make any
> adjustments, and we only apparently have the one user.

I believe you were of the opinion that the RGMII delays in the phy-mode
are from the perspective of the other end of the RGMII connection - i.e.
'rgmii-rxid' means that [ the other end, or the board serpentine traces ]
have set up a clock skew on our RX_CLK relative to our RXD[3:0].

In that interpretation, it doesn't matter whether we're doing anything
in the 4 different phy-modes for rgmii or not, and it's not illegal to
have any of those 4 properties. Only a PHY should modify RGMII delays
based purely upon a phy-mode, and we're not a PHY.

A MAC could adjust its RGMII delays based on rx-internal-delay-ps and
tx-internal-delay-ps, independently (to some extent) of what its
phy-mode is. The rtl8365mb_ext_config_rgmii() method of the related
rtl8365mb does just that.