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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aa1dcdf6-94a0-4922-83f0-3cf49516ac4f@quicinc.com>
Date: Wed, 18 Dec 2024 15:25:22 +0800
From: Yijie Yang <quic_yijiyang@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
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



On 2024-12-17 18:18, Andrew Lunn wrote:
> On Tue, Dec 17, 2024 at 10:26:15AM +0800, Yijie Yang wrote:
>>
>>
>> On 2024-12-16 17:18, Andrew Lunn wrote:
>>>> I intend to follow these steps. Could you please check if they are correct?
>>>> 1. Add a new flag in DTS to inform the MAC driver to include the delay when
>>>> configured with 'rgmii-id'. Without this flag, the MAC driver will not be
>>>> aware of the need for the delay.
>>>
>>> Why do you need this flag?
>>>
>>> If the phy-mode is rgmii-id, either the MAC or the PHY needs to add
>>> the delay.
>>>
>>> The MAC driver gets to see phy-mode first. If it wants to add the
>>> delay, it can, but it needs to mask out the delays before passing
>>> phy-mode to the PHY. If the MAC driver does not want to add the
>>> delays, pass phy-mode as is the PHY, and it will add the delays.
>>
>> In this scenario, the delay in 'rgmii-id' mode is currently introduced by
>> the MAC as it is fixed in the driver code. How can we enable the PHY to add
>> the delay in this mode in the future (If we intend to revert to the most
>> common approach of the Linux kernel)? After all, the MAC driver is unsure
>> when to add the delay.
> 
> You just take out the code in the MAC driver which adds the delay and
> masks the phy-mode. 2ns should be 2ns delay, independent of who
> inserts it. The only danger is, there might be some board uses a PHY
> which is incapable of adding the 2ns delay, and such a change breaks
> that board.

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.

> 
> 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 agree that the original author's PHY might not support adding the 
delay. However, this assumption cannot be verified since the initial 
code was uploaded from the internal code base.

> 	Andrew
> 

-- 
Best Regards,
Yijie