linux-kernel - Re: [PATCH 2/3] dt-bindings: regulator: Add regulator-output bindingg

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]

Message-ID: <Y1wxMk2x25AeRwLr@hatter.bewilderbeest.net>
Date:   Fri, 28 Oct 2022 12:44:50 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Mark Brown <broonie@...nel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Naresh Solanki <naresh.solanki@...ements.com>,
        Patrick Rudolph <patrick.rudolph@...ements.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        openbmc@...ts.ozlabs.org
Subject: Re: [PATCH 2/3] dt-bindings: regulator: Add regulator-output bindingg

On Fri, Oct 28, 2022 at 08:51:54AM PDT, Mark Brown wrote:
>On Thu, Oct 27, 2022 at 09:12:22PM -0700, Zev Weiss wrote:
>
>> I can see why it might look that way, but I'd argue it's actually not.  The
>> systems this is intended to support provide power to entirely separate
>> external devices -- think of a power distribution unit that might have
>> arbitrary things plugged into it.  It seems to me like a property of the
>> hardware that those things shouldn't have their power supply turned off (or
>> on) just because a controller in the PDU rebooted.
>
>We don't turn things off on reboot?  We don't do anything in particular
>on reboot...
>

Okay, perhaps not on reboot specifically, but the userspace-consumer 
driver has a regulator_bulk_disable() in its .remove function, so it 
would be triggered at least by a module unload (which is sort of why I 
ended up with the "when software relinquishes control" wording in the 
patch).  If we're going to continue with the plan of using that driver 
for this functionality (which seems overall quite reasonable to me), we 
need a way to express that that must not happen on this hardware.


Thanks,
Zev