Bad assumption about ID field definition for Samsung NAND?

Bad assumption about ID field definition for Samsung NAND?

[Tilman Sauerbeck]

Hi,
on my GuruPlug, I was seeing lots of bad block errors for the NAND chip
when booting a 2.6.35 kernel. With earlier kernels (2.6.33, 2.6.34),
no bad blocks were reported. See below for the exact error messages.
Since _all_ of the first 128 blocks are claimed to be bad, and the NAND
chips appears to be working just fine, I suspect the kernel is lying.

I bisected linux-2.6.35.y.git, and found that the kernel started
reporting bad blocks starting with this commit:
426c457a3216fac74e mtd: nand: extend NAND flash detection to new MLC chips

Patching nand_base.c with the following diff (thus restoring the
previously used behaviour) the kernel stops reporting bad blocks:

@@ -2852,6 +2852,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
                 */
                if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
                                id_data[0] == NAND_MFR_SAMSUNG &&
+                               (chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
                                id_data[5] != 0x00) {
                        /* Calc pagesize */
                        mtd->writesize = 2048 << (extid & 0x03);

I added a check for the MLC bit since
a) the commit message talks about MLC chips and
b) the NAND chip that the GuruPlug features is a Samsung K9F4G08U0B
   (which is SLC according to the part number decoder on samsung.com)

I have no idea if that's the right fix though. Unfortunately I couldn't
find the data sheet for the K9F4G08U0B online, so I couldn't verify if
it uses the old field definition or the new one...

Please CC me in your replies; I'm not subscribed to the list.

Thanks,
Tilman

Kernel messages:
Scanning device for bad blocks
Bad eraseblock 0 at 0x000000000000
Bad eraseblock 1 at 0x000000400000
[same for the following blocks]
Bad eraseblock 127 at 0x00001fc00000
Creating 3 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
mtd: partition "u-boot" doesn't end on an erase block -- force read-only
Moving partition 1: 0x000000100000 -> 0x000000400000
0x000000400000-0x000000800000 : "uImage"
0x000000800000-0x000020000000 : "root"

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Bad assumption about ID field definition for Samsung NAND?

[Brian Norris]

Hello,

I have similar problems on similar chips, however, I cannot determine 
that for sure; can you print out the full ID string (8 bytes) from 
nand_base?

This may be an issue with an unfortunate wraparound of the ID where it 
*should* give a 5-byte string, then wraparound to give the same ID 
again, but instead it gives a 6-byte string, then wraps around again. 
This would incorrectly classify this ID string under the detection 
scheme for new Samsung MLC flash instead of the old scheme. Your fix is 
safe, AFAIK, although there may be other Samsung MLC that still have 
unpredictable ID patterns that will cause this pattern. Maybe we can 
submit a similar patch to yours.

Thanks,
Brian

 > Hi,
 > on my GuruPlug, I was seeing lots of bad block errors for the NAND chip
 > when booting a 2.6.35 kernel. With earlier kernels (2.6.33, 2.6.34),
 > no bad blocks were reported. See below for the exact error messages.
 > Since _all_ of the first 128 blocks are claimed to be bad, and the NAND
 > chips appears to be working just fine, I suspect the kernel is lying.
 >
 > I bisected linux-2.6.35.y.git, and found that the kernel started
 > reporting bad blocks starting with this commit:
 > 426c457a3216fac74e mtd: nand: extend NAND flash detection to new MLC 
chips
 >
 > Patching nand_base.c with the following diff (thus restoring the
 > previously used behaviour) the kernel stops reporting bad blocks:
 >
 > @@ -2852,6 +2852,7 @@ static struct nand_flash_dev 
