From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 16 Jan 2012 10:55:32 -0600 Subject: [U-Boot] [PATCH 2/2] nand/fsl_elbc: Convert to self-init In-Reply-To: <4F145582.1000104@freescale.com> References: <20120113015941.GB18732@schlenkerla.am.freescale.net> <201201151429.51505.vapier@gentoo.org> <4F145582.1000104@freescale.com> Message-ID: <4F145684.2090002@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 10:51 AM, 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. Also, even when there isn't a mismatch with the hardware interface, this frees up the driver to initialize in other ways, separate from a fixed list iterated over during U-Boot startup -- the addresses could come from a device tree, for example. -Scott