Re: [PATCH v2 2/2] arm64: dts: qcom: qcs615-ride: Enable ethernet node

[Andrew Lunn]

On Mon, Dec 09, 2024 at 10:11:23AM +0800, Yijie Yang wrote:
> 
> 
> On 2024-11-29 23:29, Andrew Lunn wrote:
> > > I was mistaken earlier; it is actually the EMAC that will introduce a time
> > > skew by shifting the phase of the clock in 'rgmii' mode.
> > 
> > This is fine, but not the normal way we do this. The Linux preference
> > is that the PHY adds the delays. There are a few exceptions, boards
> > which have PHYs which cannot add delays. In that case the MAC adds the
> > delays. But this is pretty unusual.
> 
> After testing, it has been observed that modes other than 'rgmii' do not
> function properly due to the current configuration sequence in the driver
> code.

O.K, so now you need to find out why.

It not working probably suggests you are adding double delays, both in
the MAC and the PHY. Where the PHY driver add delays is generally easy
to see in the code. Just search for PHY_INTERFACE_MODE_RGMII_ID. For
the MAC driver you probably need to read the datasheet and find
registers which control the delay.

> > If you decided you want to be unusual and have the MAC add the delays,
> > it should not be hard coded. You need to look at phy-mode. Only add
> 
> Are you suggesting that 'rgmii' indicates the delay is introduced by the
> board rather than the EMAC?

Yes.

> But according to the
> Documentation/devicetree/bindings/net/ethernet-controller.yaml, this mode
> explicitly states that 'RX and TX delays are added by the MAC when
> required'. That is indeed my preference.

You need to be careful with context. If the board is not adding
delays, and you pass PHY_INTERFACE_MODE_RGMII to the PHY, the MAC must
be adding the delays, otherwise there will not be any delays, and it
will not work.

> > delays for rgmii-id. And you then need to mask the value passed to the
> > PHY, pass PHY_INTERFACE_MODE_RGMII, not PHY_INTERFACE_MODE_RGMII_ID,
> > so the PHY does not add delays as well.

	Andrew