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]

Date:   Tue, 20 Apr 2021 10:19:04 -0500
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Mark Brown <broonie@...nel.org>, 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 05:52:16AM CDT, Guenter Roeck wrote:
>On 4/20/21 12:06 AM, Zev Weiss wrote:
>> On Tue, Apr 20, 2021 at 01:00:25AM CDT, Guenter Roeck wrote:
>>> On 4/19/21 10:50 PM, Zev Weiss wrote:
>>> [ ... ]
>>>
>>>> I had a glance at the enclosure driver; it looks pretty geared toward SES-like things (drivers/scsi/ses.c being its only usage I can see in the kernel at the moment) and while it could perhaps be pressed into working for this it seems like it would probably drag in a fair amount of boilerplate and result in a somewhat gratuitously confusing driver arrangement (calling the things involved in the cases we're looking at "enclosures" seems like a bit of a stretch).
>>>>
>>>> As an alternative, would something like the patch below be more along the lines of what you're suggesting?  And if so, would it make sense to generalize it into something like 'pmbus-switch.c' and add a PMBUS_HAVE_POWERSWITCH functionality bit or similar in the pmbus code instead of hardcoding it for only LM25066 support?
>>>>
>>>>
>>>
>>> No. Don't access pmbus functions from outside drivers/hwmon/pmbus.
>>>
>>> I used to be opposed to function export restrictions (aka export namespaces),
>>> but you are making a good case that we need to introduce them for pmbus
>>> functions.
>>>
>>> Guenter
>>
>> Okay -- I figured that was likely to be frowned upon, but the alternative seemed to be effectively duplicating non-trivial chunks of the pmbus code.  However, upon realizing that the LM25066 doesn't actually require any of the paging work the generic pmbus code provides, I suppose it can actually be done with a simple smbus read & write.  Does this version look better?
>>
>
>It is just getting worse and worse. You are re-implementing regulator
>support for the lm25066. The correct solution would be to implement
>regulator support in the lm25066 and use it from the secondary driver
>(which should be chip independent).
>
>Guenter
>

Implementing it by way of regulator support seems like it would make 
sense, but that in turn sounds like it would then end up just being a 
reimplementation of REGULATOR_USERSPACE_CONSUMER, which (unless there 
was some more subtle distinction that I missed) Mark already told me in 
no uncertain terms is not the way to go.  So I hope I could be forgiven 
for feeling a bit stuck here.

Mark, do you have any further input on what a viable approach might look 
like?


Thanks,
Zev