[pmbusplus] userspace i2c, pmbus interactions

[Patrick Williams]

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