Thread (25 messages) 25 messages, 5 authors, 2022-05-17

Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

From: Rob Herring <robh@kernel.org>
Date: 2022-05-17 00:47:16
Also in: linux-arm-kernel, linux-devicetree, linux-sunxi, lkml

On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help