PECI patchset status

[Mihm, James]

>-----Original Message-----
>From: Patrick Williams <patrick at stwcx.xyz>
>Sent: Friday, September 4, 2020 9:35 AM
>To: Vernon Mauery <vernon.mauery at linux.intel.com>
>Cc: Mihm, James <james.mihm at intel.com>; OpenBMC Maillist
><openbmc at lists.ozlabs.org>
>Subject: Re: PECI patchset status
>
>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.
>
>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?
>

[James Mihm] 
As a product development team, we need to balance between product deliverables and upstreaming. Where product deliverables and schedules have taken priority over upstreaming.
We are working on a prioritized kernel upstreaming plan and will be sharing with the community after internal reviews. 

Regarding the PECI v11 driver, the kernel maintainers reached out to us with additional requirements before we could proceed with v12. We are taking steps to meet those requirements.

The Intel fork of openbmc/linux is to allow anyone needing to build openbmc for an Intel server and to be able to do so without having to apply patches. Placing the burden of maintaining the 84+ Intel patches against the kernel on ourselves while working through the upstreaming process. Intel would own rebasing the Intel fork with openbmc/linux. The lifespan of this fork would be as short as possible and is dependent upon our execution to upstream our patchsets.

Would it be acceptable for all of the 84+ Intel patches to reside in the openbmc repo while we work through the upstreaming process? 
Some of the patches require design changes and will take much longer to upstream.

James

>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