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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191122/10714276/attachment.sig>