[pmbusplus] userspace i2c, pmbus interactions

[Mike Jones]

> On Apr 30, 2021, at 2: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.)

In networking boards, I have seen many cases where muxes are part of programming. Because of this, the data language we are working on, which is not very procedural, but does have things like order, polling, retry, etc, is a layered system, where there are files/data per device, and integration file/data that pulls in the per device files, and deals with muxes and such.

That is a little difficult when considering how linux handles them. My understanding is they are in a hierarchy, and there are multiple /dev/i2cN, and when you write to one of them, linux drivers move the mux for you. So any user space application applying a file/data, that handles muxes, has to handle this. So we are thinking that each mux has an ID, and perhaps there is a translation table that maps an abstract mux Id to the actual one, etc.

> 
>> 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.

I think I have tested this and it worked, but it was long ago. My recollection was hwmon and other drivers lock the i2c per transaction, not the driver loads/opens and keeps it locked. But I am not an expert here, so I could be wrong.

> 
>> 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