Messages in this thread | | | From | Pierluigi Passaro <> | Subject | Re: [PATCH] net: mdio: force deassert MDIO reset signal | Date | Mon, 16 Jan 2023 09:44:01 +0000 |
| |
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 ;) 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.
| |