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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d711ee4b-b315-4d34-86a6-1f1e2d39fc8d@quicinc.com>
Date: Tue, 17 Dec 2024 10:26:15 +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-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.

> 
> There is nothing special here, every MAC/PHY pair does this, without
> needing additional properties.
> 
> 	Andrew

-- 
Best Regards,
Yijie


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