[pmbusplus] userspace i2c, pmbus interactions

[Patrick Williams]

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 --------------
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/81563958/attachment.sig>