abuse of nand_correct_data in tmio_nand driver

abuse of nand_correct_data in tmio_nand driver

[Atsushi Nemoto]

Hi.  I found tmio_nand driver abuses nand_correct_data.

The current nand_correct_data() can be used for ecc.bytes = 3 case
only.  The tmio_nand driver uses ecc.bytes = 6.

This is just a report.  No patch since I don't have this hardware.

---
Atsushi Nemoto

Re: abuse of nand_correct_data in tmio_nand driver

[Dmitry Eremin-Solenikov]

Hi,

On Tue, Jul 14, 2009 at 11:05:03PM +0900, Atsushi Nemoto wrote:
> Hi.  I found tmio_nand driver abuses nand_correct_data.
> 
> The current nand_correct_data() can be used for ecc.bytes = 3 case
> only.  The tmio_nand driver uses ecc.bytes = 6.

IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
most probably ok. I'll look into it though, when I have some time.

-- 
With best wishes
Dmitry

Re: abuse of nand_correct_data in tmio_nand driver

[Atsushi Nemoto]

On Sun, 19 Jul 2009 04:11:27 +0400, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote:
> > The current nand_correct_data() can be used for ecc.bytes = 3 case
> > only.  The tmio_nand driver uses ecc.bytes = 6.
> 
> IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
> most probably ok. I'll look into it though, when I have some time.

Yes, tmio_nand driver read 512 byte data and calculate 6 byte ecc at
once, but nand_correct_data only references first 3 byte of ecc.

I doubt the driver cannot detect errors in the second 256 byte sector
of the 512 byte block.

---
Atsushi Nemoto

Re: abuse of nand_correct_data in tmio_nand driver

[Dmitry Eremin-Solenikov]

2009/7/19, Atsushi Nemoto <anemo@mba.ocn.ne.jp>:
> On Sun, 19 Jul 2009 04:11:27 +0400, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> > The current nand_correct_data() can be used for ecc.bytes = 3 case
>> > only.  The tmio_nand driver uses ecc.bytes = 6.
>>
>> IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
>> most probably ok. I'll look into it though, when I have some time.
>
> Yes, tmio_nand driver read 512 byte data and calculate 6 byte ecc at
> once, but nand_correct_data only references first 3 byte of ecc.
>
> I doubt the driver cannot detect errors in the second 256 byte sector
> of the 512 byte block.

Hmm. That's strange: nand_correct_data() seems to support 512-byte sectors,
however it assumes that ECC is still 3 bytes. I'll have to check specs to see
who is wrong...

-- 
With best wishes
Dmitry

Re: abuse of nand_correct_data in tmio_nand driver

[vimal singh]

On Sun, Jul 19, 2009 at 9:38 PM, Dmitry
Eremin-Solenikov<dbaryshkov@gmail.com> wrote:
> 2009/7/19, Atsushi Nemoto <anemo@mba.ocn.ne.jp>:
>> On Sun, 19 Jul 2009 04:11:27 +0400, Dmitry Eremin-Solenikov
>> <dbaryshkov@gmail.com> wrote:
>>> > The current nand_correct_data() can be used for ecc.bytes = 3 case
>>> > only.  The tmio_nand driver uses ecc.bytes = 6.
>>>
>>> IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
>>> most probably ok. I'll look into it though, when I have some time.
>>
>> Yes, tmio_nand driver read 512 byte data and calculate 6 byte ecc at
>> once, but nand_correct_data only references first 3 byte of ecc.
>>
>> I doubt the driver cannot detect errors in the second 256 byte sector
>> of the 512 byte block.

Seems like this driver may be reading 512 bytes at a times, but still
calculates 256-byte sector ECC. (1-bit error correction for each 256
bytes of data).
In that case, nand_correct_data() should be called twice, once for
each 256 byte data.

This can be handled by overriding 'chip->ecc.correct' in driver. You
may reuse 'nand_correct_data()' code in the driver of 256 byte sector
ECC.

>
> Hmm. That's strange: nand_correct_data() seems to support 512-byte sectors,
> however it assumes that ECC is still 3 bytes. I'll have to check specs to see
> who is wrong...

Yes, nand_correct_data() supports 512-byte sector ECC. 3 bytes of ECC
are not assumed one, but are required by Hamming algo for 512 byte
sector. Which gives 1 bit error correction capability over 512 bytes
of data.


>
> --
> With best wishes
> Dmitry
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



-- 
---
Regards,
\/ | |\/| /-\ |_

____      __o
------   -\<,
-----  ( )/ ( )

Re: abuse of nand_correct_data in tmio_nand driver

[Atsushi Nemoto]

On Mon, 20 Jul 2009 10:45:20 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
> Seems like this driver may be reading 512 bytes at a times, but still
> calculates 256-byte sector ECC. (1-bit error correction for each 256
> bytes of data).
> In that case, nand_correct_data() should be called twice, once for
> each 256 byte data.

But unfortunately nand_correct_data() cannot be used as is because it
depends on chip->ecc.size (which is 512 for tmio_nand driver).

> This can be handled by overriding 'chip->ecc.correct' in driver. You
> may reuse 'nand_correct_data()' code in the driver of 256 byte sector
> ECC.

Yes, the driver can reuse nand_ecc code to implement its own
nand_correct rountine.

Or how about adding support for 6byte-ecc/512byte-data to nand_ecc.c
to avoid code duplication?

I mean something like this.  If it looks acceptable, I will prepare a
patch including similer change to nand_calculate_ecc.

diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
index c0cb87d..77e13c8 100644
--- a/drivers/mtd/nand/nand_ecc.c
+++ b/drivers/mtd/nand/nand_ecc.c
@@ -425,14 +425,12 @@ EXPORT_SYMBOL(nand_calculate_ecc);
  *
  * Detect and correct a 1 bit error for 256/512 byte block
  */
-int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
-		      unsigned char *read_ecc, unsigned char *calc_ecc)
+static int nand_correct_data_sub(unsigned char *buf,
+	unsigned char *read_ecc, unsigned char *calc_ecc,
+	const uint32_t eccsize_mult)
 {
 	unsigned char b0, b1, b2, bit_addr;
 	unsigned int byte_addr;
-	/* 256 or 512 bytes/ecc  */
-	const uint32_t eccsize_mult =
-			(((struct nand_chip *)mtd->priv)->ecc.size) >> 8;
 
 	/*
 	 * b0 to b2 indicate which bit is faulty (if any)
@@ -495,6 +493,26 @@ int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
 	printk(KERN_ERR "uncorrectable error : ");
 	return -1;
 }
+int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
+		      unsigned char *read_ecc, unsigned char *calc_ecc)
+{
+	struct nand_chip *chip = mtd->priv;
+	/* 256 or 512 bytes/ecc  */
+	const uint32_t eccsize_mult = (chip->ecc.size) >> 8;
+	int r0, r1;
+
+	if (eccsize_mult == 2 && chip->ecc.bytes == 6) {
+		r0 = nand_correct_data_sub(buf, read_ecc, calc_ecc, 1);
+		if (r0 < 0)
+			return r0;
+		r1 = nand_correct_data_sub(buf + 256,
+					   read_ecc + 3, calc_ecc + 3, 1);
+		if (r1 < 0)
+			return r1;
+		return r0 | r1;
+	}
+	return nand_correct_data_sub(buf, read_ecc, calc_ecc, eccsize_mult);
+}
 EXPORT_SYMBOL(nand_correct_data);
 
 MODULE_LICENSE("GPL");

Re: abuse of nand_correct_data in tmio_nand driver

[vimal singh]

