PHY hardware reset

PHY hardware reset

[Sergei Shtylyov]

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! 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...
    Florian (and everybody), what's your thoughts on this matter?

MBR, Sergei

Re: PHY hardware reset

[Andrew Lunn]

On Sun, Mar 06, 2016 at 01:09:40AM +0300, Sergei Shtylyov wrote:
> 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).

Hi Sergei

There is a thread about power sequencing for USB devices going on at
the moment. You have a very similar issue. The solution should be
generic enough to apply to MDIO busses as well as USB busses.

Search for:

[PATCH 1/3] usb: core: add power sequence for USB devices

       Andrew

Re: PHY hardware reset

[Florian Fainelli]

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