linux-kernel - Re: PHY reset question

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: <20201012054839.n6do5ruxhbhc7h7n@pengutronix.de>
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 |