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: <YH8D+LWxWPqnFd2h@hatter.bewilderbeest.net>
Date:   Tue, 20 Apr 2021 11:40:24 -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 11:13:18AM CDT, Mark Brown wrote:
>On Tue, Apr 20, 2021 at 10:19:04AM -0500, Zev Weiss wrote:
>
>> Mark, do you have any further input on what a viable approach might look
>> like?
>
>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.

  - 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.

>you basically don't want to use any abstraction or framework, but that's
>not really suitable for upstream integration

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.

>other hardware that looks similar to the end user should look similar 
>in the kernel too.

Agreed -- hence my disinclination to write drivers artificially specific 
to whatever is behind the LM25066.  What it looks like to the end user, 
and I'd hope evetually the kernel as well, is a simple power switch and 
nothing more.


Zev