From: Patrick Williams <patrick@stwcx.xyz>
To: William Kennington <wak@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Joel Stanley <joel@jms.id.au>
Subject: Re: Linux kernel updates and v6.0
Date: Wed, 5 Oct 2022 06:32:57 -0500 [thread overview]
Message-ID: <Yz1raUAKT8CjTp7o@heinlein> (raw)
In-Reply-To: <CAPnigK=NZVWH+msS3Ajf-RBQqzK9hnoecizuFF=QbKh-mK=DNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
Joel,
Any thoughts on this?
On Wed, Sep 28, 2022 at 03:30:23PM -0700, William Kennington wrote:
> The ToF was talking about linux versions being used for OpenBMC users and
> we were wondering if we could codify a policy around which versions we will
> be developing against regularly. In the past it seems like you usually pick
> LTS releases to base on (and Facebook / Google are interested in sticking
> with LTS releases in order to reduce toil / number of potentially
> incompatible kernel upgrades for each of our machines). It would seem like
> kernel 6.0 should be an LTS release, although gregkh hasn't said anything
> specifically about it yet. Can we get something written about the expected
> alignment with upstream kernel release cadence?
For minor clairification, I believe it was Intel / Google that preferred
LTS. Meta does not have a preference as long as the OpenBMC tree is
well-supported and we can backport changes that have been sent
upstream.
> On Tue, Sep 27, 2022 at 11:35 PM Joel Stanley <joel@jms.id.au> wrote:
>
> > Hello OpenBMC,
> >
> > We've been using the v5.15 kernel as a base for almost 11 months. In
> > that time there's been 16 bumps to pull in stable fixes. We have
> > merged about 300 patches in that time to support new machines, and new
> > hardware, including MCTP, nct6775, lm25066, aspeed-adc and aspeed's
> > spi-nor devices.
> >
> > It's time to move to a new base to ensure progress is made on our
> > mission to upstream all of the support. By rebasing on a new kernel
> > release we can see what work has been done, and what remains. Since
> > v5.15 we have upstream support for:
> >
> > - PECI, thanks to Jae and Iwona
> > - MCTP, thanks to Jermey and Matt
> > - spi-nor, thanks to Cédric
> > - nct6775 i2c and lm25066, thanks to Zev
> > - ast2600 adc, thanks to Billy
> > - ast2600 gfx, thanks to Tommy
> >
> > and others I have missed.
> >
> > In addition to the ASPEED changes the Nuvton hackers have been hard at
> > work. We now have support for their latest generation Cortex-A35 BMC,
> > the npcm845 "Arbel" and it's eval board. Likewise the HPE "GXP"
> > Cortex-A9 ASIC now has upstream support. Congratulations to both teams
> > for this work.
> >
> > I have prepared a v6.0 tree that contains backports of the FSI and
> > Aspeed v6.1 patches, and a small set of existing patches. I will
> > publish this on Monday, or once v6.0 final has been tagged.
> >
> > As promised the last time we rebased, the Nuvoton patches that have
> > not seen any updates since they were merged in 2019 have been dropped.
> > They are welcome to be resubmitted as long as they are also being
> > worked on upstream.
> >
> > Please address any future patches to the dev-6.0 tree.
> >
> > Cheers,
> >
> > Joel
> >
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-10-05 11:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 6:34 Linux kernel updates and v6.0 Joel Stanley
2022-09-28 22:30 ` William Kennington
2022-10-05 11:32 ` Patrick Williams [this message]
2022-10-24 4:32 ` Joel Stanley
2022-10-06 1:26 ` Joel Stanley
2022-10-06 3:31 ` Patrick Williams
2022-10-06 8:33 ` Joel Stanley
2022-10-06 7:04 ` Quan Nguyen
2022-10-06 8:37 ` Joel Stanley
2022-10-06 12:52 ` Quan Nguyen
2022-10-24 0:07 ` Tao Ren
2022-10-24 4:31 ` Joel Stanley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yz1raUAKT8CjTp7o@heinlein \
--to=patrick@stwcx.xyz \
--cc=joel@jms.id.au \
--cc=openbmc@lists.ozlabs.org \
--cc=wak@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.