[pmbusplus] userspace i2c, pmbus interactions

[Jason Ling]

>
> I assume you mean "internal to Google applications"?

Yes
I have two questions that come to mind:

    1. Why was the library provided by i2c-tools not good enough?
>        (ie. What are you bringing to the table that should make people
>        want to use your library rather than a widely used existing
>        library?)

i2c-tools are functionally fine; the initial motivation of this library was
to improve testability of the code that uses it. As a result C++ i2c-tools
bindings that themselves are unit tested and mockable (so applications that
interact with i2c could also be unit tested).


    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.

       To further clarify this question, we've generally said we want to
>        see code using and contributing to upstream Linux subsystems when
>        those subsystems already exist.  We don't want a reimplementation
>        of the i2c and pmbus subsystem in userspace when those are
>        already well-supported upstream by the kernel.

Agreed, but some things just get rejected when you try to push them
upstream. Like updating sequencer firmware, or updating some other non
pmbus device via i2c. We've tried, patches were rejected.

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



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

> On Fri, Apr 23, 2021 at 03:22:35PM -0700, Jason Ling wrote:
> > Hi all,
> >
> > What started as an attempt to create a simple command line tool to
> perform
> > pmbus device upgrades over i2c has turned into the start of a user-space
> > i2c library (with some pmbus support).
> >
> > I've already reused this library in some other obmc applications and it's
> > been fairly well unit-tested. It also comes with all the public
> interfaces
> > mocked (so you can unit test your own code).
>
> I assume you mean "internal to Google applications"?
>
> > The idea is that more and more classes get added that will support
> > different pmbus devices.
> > General idea is that each device that gets support can expose methods to
> > allow device upgrade, black box retrieval, etc..
>
> I have two questions that come to mind:
>
>     1. Why was the library provided by i2c-tools not good enough?
>        (ie. What are you bringing to the table that should make people
>        want to use your library rather than a widely used existing
>        library?)
>
>     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?
>
>        To further clarify this question, we've generally said we want to
>        see code using and contributing to upstream Linux subsystems when
>        those subsystems already exist.  We don't want a reimplementation
>        of the i2c and pmbus subsystem in userspace when those are
>        already well-supported upstream by the kernel.
>
>        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 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?
>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210430/4c044fc6/attachment.htm>