<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">> However, in general, ADI PMBus devices have a PAGE command, especially the LTC388X and LTC297X families.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> This means that many actions require locking the bus to create compound transactions or the use of PAGE_PLUS.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> 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.</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>I'm not sure how this is even possible.  How did an hwmon driver touch<br>the device and userspace access it?  I'm fairly sure.</blockquote><div><br></div><div>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.</div><div>Also userspace can pass the force option to i2c-dev and it'll let you hammer away on the device as well. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 30, 2021 at 1:54 PM Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Apr 30, 2021 at 09:43:21AM -0600, Mike Jones wrote:<br>
<br>
> 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.<br>
<br>
I'm pretty sure there is locking such that the kernel won't let you talk to a<br>
device that is already bound to a driver.  Once you unbind the kernel side<br>
you're free to do what you want.<br>
<br>
What I don't recall is how much of the i2c-mux support gets propagated<br>
out to userspace.  Hopefully you don't have to mess with moving muxes<br>
and talking past those devices.  (I've seen some nasty shell scripts<br>
using i2c-tools doing things like this in the past.)<br>
<br>
> However, in general, ADI PMBus devices have a PAGE command, especially the LTC388X and LTC297X families.<br>
> <br>
> This means that many actions require locking the bus to create compound transactions or the use of PAGE_PLUS.<br>
> <br>
> 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.<br>
<br>
I'm not sure how this is even possible.  How did an hwmon driver touch<br>
the device and userspace access it?  I'm fairly sure.<br>
<br>
> 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.<br>
> <br>
> 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.<br>
<br>
Right.  I would expect the locking at a pmbus level so that the<br>
pmbus-hwmon parts would block on a mutex until the firmware update is<br>
complete (if firmware update were done in the pmbus driver).<br>
<br>
> This problem is not unique to our desire for a file format. That is driven by the vendors complexity and business models.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
<br>
There is already some firmware blob support in the kernel, just not for<br>
pmbus.  Has anyone investigated what (if anything) we'd need to do to be<br>
able to leverage this?<br>
<br>
-- <br>
Patrick Williams<br>
</blockquote></div>