<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">I assume you mean "internal to Google applications"?</blockquote><span class="gmail-im" style="color:rgb(80,0,80)">Yes<br></span>I have two questions that come to mind:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 1. Why was the library provided by i2c-tools not good enough?<br> (ie. What are you bringing to the table that should make people<br> want to use your library rather than a widely used existing<br> library?)</blockquote>i2c-tools are functionally fine; the initial motivation of this library was to improve testability of the code that uses it. As a result C++ i2c-tools bindings that themselves are unit tested and mockable (so applications that interact with i2c could also be unit tested).<div><br></div><div><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 2. How does the availability (and potential recommendation of usage<br> by our community) affect the effort to ensure that all i2c and<br> pmbus drivers are upstreamed?</blockquote><div>Well, this library is meant for userspace usage. So i2c (hwmon?) and pmbus drivers would continue to be upstreamed as per usual.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> To further clarify this question, we've generally said we want to<br> see code using and contributing to upstream Linux subsystems when<br> those subsystems already exist. We don't want a reimplementation<br> of the i2c and pmbus subsystem in userspace when those are<br> already well-supported upstream by the kernel.</blockquote>Agreed, but some things just get rejected when you try to push them upstream. Like updating sequencer firmware, or updating some other non pmbus device via i2c. We've tried, patches were rejected.</div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> What is it that makes you want to write your code using low-level<br> i2c and PMBus APIs directly in userspace instead of writing or<br> updating drivers and using the various high-level user APIs<br> provided by kernel subsystems?</blockquote>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.</div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I see you mentioned "pmbus device upgrades" and I know the PMBus<br> subsystem doesn't currently support firmware upgrade paths. But,<br> there has been LKML threads about it and what I recollect was<br> that it wasn't "not allowed" but just "not implemented".<br> Shouldn't we be focusing our efforts on enhancing features for<br> the whole OSS community rather than building our own different<br> library?</blockquote><div>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.</div></div></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 30, 2021 at 7:18 AM 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 23, 2021 at 03:22:35PM -0700, Jason Ling wrote:<br>
> Hi all,<br>
> <br>
> What started as an attempt to create a simple command line tool to perform<br>
> pmbus device upgrades over i2c has turned into the start of a user-space<br>
> i2c library (with some pmbus support).<br>
> <br>
> I've already reused this library in some other obmc applications and it's<br>
> been fairly well unit-tested. It also comes with all the public interfaces<br>
> mocked (so you can unit test your own code).<br>
<br>
I assume you mean "internal to Google applications"?<br>
<br>
> The idea is that more and more classes get added that will support<br>
> different pmbus devices.<br>
> General idea is that each device that gets support can expose methods to<br>
> allow device upgrade, black box retrieval, etc..<br>
<br>
I have two questions that come to mind:<br>
<br>
1. Why was the library provided by i2c-tools not good enough?<br>
(ie. What are you bringing to the table that should make people<br>
want to use your library rather than a widely used existing<br>
library?)<br>
<br>
2. How does the availability (and potential recommendation of usage<br>
by our community) affect the effort to ensure that all i2c and<br>
pmbus drivers are upstreamed?<br>
<br>
To further clarify this question, we've generally said we want to<br>
see code using and contributing to upstream Linux subsystems when<br>
those subsystems already exist. We don't want a reimplementation<br>
of the i2c and pmbus subsystem in userspace when those are<br>
already well-supported upstream by the kernel.<br>
<br>
What is it that makes you want to write your code using low-level<br>
i2c and PMBus APIs directly in userspace instead of writing or<br>
updating drivers and using the various high-level user APIs<br>
provided by kernel subsystems?<br>
<br>
I see you mentioned "pmbus device upgrades" and I know the PMBus<br>
subsystem doesn't currently support firmware upgrade paths. But,<br>
there has been LKML threads about it and what I recollect was<br>
that it wasn't "not allowed" but just "not implemented".<br>
Shouldn't we be focusing our efforts on enhancing features for<br>
the whole OSS community rather than building our own different<br>
library?<br>
<br>
-- <br>
Patrick Williams<br>
</blockquote></div>