On Mon, Nov 07, 2016 at 04:47:38PM +0100, Maxime Ripard wrote: > Since regulator_get returns a struct regulator pointer, it felt > logical to try to add the list of parent regulators to it, especially > as this structure is per-consumer, and different consumers might have > different combinations of regulators. > However, this structure embeds a pointer to a struct regulator_dev, > which seems to model the regulator itself, but will also contain > pointer to the struct regulator, probably to model its parent? I guess It'd be a lot easier to follow this if you named the fields... The rdev in the struct regulator is indeed the physical device. The struct regulator called supply in struct regulator_dev is indeed the parent regulator. > my first question would be do we care about nesting? or having a > regulator with multiple parents? Well, it seems that your use case here is multiple parents so I guess we do care about it. :) > It also contains the constraints on each regulator, which might or > might not be different for each of the coupled regulators, but I'm > guessing the couple might have contraints of its own too I guess. Is > it something that might happen? Should we care about it? I can't see how one could physically have constraints that didn't apply to both parents. > And finally, my real question is, do we want to aggregate them in > struct regulator, at the consumer level, which might make the more > sense, or do we want to create an intermediate regulator internally? > What is your take on this? My initial thought without having tried to implement this is that doing things in an intermediate regulator might do a better job of encapsulating things it if it works out but I've got a feeling that it's not going to work out well and that therefore doing it in the consumer with multiple rdevs will be better. But really either approach is fine if it doesn't look horrible.
Attachment:
signature.asc
Description: PGP signature
