[pmbusplus] userspace i2c, pmbus interactions
patrick at stwcx.xyz
Sat May 1 01:10:24 AEST 2021
On Fri, Apr 30, 2021 at 07:52:36AM -0700, Jason Ling wrote:
> 2. How does the availability (and potential recommendation of usage
> > by our community) affect the effort to ensure that all i2c and
> > pmbus drivers are upstreamed?
> Well, this library is meant for userspace usage. So i2c (hwmon?) and pmbus
> drivers would continue to be upstreamed as per usual.
> Motivating use case for userspace i2c transactions are pmbus firmware
> updates. With adm1266 we tried to upstream sequencer configuration update
> via the hwmon/pmbus driver, it failed spectacularly. So we have to do it
Do you have pointers to the discussion?
> > What is it that makes you want to write your code using low-level
> > i2c and PMBus APIs directly in userspace instead of writing or
> > updating drivers and using the various high-level user APIs
> > provided by kernel subsystems?
> I speak in the context of hwmon/pmbus but these patches were simply
> rejected. A lot of times the device you want to upgrade is also the device
> you're gathering telemetry from.
I think the "is also" is the part that gives me concern. Generally this
means binding/unbinding the kernel side of it, which isn't pleasant.
> I see you mentioned "pmbus device upgrades" and I know the PMBus
> > subsystem doesn't currently support firmware upgrade paths. But,
> > there has been LKML threads about it and what I recollect was
> > that it wasn't "not allowed" but just "not implemented".
> > Shouldn't we be focusing our efforts on enhancing features for
> > the whole OSS community rather than building our own different
> > library?
> Fair point but I don't see them as mutually exclusive, use hwmon/pmbus
> drivers where they make sense and work for you. Switch to userspace for
> stuff that gets strong pushback from hwmon/pmbus maintainer or stuff that
> just doesn't make sense to put into a driver.
My feeling is that we need more definition on what that boundary is. As
long as we are really only doing stuff from userspace when there is no
other path forward, I don't have much concern. But, I've seen too many
cases where someone has tried to write an i2c-driver-in-userspace
because they "didn't like working with the kernel" or some similar
What is something that doesn't make sense to put into a driver and why?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the openbmc