linux-kernel - Re: [PATCH] net: mdio: force deassert MDIO reset signal

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]

Date:   Mon, 16 Jan 2023 09:44:01 +0000
From:   Pierluigi Passaro <pierluigi.p@...iscite.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Pierluigi Passaro <pierluigi.passaro@...il.com>
CC:     Lars-Peter Clausen <lars@...afoo.de>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Eran Matityahu <eran.m@...iscite.com>,
        Nate Drude <Nate.D@...iscite.com>,
        Francesco Ferraro <francesco.f@...iscite.com>
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal

On Mon, Jan 16, 2023 at 1:11 AM Andrew Lunn <andrew@...n.ch> wrote:
> > IMHO, since the framework allows defining the reset GPIO, it does not sound
> > reasonable to manage it only after checking if the PHY can communicate:
> > if the reset is asserted, the PHY cannot communicate at all.
> > This patch just ensures that, if the reset GPIO is defined, it's not asserted
> > while checking the communication.
>
> The problem is, you are only solving 1/4 of the problem. What about
> the clock the PHY needs? And the regulator, and the linux reset
> controller? And what order to do enable these, and how long do you
> wait between each one?
>
Interesting point of view: I was thinking about solving one of 4 problems ;)
This problem affects all the platforms using the reset GPIO without
ensuring that either u-boot or the HW put a pull-up on it.
In our test, the problem is reproducible simply setting the reset to 0 from
u-boot and then use the GPIO reset as designed in the MDIO framework.
Is this approach reasonable or a comprehensive solution is expected to
cover all additional HW actors (clocks, regulators, ...) ?>
> And why are you solving this purely for Ethernet PHYs when the same
> problem probably affects other sorts of devices which have reset
> GPIOs, regulators and clocks? It looks like MMC/SDIO devices have a
> similar problem.
>
> https://lwn.net/Articles/867740/
>
> As i said, i've not been following this work. Has it got anywhere? Can
> ethernet PHYs use it?
>
>          Andrew
I'm not that familiar with the article's implications, but it sounds like a
partial redesign of the framework is needed.
I'm not sure this is the real point.
Let's refer to I2C/SPI/USB busses, the sequence is something like
- probe and setup the bus
- once the bus is up & running, start probing the connected slaves
Apparently, in the MDIO framework there's an excessive coupling
between the MDIO bus and the PHYs.
I can't really understand why the MDIO bus must check the PHY presence.
Other busses try the communication only while probing the slaves,
never before.