Messages in this thread | | | Date | Tue, 17 Jan 2023 15:01:48 +0100 | From | Andrew Lunn <> | Subject | Re: [PATCH] net: mdio: force deassert MDIO reset signal |
| |
On Mon, Jan 16, 2023 at 09:44:01AM +0000, Pierluigi Passaro wrote: > On Mon, Jan 16, 2023 at 1:11 AM Andrew Lunn <andrew@lunn.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 ;)
Lots of small incremental 'improvements' sometimes get you into a real mess because you loose track of the big picture. And i do think we are now in a mess. But i also think we have a better understanding of the problem space. We know there can be arbitrate number of resources which need to be enabled before you can enumerate the bus. We need a generic solution to that problem. And Linux is good at solving a problem once and reusing it other places. So the generic solution should be applicable to other bus types.
We also have a well understood workaround, put the IDs in DT. So as far as i'm concerned we don't need to add more incremental 'improvements', we can wait for somebody to put in the effort to solve this properly with generic code.
So i don't want to merge this change. Sorry.
Andrew
| |