GPMI-NAND: Wrong ECC size in driver

[Brian Norris]

On Tue, Jan 31, 2012 at 11:09 AM, Scott Wood <scottwood at freescale.com> wrote:
> On 01/31/2012 11:30 AM, Brian Norris wrote:
>> There's another distinct possibility (one that I use on an out-of-tree
>> driver): instead of calling "nand_scan()", separate it into its two
>> sub-functions "nand_scan_ident()" and "nand_scan_tail()" so you have
>> something like this
>>
>>     ret = nand_scan_ident(mtd, pdata->max_chip_count, NULL);
>>     chip->options |= NAND_NO_SUBPAGE_WRITE;
>>     if (!ret)
>>             ret = nand_scan_tail(mtd);
>>
>> That way your option is set after we mask with NAND_CHIPOPTIONS_MSK. I'm
>> not sure if this solution is better than really trying to tackle the
>> issue of why we have that mask and whether it is still needed, but it
>> solves the problem.
>
>
> It's a bit hackish, but should work.  Why not get just rid of the mask,
> though, if it's not actually doing anything constructive and is
> requiring such workarounds?

I'm not sure "why not." I hadn't looked at it in enough detail to tell
for sure. I was just providing my own solution, which doesn't require
any big system changes.

And actually, I think that my solution isn't really too "hackish." I
believe nand_scan_ident() and nand_scan_tail() are intentionally
exported separately to support some driver-level tweaking between the
initialization steps. For instance, my systems use the
nand_base-detected parameters (size, page size, etc.) to initialize
controller values before continuing to the tail, where we build our
BBT. I don't see why other options can't be tweaked here as well.

But I do see how, on a system that otherwise could use the default
nand_scan() interface, it seems counterintuitive that you cannot set
NAND_NO_SUBPAGE_WRITE before scanning.

Brian