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

[Tom Rini <trini@konsulko.com>]

On Mon, Dec 28, 2015 at 09:02:02PM -0600, Joe Hershberger wrote:
> 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.

What one(s) are that?  ELDK 5.3 has failed for a while for me and ELDK
5.6 just started with this PR.

> >> 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

Yes, this is where I do agree and wonder if we perhaps haven't been
giving enough care here.  Especially since until another big gcc release
or two we won't have the stupid string consolidation bug fixed.  We may
need to keep that bug in mind and re-think how we structure some of the
code.

> 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?

The problem with "iocon" is that we have an active board maintainer and
I'm not immediately seeing a bunch of waste that could just be turned
off here.  Perhaps Dirk will see something or another.

> 
> -Joe

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151229/4ef88c1f/attachment.sig>