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: <20210420171540.GG6073@sirena.org.uk>
Date:   Tue, 20 Apr 2021 18:15:40 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Zev Weiss <zev@...ilderbeest.net>
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 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.

> I'm not at all opposed to using a abstractions or frameworks (I'd very much
> like to do so in fact).  The problem is that I've thus far been unable to
> determine exactly what the appropriate one is.

Perhaps you need to write some kind of generic system for hotplugging
modules if you can't find one.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)