From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Sat, 16 Oct 2010 00:17:01 +0200 Subject: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init(). In-Reply-To: <20101015164801.3fd031b7@udp111988uds.am.freescale.net> References: <20101015185902.GA7581@udp111988uds.am.freescale.net> <20101015193640.722281365CF@gemini.denx.de> <201010151608.30637.vapier@gentoo.org> <20101015213952.CBA531365CF@gemini.denx.de> <20101015164801.3fd031b7@udp111988uds.am.freescale.net> Message-ID: <20101015221701.982F61365CF@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Scott Wood, In message <20101015164801.3fd031b7@udp111988uds.am.freescale.net> you wrote: > > > > it makes more sense to me to hide this in the header (which Scott has done)> > > > and let the compiler/code optimize dead crap away. > > > > Why do we need an explicit call to nand_init() at all? > > > > Why cannot the NAND routines check internally if they have been > > initialized yet, and run nand_init() if and when needed? > > mtdparts doesn't make any calls directly to NAND routines (other than > this new call to nand_init). It looks for registered MTD devices. > > Until nand_init runs, you won't have any NAND mtd devices -- and no > NAND function will be invoked where such initialization could be done. This looks like a broken design to me. Assume we add this call here; would it then not also be needed in the 'static' version of mtdparts_init() in "common/cmd_jffs2.c" (whatever 'static' is supposed to mean) ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de In the realm of scientific observation, luck is granted only to those who are prepared. - Louis Pasteur