From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 17 Sep 2012 19:06:40 -0500
Subject: [U-Boot] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from
 driver
In-Reply-To: <201209180201.40032.marex@denx.de> (from marex@denx.de on Mon
	Sep 17 19:01:39 2012)
References: <1346369978-28137-1-git-send-email-marex@denx.de>
	<20120917235512.GA31827@buserror.net>
	<201209180201.40032.marex@denx.de>
Message-ID: <1347926800.19543.22@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 09/17/2012 07:01:39 PM, Marek Vasut wrote:
> Dear Scott Wood,
> 
> > On Thu, Aug 30, 2012 at 01:39:38PM -0000, Marek Vasut wrote:
> > > This is based on Linux kernel -next:
> > >
> > > commit a1256b0e087ed3cdb584c683acb966ee885f733c
> > > Author: Brian Norris <computersforpeace@gmail.com>
> > > Date:   Fri Jul 13 09:28:24 2012 -0700
> > >
> > >     mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver
> > >
> > >     The NAND_CHIPOPTIONS_MSK has limited utility and is causing  
> real
> > >     bugs. It silently masks off at least one flag that might be  
> set by
> > >     the driver (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND  
> driver
> > >     and possibly others.
> > >
> > >     Really, as long as driver writers exercise a small amount of  
> care
> > >     with NAND_* options, this mask is not necessary at all; it  
> was only
> > >     here to prevent certain options from accidentally being set  
> by the
> > >     driver. But the original thought turns out to be a bad idea
> > >     occasionally. Thus, kill it.
> > >
> > >     Note, this patch fixes some major gpmi-nand breakage.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Cc: Brian Norris <computersforpeace@gmail.com>
> > > Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> > > Cc: Fabio Estevam <festevam@gmail.com>
> > > Cc: Otavio Salvador <otavio@ossystems.com.br>
> > > Cc: Scott Wood <scottwood@freescale.com>
> >
> > Applied to u-boot-nand-flash with the SHA1 updated based on current
> > linux-next: 14f44abf1dafc20ba42ce8616a8fc8fbd1b3712b
> 
> Thanks ... I think the sha1 is irrelevant as next is being constantly  
> rebased
> anyway :/

They're at -rc6 or so, so maybe this'll be the final one. :-)

The SHA1 should only change if the tree it was pulled from got rebased.

> btw. this should definitelly go to current release.

Yes.

-Scott