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

Message-ID: <YH8jUuOEJKDDDoMb@hatter.bewilderbeest.net>
Date:   Tue, 20 Apr 2021 13:54:10 -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 Tue, Apr 20, 2021 at 12:15:40PM CDT, Mark Brown wrote:
>On Tue, Apr 20, 2021 at 11:40:24AM -0500, Zev Weiss wrote:
>> On Tue, Apr 20, 2021 at 11:13:18AM CDT, Mark Brown wrote:
>
>> > I already suggested writing a driver or drivers that represent the
>> > hardware you have, that advice remains.  It's hard to follow what you
>> > were trying to say with your long mail earlier today but it seems like
>
>> That email was an attempt to explain why writing a driver for the specific
>> hardware devices we're powering seems like a poor fit to me.  To summarize:
>
>>  - There's a wide variety of different devices potentially behind an
>> LM25066.
>
>This is true for lots of hardware, we still integrate things into
>frameworks.
>
>>  - A hypothetical driver for any one of them would be completely
>> non-specific to that device and functionally identical to a driver    for
>> any other, because the only hardware it would actually be    touching is the
>> LM25066, and in ways that are again completely    non-specific to anything
>> but the LM25066 itself.
>
>I don't see why that would be the case at all.  Even within the indended
>application as a power controller for a hotpluggable bus there's plenty
>of potential for integration into a wider representation of the socket
>things get inserted into - for example I've worked with buses that had
>support for operator signalling of hotplug (buttons to press to initiate
>hot removal, with lights to signal when a clean shutdown of the card had
>been completed), you might also want to have additional environment
>monitoring and of course the labelling that I mentioned in an earlier
>post.  I can imagine you probably have some other connection of some
>kind to the host too (eg, network ports) to join up and perhaps sync
>hotplug for.
>

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 that it just provides a way for an operator to remotely 
cut power to a thing that's plugged into it.  There's no other bus or 
anything in the picture.  (And pragmatically, given that its most common 
usage is likely to be to provide a cold power cycle as a last-ditch 
recovery option when things are wedged in some unresponsive state, 
attempting any sort of coordination with the downstream device would 
probably be a dead end anyway.)


Zev