Feedback on Current OpenBMC and Proposing Some Improvements ---- "Improvements" Ideas

[Alex Qiu]

Thank you, Ed!

Hi Brad,

Last time we checked with the maintainer Guenter Roeck
<linux at roeck-us.net>, I remembered that he suggested we could add
these controls in debugfs. Feel free to reach out to him and see if
anything new is coming up.

On the other hand, my solution to this of the proposals in these email
series is to create a wrapper library around I2C devices and hwmon. We
can continue to have the benefit of hwmon to take care of the reading
tasks, and we can also lock all the I2C access at this level and issue
raw I2C commands as needed without worrying races between I2C
transactions. However, we need to ensure that no other applications
are sneaking below this library and interacting with hwmon sysfs.

Thanks!

- Alex Qiu


On Thu, Jul 9, 2020 at 5:43 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> On Wed, Jul 08, 2020 at 11:15:03PM -0700, Ed Tanous wrote:
> >On Wed, Jul 8, 2020 at 2:46 PM Alex Qiu <xqiu at google.com> wrote:
>
> >> We've talked with the maintainer of hwmon, and he doesn't think adding
> >> these to hwmon interface is a good idea, as hwmon is supposed to be a
> >> monitoring interface.
>
> Except most "monitoring devices" are configurable and/or have a dual
> nature - e.g. voltage regulators.
>
> >> Although we haven't yet met the need to set the
> >> voltage other than debugging.
>
> We have a need to tweak things in the production firmware.
>
> >Excellent.  I hadn't realized you'd done that.  You're right,
> >userspace is probably the right spot for this then.
>
> I dunno.  It would be nice to have an in-kernel solution that allows
> VRMs to be both monitored and controlled.  Mixing i2c-dev with the
> actual vrm driver makes us do strange things like unbinding drivers
> while the vrms are configured, or rewriting the vrm driver monitor
> function in usersapce and missing out on the benefit of a well
> maintained kernel driver.
>
> This problem comes up over and over again.  What would be great is if
> someone with good relationships and standing in the kernel community
> could work with the kernel maintainers to build their understanding of
> how we are using the kernel and figure out a good solution we could
> implement other than just: "use i2c-dev".