[U-Boot] Pull request: u-boot-net

From: Joe Hershberger <joe.hershberger@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Pull request: u-boot-net
Date: Mon, 28 Dec 2015 21:02:02 -0600	[thread overview]
Message-ID: <CANr=Z=a-=YVOuM2vukBmMXT0c2Op8x+a0J44BrBrZg=j+mT0gg@mail.gmail.com> (raw)
In-Reply-To: <20151224034747.GX11783@bill-the-cat>

Hi Tom,

On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
>
>> A few patches that came in during the merge window and appear harmless.
>
> so..

Hmm... With the buildman toolchains I'm using nothing broke.

>>
>> These cause no additional build warnings or errors.
>>
>> Thanks,
>> -Joe
>>
>> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
>>
>>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
>> (2015-12-18 07:28:24 -0500)
>>
>> are available in the git repository at:
>>
>>
>>   git://git.denx.de/u-boot-net.git master
>>
>> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
>>
>>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>> (2015-12-21 20:01:57 -0600)
>>
>> ----------------------------------------------------------------
>> Bin Meng (5):
>>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>>       fdt: Rewrite the logic in fdt_fixup_ethernet()
>
> This one here pushes "iocon" just over the edge, again, with ELDK 5.6.
>
> First off, let me say that I eagarly await the gcc that will finally let
> strings of garbage collected functions also be collected and dropped.
> My first very quick _hack_ here to gain a tiny bit of space back was to
> remove from the common case some functions in common/fdt_support.c
>
> I really don't know a good fix for today and as Dirk has pointed out
> (and I frankly agree, and have been poked about in some other places),
> we really do need to take care with our image sizes when adding all of
> these neat new features.

That's a fine goal, but features aren't free. We can have a goal of
not bloating grossly or making easily separable functionality
disable-able by adding ifdefs, but requiring that any given
combination of ifdefs in a config never grow even a few bytes seems
unwieldy. Surely keeping any target so close to the limit is a waste
of everyone's time and energy. Why not take advantage of the enormous
numbers of ifdefs and start disabling some features to get these
targets off the ledge?

-Joe