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

[Marek Vasut]

On 11/22/19 4:44 PM, Tom Rini wrote:
> On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote:
>> 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.
> 
> If, with your USB custodian hat on, your answer to Heinrich is that his
> changes expose a more fundamental problem with the code that needs
> addressing then no, I'm not overriding your objection.

The fundamental problem is that we are letting too much bloat in and now
it starts to take over useful functionality on existing devices. I am
strongly opposed to this, that's the fundamental problem we need to deal
with. Heinrichs' approach only underlined the problem.