linux-kernel - Re: Enabling pmbus power control

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:   Wed, 21 Apr 2021 13:29:07 -0500
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Mark Brown <broonie@...nel.org>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        Andrew Jeffery <andrew@...id.au>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org, openbmc@...ts.ozlabs.org
Subject: Re: Enabling pmbus power control

On Wed, Apr 21, 2021 at 06:05:40AM CDT, Mark Brown wrote:
>On Tue, Apr 20, 2021 at 01:54:10PM -0500, Zev Weiss wrote:
>
>> Consider the power shelf I mentioned earlier -- it's a rackmount power
>> supply and that's about it.  It provides DC power to arbitrary devices that
>> it has no other connection to, just ground and +12V.  Those devices might be
>> servers, or cooling fans, or vacuum cleaners or floodlights -- the power
>> shelf doesn't know, or care.  It's a lot like a switchable network PDU in
>
>If your chassis is particularly simple then it will be particularly
>simple to fit into a generic framework so that should make your life a
>lot easier here.  Generally the simpler your system is the easier it
>will be to use in something generic, it's not going to be stretching
>ideas about how things should look and is more likely to have good
>helpers available already.

The simplicity of the use-case should make it easy to implement via a 
generic framework, yes.  But at the same time, if we're talking about 
that being a new framework that doesn't currently exist, the minimal 
needs of this case make it difficult for me to see what sort of 
structure or additional functionality would be required of such a 
framework to support more complex cases, because the simple/minimal case 
is the only example I have at hand.  I think there's also (quite 
reasonably) a general reluctance to merge infrastructure that doesn't 
have any users.

Given that, I'd think the appropriate approach for a first-cut 
implementation of that would be to only implement what's presently 
needed, and put off incorporating any other bells and whistles until 
there's something that would use them.  It seems like a minimal, 
only-what's-needed version of that at present would end up looking 
extremely similar to reg-userspace-consumer though.  Would that not be 
problematic?

Zev