From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Hershberger Date: Mon, 28 Dec 2015 21:02:02 -0600 Subject: [U-Boot] Pull request: u-boot-net In-Reply-To: <20151224034747.GX11783@bill-the-cat> References: <20151224034747.GX11783@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini 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