Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <314489f6-cb54-fb3b-6557-d69b1284fa4d@amd.com>
Date:   Fri, 13 Jan 2023 13:54:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Content-Language: en-US
To:     Greg KH <gregkh@linuxfoundation.org>
CC:     Kris Chaplin <kris.chaplin@amd.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <CAPDLWs-Z8pYkwQ13dEgHXqSCjiq4xVnjuAXTy26H3=8NZCpV_g@mail.gmail.com>
 <Yz/ZWBeNZvKenEVM@kroah.com>
 <CAPDLWs9KWKs_-fpAp2=97uBARYqrHSYTPEU6RbqtWjAD8NpqgQ@mail.gmail.com>
 <CAPDLWs9CoWw7NLfrtCfMsRAdCSfBgomVELRhM70QWVca99z65A@mail.gmail.com>
 <Y53BputYK+3djDME@kroah.com> <c6c4787f-f0c6-7285-f782-d36bd86b1e01@amd.com>
 <96e41e6d-bec9-f8cf-22ed-1fa5d9022238@amd.com> <Y8FAFAwB9gBzQXQG@kroah.com>
From:   Michal Simek <michal.simek@amd.com>
Subject: Re: Reg the next LTS kernel (6.1?)
In-Reply-To: <Y8FAFAwB9gBzQXQG@kroah.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2023 12:54:33.3793
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 262bee22-b86b-418d-d6d6-08daf5655185
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT114.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4183
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 1/13/23 12:27, Greg KH wrote:
> On Thu, Jan 12, 2023 at 01:26:28PM +0100, Michal Simek wrote:
>> Hi Greg,
>>
>> On 1/12/23 13:23, Kris Chaplin wrote:
>>> Hello Greg,
>>>
>>>> You tell me please.  How has your testing gone for 6.1 so far?  Does it
>>>> work properly for you?  Are you and/or your company willing to test out
>>>> the -rc releases and provide feedback if it works or not for your
>>>> systems?  Do you have problems with 6.1.y vs. older kernels?  Is there
>>>> anything missing in it that you feel needs to be addressed with a newer
>>>> kernel instead?
>>>
>>> We have been integrating and testing 6.1 on the Microblaze, ARM32 and
>>> ARM64-bit architectures over the past few weeks.  These builds have
>>> been successful and we are able to run our regression tests on hardware
>>> targeting our FPGA SoC devices.
>>>
>>> We're continuing our tests as new updates to the 6.1 kernel series
>>> appear.
>>
>> As Kris said AMD/Xilinx has already moved internal SOC tree to 6.1 based
>> kernel in expectation that 6.1 will become next LTS.
>> And I am not aware about any issue from testing team related to 6.1 kernel
>> version. And we are covering our AMD/Xilinx SOCs based on arm32/arm64 and
>> Microblaze CPUs.
>>
>> It would be good to continue with the same strategy which using the latest
>> kernel at that year which is what I am hearing all the time from others that
>> 6.1 was last kernel at that year and it should be LTS.
> 
> Generally yes, I pick the last release of the year but we need people to
> verify and validate that both it works for them, and that they are going
> to be using it in their systems and can provide testing results to us
> (as well as providing a way for their devices to actually be updated to
> the new releases, we've had previous stable kernel releases that were
> never actually shipped out to devices...)

We are preparing base (every year) for our customers which is what it is also 
shipped in our distribution.
Other distribution like Ubuntu with their derivative kernels prefer to stay on 
the LTS kernels too.
Also users will be getting fixes against our base for extended period with fixes 
going from vanilla kernel.
For code which is not upstream(which we unfortunately have it) we are providing 
fixes only till the next LTS version base is created.

That's why it is very beneficial to use for our base kernel which is going to be 
LTS that users will get that extended period support.

Base Kernel version is taken after your decision about LTS. But this year 
because of timing we couldn't wait for this decision. That's why 6.1 was taken 
with expectation that your generic concept about picking up the last release of 
the year is going to continue.

Tested wise. We have test result from 6.1 <.0> and I have also shared 6.1.5 
based version for our distribution. As of today we can't see any issue with 6.1 
kernel in general on features which we are using on AMD/Xilinx SOCs.

Also Jonathan wrote at https://lwn.net/Articles/915435/
"Unless something extremely surprising happens, 6.1 will be the final kernel 
release for 2022, and thus will become the next LTS kernel."
That's why I hope that 6.1 is going to be next LTS.

> 
>> I didn't run any stats but normally also more patches are going to this
>> version to be the part of LTS.
> 
> What do you mean by this?  The patches accepted so far since 6.1.0 was
> released, or up until 6.1.0 was released?  For the patches since 6.1.0
> was released, that's due to more developers/maintainers tagging patches
> during the -rc1 merge window for stable releases (honestly they should
> have gotten them into the -final release first), and due to us having
> better tools in digging up potential stable patches (i.e. Sasha's
> AUTOSEL bot work.)

I am just saying that developers/driver owners can simple do calculation to 
identify LTS version. When they know it they also know time when their deadline 
is for upstreaming work. It means if patch is accepted between 6.0-r1 and 
6.0-rc5/6 they know that it will get to 6.1 merge window.
And by this there will be less patches pending for the next release upgrade.
I am not working in this mood but I have met with it couple of times.

Thanks,
Michal