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

Alex Qiu xqiu at google.com
Thu Jul 9 07:46:22 AEST 2020


On Wed, Jul 8, 2020 at 11:06 AM Ed Tanous <ed at tanous.net> wrote:
>
> On Wed, Jul 1, 2020 at 10:06 AM Alex Qiu <xqiu at google.com> wrote:
> >
> > On Tue, Jun 30, 2020 at 7:00 PM Ed Tanous <ed at tanous.net> wrote:
> > >
> > > I'm not following that statement.  "find the bus number" would occur
> > > whether or not you have the busses hardcoded.  Are you advocating for
> > > not using hwmon sensors here?  Needing to do a calculation for the new
> > > part you're adding would need to be done regardless.  If you turn it
> > > into a hwmon sensor, you could have the kernel do the math for you,
> > > and keep your debugability.
> >
> > Hardware engineers want to set the output voltage for voltage
> > regulators for debugging, which is not covered by hwmon interface or
> > drivers, so we need to send raw I2C commands.
> Or add support to the drivers.....
> I'm not against raw i2c commands for debugging, but long term, it's
> really hard to maintain (as you seem to be finding).

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. Although we haven't yet met the need to set the
voltage other than debugging.

>
> With respect to those companies, their downstream is their problem.
> That's why upstreaming is important.  I'm not saying we need to break
> things unnecessarily, but it's a really poor excuse to say we can't
> change things because of an unknown entity that didn't share their
> code.  If they exist, they're using a feature that's relatively new to
> entity manager, and so far as I know, is only used in a single case,
> and in that case, mod operator is at the same or greater precedence
> than + operator, so you could make the change with zero impact to a
> anyone that I'm aware of.
>
>
> We've gone several rounds on this email, with a lot of places where
> you could make improvements, including many that wouldn't break
> anything, but you always seem to come back to being too busy for it,
> or it not being "upstreamable".  Is there anything that the project
> could do to help convince you to at least share some changes that
> you've suggested?  The feedback is really great, but I was hoping with
> the level of interest you have in this, you'd be interested in putting
> together some patchsets to do some of these things, even if they're
> minor, like adding support for your new chip.

First of all, I don't have the magic to turn downstream patches into
an upstream fix in one day, one week or so, and we currently have the
priority to fix sensor performance issues so that we can get our new
platform out of the door this month. On the other hand, my intention
is to get this conversation started and rolling before we eventually
have the free time to deal with all the technical debt we accumulated
downstream, so that we know the aim is as soon as we are at that
stage.

Clearly, I see the conversation we had so far is greatly valuable at
least to us, and I believe we have an internal communication gap to
fill between different teams first. For example, before the
conversation, I never knew that we were supposed to upstream our
configuration files. By contrast, I was told that these code names
can't be publicized, and we've been keeping patches downstream, so
there's definitely something to resolve internally first. Our team has
been working underwater for a long time without knowing these
intentions upstream, and I think it's the first time that we reach
upstream in this level of detail.

I hope this explains that I can't put up patches for things that I've
been aware of right away, since we might have been doing something in
the wrong way for quite some time. Thanks.

- Alex Qiu


More information about the openbmc mailing list