[U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL

[Michael Cashwell]

On Apr 2, 2013, at 2:56 PM, Tom Rini <trini at ti.com> wrote:

> On 04/02/2013 02:41 PM, Michael Cashwell wrote:
> 
>> I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in 
>> u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71.
> 
> You're on a 3.0.8 from somewhere-within-TI, that's not getting regular updates (or it would be on 3.0.71 or close-to), yes?

It's an Android-related project and the kernel is what was current for Ice Cream Sandwich at the time the development started. Being Anddroid-related I expect you can appreciate why kernel updates are not trivial undertakings.

Would 3.0.71 not need the legacy support? I could likely update to 3.0.71 but going to 3.4.x or 3.8.x would have a large ripple effect to the rest of the system.

>> ... forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing.
>> 
>> I'm very worried if that's what's being proposed here as it would be very user unfriendly.
> 
> What I'm saying is that once either mainline, or another TI-provided tree exists and doesn't need these options set, they can go away.

IMO, that's overly dismissive of the collateral impact of making such a large kernel change. As noted, there are many cases where users can update to the latest patch level but more than that is too invasive.

One could argue that no one's being forced. If a user's kernel is stuck then having their boot loader also be stuck is OK. Perhaps, but it seems a bit artificial.

I want several new u-boot features (DFU, USB host Ethernet, GPT support, etc.) but cannot casually update my Linux kernel. These feature sets are clearly orthogonal and I would lament an all-or-nothing binding that wasn't technically necessary.

-Mike