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: > > 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. 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
