[pmbusplus] userspace i2c, pmbus interactions

[Jason Ling]

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


Yup, this definitely isn't pleasant but it's doable. Have you had
experiences where unbinding/binding caused lots of pain? The only pain that
I've seen is that telemetry daemons generally don't take well to having
hwmon sysfs attributes yanked from underneath them.
Just spitballing.. but for devices that need to be upgradeable *and* need
to report telemetry, that such things should be done in a single service
and perhaps it makes the most sense to do it all in userspace (to avoid
ugly unbinding/binding).


>
> >        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?


Firmware/config upgrades and the reason is that your patch will get
rejected.
The feeling is that "dangerous" i2c things that could brick the system or
damage it shouldn't be put into the kernel and that the preference is to
have this done in userspace via i2c-dev. This statement was made about
sequencer config and firmware upgrades.
I suspect it would extend to arbitrarily adjusting voltages, putting
devices into special states, sending control commands to a device's non
pmbus standard i2c interface (vendor specific stuff, like indirect register
accesses).

On Fri, Apr 30, 2021 at 8:45 AM Jason Ling <jasonling at google.com> 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?
>
> 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/3093072f/attachment-0001.htm>