On Tue, Jul 21, 2009 at 8:50 PM, Atsushi Nemoto<anemo@mba.ocn.ne.jp> wrote:
> On Mon, 20 Jul 2009 10:45:20 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
>> Seems like this driver may be reading 512 bytes at a times, but still
>> calculates 256-byte sector ECC. (1-bit error correction for each 256
>> bytes of data).
>> In that case, nand_correct_data() should be called twice, once for
>> each 256 byte data.
>
> But unfortunately nand_correct_data() cannot be used as is because it
> depends on chip->ecc.size (which is 512 for tmio_nand driver).
>
>> This can be handled by overriding 'chip->ecc.correct' in driver. You
>> may reuse 'nand_correct_data()' code in the driver of 256 byte sector
>> ECC.
>
> Yes, the driver can reuse nand_ecc code to implement its own
> nand_correct rountine.
>
> Or how about adding support for 6byte-ecc/512byte-data to nand_ecc.c
> to avoid code duplication?
>
> I mean something like this.  If it looks acceptable, I will prepare a
> patch including similer change to nand_calculate_ecc.

I personally do not like any HW specific implementation going into the
generic part
of the code. This particular issue is specific to your HW, so better
handle it in the
driver only.


>
> diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
> index c0cb87d..77e13c8 100644
> --- a/drivers/mtd/nand/nand_ecc.c
> +++ b/drivers/mtd/nand/nand_ecc.c
> @@ -425,14 +425,12 @@ EXPORT_SYMBOL(nand_calculate_ecc);
>  *
>  * Detect and correct a 1 bit error for 256/512 byte block
>  */
> -int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
> -                     unsigned char *read_ecc, unsigned char *calc_ecc)
> +static int nand_correct_data_sub(unsigned char *buf,
> +       unsigned char *read_ecc, unsigned char *calc_ecc,
> +       const uint32_t eccsize_mult)
>  {
>        unsigned char b0, b1, b2, bit_addr;
>        unsigned int byte_addr;
> -       /* 256 or 512 bytes/ecc  */
> -       const uint32_t eccsize_mult =
> -                       (((struct nand_chip *)mtd->priv)->ecc.size) >> 8;
>
>        /*
>         * b0 to b2 indicate which bit is faulty (if any)
> @@ -495,6 +493,26 @@ int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
>        printk(KERN_ERR "uncorrectable error : ");
>        return -1;
>  }
> +int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
> +                     unsigned char *read_ecc, unsigned char *calc_ecc)
> +{
> +       struct nand_chip *chip = mtd->priv;
> +       /* 256 or 512 bytes/ecc  */
> +       const uint32_t eccsize_mult = (chip->ecc.size) >> 8;
> +       int r0, r1;
> +
> +       if (eccsize_mult == 2 && chip->ecc.bytes == 6) {
> +               r0 = nand_correct_data_sub(buf, read_ecc, calc_ecc, 1);
> +               if (r0 < 0)
> +                       return r0;
> +               r1 = nand_correct_data_sub(buf + 256,
> +                                          read_ecc + 3, calc_ecc + 3, 1);
> +               if (r1 < 0)
> +                       return r1;
> +               return r0 | r1;
> +       }
> +       return nand_correct_data_sub(buf, read_ecc, calc_ecc, eccsize_mult);
> +}
>  EXPORT_SYMBOL(nand_correct_data);
>
>  MODULE_LICENSE("GPL");
>



-- 
---
Regards,
\/ | |\/| /-\ |_

____      __o
------   -\<,
-----  ( )/ ( )

Re: abuse of nand_correct_data in tmio_nand driver

[Atsushi Nemoto]

On Wed, 22 Jul 2009 14:13:30 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
> >> This can be handled by overriding 'chip->ecc.correct' in driver. You
> >> may reuse 'nand_correct_data()' code in the driver of 256 byte sector
> >> ECC.
> >
> > Yes, the driver can reuse nand_ecc code to implement its own
> > nand_correct rountine.
> >
> > Or how about adding support for 6byte-ecc/512byte-data to nand_ecc.c
> > to avoid code duplication?
> >
> > I mean something like this.  If it looks acceptable, I will prepare a
> > patch including similer change to nand_calculate_ecc.
> 
> I personally do not like any HW specific implementation going into the
> generic part
> of the code. This particular issue is specific to your HW, so better
> handle it in the
> driver only.

OK, but I still feel duplicating nand_ecc code is not so good.  How
about splitting nand_correct_data into two parts?  A pure calculation
function and a wrapper for mtd interface.  Like this:

diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
index c0cb87d..3920896 100644
--- a/drivers/mtd/nand/nand_ecc.c
+++ b/drivers/mtd/nand/nand_ecc.c
@@ -425,14 +425,14 @@ EXPORT_SYMBOL(nand_calculate_ecc);
  *
  * Detect and correct a 1 bit error for 256/512 byte block
  */
-int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
-		      unsigned char *read_ecc, unsigned char *calc_ecc)
+int __nand_correct_data(unsigned char *buf,
+			unsigned char *read_ecc, unsigned char *calc_ecc,
+			unsigned int eccsize)
 {
 	unsigned char b0, b1, b2, bit_addr;
 	unsigned int byte_addr;
 	/* 256 or 512 bytes/ecc  */
-	const uint32_t eccsize_mult =
-			(((struct nand_chip *)mtd->priv)->ecc.size) >> 8;
+	const uint32_t eccsize_mult = eccsize >> 8;
 
 	/*
 	 * b0 to b2 indicate which bit is faulty (if any)
@@ -495,6 +495,16 @@ int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
 	printk(KERN_ERR "uncorrectable error : ");
 	return -1;
 }
+EXPORT_SYMBOL(__nand_correct_data);
+
+int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
+		      unsigned char *read_ecc, unsigned char *calc_ecc)
+{
+	const uint32_t eccsize_mult =
+			(((struct nand_chip *)mtd->priv)->ecc.size) >> 8;
+	return __nand_correct_data(buf, read_ecc, calc_ecc,
+				   ((struct nand_chip *)mtd->priv)->ecc.size);
+}
 EXPORT_SYMBOL(nand_correct_data);
 
 MODULE_LICENSE("GPL");


There is a little bonus: the STANDALONE macro in nand_ecc.c can be
more useful with this change ;)

---
Atsushi Nemoto

Re: abuse of nand_correct_data in tmio_nand driver

[vimal singh]

On Wed, Jul 22, 2009 at 8:43 PM, Atsushi Nemoto<anemo@mba.ocn.ne.jp> wrote:
> On Wed, 22 Jul 2009 14:13:30 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
>> >> This can be handled by overriding 'chip->ecc.correct' in driver. You
>> >> may reuse 'nand_correct_data()' code in the driver of 256 byte sector
>> >> ECC.
>> >
>> > Yes, the driver can reuse nand_ecc code to implement its own
>> > nand_correct rountine.
>> >
>> > Or how about adding support for 6byte-ecc/512byte-data to nand_ecc.c
>> > to avoid code duplication?
>> >
>> > I mean something like this.  If it looks acceptable, I will prepare a
>> > patch including similer change to nand_calculate_ecc.
>>
>> I personally do not like any HW specific implementation going into the
>> generic part
>> of the code. This particular issue is specific to your HW, so better
>> handle it in the
>> driver only.
>
> OK, but I still feel duplicating nand_ecc code is not so good.  How
> about splitting nand_correct_data into two parts?  A pure calculation
> function and a wrapper for mtd interface.  Like this:

But I do not see any thing extra, which you achieve from this
wrapper...  Is this a prototype, and you want to handle above scenario
in this wrapper (calling 'nand_correct_data' multiple times based on
something, probably 'ecc.bytes')?

>
> diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
> index c0cb87d..3920896 100644
> --- a/drivers/mtd/nand/nand_ecc.c
> +++ b/drivers/mtd/nand/nand_ecc.c
> @@ -425,14 +425,14 @@ EXPORT_SYMBOL(nand_calculate_ecc);
>  *
>  * Detect and correct a 1 bit error for 256/512 byte block
>  */
> -int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
> -                     unsigned char *read_ecc, unsigned char *calc_ecc)
> +int __nand_correct_data(unsigned char *buf,
> +                       unsigned char *read_ecc, unsigned char *calc_ecc,
> +                       unsigned int eccsize)
>  {
>        unsigned char b0, b1, b2, bit_addr;
>        unsigned int byte_addr;
>        /* 256 or 512 bytes/ecc  */
> -       const uint32_t eccsize_mult =
> -                       (((struct nand_chip *)mtd->priv)->ecc.size) >> 8;
> +       const uint32_t eccsize_mult = eccsize >> 8;
>
>        /*
>         * b0 to b2 indicate which bit is faulty (if any)
> @@ -495,6 +495,16 @@ int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
>        printk(KERN_ERR "uncorrectable error : ");
>        return -1;
>  }
> +EXPORT_SYMBOL(__nand_correct_data);
> +
> +int nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
> +                     unsigned char *read_ecc, unsigned char *calc_ecc)
> +{
> +       const uint32_t eccsize_mult =
> +                       (((struct nand_chip *)mtd->priv)->ecc.size) >> 8;
> +       return __nand_correct_data(buf, read_ecc, calc_ecc,
> +                                  ((struct nand_chip *)mtd->priv)->ecc.size);
> +}
>  EXPORT_SYMBOL(nand_correct_data);
>
>  MODULE_LICENSE("GPL");
>
>
> There is a little bonus: the STANDALONE macro in nand_ecc.c can be
> more useful with this change ;)
>
> ---
> Atsushi Nemoto
>



-- 
---
Regards,
\/ | |\/| /-\ |_

____      __o
------   -\<,
-----  ( )/ ( )

Re: abuse of nand_correct_data in tmio_nand driver

[Atsushi Nemoto]

On Thu, 23 Jul 2009 12:34:43 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
> > OK, but I still feel duplicating nand_ecc code is not so good.  How
> > about splitting nand_correct_data into two parts?  A pure calculation
> > function and a wrapper for mtd interface.  Like this:
> 
> But I do not see any thing extra, which you achieve from this
> wrapper...  Is this a prototype, and you want to handle above scenario
> in this wrapper (calling 'nand_correct_data' multiple times based on
> something, probably 'ecc.bytes')?

Yes, if we have __nand_correct_data(buf, read_ecc, calc_ecc, eccsize)
which do job based on its eccsize argument, the ecc.correct function
of the tmio_nand driver can be implemented like this:

int tmio_nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
		unsigned char *read_ecc, unsigned char *calc_ecc)
{
	int r0, r1;

	/* assume ecc.size = 512 and ecc.bytes = 6 */
	r0 = __nand_correct_data(buf, read_ecc, calc_ecc, 256);
	if (r0 < 0)
		return r0;
	r1 = __nand_correct_data(buf + 256, read_ecc + 3, calc_ecc + 3, 256);
	if (r1 < 0)
		return r1;
	return r0 | r1;
}

