All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 1/2 v2] nand: allow delayed initialization
Date: Thu, 7 Oct 2010 22:00:18 -0400	[thread overview]
Message-ID: <201010072200.19468.vapier@gentoo.org> (raw)
In-Reply-To: <201010071726.57488.vapier@gentoo.org>

On Thursday, October 07, 2010 17:26:55 Mike Frysinger wrote:
> On Thursday, October 07, 2010 15:35:44 Wolfgang Denk wrote:
> > Mike Frysinger wrote:
> > > > Do you plan to post an update?
> > > 
> > > there isnt a clear indication of where to take this.  seems like we
> > > want to do this, and we want it as the default moving forward, but we
> > > want all existing boards to be unchanged.  so only reasonable way
> > > would be to invert the logic, add a define for the arch lib/board.c
> > > files, and then add that define to all existing boards.
> > 
> > I don't think we want to modify 550+ Board configurations and re-test
> > on that many boards...
> 
> it would be ~100 boards.  board_init() is only called when CONFIG_CMD_NAND
> is defined.  so it should be as simple as:
> 	sed -i \
> 	'/define[[:space:]]*CONFIG_CMD_NAND/i#define CONFIG_NAND_EARLY_INIT' \
> 	include/configs/*
> 
> > I think we should rather enable the new feature by some #define, and
> > recommend to enable this on new boards.
> 
> problem with recommendations is that people dont notice them

hmm, what about this scheme:
 - add NAND_MAYBE_EARLY_INIT to include/config_defaults.h
 - have nand_init() emit a #warning if NAND_MAYBE_EARLY_INIT is defined but 
NAND_EARLY_INIT is not
 - board porters add either "#define NAND_EARLY_INIT" or "#undef 
NAND_MAYBE_EARLY_INIT" to their board config
 - after a release or two, we set "#define NAND_EARLY_INIT" to any boards 
where their maintainers did not step up and drop "NAND_MAYBE_EARLY_INIT" 
totally

this way, existing behavior is retained, board porters have an incentive to 
choose the desired behavior themselves (kill the #warning), and we have 
confidence that we didnt break (most) people.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101007/1b0878a2/attachment.pgp 

  reply	other threads:[~2010-10-08  2:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-21 23:45 [U-Boot] [RFC PATCH 1/2] nand: allow delayed initialization Mike Frysinger
2010-09-21 23:45 ` [U-Boot] [PATCH 2/2] Blackfin: nand: support " Mike Frysinger
2010-10-02 19:47 ` [U-Boot] [RFC PATCH 1/2 v2] nand: allow " Mike Frysinger
2010-10-03 18:27   ` Wolfgang Denk
2010-10-03 20:32     ` Mike Frysinger
2010-10-03 21:40       ` Wolfgang Denk
2010-10-03 22:19         ` Mike Frysinger
2010-10-06 20:40           ` Wolfgang Denk
2010-10-07 17:00             ` Mike Frysinger
2010-10-07 19:35               ` Wolfgang Denk
2010-10-07 21:26                 ` Mike Frysinger
2010-10-08  2:00                   ` Mike Frysinger [this message]
2010-10-10  8:37                     ` Mike Frysinger
2010-10-10  9:20                       ` Wolfgang Denk
2010-10-04 17:36   ` Scott Wood
2010-10-05  8:08     ` Mike Frysinger
2010-10-05 16:31       ` Scott Wood
2010-10-05 18:27         ` Wolfgang Denk
2010-10-05 19:18           ` Scott Wood

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=201010072200.19468.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.