Reaching out to Greg KH for 6 year LTS kernel versions

Florian Fainelli f.fainelli at gmail.com
Fri Aug 12 14:06:40 PDT 2022


On 8/12/22 13:49, Philip Prindeville wrote:
> 
> 
>> On Aug 12, 2022, at 11:54 AM, Florian Fainelli <f.fainelli at gmail.com> wrote:
>>
>> One aspect I could see is take for instance a device that is widely popular amongst our user base as was TI's ar7 for instance a while back, and for which we might have done a Linux 5.4, or 5.10 version at the time but we do not wish to continue to maintain.
> 
> 
> Per my previous email, that seems like something that the SoC manufacturer should be doing... Why is this our burden?
> 

Totally agree that SoC manufacturers share a fair amount of 
responsibility, there is no substitute for upstream and it associated 
benefits, but it is a commitment, and you are not stranger to this world.

In terms of supporting a given piece of hardware though, I would 
decouple the timeline.

There is the initial effort required to support your SoC and its many 
products which largely involves writing architecture specific code 
sometimes, DTS files, clock/SPI/USB/NAND/Ethernet MAC/PHY/Switch/Wi-Fi 
drivers for the most part. You would typically target a LTS kernel 
version for that effort such that you amortize that effort over a few 
years to come until the next LTS, and if possible in the meantime try to 
get your patches upstream such that the next LTS requires fewer patches 
to be carried over.

Now, when new stable updates show up though, the amount of merge 
conflicts or SoC support code you need to adjust is minimal compared to 
the other parts of the kernel that got updated.

So back to my example, we could have invested out of tree support for TI 
AR7 up until 5.4 and then decided to put it into an EOL/deep maintenance 
mode. Updating the stable 5.4 kernel would unlikely change the amount of 
AR7 specific patches, so the maintenance cost could be fairly low.

Does that make sense?
-- 
Florian



More information about the openwrt-devel mailing list