[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Mar 2020 15:30:13 +0000
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Antoine Tenart <antoine.tenart@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] net: phy: marvell10g: add energy detect
power down tunable
On Tue, Mar 03, 2020 at 04:19:58PM +0100, Antoine Tenart wrote:
> On Tue, Mar 03, 2020 at 03:12:32PM +0000, Russell King - ARM Linux admin wrote:
> > On Tue, Mar 03, 2020 at 04:07:41PM +0100, Antoine Tenart wrote:
> > > On Tue, Mar 03, 2020 at 02:44:02PM +0000, Russell King wrote:
> > > > drivers/net/phy/marvell10g.c | 111 ++++++++++++++++++++++++++++++++++-
> > > >
> > > > +static int mv3310_maybe_reset(struct phy_device *phydev, u32 unit, bool reset)
> > > > +{
> > > > + int retries, val, err;
> > > > +
> > > > + if (!reset)
> > > > + return 0;
> > >
> > > You could also call mv3310_maybe_reset after testing the 'reset'
> > > condition, that would make it easier to read the code.
> >
> > I'm not too convinced:
> >
> > diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
> > index ef1ed9415d9f..3daf73e61dff 100644
> > --- a/drivers/net/phy/marvell10g.c
> > +++ b/drivers/net/phy/marvell10g.c
> > @@ -279,13 +279,10 @@ static int mv3310_power_up(struct phy_device *phydev)
> > MV_V2_PORT_CTRL_PWRDOWN);
> > }
> >
> > -static int mv3310_maybe_reset(struct phy_device *phydev, u32 unit, bool reset)
> > +static int mv3310_reset(struct phy_device *phydev, u32 unit)
> > {
> > int retries, val, err;
> >
> > - if (!reset)
> > - return 0;
> > -
> > err = phy_modify_mmd(phydev, MDIO_MMD_PCS, unit + MDIO_CTRL1,
> > MDIO_CTRL1_RESET, MDIO_CTRL1_RESET);
> > if (err < 0)
> > @@ -684,10 +681,10 @@ static int mv3310_config_mdix(struct phy_device *phydev)
> >
> > err = phy_modify_mmd_changed(phydev, MDIO_MMD_PCS, MV_PCS_CSCR1,
> > MV_PCS_CSCR1_MDIX_MASK, val);
> > - if (err < 0)
> > + if (err <= 0)
> > return err;
> >
> > - return mv3310_maybe_reset(phydev, MV_PCS_BASE_T, err > 0);
> > + return mv3310_reset(phydev, MV_PCS_BASE_T);
> > }
> >
> > static int mv3310_config_aneg(struct phy_device *phydev)
> >
> > The change from:
> >
> > if (err < 0)
> >
> > to:
> >
> > if (err <= 0)
> >
> > could easily be mistaken as a bug, and someone may decide to try to
> > "fix" that back to being the former instead. The way I have the code
> > makes the intention explicit.
>
> Using a single line to test both the error and the 'return 0'
> conditions, yes, I agree. Another solution would be to do something of
> the like:
>
> phy_modify_mmd_changed()
> if (err < 0)
> return err;
>
> if (err)
> mv3310_reset();
>
> return 0;
>
> I find it more readable, but this kind of thing is also a matter of
> personal taste.
Well, it either becomes:
err = phy_modify_mmd_changed(phydev, MDIO_MMD_PCS, MV_PCS_CSCR1,
MV_PCS_CSCR1_MDIX_MASK, val);
if (err < 0)
return err;
if (err > 0)
return mv3310_reset(phydev, MV_PCS_BASE_T);
return 0;
or:
err = phy_modify_mmd_changed(phydev, MDIO_MMD_PCS, MV_PCS_CSCR1,
MV_PCS_CSCR1_MDIX_MASK, val);
if (err > 0)
err = mv3310_reset(phydev, MV_PCS_BASE_T);
return err;
In the former case, we have two success-exit paths - one via a successful
mv3310_reset() and one by dropping through to the final return statement.
The latter case looks a bit better, at least to me.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Powered by blists - more mailing lists