public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL
Date: Fri, 6 Jan 2012 13:03:49 -0600	[thread overview]
Message-ID: <4F074595.9080007@freescale.com> (raw)
In-Reply-To: <CA+M6bXmeSgW=ATBV62yXUeo=AYzDor017tmXn67F5_GbnVZRfg@mail.gmail.com>

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.

-Scott

  reply	other threads:[~2012-01-06 19:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05 23:17 [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL Marek Vasut
2012-01-04 23:56 ` Scott Wood
2012-01-05  3:11   ` Tom Rini
2012-01-05  9:09     ` Marek Vasut
2012-01-05 14:15       ` Tom Rini
2012-01-05 23:04         ` Scott Wood
2012-01-06  0:41           ` Tom Rini
2012-01-06 19:03             ` Scott Wood [this message]
2012-01-06 19:14               ` Tom Rini
2012-01-06 19:18                 ` Scott Wood
2012-01-08  9:56   ` Mike Frysinger
2012-01-09 19:41     ` Scott Wood
2012-01-09 21:21       ` Mike Frysinger
2012-01-09 21:23         ` Tom Rini
2012-01-09 21:25           ` Tom Rini
2012-01-10 18:25             ` Mike Frysinger
2012-01-10 18:36               ` Tom Rini
2012-01-09 21:27         ` Scott Wood
2012-01-10 18:25           ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F074595.9080007@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox