linux-kernel - Re: [PATCH v3 2/4] net: stmmac: dwmac-qcom-ethqos: Mask PHY mode if configured with rgmii-id

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: <80762356-f827-4a78-9ccf-dbe644248667@quicinc.com>
Date: Tue, 11 Feb 2025 09:20:18 +0800
From: Yijie Yang <quic_yijiyang@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Krzysztof Kozlowski
	<krzk@...nel.org>,
        Andrew Lunn <andrew+netdev@...n.ch>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio
	<konradybcio@...nel.org>,
        Richard Cochran <richardcochran@...il.com>
CC: <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 2/4] net: stmmac: dwmac-qcom-ethqos: Mask PHY mode if
 configured with rgmii-id



On 2025-02-11 02:01, Konrad Dybcio wrote:
> On 10.02.2025 4:09 AM, Yijie Yang wrote:
>>
>>
>> On 2025-01-27 18:49, Konrad Dybcio wrote:
>>> On 22.01.2025 10:48 AM, Krzysztof Kozlowski wrote:
>>>> On 22/01/2025 09:56, Yijie Yang wrote:
>>>>>
>>>>>
>>>>> On 2025-01-21 20:47, Krzysztof Kozlowski wrote:
>>>>>> On 21/01/2025 08:54, Yijie Yang wrote:
>>>>>>> The Qualcomm board always chooses the MAC to provide the delay instead of
>>>>>>> the PHY, which is completely opposite to the suggestion of the Linux
>>>>>>> kernel.
>>>>>>
>>>>>>
>>>>>> How does the Linux kernel suggest it?
>>>>>>
>>>>>>> The usage of phy-mode in legacy DTS was also incorrect. Change the
>>>>>>> phy_mode passed from the DTS to the driver from PHY_INTERFACE_MODE_RGMII_ID
>>>>>>> to PHY_INTERFACE_MODE_RGMII to ensure correct operation and adherence to
>>>>>>> the definition.
>>>>>>> To address the ABI compatibility issue between the kernel and DTS caused by
>>>>>>> this change, handle the compatible string 'qcom,qcs404-evb-4000' in the
>>>>>>> code, as it is the only legacy board that mistakenly uses the 'rgmii'
>>>>>>> phy-mode.
>>>>>>>
>>>>>>> Signed-off-by: Yijie Yang <quic_yijiyang@...cinc.com>
>>>>>>> ---
>>>>>>>     .../net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 18 +++++++++++++-----
>>>>>>>     1 file changed, 13 insertions(+), 5 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>>>>>>> index 2a5b38723635b5ef9233ca4709e99dd5ddf06b77..e228a62723e221d58d8c4f104109e0dcf682d06d 100644
>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>>>>>>> @@ -401,14 +401,11 @@ static int ethqos_dll_configure(struct qcom_ethqos *ethqos)
>>>>>>>     static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos)
>>>>>>>     {
>>>>>>>         struct device *dev = &ethqos->pdev->dev;
>>>>>>> -    int phase_shift;
>>>>>>> +    int phase_shift = 0;
>>>>>>>         int loopback;
>>>>>>>            /* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
>>>>>>> -    if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
>>>>>>> -        ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
>>>>>>> -        phase_shift = 0;
>>>>>>> -    else
>>>>>>> +    if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID)
>>>>>>>             phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
>>>>>>>            /* Disable loopback mode */
>>>>>>> @@ -810,6 +807,17 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>>>>>>>         ret = of_get_phy_mode(np, &ethqos->phy_mode);
>>>>>>>         if (ret)
>>>>>>>             return dev_err_probe(dev, ret, "Failed to get phy mode\n");
>>>>>>> +
>>>>>>> +    root = of_find_node_by_path("/");
>>>>>>> +    if (root && of_device_is_compatible(root, "qcom,qcs404-evb-4000"))
>>>>>>
>>>>>>
>>>>>> First, just check if machine is compatible, don't open code it.
>>>>>>
>>>>>> Second, drivers should really, really not rely on the machine. I don't
>>>>>> think how this resolves ABI break for other users at all.
>>>>>
>>>>> As detailed in the commit description, some boards mistakenly use the
>>>>> 'rgmii' phy-mode, and the MAC driver has also incorrectly parsed and
>>>>
>>>> That's a kind of an ABI now, assuming it worked fine.
>>>
>>> I'm inclined to think it's better to drop compatibility given we're talking
>>> about rather obscure boards here.
>>>
>>> $ rg 'mode.*=.*"rgmii"' arch/arm64/boot/dts/qcom -l
>>>
>>> arch/arm64/boot/dts/qcom/sa8155p-adp.dts
>>> arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts
>>>
>>> QCS404 seems to have zero interest from anyone (and has been considered
>>> for removal upstream..).
>>>
>>> The ADP doesn't see much traction either, last time around someone found
>>> a boot breaking issue months after it was committed.
>>
>> But what about the out-of-tree boards that Andrew mentioned? We need to ensure we don't break them, right?
> 
> No. What's not on the list, doesn't exist

Okay, I understand.

> 
> Konrad

-- 
Best Regards,
Yijie