PECI patchset status

[Ed Tanous]

On Fri, Sep 4, 2020 at 9:36 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Thu, Sep 03, 2020 at 10:15:56AM -0700, Vernon Mauery wrote:
> > On 03-Sep-2020 10:27 AM, Patrick Williams wrote:
> > >On Thu, Sep 03, 2020 at 05:57:48AM +0000, Mihm, James wrote:
> > >Rather than create a separate fork of the kernel, is there something
> > >that could be done here to have someone from Intel work with Joel on
> > >preparing the patches?  When a new kernel comes out, Joel can ensure it
> > >works on the base AST2xxx system design and before we move all the
> > >systems to it, someone from Intel can rebase the non-upstreamed patches
> > >they are carrying?  This hopefully reduces some of the burden on Joel
> > >and stops us from further fragmenting the community.
> >
> > Keep in mind that Intel does not plan to keep the fork around
> > indefinitely. The hope is to fully upstream all of the patches that we
> > have outstanding. Our intention is not to fragment the community, but to
> > provide a mechanism to continue to move forward while still providing a
> > way for other users to build the intel-platforms target.
> >
> > As an added feature, having our full kernel source in a publicly
> > available tree will allow us to upstream more features that depend on
> > kernel support that is not currently available.
>
> I'm not really following this last paragraph.  I suppose you're saying
> that you have kernel changes that are not in openbmc/linux that add
> additional features?  Why aren't they in openbmc/linux?  I thought there
> was a process for getting code in that isn't quite ready for
> upstreaming, as long as there is progress towards that?  Is there some
> list of what these features are and what the upstreaming state is,
> because this original thread was about PECI, but you're implying there
> is much more.

I pulled down the tree the other day and counted 84 independent
patches.  How many of these have been submitted to upstream?

>
> If the process isn't working for the community shouldn't we discuss
> improving that to something that does work?  It seems like your team has
> decided to go to the nuclear option of forking after Joel has proposed
> dropping a patchset that he's been carrying for three months short of
> three years.
>
> Joel does great work of keeping the kernel up to date, both on a major
> release and picking up supplemental fixes.  Is Intel committing to this
> same level of support that Joel is currently providing for your own
> fork?
>
> Past performance doesn't really give me a lot of confidence that this
> will be a short-term fork.  In December 2019, Joel raised this exact
> same problem with the PECI driver[1] and it was promised that there
> would be forward progress "within a week"[2].  One week later, there was
> a v11 of the patches posted[3] and we got some good comments from a
> variety of upstream maintainers.  Since then, there has been zero
> activity.  Shouldn't we have seen a v12 pretty quickly after that?

+1.  I'm really wondering what's holding this up.

>
> 1. https://lists.ozlabs.org/pipermail/openbmc/2019-December/019684.html
> 2. https://lists.ozlabs.org/pipermail/openbmc/2019-December/019728.html
> 3. https://lists.ozlabs.org/pipermail/openbmc/2019-December/019823.html
>
> --
> Patrick Williams