linux-kernel - Re: [PATCH v2 1/2] regulator: Add coupled regulator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 11 Nov 2016 16:46:10 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Rob Herring <robh@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] regulator: Add coupled regulator

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.

Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)