No subject

"Did you ask some clarification to manufacturers ?"

No, unfortunately, I did not. I didn't realize the "regression" issues
at the time, so I didn't think to look further than my interpretation
of the datasheets.

On Tue, Apr 26, 2011 at 12:30 AM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
>
> On Fri, 22 Apr 2011, Matthieu CASTET wrote:
>
>>> So I bet
>>> your device is actually an x8 device and so the 1st/6th byte pattern is
>>> correct. I think the fact that this conflicts with your ECC patterns is
>>> something you must deal with.
>>
>> I don't agree, that's a big mtd regression. If you update your kernel on such
>> flash, you brick it.
>
> I agree, even if the behavior may have been incorrect in the past, we should think very carefully about changing this for exactly this reason.

Right, I see how this could be a problem. So for a resolution, I'd ask
for suggestions on which of the following seems best:
1) Completely revert the SCANBYTE1AND6 change
2) Remove the option from nand_get_flash_type(), still allowing
drivers to enable the scan option themselves
3) Have nand_get_flash_type() use ECC layout information to decide to
scan bytes 1+6 or just byte 1 only

Regarding correctness:
As far as I can tell, no one has found a definitive answer on the
manufacturer intention, right? I'm now leaning toward the intention
that software only needs to scan *either* byte 1 *or* byte 6, but I
don't know for sure.

Thanks,
Brian