*nand_get_flash_type(struct mtd_info *mtd,
 >                  */
 >                 if (id_data[0] == id_data[6] && id_data[1] == 
id_data[7] &&
 >                                 id_data[0] == NAND_MFR_SAMSUNG &&
 > +                               (chip->cellinfo & 
NAND_CI_CELLTYPE_MSK) &&
 >                                 id_data[5] != 0x00) {
 >                         /* Calc pagesize */
 >                         mtd->writesize = 2048 << (extid & 0x03);
 >
 > I added a check for the MLC bit since
 > a) the commit message talks about MLC chips and
 > b) the NAND chip that the GuruPlug features is a Samsung K9F4G08U0B
 >    (which is SLC according to the part number decoder on samsung.com)
 >
 > I have no idea if that's the right fix though. Unfortunately I couldn't
 > find the data sheet for the K9F4G08U0B online, so I couldn't verify if
 > it uses the old field definition or the new one...
 >
 > Please CC me in your replies; I'm not subscribed to the list.
 >
 > Thanks,
 > Tilman
 >
 > Kernel messages:
 > Scanning device for bad blocks
 > Bad eraseblock 0 at 0x000000000000
 > Bad eraseblock 1 at 0x000000400000
 > [same for the following blocks]
 > Bad eraseblock 127 at 0x00001fc00000
 > Creating 3 MTD partitions on "orion_nand":
 > 0x000000000000-0x000000100000 : "u-boot"
 > mtd: partition "u-boot" doesn't end on an erase block -- force read-only
 > Moving partition 1: 0x000000100000 -> 0x000000400000
 > 0x000000400000-0x000000800000 : "uImage"
 > 0x000000800000-0x000020000000 : "root"

Re: Bad assumption about ID field definition for Samsung NAND?

[Tilman Sauerbeck]

Brian Norris [2010-08-18 16:25]:

Hi,

> I have similar problems on similar chips, however, I cannot
> determine that for sure; can you print out the full ID string (8
> bytes) from nand_base?

ID: ec dc 10 95 54 ec ec dc

> This may be an issue with an unfortunate wraparound of the ID where
> it *should* give a 5-byte string, then wraparound to give the same
> ID again, but instead it gives a 6-byte string, then wraps around
> again. This would incorrectly classify this ID string under the

I think I might have found the real problem.
Kevin's commit message says:

>   This patch uses the new 6-byte scheme if the following conditions are
>   all true:
>   [...]
>   3) 6th byte is zero

... but what the code does is use new scheme if id_data[5] is _not_
zero.

The following diff works for me, but I cannot test with any other flash
chip but the K9F4G08U0B:

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 4a7b864..abc71cd 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2847,12 +2847,12 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
                 * Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
                 * New style   (6 byte ID): Samsung K9GAG08U0D (p.40)
                 *
-                * Check for wraparound + Samsung ID + nonzero 6th byte
+                * Check for wraparound + Samsung ID + zero 6th byte
                 * to decide what to do.
                 */
                if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
                                id_data[0] == NAND_MFR_SAMSUNG &&
-                               id_data[5] != 0x00) {
+                               id_data[5] == 0x00) {
                        /* Calc pagesize */
                        mtd->writesize = 2048 << (extid & 0x03);
                        extid >>= 2;

Thanks,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Bad assumption about ID field definition for Samsung NAND?

[Kevin Cernekee]

On Thu, Aug 19, 2010 at 10:16 AM, Tilman Sauerbeck
<tilman@code-monkey.de> wrote:
>>   This patch uses the new 6-byte scheme if the following conditions are
>>   all true:
>>   [...]
>>   3) 6th byte is zero
>
> ... but what the code does is use new scheme if id_data[5] is _not_
> zero.

ID for Samsung K9GAG08U0D (6-byte sequence): ec d5 94 29 34 41

The code is right; the comment is wrong.

Re: Bad assumption about ID field definition for Samsung NAND?

[Brian Norris]

On 08/19/2010 12:46 PM, Kevin Cernekee wrote:
> The code is right; the comment is wrong.

In that case, should we fix the comment and add the
check that Tilman mentioned previously? (below)
This looks safe and will at least eliminate a few weird
cases where Samsung SLC happen to have 6-byte ID strings
(such as the K9F4G08U0B in question).

I have another fix I will tack on in series to this; should
I include you as a "Signed-off-by", Tilman?

Brian

