From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 17 May 2012 17:48:24 -0500 Subject: [U-Boot] [PATCH 5/6] cmd_nvedit.c: allow board-specific code before/after saving the environment In-Reply-To: <20120517221808.2AEAE206271@gemini.denx.de> References: <1336170092-22538-1-git-send-email-timur@freescale.com> <1336170092-22538-5-git-send-email-timur@freescale.com> <201205140120.45712.vapier@gentoo.org> <4FB12E88.1050906@freescale.com> <20120517221808.2AEAE206271@gemini.denx.de> Message-ID: <4FB58038.8060004@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 05/17/2012 05:18 PM, Wolfgang Denk wrote: > Dear Timur Tabi, > > In message <4FB12E88.1050906@freescale.com> you wrote: >> >>> all these board hooks are paper-cutting us to death with unused bloat >> >> I know, and I don't like it either. I hate how our hardware designers are >> always breaking the "rules", forcing us software developers to hack up our >> software more and more. The muxing on this chip is a like a cruel joke >> being played on me. I've even been told that I'm trying too hard to make >> it work. > > I think whoever told you this was right. Let it break. > > We cannot add pre- and post-hooks all ever the place for brain-dead > designs that need to do this and that before and after doing perfectly > things. > > It makes no sense adding this to saveenv, because there will be othe > rplaces in the code that need to to the same - like if it's NAND > flash, you will probabaly need to do the same for all NAND related > commands. NAND doesn't need it because NAND goes through an API rather than direct memory-mapped access, and has more coarse-grained operations. NAND should be able to take care of this entirely in the driver using the select_chip() callback. Timur, is there any reason to use NOR rather than NAND with this chip? -Scott