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]
Date:   Tue, 3 Mar 2020 16:33:43 +0100
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Antoine Tenart <antoine.tenart@...tlin.com>,
        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 03:30:13PM +0000, Russell King - ARM Linux admin wrote:
> 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.

I do agree, the latter looks good.

Thanks,
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