On Mon, Nov 24, 2014 at 06:32:04PM +0100, Alban Bedel wrote: > Honestly my primary aim wasn't the sequencing, but rather to increase > the usefulness of generic drivers. Generic driver generally only > manipulate a single supply, however many hardware might have more, > and won't need any specific power up ordering. Having to write a full > new driver just because of an extra supply doesn't seems to make much > sense to me. I'm having a really hard time following the above - you say "generic driver generally only manipulate a single supply" but that's absolutely not the case. A driver should control exactly as many supplies as the device it is controlling does. The nearest I can get to something that I think I can understand is a device variant that has some changes in supplies but varaints aren't something that we need to write entirely new drivers for, just new device IDs and a few lines of conditional code. It's possible that I'm missing something but I'm really struggling to see the problem that you're trying to solve here or why this is an abstraction that makes sense. > As alternative solution to this problem I though about allowing a list > of regulator for the supplies: > vin-supply = <®1>, <®2>; > The API could still return a single consumer but it would operate on > all the regulators in the list instead of just one. Would that be a > better solution? No, that's even worse - this is just hacking around whatever problem you're facing. The device tree should accurately describe the hardware not some random thing that vaguely looks like the hardware because it happens to let us shoehorn things onto it.
Attachment:
signature.asc
Description: Digital signature
