<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">So any provisioning for updates could include provision for initial values if you want it to be controlled outside device tree.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 30, 2021, at 3:00 PM, Jason Ling <<a href="mailto:jasonling@google.com" class="">jasonling@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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 class=""></span><span class="gmail-im" style="color:rgb(80,0,80)">><br class=""></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 class=""></span><span class="gmail-im" style="color:rgb(80,0,80)">><br class=""></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 class=""></span>I'm not sure how this is even possible. How did an hwmon driver touch<br class="">the device and userspace access it? I'm fairly sure.</blockquote><div class=""><br class=""></div><div class="">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 class="">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 class=""><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" class="">patrick@stwcx.xyz</a>> wrote:<br class=""></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 class="">
<br class="">
> 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 class="">
<br class="">
I'm pretty sure there is locking such that the kernel won't let you talk to a<br class="">
device that is already bound to a driver. Once you unbind the kernel side<br class="">
you're free to do what you want.<br class="">
<br class="">
What I don't recall is how much of the i2c-mux support gets propagated<br class="">
out to userspace. Hopefully you don't have to mess with moving muxes<br class="">
and talking past those devices. (I've seen some nasty shell scripts<br class="">
using i2c-tools doing things like this in the past.)<br class="">
<br class="">
> However, in general, ADI PMBus devices have a PAGE command, especially the LTC388X and LTC297X families.<br class="">
> <br class="">
> This means that many actions require locking the bus to create compound transactions or the use of PAGE_PLUS.<br class="">
> <br class="">
> 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 class="">
<br class="">
I'm not sure how this is even possible. How did an hwmon driver touch<br class="">
the device and userspace access it? I'm fairly sure.<br class="">
<br class="">
> 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 class="">
> <br class="">
> 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 class="">
<br class="">
Right. I would expect the locking at a pmbus level so that the<br class="">
pmbus-hwmon parts would block on a mutex until the firmware update is<br class="">
complete (if firmware update were done in the pmbus driver).<br class="">
<br class="">
> This problem is not unique to our desire for a file format. That is driven by the vendors complexity and business models.<br class="">
> <br class="">
> 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 class="">
> <br class="">
> 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 class="">
> <br class="">
> 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 class="">
<br class="">
There is already some firmware blob support in the kernel, just not for<br class="">
pmbus. Has anyone investigated what (if anything) we'd need to do to be<br class="">
able to leverage this?<br class="">
<br class="">
-- <br class="">
Patrick Williams<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>