On 8/12/22 13:49, Philip Prindeville wrote:
On Aug 12, 2022, at 11:54 AM, Florian Fainelli <f.faine...@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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
