RE: regression from: net: phy: marvell: Avoid unnecessary soft reset

[liweihang <liweihang@hisilicon.com>]

> -----Original Message-----
> From: Heiner Kallweit [mailto:hkallweit1@gmail.com]
> Sent: Thursday, March 21, 2019 2:15 AM
> To: liweihang <liweihang@hisilicon.com>; Florian Fainelli
> <f.fainelli@gmail.com>; Phil Reid <preid@electromag.com.au>;
> netdev@vger.kernel.org
> Cc: Andrew Lunn <andrew@lunn.ch>; David S. Miller
> <davem@davemloft.net>; dongsheng.wang@hxt-semitech.com;
> cphealy@gmail.com; clemens.gruber@pqgruber.com; nbd@nbd.name;
> harini.katakam@xilinx.com
> Subject: Re: regression from: net: phy: marvell: Avoid unnecessary soft reset
> 
> On 20.03.2019 13:22, liweihang wrote:
> >
> >
> >> -----Original Message-----
> >> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> >> Sent: Wednesday, March 20, 2019 11:37 AM
> >> To: liweihang <liweihang@hisilicon.com>; Phil Reid
> >> <preid@electromag.com.au>; netdev@vger.kernel.org
> >> Cc: Andrew Lunn <andrew@lunn.ch>; David S. Miller
> >> <davem@davemloft.net>; dongsheng.wang@hxt-semitech.com;
> >> cphealy@gmail.com; clemens.gruber@pqgruber.com;
> hkallweit1@gmail.com;
> >> nbd@nbd.name; harini.katakam@xilinx.com
> >> Subject: Re: regression from: net: phy: marvell: Avoid unnecessary
> >> soft reset
> >>
> >>
> >>
> >> 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;