netdev - 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 01:11:43 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Pierluigi Passaro <pierluigi.passaro@...il.com>
Cc:     Lars-Peter Clausen <lars@...afoo.de>, hkallweit1@...il.com,
        linux@...linux.org.uk, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, eran.m@...iscite.com,
        nate.d@...iscite.com, francesco.f@...iscite.com,
        pierluigi.p@...iscite.com
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal

> 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?

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