> -----Original Message-----
> From: Heiner Kallweit [mailto:[email protected]]
> Sent: Thursday, March 21, 2019 2:15 AM
> To: liweihang <[email protected]>; Florian Fainelli
> <[email protected]>; Phil Reid <[email protected]>;
> [email protected]
> Cc: Andrew Lunn <[email protected]>; David S. Miller
> <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]
> 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:[email protected]]
> >> Sent: Wednesday, March 20, 2019 11:37 AM
> >> To: liweihang <[email protected]>; Phil Reid
> >> <[email protected]>; [email protected]
> >> Cc: Andrew Lunn <[email protected]>; David S. Miller
> >> <[email protected]>; [email protected];
> >> [email protected]; [email protected];
> [email protected];
> >> [email protected]; [email protected]
> >> 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;
