[U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL

[Scott Wood <scottwood@freescale.com>]

On 01/06/2012 01:14 PM, Tom Rini wrote:
> On Fri, Jan 6, 2012 at 12:03 PM, Scott Wood <scottwood@freescale.com> wrote:
>> On 01/05/2012 06:41 PM, Tom Rini wrote:
>>> On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood <scottwood@freescale.com> 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