[pmbusplus] userspace i2c, pmbus interactions
patrick at stwcx.xyz
Sat May 1 06:44:33 AEST 2021
On Fri, Apr 30, 2021 at 08:45:14AM -0700, Jason Ling wrote:
> On Fri, Apr 30, 2021 at 07:52:36AM -0700, Jason Ling wrote:
> Whew...took a lot longer to find the thread but here is the explicit
> rejection of firmware and configuration upgrade from within the kernel
I feel like we're not really engaging well with Guenter on some of these
hwmon/pmbus use cases. He rejected it but there was not any response
from the author on why this is useful, or any engagement on how we
This should be done ... in a controlled environment (eg manufacturing).
It can easily brick the hardware, and should not be done in the driver.
We do upgrades of firmware outside of manufacturing all the time. We
need to engage in a real discussion with him. If we are comfortable
doing this, why can't we do it? If he is worried about other
environments, like a general Linux desktop that happened to hook up a
PMBus to a power supply, then lets make it a compile option.
There is other firmware update support in the kernel so the "possibility
of bricking" is not a convincing argument to me.
> other things like don't put in ioctls
Not putting in ioctls isn't unreasonable if there is another way to
accomplish this. In general, adding ioctls seems to be a rare activity
and there is a preference for sysfs or debugfs interfaces.
> I suspect that things like adjusting voltages would similarly be rejected
> but honestly we haven't gone down that path yet.
About two years ago I was able to modify the voltage on a VR using the
PMBus subsystem and a one-line change to set a sysfs to R/W instead of
R/O. I didn't contribute it upstream because of [reasons given by a
former employer], but it doesn't seem non-doable. Again, I think we'd
need to engage if we're rejected on first pass.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the openbmc