From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 6 Jan 2012 13:18:55 -0600 Subject: [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL In-Reply-To: References: <1323127046-20694-1-git-send-email-marek.vasut@gmail.com> <4F04E727.3040709@freescale.com> <201201051009.55036.marek.vasut@gmail.com> <4F062C7C.5040700@freescale.com> <4F074595.9080007@freescale.com> Message-ID: <4F07491F.7070400@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/06/2012 01:14 PM, Tom Rini wrote: > On Fri, Jan 6, 2012 at 12:03 PM, Scott Wood wrote: >> On 01/05/2012 06:41 PM, Tom Rini wrote: >>> On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood wrote: >>>> Whatever the set of things is that you want to pull in for these SPLs, >>>> it needs to be a separate config option from the one that enables >>>> libnand.o to be included, so that other SPLs can pull in smaller NAND >>>> implementations. >>>> >>>> Is there any reason to keep defines like CONFIG_SPL_NAND_SUPPORT (versus >>>> LIBS-y += drivers/mtd/nand/libnand.o), if everything within that >>>> directory needs a separate config symbol to enable it inside an SPL >>>> (just like a normal build)? >>> >>> I think you've got it backwards. What CONFIG_SPL_NAND_SUPPORT enables >>> today is more bloated than required as our 'magic' isn't working. >> >> I realize this isn't the case today -- but it's where we need to go, >> since gc-sections doesn't do the job. I was saying that I think we can >> get rid of CONFIG_SPL_NAND_SUPPORT once we change to a model where every >> bit of code within the directory needs some other config symbol to pull >> it in. > > Ah, OK. But maybe this also means we need to rethink other parts of > SPL too? I'd imagine this isn't a NAND subsystem specific issue we're > running into. Right, the toplevel config symbol on a directory only makes sense if there's code that will be wanted by all SPLs using that directory -- and given the nature of SPL, that's probably not going to be the case very often. -Scott