Note that this is not tested at all since I do not have tmio device.

Of course if Dmitry had another idea, I will not intrude this
approach.

---
Atsushi Nemoto

Re: abuse of nand_correct_data in tmio_nand driver

[Dmitry Eremin-Solenikov]

2009/7/23 Atsushi Nemoto <anemo@mba.ocn.ne.jp>:
> On Thu, 23 Jul 2009 12:34:43 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
>> > OK, but I still feel duplicating nand_ecc code is not so good.  How
>> > about splitting nand_correct_data into two parts?  A pure calculation
>> > function and a wrapper for mtd interface.  Like this:
>>
>> But I do not see any thing extra, which you achieve from this
>> wrapper...  Is this a prototype, and you want to handle above scenario
>> in this wrapper (calling 'nand_correct_data' multiple times based on
>> something, probably 'ecc.bytes')?
>
> Yes, if we have __nand_correct_data(buf, read_ecc, calc_ecc, eccsize)
> which do job based on its eccsize argument, the ecc.correct function
> of the tmio_nand driver can be implemented like this:
>
> int tmio_nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
>                unsigned char *read_ecc, unsigned char *calc_ecc)
> {
>        int r0, r1;
>
>        /* assume ecc.size = 512 and ecc.bytes = 6 */
>        r0 = __nand_correct_data(buf, read_ecc, calc_ecc, 256);
>        if (r0 < 0)
>                return r0;
>        r1 = __nand_correct_data(buf + 256, read_ecc + 3, calc_ecc + 3, 256);
>        if (r1 < 0)
>                return r1;
>        return r0 | r1;
> }
>
> Note that this is not tested at all since I do not have tmio device.

