[pmbusplus] userspace i2c, pmbus interactions

[Mike Jones]

> On Apr 30, 2021, at 9:10 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> On Fri, Apr 30, 2021 at 07:52:36AM -0700, Jason Ling wrote:
>> 
>>    2. How does the availability (and potential recommendation of usage
>>>       by our community) affect the effort to ensure that all i2c and
>>>       pmbus drivers are upstreamed?
>> 
>> Well, this library is meant for userspace usage. So i2c (hwmon?) and pmbus
>> drivers would continue to be upstreamed as per usual.
>> Motivating use case for userspace i2c transactions are pmbus firmware
>> updates. With adm1266 we tried to upstream sequencer configuration update
>> via the hwmon/pmbus driver, it failed spectacularly. So we have to do it
>> userspace.
> 
> Do you have pointers to the discussion?
> 
>>>      What is it that makes you want to write your code using low-level
>>>       i2c and PMBus APIs directly in userspace instead of writing or
>>>       updating drivers and using the various high-level user APIs
>>>       provided by kernel subsystems?
>> 
>> I speak in the context of hwmon/pmbus but these patches were simply
>> rejected. A lot of times the device you want to upgrade is also the device
>> you're gathering telemetry from.
> 
> I think the "is also" is the part that gives me concern.  Generally this
> means binding/unbinding the kernel side of it, which isn't pleasant.
> 
>> 
>>       I see you mentioned "pmbus device upgrades" and I know the PMBus
>>>       subsystem doesn't currently support firmware upgrade paths.  But,
>>>       there has been LKML threads about it and what I recollect was
>>>       that it wasn't "not allowed" but just "not implemented".
>>>       Shouldn't we be focusing our efforts on enhancing features for
>>>       the whole OSS community rather than building our own different
>>>       library?
>> 
>> Fair point but I don't see them as mutually exclusive, use hwmon/pmbus
>> drivers where they make sense and work for you. Switch to userspace for
>> stuff that gets strong pushback from hwmon/pmbus maintainer or stuff that
>> just doesn't make sense to put into a driver.
> 
> My feeling is that we need more definition on what that boundary is.  As
> long as we are really only doing stuff from userspace when there is no
> other path forward, I don't have much concern.  But, I've seen too many
> cases where someone has tried to write an i2c-driver-in-userspace
> because they "didn't like working with the kernel" or some similar
> excuse.

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.

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.

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.

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.