[pmbusplus] userspace i2c, pmbus interactions

[Patrick Williams]

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

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

What is something that doesn't make sense to put into a driver and why?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210430/daa0a50b/attachment.sig>