> @@ -2852,6 +2852,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
>                  */
>                 if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
>                                 id_data[0] == NAND_MFR_SAMSUNG &&
> +                               (chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
>                                 id_data[5] != 0x00) {
>                         /* Calc pagesize */
>                         mtd->writesize = 2048 << (extid & 0x03);

Re: Bad assumption about ID field definition for Samsung NAND?

[Kevin Cernekee]

On Thu, Aug 19, 2010 at 3:28 PM, Brian Norris <norris@broadcom.com> wrote:
> On 08/19/2010 12:46 PM, Kevin Cernekee wrote:
>> The code is right; the comment is wrong.
>
> In that case, should we fix the comment and add the
> check that Tilman mentioned previously? (below)

To clarify - the comment in the code is correct, but the checkin
comment was inaccurate.

>> @@ -2852,6 +2852,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
>>                  */
>>                 if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
>>                                 id_data[0] == NAND_MFR_SAMSUNG &&
>> +                               (chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
>>                                 id_data[5] != 0x00) {
>>                         /* Calc pagesize */
>>                         mtd->writesize = 2048 << (extid & 0x03);

This looks OK (at least for K9GAG08U0D).

I wonder if Samsung could provide some firm guidelines for when to use
the old style vs. the new style.

RE: Bad assumption about ID field definition for Samsung NAND?

[Liu Hui-R64343]

> -----Original Message-----
> From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-
> bounces@lists.infradead.org] On Behalf Of Kevin Cernekee
> Sent: Friday, August 20, 2010 11:30 AM
> To: Brian Norris
> Cc: linux-mtd@lists.infradead.org; Tilman Sauerbeck
> Subject: Re: Bad assumption about ID field definition for Samsung NAND?
> 
> On Thu, Aug 19, 2010 at 3:28 PM, Brian Norris <norris@broadcom.com> wrote:
> > On 08/19/2010 12:46 PM, Kevin Cernekee wrote:
> >> The code is right; the comment is wrong.
> >
> > In that case, should we fix the comment and add the check that Tilman
> > mentioned previously? (below)
> 
> To clarify - the comment in the code is correct, but the checkin comment
> was inaccurate.
> 
> >> @@ -2852,6 +2852,7 @@ static struct nand_flash_dev
> >> *nand_get_flash_type(struct mtd_info *mtd,
> >>                  */
> >>                 if (id_data[0] == id_data[6] && id_data[1] ==
> >> id_data[7] &&
> >>                                 id_data[0] == NAND_MFR_SAMSUNG &&
> >> +                               (chip->cellinfo &
> >> + NAND_CI_CELLTYPE_MSK) &&
> >>                                 id_data[5] != 0x00) {
> >>                         /* Calc pagesize */
> >>                         mtd->writesize = 2048 << (extid & 0x03);
> 
> This looks OK (at least for K9GAG08U0D).

The temp fix is not the good solution. We can make a fix for Samsung here, what about other vendors?
If we put such kind of fix into nand_base.c file, which will make the code ugly. 

> 
> I wonder if Samsung could provide some firm guidelines for when to use
> the old style vs. the new style.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Bad assumption about ID field definition for Samsung NAND?

[Tilman Sauerbeck]

Kevin Cernekee [2010-08-19 20:29]:
> On Thu, Aug 19, 2010 at 3:28 PM, Brian Norris <norris@broadcom.com> wrote:
> > On 08/19/2010 12:46 PM, Kevin Cernekee wrote:
> >> @@ -2852,6 +2852,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
> >>                  */
> >>                 if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
> >>                                 id_data[0] == NAND_MFR_SAMSUNG &&
> >> +                               (chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
> >>                                 id_data[5] != 0x00) {
> >>                         /* Calc pagesize */
> >>                         mtd->writesize = 2048 << (extid & 0x03);
> 
> This looks OK (at least for K9GAG08U0D).
> 
> I wonder if Samsung could provide some firm guidelines for when to use
> the old style vs. the new style.

Okay, how do we proceed? Should I send a proper patch with the diff
above? Or does anyone want to try and come up with a better fix...?

Regards,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Bad assumption about ID field definition for Samsung NAND?

[Brian Norris]

On 08/20/2010 06:43 AM, Tilman Sauerbeck wrote:

> Okay, how do we proceed? Should I send a proper patch with the diff
> above? Or does anyone want to try and come up with a better fix...?

I vote for Tilman's patch. There's nothing unnecessarily ugly about it; 
it simply checks cell-type in order to decide whether we use Samsung's 
new "standard" for MLC or fall-back to the real standard. If anything, 
the existing code (checking ID length) is ugly. However, both checks 
seem necessary.

Brian

Re: Bad assumption about ID field definition for Samsung NAND?

[David Woodhouse]

On Fri, 2010-08-20 at 10:42 -0700, Brian Norris wrote:
> On 08/20/2010 06:43 AM, Tilman Sauerbeck wrote:
> 
> > Okay, how do we proceed? Should I send a proper patch with the diff
> > above? Or does anyone want to try and come up with a better fix...?
> 
> I vote for Tilman's patch. There's nothing unnecessarily ugly about it; 
> it simply checks cell-type in order to decide whether we use Samsung's 
> new "standard" for MLC or fall-back to the real standard. If anything, 
> the existing code (checking ID length) is ugly. However, both checks 
> seem necessary.

That's for 2.6.36 and -stable (for 2.6.35), yes?


@@ -2852,6 +2852,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
                 */
                if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
                                id_data[0] == NAND_MFR_SAMSUNG &&
+                               (chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
                                id_data[5] != 0x00) {
                        /* Calc pagesize */
                        mtd->writesize = 2048 << (extid & 0x03);

Can I have a signed-off-by for it?

Brian, I have a distinct impression that there's at least one more patch
from you that I really ought to be sending to Linus for 2.6.36, but I
can't find it right now. Other than this and what's already in
mtd-2.6.git, is there anything else?

Thanks, btw.

-- 
dwmw2

Re: Bad assumption about ID field definition for Samsung NAND?

[Tilman Sauerbeck]

David Woodhouse [2010-08-20 20:53]:
> On Fri, 2010-08-20 at 10:42 -0700, Brian Norris wrote:
> > On 08/20/2010 06:43 AM, Tilman Sauerbeck wrote:
> > 
> > > Okay, how do we proceed? Should I send a proper patch with the diff
> > > above? Or does anyone want to try and come up with a better fix...?
> > 
> > I vote for Tilman's patch. There's nothing unnecessarily ugly about it; 
> > it simply checks cell-type in order to decide whether we use Samsung's 
> > new "standard" for MLC or fall-back to the real standard. If anything, 
> > the existing code (checking ID length) is ugly. However, both checks 
> > seem necessary.
> 
> That's for 2.6.36 and -stable (for 2.6.35), yes?

Yes.

> @@ -2852,6 +2852,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
>                  */
>                 if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
>                                 id_data[0] == NAND_MFR_SAMSUNG &&
> +                               (chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
>                                 id_data[5] != 0x00) {
>                         /* Calc pagesize */
>                         mtd->writesize = 2048 << (extid & 0x03);
> 
> Can I have a signed-off-by for it?

Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>

Thanks,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Bad assumption about ID field definition for Samsung NAND?

[Brian Norris]

> Can I have a signed-off-by for it?

I don't know what's "legal" here. I'm appending the patch with a
sign-off for me and Tilman (since Tilman authored it). Hopefully that's
ok.

> Brian, I have a distinct impression that there's at least one more patch
> from you that I really ought to be sending to Linus for 2.6.36, but I
> can't find it right now. Other than this and what's already in
> mtd-2.6.git, is there anything else?

I'm really no expert on how inclusion for different versions goes; I
just send 'em to you! Anyway, this patch is *very* important:
	* [PATCH] mtd: nand: Fix regression in BBM detection
	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031594.html
It addresses issues I overlooked with a lot of Hynix small-page NAND
(and others).

Other patches - they are ready, but not as important:
	* Spansion ORNAND
	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031603.html
	* New Samsung MLC OOB sizes
	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031621.html

No one has decided between these two (it's a "choose one or the other"
situation). They may or may not be ready:
	mtd: nand: Expand nand_ecc_layout, deprecate ioctl ECCGETLAYOUT
	Cover page: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031591.html
	Choice 1: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031593.html
	Choice 2: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031598.html
	Explanation: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031619.html

And since you asked, the trivial...
	Indentation errors :)
	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031588.html

You already got this one, I believe:
	Fixing a typo in on a buswidth option
	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031518.html

Thanks for looking out for me :)

Brian

----------------------------------------------------------------

Apparently, the check for a 6-byte ID string is NOT sufficient to
determine whether or not a Samsung chip uses their new MLC detection
scheme or the old, standard scheme. This adds a condition to check cell
type.

Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
Signed-off-by: Brian Norris <norris@broadcom.com>
---
 drivers/mtd/nand/nand_base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a3c7473..172a299 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2866,6 +2866,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 		 */
 		if (id_data[0] == id_data[6] && id_data[1] == id_data[7] &&
 				id_data[0] == NAND_MFR_SAMSUNG &&
+				(chip->cellinfo & NAND_CI_CELLTYPE_MSK) &&
 				id_data[5] != 0x00) {
 			/* Calc pagesize */
 			mtd->writesize = 2048 << (extid & 0x03);
-- 
1.7.0.4

Re: Bad assumption about ID field definition for Samsung NAND?

[David Woodhouse]

On Fri, 2010-08-20 at 14:01 -0700, Brian Norris wrote:
> > Can I have a signed-off-by for it?
> 
> I don't know what's "legal" here. I'm appending the patch with a
> sign-off for me and Tilman (since Tilman authored it). Hopefully that's
> ok.

You have to cut and paste Tilman's own Signed-off-by: header; the magic
doesn't work if you type it yourself. :)

> > Brian, I have a distinct impression that there's at least one more patch
> > from you that I really ought to be sending to Linus for 2.6.36, but I
> > can't find it right now. Other than this and what's already in
> > mtd-2.6.git, is there anything else?
> 
> I'm really no expert on how inclusion for different versions goes; I
> just send 'em to you! Anyway, this patch is *very* important:
> 	* [PATCH] mtd: nand: Fix regression in BBM detection
> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031594.html
> It addresses issues I overlooked with a lot of Hynix small-page NAND
> (and others).

That's in the tree already:
http://git.infradead.org/mtd-2.6.git/commitdiff/065a1ed8 

It's also https://bugzilla.kernel.org/show_bug.cgi?id=16639

> Other patches - they are ready, but not as important:
> 	* Spansion ORNAND
> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031603.html
> 	* New Samsung MLC OOB sizes
> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031621.html

Those aren't regressions or important bug-fixes, so given the timing I
think they've missed the merge window and are now candidates for 2.6.37
rather than 2.6.36?

I'll merge them as soon as I've asked Linus to pull what's in the tree
right now. Unless you object to my classification?

> No one has decided between these two (it's a "choose one or the other"
> situation). They may or may not be ready:
> 	mtd: nand: Expand nand_ecc_layout, deprecate ioctl ECCGETLAYOUT
> 	Cover page: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031591.html
> 	Choice 1: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031593.html
> 	Choice 2: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031598.html
> 	Explanation: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031619.html

Yeah, definitely 2.6.37 material.

> And since you asked, the trivial...
> 	Indentation errors :)
> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031588.html

That can wait for 2.6.37 too.

> You already got this one, I believe:
> 	Fixing a typo in on a buswidth option
> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031518.html

Yep, that's already in 2.6.36-rc1.

> Thanks for looking out for me :)
> 
> Brian
>
> ----------------------------------------------------------------
> 
> Apparently, the check for a 6-byte ID string is NOT sufficient to
> determine whether or not a Samsung chip uses their new MLC detection
> scheme or the old, standard scheme. This adds a condition to check cell
> type.
> 
> Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
> Signed-off-by: Brian Norris <norris@broadcom.com>
> ---

Just FYI; not to criticise when you're doing such excellent work -- this
would ideally have a From: and Subject: "header" indicating that Tilman
is the author, and giving the first line of the commit comment. That
way, running 'git-am' on it would fairly much work. Not that it's a
problem for me to do it either, of course.

Thanks again.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: Bad assumption about ID field definition for Samsung NAND?

[Brian Norris]

On 08/20/2010 02:34 PM, David Woodhouse wrote:
> On Fri, 2010-08-20 at 14:01 -0700, Brian Norris wrote:
>>> Can I have a signed-off-by for it?
>>
>> I don't know what's "legal" here. I'm appending the patch with a
>> sign-off for me and Tilman (since Tilman authored it). Hopefully that's
>> ok.
>
> You have to cut and paste Tilman's own Signed-off-by: header; the magic
> doesn't work if you type it yourself. :)

I'm glad someone has a sense of humor (or humour, depending on the country)

>> I'm really no expert on how inclusion for different versions goes; I
>> just send 'em to you! Anyway, this patch is *very* important:
>> 	* [PATCH] mtd: nand: Fix regression in BBM detection
>> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031594.html
>> It addresses issues I overlooked with a lot of Hynix small-page NAND
>> (and others).
>
> That's in the tree already:
> http://git.infradead.org/mtd-2.6.git/commitdiff/065a1ed8

I realized that right after sending this.

>> Other patches - they are ready, but not as important:
>> 	* Spansion ORNAND
>> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031603.html
>> 	* New Samsung MLC OOB sizes
>> 	http://lists.infradead.org/pipermail/linux-mtd/2010-August/031621.html
>
> Those aren't regressions or important bug-fixes, so given the timing I
> think they've missed the merge window and are now candidates for 2.6.37
> rather than 2.6.36?
>
> I'll merge them as soon as I've asked Linus to pull what's in the tree
> right now. Unless you object to my classification?

No objection.

> Just FYI; not to criticise when you're doing such excellent work -- this
> would ideally have a From: and Subject: "header" indicating that Tilman
> is the author, and giving the first line of the commit comment. That
> way, running 'git-am' on it would fairly much work. Not that it's a
> problem for me to do it either, of course.

I see. (Thanks for the compliment, btw, I'm rather new to this)

Brian