[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8SWPwM7V8yj9s+v@lunn.ch>
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
Powered by blists - more mailing lists