[pmbusplus] userspace i2c, pmbus interactions

[Mike Jones]

For some additional context, devices like LTC2991/2 have no EEPROM. The configuration is set when the driver initializes using values in the device tree.

So if they are updated in the field somehow, it has to be done after every boot, because they will be reset to the device tree values.

So any provisioning for updates could include provision for initial values if you want it to be controlled outside device tree.

> On Apr 30, 2021, at 3:00 PM, Jason Ling <jasonling at google.com> wrote:
> 
> > 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 <mailto: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/d2c35ddd/attachment.htm>