On 10/13/21 3:23 PM, Vladimir Oltean wrote:
> This change does not fix any functional issue or address any real life
> use case that wasn't possible before. It is just a small step in the
> process of standardizing the way in which Ethernet MAC drivers may apply
> RGMII delays (traditionally these have been applied by PHYs, with no
> clear definition of what to do in the case of a fixed-link).
>
> The sja1105 driver used to apply MAC-level RGMII delays on the RX data
> lines when in fixed-link mode and using a phy-mode of "rgmii-rxid" or
> "rgmii-id" and on the TX data lines when using "rgmii-txid" or "rgmii-id".
> But the standard definitions don't say anything about behaving
> differently when the port is in fixed-link vs when it isn't, and the new
> device tree bindings are about having a way of applying the delays in a
> way that is independent of the phy-mode and of the fixed-link property.
>
> When the {rx,tx}-internal-delay-ps properties are present, use them,
> otherwise fall back to the old behavior and warn.
>
> One other thing to note is that the SJA1105 hardware applies a delay
> value in degrees rather than in picoseconds (the delay in ps changes
> depending on the frequency of the RGMII clock - 125 MHz at 1G, 25 MHz at
> 100M, 2.5MHz at 10M). I assume that is fine, we calculate the phase
> shift of the internal delay lines assuming that the device tree meant
> gigabit, and we let the hardware scale those according to the link speed.
>
> Link: https://patchwork.kernel.org/project/netdevbpf/patch/20210723173108.459770-6-prasanna.vengateshan@xxxxxxxxxxxxx/
> Link: https://patchwork.ozlabs.org/project/netdev/patch/20200616074955.GA9092@laureti-dev/#2461123
> Signed-off-by: Vladimir Oltean <vladimir.oltean@xxxxxxx>
Reviewed-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
FWIW, this is definitively a step in the right direction, and this is a
good way to deal with the phy-mode RGMII mess that has plagued us, thanks!
--
Florian