This seems to be the thing that was initially ment by Zaurus kernels, so
this if Ian doesn't object,

Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>

-- 
With best wishes
Dmitry

Re: abuse of nand_correct_data in tmio_nand driver

[vimal singh]

On Thu, Jul 23, 2009 at 8:41 PM, Atsushi Nemoto<anemo@mba.ocn.ne.jp> wrote:
> On Thu, 23 Jul 2009 12:34:43 +0530, vimal singh <vimal.newwork@gmail.com> wrote:
>> > OK, but I still feel duplicating nand_ecc code is not so good.  How
>> > about splitting nand_correct_data into two parts?  A pure calculation
>> > function and a wrapper for mtd interface.  Like this:
>>
>> But I do not see any thing extra, which you achieve from this
>> wrapper...  Is this a prototype, and you want to handle above scenario
>> in this wrapper (calling 'nand_correct_data' multiple times based on
>> something, probably 'ecc.bytes')?
>
> Yes, if we have __nand_correct_data(buf, read_ecc, calc_ecc, eccsize)
> which do job based on its eccsize argument, the ecc.correct function
> of the tmio_nand driver can be implemented like this:
>
> int tmio_nand_correct_data(struct mtd_info *mtd, unsigned char *buf,
>                unsigned char *read_ecc, unsigned char *calc_ecc)
> {
>        int r0, r1;
>
>        /* assume ecc.size = 512 and ecc.bytes = 6 */
>        r0 = __nand_correct_data(buf, read_ecc, calc_ecc, 256);
>        if (r0 < 0)
>                return r0;
>        r1 = __nand_correct_data(buf + 256, read_ecc + 3, calc_ecc + 3, 256);
>        if (r1 < 0)
>                return r1;
>        return r0 | r1;

Better 'r0 + r1', returned value should represent number of error bits
corrected.


After fixing above comment:

Acked-by: Vimal Singh <vimalsingh@ti.com>


---
Regards,
\/ | |\/| /-\ |_

____      __o
------   -\<,
-----  ( )/ ( )

Re: abuse of nand_correct_data in tmio_nand driver

[Ian molton]

Dmitry Eremin-Solenikov wrote:
> Hi,
> 
> On Tue, Jul 14, 2009 at 11:05:03PM +0900, Atsushi Nemoto wrote:
>> Hi.  I found tmio_nand driver abuses nand_correct_data.
>>
>> The current nand_correct_data() can be used for ecc.bytes = 3 case
>> only.  The tmio_nand driver uses ecc.bytes = 6.
> 
> IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
> most probably ok. I'll look into it though, when I have some time.

Are we really the only chip that does this?

Re: abuse of nand_correct_data in tmio_nand driver

[Atsushi Nemoto]

On Tue, 28 Jul 2009 14:57:05 +0100, Ian molton <spyro@f2s.com> wrote:
> >> The current nand_correct_data() can be used for ecc.bytes = 3 case
> >> only.  The tmio_nand driver uses ecc.bytes = 6.
> > 
> > IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
> > most probably ok. I'll look into it though, when I have some time.
> 
> Are we really the only chip that does this?

TXx9 NDFMC can read 6 byte ECC (for two 256 byte sectors) at a time.
I will try to see if doing it increase performance or not.

---
Atsushi Nemoto

Re: abuse of nand_correct_data in tmio_nand driver

[Ian Molton]

Atsushi Nemoto wrote:
> On Tue, 28 Jul 2009 14:57:05 +0100, Ian molton <spyro@f2s.com> wrote:
>>>> The current nand_correct_data() can be used for ecc.bytes = 3 case
>>>> only.  The tmio_nand driver uses ecc.bytes = 6.
>>> IIRC, tmio_nand driver accesses two ecc "sectors" at once, so this is
>>> most probably ok. I'll look into it though, when I have some time.
>> Are we really the only chip that does this?
> 
> TXx9 NDFMC can read 6 byte ECC (for two 256 byte sectors) at a time.
> I will try to see if doing it increase performance or not.

Cool,

If theres more than one chip that can do this, I think the change should 
go in the core mmc code.