[pmbusplus] userspace i2c, pmbus interactions

[Jason Ling]

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?

Whew...took a lot longer to find the thread but here is the explicit
rejection of firmware and configuration upgrade from within the kernel

https://lkml.org/lkml/2020/8/7/565

other things like don't put in ioctls

https://lkml.org/lkml/2020/6/24/830

This is the strongest use-case as it's been explicitly rejected by the
subsystem maintainer.

I suspect that things like adjusting voltages would similarly be rejected
but honestly we haven't gone down that path yet.


On Fri, Apr 30, 2021 at 8:10 AM Patrick Williams <patrick at stwcx.xyz> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210430/44da3495/attachment.htm>