linux-kernel - Re: [PATCH v4 2/4] dt-bindings: regulator: add bindings for output-supply

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Jul 2022 01:33:20 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Rob Herring <robh@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Naresh Solanki <naresh.solanki@...ements.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Patrick Rudolph <patrick.rudolph@...ements.com>
Subject: Re: [PATCH v4 2/4] dt-bindings: regulator: add bindings for
 output-supply

On Thu, Jul 14, 2022 at 09:59:48AM PDT, Rob Herring wrote:
>+Zev
>
>On Thu, Jul 14, 2022 at 9:54 AM Mark Brown <broonie@...nel.org> wrote:
>>
>> On Thu, Jul 14, 2022 at 09:07:49AM -0600, Rob Herring wrote:
>> > On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <broonie@...nel.org> wrote:
>>
>> > > Consider for example a BMC (IIRC that's what their specific product is),
>> > > a bench supply or some automated test equipment.  Part of the function
>> > > for these systems is to provide power to other systems which would be
>> > > represented as a root or wall supply in the description of the system
>> > > that actually uses the supply if it were described using DT.
>>
>> > Didn't someone else have a similar use recently? Controlling some
>> > supply external to the system. I can't seem to find it now.
>>
>> IIRC that was an earlier iteration of the same thing - it's been round
>> the houses a bit.  extcon seemed like it might be a home since these are
>> external connections from the system but in the end people didn't think
>> it looked like a good fit.
>
>Found it:
>
>v1: https://lore.kernel.org/all/20220504065252.6955-2-zev@bewilderbeest.net/
>v2: https://lore.kernel.org/all/20220505232557.10936-1-zev@bewilderbeest.net/
>
>v2 was the using extcon version. v1 looks pretty similar to this one
>though anything that's just a compatible plus supplies would.
>
>But AFAICT these 2 submissions are completely independent.
>

Thanks for looping me in here Rob, I hadn't been aware of this series.

Naresh, I'd appreciate it if you could CC me on any subsequent 
iterations; as linked above I've made some sporadic attempts at getting 
support for this functionality merged, and am certainly interested in 
any other efforts on that front.

A question for Mark though -- in one of my earliest stabs at this I 
floated the idea of using reg-userspace-consumer for it, but was told in 
no uncertain terms that that driver was for testing only and should 
under no circumstances ever be instantiated in a production system.  Has 
the thinking on its usage changed in the last year or so such that this 
approach was deemed okay?


Thanks,
Zev