linux-kernel - 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <YGLepYLvtlO6Ikzs@hatter.bewilderbeest.net>
Date:   Tue, 30 Mar 2021 03:17:41 -0500
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Guenter Roeck <linux@...ck-us.net>,
        Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org
Cc:     Andrew Jeffery <andrew@...id.au>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org,
        openbmc@...ts.ozlabs.org
Subject: Enabling pmbus power control

Hello,

I'm working on a board that has a handful of LM25066 PMICs controlling
the power supply to various devices, and I'd like to have both the
existing hwmon sensor functionality as well as userspace power on/off
control, which does not currently seem to be available (other than via
'i2cset -f', which I'd of course prefer to avoid).  I've drafted up a
couple possible versions of this, and was hoping to get some opinions
on the appropriate overall approach.

One option is to add a read-write sysfs attribute to the existing
hwmon directory (current incarnation of the patch:
https://thorn.bewilderbeest.net/~zev/patches/pmbus-statectl.patch).
This bears a vague resemblance to a patch that was rejected a couple
years ago
(https://lore.kernel.org/linux-hwmon/20190417161817.GA13109@roeck-us.net/),
but is different enough that I wonder if it might potentially be
tolerable?  (It exposes significantly less, for one thing.)

The other approach involves layering a regulator device over the pmbus
device as is done in the LTC2978 driver, and then putting a
reg-userspace-consumer on top of that (current patch:
https://thorn.bewilderbeest.net/~zev/patches/pmbus-ureg.patch).  My
first attempt at this ran into problems with all the
reg-userspace-consumer instances getting attached to the first
regulator device, I think due to all of the regulators ending up under
the same name in the global namespace of regulator_map_list.  I worked
around that by adding an ID counter to produce a unique name for each,
though that changes device names in userspace-visible ways that I'm
not sure would be considered OK for backwards compatibility.  (I'm not
familiar enough with the regulator code to know if there's a better
way of fixing that problem.)  The #if-ing to keep it behind a Kconfig
option is also kind of ugly as it stands.

The first version seems simpler to me (and avoids the rather more
cumbersome sysfs paths the second one produces, for what that's
worth).  I think the second is (at least structurally) perhaps more
aligned with what Guenter was saying in the previous discussion linked
above, though.  Does anyone have any advice on the best way to proceed
with this?  If the reg-userspace-consumer approach is the preferred
route, suggestions on a better fix for the name collision problem
would be welcome.

Thanks,
Zev