[U-Boot] Maximum size of u-boot.imx for TBS2910 board

[Marek Vasut]

On 11/22/19 4:41 AM, Tom Rini wrote:
[...]
>>>>>>>>> I believe
>>>>>>>>> the specific changes in question that once again push this board over
>>>>>>>>> fall in to that grey area.  Whatever size-trimming the board maintainer
>>>>>>>>> is fine with next is fine with me, but needs to get ack'd by someone.
>>>>>>>>
>>>>>>>> Or, the other option is, make these new extra features configurable and
>>>>>>>> disable them on this board. And so there should be no size problem.
>>>>>>>
>>>>>>> But that direction leads to saying every slight bit of functionality
>>>>>>> requires a new Kconfig entry.  Some levels of bugfixes as well.
>>>>>>
>>>>>> The other option is, we will sink in bloat and suffer endless size problems.
>>>>>
>>>>> Yes, it is a hard balancing act.  Stepping back, perhaps a "minimal" or
>>>>> "complete" choice for USB HID devices would make sense and allow us
>>>>> further areas to reduce size, on the minimal portion.
>>>>
>>>> Or maybe there is a way to help compiler optimize that USB key code
>>>> handling better.
>>>
>>> Perhaps.  But my point is that every little functional change or
>>> enhancement does not need a Kconfig option.
>>
>> Except this leads to slow and steady accumulation of bloat, and as we
>> already see for quite a while, this is problematic for more and more boards.
> 
> And "bloat" and "features" are interchangable terms.

Nope, bloat is unhelpful growth of size, features are actually
helpful/useful.

> I really am trying
> to be more responsive than ever to size growth in common, rather than
> board specific areas.  And I agree, some investigation in to ways that
> might reduce the size of binary support for USB HID devices is good.

So we agree that's what this series should fix ?

> Figuring out if we can make this series:
> http://patchwork.ozlabs.org/project/uboot/list/?series=135448
> not also increase the overall size, or increase it less, is good.
> Hiding the content of 2/5 behind a CONFIG option in turn brings us back
> to "the code is too messy and full of #ifdef" lines.

Which might be somewhat better than if the code is sprinkled with tiny
chunks of random pieces of code which are never used, but in total add
up to a lot of unused code in the binary.