[pmbusplus] userspace i2c, pmbus interactions

[Jason Ling]

>
> > However, in general, ADI PMBus devices have a PAGE command, especially
> the LTC388X and LTC297X families.
> >
> > This means that many actions require locking the bus to create compound
> transactions or the use of PAGE_PLUS.
> >
> > The In System Programming code we support on linux via /dev/i2c has this
> issue. If another process touched hwmon during programming, and touches a
> PAGE, the programming may fail, or worse it sends the wrong settings.
> I'm not sure how this is even possible.  How did an hwmon driver touch
> the device and userspace access it?  I'm fairly sure.


IIRC there is some protection if you use the smbus_readX smbus_writeX APIs
but if you're doing ioctl(I2C_RDWR) then a hwmon driver being bound to a
device won't stop you from hammering on it.
Also userspace can pass the force option to i2c-dev and it'll let you
hammer away on the device as well.

On Fri, Apr 30, 2021 at 1:54 PM Patrick Williams <patrick at stwcx.xyz> wrote:

> On Fri, Apr 30, 2021 at 09:43:21AM -0600, Mike Jones wrote:
>
> > I had a similar discussion with Guenter, who suggested that any i2c code
> in user space is problematic, but I think it also said there was enough
> locking in the drivers that SMBus transactions from /dev/i2c or i2c-tools
> would not interact with hwmon.
>
> I'm pretty sure there is locking such that the kernel won't let you talk
> to a
> device that is already bound to a driver.  Once you unbind the kernel side
> you're free to do what you want.
>
> What I don't recall is how much of the i2c-mux support gets propagated
> out to userspace.  Hopefully you don't have to mess with moving muxes
> and talking past those devices.  (I've seen some nasty shell scripts
> using i2c-tools doing things like this in the past.)
>
> > However, in general, ADI PMBus devices have a PAGE command, especially
> the LTC388X and LTC297X families.
> >
> > This means that many actions require locking the bus to create compound
> transactions or the use of PAGE_PLUS.
> >
> > The In System Programming code we support on linux via /dev/i2c has this
> issue. If another process touched hwmon during programming, and touches a
> PAGE, the programming may fail, or worse it sends the wrong settings.
>
> I'm not sure how this is even possible.  How did an hwmon driver touch
> the device and userspace access it?  I'm fairly sure.
>
> > If the work within the PMBus community to have a standard programming
> file format, if it were to be applied in user space, OBMC would have to
> disable hwmon and all telemetry while the programming is in process.
> >
> > If the file (or data blob) was applied in a kernel driver, it could lock
> the i2c during the process so that all hwmon activity and telemetry are
> held off.
>
> Right.  I would expect the locking at a pmbus level so that the
> pmbus-hwmon parts would block on a mutex until the firmware update is
> complete (if firmware update were done in the pmbus driver).
>
> > This problem is not unique to our desire for a file format. That is
> driven by the vendors complexity and business models.
> >
> > But, in the context of the ADM1266, it is a multipage device. The DS
> does not say it can do PAGE_PLUS. Therefore, unless I am missing something,
> the above problems apply unless using a PAGEless bulk programming
> mechanism. I don’t know this part well enough to know how that works, or if
> it is published.
> >
> > The other two families LTC388X and LTC297X do have a PAGEless bulk
> programming. We don’t like do it with telemetry hammering it, mainly
> because it feels risky.
> >
> > Finally, one could argue that most OMBC systems are using the 1266 and
> not the other parts. But I can say I have sent patches for other parts to
> OBMC users, so they are in use.
>
> There is already some firmware blob support in the kernel, just not for
> pmbus.  Has anyone investigated what (if anything) we'd need to do to be
> able to leverage this?
>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210430/ff378b73/attachment.htm>