| Message ID | 1377355884-5920-1-git-send-email-eliedebrauwer@gmail.com |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Stefano Babic |
| Headers | show |
On 24/08/2013 16:51, Elie De Brauwer wrote: > On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says: > > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4), > 512MiB, page size: 4096, OOB size: 224) the ECC strength is 16. > > root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize subpagesize; do echo $i = `cat $i`; done > ecc_strength = 16 > oobsize = 224 > subpagesize = 4096 > > The ECC strength was not properly discovered by U-Boot causing the data > written by Linux to return an -74 (EBADMSG) when read from U-Boot. This > patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND > flash with page_data_size = 4096 and page_oob_size= 224. > > Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> > --- Scott, I found this is assigned to me in patchwork. Is it ok if I apply it ? Best regards, Stefano
On Tue, 2013-09-10 at 19:02 +0200, Stefano Babic wrote: > On 24/08/2013 16:51, Elie De Brauwer wrote: > > On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says: > > > > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4), > > 512MiB, page size: 4096, OOB size: 224) the ECC strength is 16. > > > > root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize subpagesize; do echo $i = `cat $i`; done > > ecc_strength = 16 > > oobsize = 224 > > subpagesize = 4096 > > > > The ECC strength was not properly discovered by U-Boot causing the data > > written by Linux to return an -74 (EBADMSG) when read from U-Boot. This > > patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND > > flash with page_data_size = 4096 and page_oob_size= 224. > > > > Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> > > --- > > Scott, I found this is assigned to me in patchwork. Is it ok if I apply it ? > > Best regards, > Stefano Sure. Acked-by: Scott Wood <scottwood@freescale.com> I'm curious who's been doing these patchwork assignments and what they're basing it on. -Scott
Hi Scott, On 10/09/2013 22:11, Scott Wood wrote: > Sure. > > Acked-by: Scott Wood <scottwood@freescale.com> > > I'm curious who's been doing these patchwork assignments and what > they're basing it on. > I think that everyone of us custodians has write rights to assign patches. Personally, I check the list and I assign myself the i.MXes. Surely there are a lot of unassigned patches, and someone tries to make order - better there is who takes care of a patch as to let the patch oblivious. However, this is an error-prone approach, and it should be nice if there could be an automatic way to assign patches, maybe using the subject. Regards, Stefano
On Wed, 2013-09-11 at 09:24 +0200, Stefano Babic wrote: > Hi Scott, > > On 10/09/2013 22:11, Scott Wood wrote: > > Sure. > > > > Acked-by: Scott Wood <scottwood@freescale.com> > > > > I'm curious who's been doing these patchwork assignments and what > > they're basing it on. > > > > I think that everyone of us custodians has write rights to assign > patches. Personally, I check the list and I assign myself the i.MXes. > Surely there are a lot of unassigned patches, and someone tries to make > order - better there is who takes care of a patch as to let the patch > oblivious. Sure... Probably what prompted the comment more than this was when other people assign patches to me that aren't in the NAND code (e.g. UBI patches, or patches in arch/board code). Then I need to choose between just unassigning them, or figuring out who to assign them to, and I can't even see who assigned them to me to ask them about it. A log of patchwork updates would be nice. > However, this is an error-prone approach, and it should be > nice if there could be an automatic way to assign patches, maybe using > the subject. It'd be nice if the files touched could be used. -Scott
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 378f8c5..036c113 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -155,6 +155,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size, if (page_oob_size == 218) return 16; + + if (page_oob_size == 224) + return 16; } return 0;
On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4), 512MiB, page size: 4096, OOB size: 224) the ECC strength is 16. root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize subpagesize; do echo $i = `cat $i`; done ecc_strength = 16 oobsize = 224 subpagesize = 4096 The ECC strength was not properly discovered by U-Boot causing the data written by Linux to return an -74 (EBADMSG) when read from U-Boot. This patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND flash with page_data_size = 4096 and page_oob_size= 224. Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> --- drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)