linux-kernel - Re: [PATCH v3 4/4] regulator: core: Balance coupled regulators voltages

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 PHC
Open Source and information security mailing list archives

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

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

Date:   Thu, 21 Dec 2017 14:29:14 +0100
From:   Maciej Purski <m.purski@...sung.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v3 4/4] regulator: core: Balance coupled regulators
 voltages



On 12/15/2017 04:19 PM, Mark Brown wrote:
> On Wed, Dec 13, 2017 at 10:25:00AM +0100, Maciej Purski wrote:
> 
>>> shared.  To that end I'd adjust the code so that we always have a
>>> coupling descriptor and then handle the case where there's only one
>>> regulator described in there.
> 
>> Do you have any suggestion, how should I implement that path? The thing which
>> makes it more complicated is locking, because set_voltage_unlocked is done
>> under one regulator's mutex and its suppliers, while balance procedure locks
>> every coupled regulator without its suppliers. The suppliers for a single
>> regulator are locked when setting a single regulator's voltage takes place.
> 
> We only really need to lock the supplies when doing the actual mechanics
> of voltage changes so I'm not sure I see a big issue here - if we always
> go through balancing first then voltage setting it should be fine.  If
> everything is always balancing (even uncoupled regulators) then part of
> the transition should be moving some if not all of the data updates to
> balancing.
> 

Now I can understand your point, but I still have doubts what is the advantage 
of that solution. For non-coupled regulators we end up with useless data 
structure - coupling_desc. That also might cause some confusion. We expect 
coupled regulators to be a very rare case, so in most of the cases we will have 
a pointless structure in reg_dev with a pointer to itself. Maybe you suggest 
that coupling_desc should contain something different?