netdev - Re: [PATCH v4 10/14] net: phy: adin: implement PHY subsystem software reset

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <916a477bb97aef904bdd1d84e85c92f6318b30df.camel@analog.com>
Date:   Tue, 13 Aug 2019 05:42:55 +0000
From:   "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>
To:     "andrew@...n.ch" <andrew@...n.ch>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: Re: [PATCH v4 10/14] net: phy: adin: implement PHY subsystem
 software reset

On Mon, 2019-08-12 at 16:19 +0200, Andrew Lunn wrote:
> [External]
> 
> > +static int adin_reset(struct phy_device *phydev)
> > +{
> > +	/* If there is a reset GPIO just exit */
> > +	if (!IS_ERR_OR_NULL(phydev->mdio.reset_gpio))
> > +		return 0;
> 
> I'm not so happy with this.
> 
> First off, there are two possible GPIO configurations. The GPIO can be
> applied to all PHYs on the MDIO bus. That GPIO is used when the bus is
> probed. There can also be a per PHY GPIO, which is what you are
> looking at here.
> 
> The idea of putting the GPIO handling in the core is that PHYs don't
> need to worry about it. How much of a difference does it make if the
> PHY is both reset via GPIO and then again in software? How slow is the
> software reset? Maybe just unconditionally do the reset, if it is not
> too slow.
> 

Ack.
Will do it unconditionally.
The reset is not too slow.


> > +
> > +	/* Reset PHY core regs & subsystem regs */
> > +	return adin_subsytem_soft_reset(phydev);
> > +}
> > +
> > +static int adin_probe(struct phy_device *phydev)
> > +{
> > +	return adin_reset(phydev);
> > +}
> 
> Why did you decide to do this as part of probe, and not use the
> .soft_reset member of phy_driver?

Hmmm.
This is a left-over from when I had the GPIO handling in this PHY driver.
It's also a habit picked up from writing IIO drivers, where there is no {soft_}reset hook.
Typically, the reset is done in the probe.

> 
> > +
> >  static struct phy_driver adin_driver[] = {
> >  	{
> >  		PHY_ID_MATCH_MODEL(PHY_ID_ADIN1200),
> >  		.name		= "ADIN1200",
> >  		.config_init	= adin_config_init,
> > +		.probe		= adin_probe,
> >  		.config_aneg	= adin_config_aneg,
> >  		.read_status	= adin_read_status,
> >  		.ack_interrupt	= adin_phy_ack_intr,
> > @@ -461,6 +503,7 @@ static struct phy_driver adin_driver[] = {
> >  		PHY_ID_MATCH_MODEL(PHY_ID_ADIN1300),
> >  		.name		= "ADIN1300",
> >  		.config_init	= adin_config_init,
> > +		.probe		= adin_probe,
> >  		.config_aneg	= adin_config_aneg,
> >  		.read_status	= adin_read_status,
> >  		.ack_interrupt	= adin_phy_ack_intr,
> 
> Thanks
> 	Andrew