netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Antoine Tenart <antoine.tenart@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] net: phy: marvell10g: add energy detect power down tunable
Date: Tue, 3 Mar 2020 15:30:13 +0000	[thread overview]
Message-ID: <20200303153013.GQ25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200303151958.GE3179@kwain>

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

  reply	other threads:[~2020-03-03 15:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 14:42 [PATCH net-next 0/3] marvell10g tunable and power saving support Russell King - ARM Linux admin
2020-03-03 14:43 ` [PATCH net-next 1/3] net: phy: marvell10g: add mdix control Russell King
2020-03-03 15:09   ` Antoine Tenart
2020-03-03 15:20     ` Russell King - ARM Linux admin
2020-03-03 14:44 ` [PATCH net-next 2/3] net: phy: marvell10g: add energy detect power down tunable Russell King
2020-03-03 15:07   ` Antoine Tenart
2020-03-03 15:12     ` Russell King - ARM Linux admin
2020-03-03 15:19       ` Antoine Tenart
2020-03-03 15:30         ` Russell King - ARM Linux admin [this message]
2020-03-03 15:33           ` Antoine Tenart
2020-03-03 14:44 ` [PATCH net-next 3/3] net: phy: marvell10g: place in powersave mode at probe Russell King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200303153013.GQ25745@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=antoine.tenart@bootlin.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).