netdev - Re: PHY hardware 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] [day] [month] [year] [list]

Date:	Sun, 6 Mar 2016 16:54:47 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>
Subject: Re: PHY hardware reset

Le 05/03/2016 14:09, Sergei Shtylyov a écrit :
> Hello.
> 
>    I have a need to de-assert the active-low PHY hardware reset signal
> (mapped to a GPIO) before the MDIO bus scansince it's left asserted by
> the bootloader (U-Boot). I have a device tree probed MAX driver (ravb)
> and I'm somewhat at a loss about where and how to do this. The existing
> example (Freescale FEC) has DT props controlling the PHY reset GPIO in
> the MAC device node but it doesn't seem correct at all since this signal
> has nothing to do with the MAC, only with PHY! 

Agreed, it is a property of the PHY, but it should however be utilized
by the MAC (and optionaly the MDIO bus driver) so as to make good
choices when it comes to conserving power.

I therefore would like
> this "phy-reset-gpios" property to be defined under the PHY node but
> this way I'll have to add the handling of this prop to the phylib (it
> would be too late if I did that in a a PHY driver method since that).
> I'm also seeing the mii_bus::reset() method and it seems a good place
> but I'm not sure if my PHY's reset signal can be treated as the reset
> signal for the whole bus; if it would, the DT prop should be placed
> under the MAC node anyway...

The MDIO bus reset callback did not really have a very good definition
for its use, but it seems like an appropriate place to release the PHY
from reset to ensure you will be able to scan and attach its driver to
it. In general the MDIO bus reset callback should be seen as an
opportunity for drivers to implement pre-scanning operations that will
ensure a successful PHY probing/binding.

Whether we would want PHYLIB to be taught about phy-reset-gpios is a
little more debatable, on one hand, anything that could put the PHY into
low power is done there, and it would be consistent to release/put the
PHY into reset, on the other hand, the Ethernet MAC driver is the place
where things like Wake-on-LAN are coordinated, but we can still call
into a phy_set_wol() function to avoid putting the PHY in reset or not.
If there is something sensibly generic to be put in PHYLIB wrt.
phy-reset-gpios, please propose a patch doing so and we can see how much
FEC and RAVB need to be changed.

Thanks!
-- 
Florian