[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4a6a6697-a476-40f4-b700-09ef18e4ba22@lunn.ch>
Date: Fri, 29 Nov 2024 16:29:03 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Yijie Yang <quic_yijiyang@...cinc.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Richard Cochran <richardcochran@...il.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: qcs615-ride: Enable ethernet
node
> 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.
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
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
Powered by blists - more mailing lists