[PATCH] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

[Marek Vasut]

Dear Scott Wood,

> On 07/13/2012 12:35 PM, Marek Vasut wrote:
> > Dear Brian Norris,
> > 
> >> On Fri, Jul 13, 2012 at 10:19 AM, Scott Wood <scottwood at freescale.com> 
wrote:
> >>> On 07/13/2012 12:12 PM, Marek Vasut wrote:
> >>>>> 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.
> >>>>> 
> >>>>> Signed-off-by: Brian Norris <computersforpeace at gmail.com>
> >>>>> Cc: Huang Shijie <shijie8 at gmail.com>
> >>>>> Cc: Marek Vasut <marex at denx.de>
> >>>> 
> >>>> [...]
> >>>> 
> >>>> Maybe we should simply split it into two sets of flags to make it
> >>>> clear -- chip ones and controller ones ?
> >>> 
> >>> Isn't that what we're trying to get rid of?
> > 
> > Sure, but aren't there controller specific properties and chip-specific
> > properties?
> 
> Yes, but there are some properties than can be specified by either one.
>  If you're proposing three sets of options (chip, controller, or both),
> or duplicating certain options between the sets and then checking both
> everywhere, I don't see how that's an improvement.

Ok, you're right here, screw that and let's do a single set ;-)

> > And than even chip-specific state?
> 
> Not sure what you mean here.
> 
> -Scott

Best regards,
Marek Vasut