netdev - Re: regression from: net: phy: marvell: Avoid unnecessary soft reset

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: <41e2d2bd-9b59-4842-bd65-26ce967e2ec2@electromag.com.au>
Date:   Thu, 21 Mar 2019 16:07:25 +0800
From:   Phil Reid <preid@...ctromag.com.au>
To:     liweihang <liweihang@...ilicon.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        "dongsheng.wang@...-semitech.com" <dongsheng.wang@...-semitech.com>,
        "cphealy@...il.com" <cphealy@...il.com>,
        "clemens.gruber@...ruber.com" <clemens.gruber@...ruber.com>,
        "nbd@....name" <nbd@....name>,
        "harini.katakam@...inx.com" <harini.katakam@...inx.com>
Subject: Re: regression from: net: phy: marvell: Avoid unnecessary soft reset

On 21/03/2019 2:16 pm, liweihang wrote:
> 
>>>>
>>>> On 3/19/2019 7:34 PM, liweihang wrote:
>>>>> Hi all,
>>>>>
>>>>> I've met a similar issue and sent an email to discuss about it before:
>>>>> Question about setting speed and duplex failed after
>>>>> auto-negotiation disabled on marvell phy
>>>>>
>>>>> d6ab93364734 net: phy: marvell: Avoid unnecessary soft reset I
>>>>> reverted this patch and the auto-negotiation works ok.
>>>>>
>>>>> Florian, could you please read my previous email and give me some
>> advice?
>>>>
>>>> If you can copy the patch author on that email the next time that
>>>> will help expedite things.
>>>>
>>>> So the problem seems to come from the fact that unless the BCMR_RESET
>>>> bit is written, then m88e1121_config_aneg_rgmii_delays() has no
>>>> effect, does that sound like what you are observing?
>>>>
>>>> Does the following work for you (Phil and yourself)?
>>>
>>> Thank you, Florian. But that didn't work for me either. I think the
>>> key question is as what Heiner said, some bits need to be preserved.
>>>
>>> The MII_BMCR contained information of speed and duplex mode, but
>> when
>>> we call genphy_soft_reset(), these bits will be cleared.
>>>
>> I think instead of
>>
>> ret = phy_write(phydev, MII_BMCR, BMCR_RESET);
>>
>> we should use
>>
>> ret = phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
>>
>> This is still in line with Clause 22 but covers more PHY's. A lot of PHY's won't
>> be affected because they reset all BMCR bits to a default anyway.
>> Could you please test this? If it's ok for you I'd submit a patch.
>>
> 
> Thank you, Heiner. It works ok on my device with following change as you
> suggested.
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 509d940..7241646 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1874,7 +1874,7 @@ int genphy_soft_reset(struct phy_device *phydev)
>   {
>          int ret;
>   
> -       ret = phy_write(phydev, MII_BMCR, BMCR_RESET);
> +       ret = phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
>          if (ret < 0)
>                  return ret;
> 

Thank you, Heiner.
I confirm this also works for me.


-- 
Regards
Phil