[U-Boot] [RFC PATCH 1/2 v2] nand: allow delayed initialization

[Mike Frysinger]

On Thu, Oct 7, 2010 at 10:00 PM, Mike Frysinger wrote:
> 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.

btw, i'm waiting for you to OK this path before i code it up and post
new patches ;)
-mike