[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2800557-225d-4fbd-83ee-d4b72eb587ce@oss.qualcomm.com>
Date: Fri, 22 Nov 2024 13:27:00 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Yijie Yang <quic_yijiyang@...cinc.com>, Andrew Lunn <andrew@...n.ch>
Cc: 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 19.11.2024 11:09 AM, Yijie Yang wrote:
>
>
> On 2024-11-19 09:27, Andrew Lunn wrote:
>> On Mon, Nov 18, 2024 at 02:44:02PM +0800, Yijie Yang wrote:
>>> Enable the ethernet node, add the phy node and pinctrl for ethernet.
>>>
>>> Signed-off-by: Yijie Yang <quic_yijiyang@...cinc.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/qcs615-ride.dts | 106 +++++++++++++++++++++++++++++++
>>> 1 file changed, 106 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
>>> index ee6cab3924a6d71f29934a8debba3a832882abdd..299be3aa17a0633d808f4b5d32aed946f07d5dfd 100644
>>> --- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
>>> +++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
>>> @@ -5,6 +5,7 @@
>>> /dts-v1/;
>>> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>>> +#include <dt-bindings/gpio/gpio.h>
>>> #include "qcs615.dtsi"
>>> / {
>>> model = "Qualcomm Technologies, Inc. QCS615 Ride";
>>> @@ -196,6 +197,60 @@ vreg_l17a: ldo17 {
>>> };
>>> };
>>> +ðernet {
>>> + status = "okay";
>>> +
>>> + pinctrl-0 = <ðernet_defaults>;
>>> + pinctrl-names = "default";
>>> +
>>> + phy-handle = <&rgmii_phy>;
>>> + phy-mode = "rgmii";
>>
>> That is unusual. Does the board have extra long clock lines?
>
> Do you mean to imply that using RGMII mode is unusual? While the EMAC controller supports various modes, due to hardware design limitations, only RGMII mode can be effectively implemented.
Is that a board-specific issue, or something that concerns the SoC itself?
>
>>
>>> + max-speed = <1000>;
>>
>> Why do you have this property? It is normally used to slow the MAC
>> down because of issues at higher speeds.
>
> According to the databoot, the EMAC in RGMII mode can support speeds of up to 1Gbps.
I believe the question Andrew is asking is "how is that effectively
different from the default setting (omitting the property)?"
Konrad
Powered by blists - more mailing lists