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
| ||
|
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?
Powered by blists - more mailing lists