Messages in this thread | | | Date | Fri, 2 Feb 2024 21:25:55 +0100 | From | Andrew Lunn <> | Subject | Re: [PATCH net-next v3 1/7] net: dsa: mt7530: empty default case on mt7530_setup_port5() |
| |
On Fri, Feb 02, 2024 at 06:05:36PM +0000, Russell King (Oracle) wrote: > On Fri, Feb 02, 2024 at 08:44:39PM +0300, Arınç ÜNAL wrote: > > On 2.02.2024 14:40, Russell King (Oracle) wrote: > > > While reviewing this change, but not related to it, I notice that this > > > function sets the TX delay based on the RGMII interface mode. This isn't > > > correct. I've explained why this is this many times in the past, but > > > essentially it comes down to the model: > > > > > > > > > phy-mode in NIC node Network driver PCB PHY > > > rgmii no delays delays no delays > > > rgmii-id no delays no delays tx/rx delays > > > rgmii-txid no delays no delays tx delays > > > rgmii-rxid no delays no delays rx delays > > > > > > Then we have rx-internal-delay-ps and tx-internal-delay-ps in the NIC > > > node which define the RGMII delays at the local end and similar > > > properties for the PHY node. > > > > > > > > > So, if we take the view that, when a switch is connected to a NIC in > > > RGMII mode, then the phy-mode specified delays still should not impact > > > the local NIC. > > > > > > Now, for the switch, we specify the phy-mode in the port node as well. > > > Consider the case of a switch port connected to a RGMII PHY. This has > > > to operate in exactly the same way as a normal NIC - that is, the > > > RGMII delays at the port should be ignored as it's the responsibility > > > of a PHY.
Not quite. It is unusual, but there are a few MAC drivers which do act on phy-mode, to configure MAC delays. However, if they do this, they then mask the value of phy-mode passed to the PHY in order to avoid double delays. Its not something i recommend, we prefer the PHYs do the delays. And it something i strongly suggest we avoid in DSA.
> > > The final scenario to examine is the case of a RGMII switch port > > > connected to a NIC.
This should also extend to a port connected to a port of another switch. For Marvell switches, these are so called DSA ports.
> > > The NIC's phy-mode has no way to be communicated > > > to DSA or vice versa, so neither phy-mode can impact the other side > > > of the RGMII link, but should only place the link into RGMII mode. > > > Given everything I've said above, the only way to configure RGMII > > > delays is via the rx-internal-delay-ps and tx-internal-delay-ps > > > properties. So, DSA drivers should _not_ be configuring their ports > > > with RGMII delays based on the RGMII phy interface mode.
Marvell goes against this. rx-internal-delay-ps and tx-internal-delay-ps are pretty new, when compared to the age of mv88e6xxx. I had the problem of a FEC connected to an mv88e6xxx using RGMII and i needed to somehow configure RGMII delays, or packets did not get through. So mv88e6xxx will apply phy-mode to ports being used in CPU or DSA mode. So in the case of the FEC->switch, rgmii-id is used by the switch. For DSA->DSA, there are DT blobs with rgmii-txid on both ends of the link, which results in the needed delays.
> > > The above is my purely logically reasoned point of view on this > > > subject. Others may have other (to me completely illogical) > > > interpretations that can only lead to interoperability issues.
Now that rx-internal-delay-ps and tx-internal-delay-ps actually exist, these are the best ways to handle such delays, for new drivers. But we cannot change old drivers without causing regressions.
Andrew
| |