Messages in this thread | | | From | Pierluigi Passaro <> | Subject | Re: [PATCH] net: mdio: force deassert MDIO reset signal | Date | Tue, 17 Jan 2023 15:20:44 +0000 |
| |
On Tue, Jan 17, 2023 at 3:01 PM Andrew Lunn <andrew@lunn.ch> wrote: > 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 Hi Andrew, I can understand your position and I apologize for the mess. Thanks Pier
| |