[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2b6cd2b8-1738-4131-abfe-4ab35de70c8d@lunn.ch>
Date: Wed, 18 Dec 2024 17:57:46 +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
> Okay, I will follow your instructions:
> 1. Change the phy-mode to 'rgmii-id'.
> 2. Add the delay in the MAC driver.
> 3. Mask the phy-mode before passing it to the PHY.
Good.
>
> >
> > But i assume Qualcomm RDKs always make use of a Qualcomm PHY, there is
> > special pricing if you use the combination, so there is probably
> > little incentive to use somebody elses PHY. And i assume you can
> > quickly check all Qualcomm PHYs support RGMII delays. PHYs which don't
> > support RGMII delays are very rare, it just happened that one vendors
> > RDK happened to use one, so they ended up with delays in the MAC being
> > standard for their boards.
> >
>
> Most Qualcomm MAC applications are actually paired with a third-party PHY.
I'm not sure the QCA8K, IPC and old Atheros people would agree with
you.
But since you don't have any behaviour change, you are not asking the
PHY to insert the delays, you should be safe in your part of the
Qualcomm world.
Andrew
Powered by blists - more mailing lists