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  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]
Date:   Mon, 12 Oct 2020 07:48:39 +0200
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     Bruno Thomsen <bruno.thomsen@...il.com>
Cc:     Fabio Estevam <festevam@...il.com>, Andrew Lunn <andrew@...n.ch>,
        David Jander <david@...tonic.nl>,
        Sascha Hauer <kernel@...gutronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        Marek Vasut <marex@...x.de>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: PHY reset question

Hi all,

thank you for the feedback!

On Fri, Oct 09, 2020 at 04:25:49PM +0200, Bruno Thomsen wrote:
> Hi Fabio and Oleksij
> 
> Den ons. 7. okt. 2020 kl. 11.50 skrev Fabio Estevam <festevam@...il.com>:
> >
> > Hi Oleksij,
> >
> > On Tue, Oct 6, 2020 at 5:05 AM Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> > >
> > > Hello PHY experts,
> > >
> > > Short version:
> > > what is the proper way to handle the PHY reset before identifying PHY?
> > >
> > > Long version:
> > > I stumbled over following issue:
> > > If PHY reset is registered within PHY node. Then, sometimes,  we will not be
> > > able to identify it (read PHY ID), because PHY is under reset.
> > >
> > > mdio {
> > >         compatible = "virtual,mdio-gpio";
> > >
> > >         [...]
> > >
> > >         /* Microchip KSZ8081 */
> > >         usbeth_phy: ethernet-phy@3 {
> > >                 reg = <0x3>;
> > >
> > >                 interrupts-extended = <&gpio5 12 IRQ_TYPE_LEVEL_LOW>;
> > >                 reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
> > >                 reset-assert-us = <500>;
> > >                 reset-deassert-us = <1000>;
> > >         };
> > >
> > >         [...]
> > > };
> > >
> > > On simple boards with one PHY per MDIO bus, it is easy to workaround by using
> > > phy-reset-gpios withing MAC node (illustrated in below DT example), instead of
> > > using reset-gpios within PHY node (see above DT example).
> > >
> > > &fec {
> > >         [...]
> > >         phy-mode = "rmii";
> > >         phy-reset-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
> > >         [...]
> >
> > I thought this has been fixed by Bruno's series:
> > https://www.spinics.net/lists/netdev/msg673611.html
> 
> Yes, that has fixed the Microchip/Micrel PHY ID auto detection
> issue. I have send a DTS patch v3 that makes use of the newly
> added device tree parameter:
> https://lkml.org/lkml/2020/9/23/595

This way is suitable only for boards with single PHY and single reset
line. But it is not scale on boards with multiple PHY and multiple reset
lines.

So far, it looks like using compatible like "ethernet-phy-idXXXX.XXXX"
is the only way to go.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists