[pmbusplus] userspace i2c, pmbus interactions

[Jason Ling]

Thanks Mike for the feedback

And the context is more than CPU based systems, but includes Networking,
> other boards with ASICS, etc. So broad context. Hence, it has to work
> within linux without OBMC.

Ack, although the library was written for a use-case that involves obmc, it
doesn't *require* obmc. Should work just fine in general Linux.

 Now, imagine the IC manufacturer's tool produces a file that can represent
> a qualified algorithm that is known to work under all possible scenarios,
> including CRC errors in parts, corrupt NVM, etc. This is what all the
> vendors do today. They take care of all the things that can go wrong. In
> the case of ADI, if power was lost while programming, and the BMC or linux
> can boot from an aux supply, our data files (encoding algorithms), can
> repair the part under ALL possible random values in the corrupt part.

This would be great, especially if this is codified in the pmbus spec.
Right now the library provides a pmbus interface but *part programming* is
specific to each device class...no guarantee of a common interface across
multiple parts.

1) I am interested in anything that enables our work

Sure, I'll start carving out more time to make this work suitable for
upstreaming. At the very least it should give you a mockable interface to
allow for strong unit testing of upper layers.


> 2) I am interested in inviting someone from the community, not IC vendor,
> to our meetings to offer advice and help us define something useful

Sounds good, feel free to reach out to me on an individual basis.

On Mon, Apr 26, 2021 at 7:33 PM Mike Jones <proclivis at gmail.com> wrote:

> Jason,
>
> I am interested, because within the PMBus Specification Committee, we are
> working on a data language intended for device programming. And there is
> hope that eventually it can become adopted into linux and/or OBMC.
>
> There is a particular use model that is being driven by the IC suppliers
> and their tools. One reason is that all the vendors have proprietary tools,
> but they see no competitive advantage, and would rather support a universal
> standard.
>
> Imagine that programming might be done for:
>
> - ICT
> - Proto Builds
> - Engineering Bringup
> - Remote upgrades
>
> And the context is more than CPU based systems, but includes Networking,
> other boards with ASICS, etc. So broad context. Hence, it has to work
> within linux without OBMC.
>
> My view is it is a linux library anyone can use, and OBMC is the piping if
> it were exposed to a web service, state management, etc.
>
> Now, imagine the IC manufacturer's tool produces a file that can represent
> a qualified algorithm that is known to work under all possible scenarios,
> including CRC errors in parts, corrupt NVM, etc. This is what all the
> vendors do today. They take care of all the things that can go wrong. In
> the case of ADI, if power was lost while programming, and the BMC or linux
> can boot from an aux supply, our data files (encoding algorithms), can
> repair the part under ALL possible random values in the corrupt part.
>
> Furthermore, an integrator (CM, Design House, software team) has to deal
> with segmented I2C busses, muxes, etc. And the integrator wants to write a
> wrapper file that integrates all the vendor files. So this integration file
> has to take care of muxes, order of operations, calling vendor files, etc.
>
> My interest is two part:
>
> 1) I am interested in anything that enables our work
> 2) I am interested in inviting someone from the community, not IC vendor,
> to our meetings to offer advice and help us define something useful
>
> Mike
>
>
>
> > On Apr 23, 2021, at 4:22 PM, Jason Ling <jasonling at google.com> 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).
> >
> > 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..
> >
> > Anyways, wanted to gauge community interest in this so I can determine
> how motivated I should be to upstream it.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210427/2b7d6121/attachment-0001.htm>