On Thu, May 19, 2022 at 01:33:21PM +0200, Krzysztof Kozlowski wrote: > On 19/05/2022 13:31, Mark Brown wrote: > > On Thu, May 19, 2022 at 11:55:28AM +0200, Krzysztof Kozlowski wrote: > >> On 18/05/2022 22:09, Corentin Labbe wrote: > > > >>> + regulators: > >>> + description: > >>> + List of phandle to regulators needed for the PHY > > > >> 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. 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. 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. Andrew
