[PATCH 3/6] dt-bindings: net: Add documentation for phy-supply
Rob Herring
robh at kernel.org
Mon May 16 17:47:04 PDT 2022
On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:
> > No, that's not a thing - the supplies are individual, named properties
> > and even if there were a list we'd still want them to be named so it's
> > clear what's going on.
>
> So we have a collection of regulators, varying in numbers between
> different PHYs, with different vendor names and purposes. In general,
> they all should be turned on. Yet we want them named so it is clear
> what is going on.
In what order do we turn the supplies on? How much time in between each
one? Does an external clock need to be running before or after (and how
long after). Oh, and what about resets and the order and timing of them
relative to everything else?
This always happens in the same order. First, it's just one resource
like a regulator or reset. Then one more. Then another device with some
timing constraints. If we wanted a generic solution in DT, it would need
to be able to describe any power sequencing waveform. But we don't have
that because we don't want it.
> Is there a generic solution here so that the phylib core can somehow
> enumerate them and turn them on, without actually knowing what they
> are called because they have vendor specific names in order to be
> clear what they are?
Other devices have specific compatibles so that the device can be
identified and powered up. Once again, MDIO should not be special here.
> There must be a solution to this, phylib cannot be the first subsystem
> to have this requirement, so if you could point to an example, that
> would be great.
Well, no one seems to want to make non-discoverable devices on
'discoverable' buses work. Still an issue for PCI and USB. I thought
MDIO had a solution here to probe any devices in the DT even if not
discovered.
Rob
More information about the linux-arm-kernel
mailing list