From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 16 Jan 2012 14:03:37 -0600 Subject: [U-Boot] [PATCH 2/2] nand/fsl_elbc: Convert to self-init In-Reply-To: <201201161458.10579.vapier@gentoo.org> References: <20120113015941.GB18732@schlenkerla.am.freescale.net> <201201151429.51505.vapier@gentoo.org> <4F145582.1000104@freescale.com> <201201161458.10579.vapier@gentoo.org> Message-ID: <4F148299.8000802@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/16/2012 01:58 PM, Mike Frysinger wrote: > On Monday 16 January 2012 11:51:14 Scott Wood wrote: >> On 01/15/2012 01:29 PM, Mike Frysinger wrote: >>> On Thursday 12 January 2012 20:59:41 Scott Wood wrote: >>>> --- a/drivers/mtd/nand/fsl_elbc_nand.c >>>> +++ b/drivers/mtd/nand/fsl_elbc_nand.c >>>> >>>> +#ifndef CONFIG_SYS_NAND_BASE_LIST >>>> +#define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE } >>>> +#endif >>> >>> would this be better off in nand.h ? >> >> I'm trying to get away from the model where the NAND subsystem pretends >> to know anything about how a driver talks to its hardware (except when >> the driver chooses to use a common NAND function that uses things like >> IO_ADDR_R/W). For eLBC it probably makes more sense to specify the >> chipselect rather than the address (we have to search for the former >> based on the latter), though that's a separate change that can happen on >> its own now that the connection to subsystem code has been severed. > > so the idea would be to let CONFIG_SYS_NAND_BASE_LIST and CONFIG_SYS_NAND_BASE > die for devices that could care less ? Yes. > and eventually obsolete CONFIG_SYS_MAX_NAND_DEVICE ? This is harder, as we still have a notion of an array of enumerated NAND devices in the command line code. -Scott