On Thu, May 19, 2022 at 01:58:18PM +0200, Andrew Lunn wrote:

On Thu, May 19, 2022 at 01:33:21PM +0200, Krzysztof Kozlowski wrote:

quoted

On 19/05/2022 13:31, Mark Brown wrote:

quoted

On Thu, May 19, 2022 at 11:55:28AM +0200, Krzysztof Kozlowski wrote:

quoted

On 18/05/2022 22:09, Corentin Labbe wrote:

quoted

quoted

+  regulators:
+    description:
+       List of phandle to regulators needed for the PHY

quoted

I don't understand that... is your PHY defining the regulators or using
supplies? If it needs a regulator (as a supply), you need to document
supplies, using existing bindings.

They're trying to have a generic driver which works with any random PHY
so the binding has no idea what supplies it might need.

OK, that makes sense, but then question is why not using existing
naming, so "supplies" and "supply-names"?

I'm not saying it is not possible, but in general, the names are not
interesting. All that is needed is that they are all on, or
potentially all off to save power on shutdown. We don't care how many
there are, or what order they are enabled.

Ethernet PHY can have multiple supplies. For example there can be two
digital voltages and one analogue. Most designs just hard wire them
always on. It would not be unreasonable to have one GPIO which
controls all three. Or there could be one GPIO for the two digital
supplies, and one for the analogue. Or potentially, three GPIOs.

Again, it's not just supplies...

Given all the different ways the board could be designed, i doubt any
driver is going to want to control its supplies in an way other than
all on, or all off. 802.3 clause 22 defines a standardized way to put
a PHY into a low power mode. Using that one bit is much simpler than
trying to figure out how a board is wired.

However, the API/binding should be generic, usable for other use
cases. 

The binding should not be generic as I explained here and many times 
before...

Nobody has needed an API like this before, but it is not to say
it might have other uses in the future. So maybe "supplies" and
"supply-names" is useful, but we still need a way to enumerate them as
a list without caring how many there are, or what their names are.

There's 2 standard patterns for how producer/consumer bindings work 
There's how gpio and regulators are done and then there's the
foo/foo-names style. Regulators when with the former and we're not going 
to do both.

You can still do what you want by retrieving all properties ending with 
'-supply'. Not as easy to implement, but works for existing users.

Rob