| Message ID | 1490191680-14481-1-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| Headers | show |
| Series | mtd: nand: denali: 2nd round of Denali NAND IP patch bomb | expand |
On Wed, 22 Mar 2017 23:07:19 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > @@ -339,6 +352,7 @@ struct denali_nand_info { > int bbtskipbytes; > int max_banks; > unsigned int caps; > +#define DENALI_CAP_HW_ECC_FIXUP BIT(0) Can you move this definition outside of the struct denali_nand_info definition? > }; > > extern int denali_init(struct denali_nand_info *denali);
On Wed, 22 Mar 2017 23:07:19 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > +static int denali_hw_ecc_fixup(struct mtd_info *mtd, > + struct denali_nand_info *denali) > +{ > + int bank = denali->flash_bank; > + uint32_t ecc_cor; > + unsigned int max_bitflips; > + > + ecc_cor = ioread32(denali->flash_reg + ECC_COR_INFO(bank)); > + ecc_cor >>= ECC_COR_INFO__SHIFT(bank); > + > + if (ecc_cor & ECC_COR_INFO__UNCOR_ERR) > + return -EBADMSG; As previously mentioned, just increment ecc_stats.failed. > + > + max_bitflips = ecc_cor & ECC_COR_INFO__MAX_ERRORS; > + > + /* > + * The register holds the maximum of the number of corrected bitflips > + * per sector. This can be returned from ecc->read_page() as-is. > + * Unfortunately, we can not know the total number of corrected bits > + * in the page. mtd->ecc_stats.corrected is compromised here. > + */ > + mtd->ecc_stats.corrected += max_bitflips; > + > + return max_bitflips; > +}
Hi Boris, 2017-03-28 0:31 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: > On Wed, 22 Mar 2017 23:07:27 +0900 > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > >> This will be filled by nand_scan_ident() later. >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> Changes in v2: None >> >> drivers/mtd/nand/denali.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c >> index 3badb1d..1706975 100644 >> --- a/drivers/mtd/nand/denali.c >> +++ b/drivers/mtd/nand/denali.c >> @@ -1495,7 +1495,6 @@ int denali_init(struct denali_nand_info *denali) >> >> /* now that our ISR is registered, we can enable interrupts */ >> denali_set_intr_modes(denali, true); >> - mtd->name = "denali-nand"; > > Are you sure this is safe to do that? When mtd->name is NULL, the core > takes the parent name, and in the denali_dt case it's not "denali-nand", > which means you're breaking mtdparts compat. How big impact is this? I think a bootloader could give mtdparts=denali-nand:... but, now we are able to have partitions in DT nodes. -- Best Regards Masahiro Yamada
On Wed, 29 Mar 2017 06:32:24 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > Hi Boris, > > 2017-03-28 0:31 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: > > On Wed, 22 Mar 2017 23:07:27 +0900 > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > > >> This will be filled by nand_scan_ident() later. > >> > >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > >> --- > >> > >> Changes in v2: None > >> > >> drivers/mtd/nand/denali.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c > >> index 3badb1d..1706975 100644 > >> --- a/drivers/mtd/nand/denali.c > >> +++ b/drivers/mtd/nand/denali.c > >> @@ -1495,7 +1495,6 @@ int denali_init(struct denali_nand_info *denali) > >> > >> /* now that our ISR is registered, we can enable interrupts */ > >> denali_set_intr_modes(denali, true); > >> - mtd->name = "denali-nand"; > > > > Are you sure this is safe to do that? When mtd->name is NULL, the core > > takes the parent name, and in the denali_dt case it's not "denali-nand", > > which means you're breaking mtdparts compat. > > How big impact is this? Breaking boot on some platforms (those defining partitions through mtdparts= cmdline parameter), which is not negligible :P. > > I think a bootloader could give mtdparts=denali-nand:... > but, now we are able to have partitions in DT nodes. Just because you have a new way to describe partitions (using DT) does not mean people are not using the old one (mtdparts= parameter).
Hi Boris, 2017-03-29 6:40 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: > On Wed, 29 Mar 2017 06:32:24 +0900 > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > >> Hi Boris, >> >> 2017-03-28 0:31 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: >> > On Wed, 22 Mar 2017 23:07:27 +0900 >> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: >> > >> >> This will be filled by nand_scan_ident() later. >> >> >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> >> --- >> >> >> >> Changes in v2: None >> >> >> >> drivers/mtd/nand/denali.c | 1 - >> >> 1 file changed, 1 deletion(-) >> >> >> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c >> >> index 3badb1d..1706975 100644 >> >> --- a/drivers/mtd/nand/denali.c >> >> +++ b/drivers/mtd/nand/denali.c >> >> @@ -1495,7 +1495,6 @@ int denali_init(struct denali_nand_info *denali) >> >> >> >> /* now that our ISR is registered, we can enable interrupts */ >> >> denali_set_intr_modes(denali, true); >> >> - mtd->name = "denali-nand"; >> > >> > Are you sure this is safe to do that? When mtd->name is NULL, the core >> > takes the parent name, and in the denali_dt case it's not "denali-nand", >> > which means you're breaking mtdparts compat. >> >> How big impact is this? > > Breaking boot on some platforms (those defining partitions through > mtdparts= cmdline parameter), which is not negligible :P. > >> >> I think a bootloader could give mtdparts=denali-nand:... >> but, now we are able to have partitions in DT nodes. > > Just because you have a new way to describe partitions (using DT) does > not mean people are not using the old one (mtdparts= parameter). I thought DT-node derived name can identify the hardware even if multiple Denali controllers exist on an SoC. Anyway, I admit this is a kind of breakage. If this one is reject, I will drop it drop v3. -- Best Regards Masahiro Yamada
On Wed, 29 Mar 2017 10:19:02 +0900 Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > Hi Boris, > > 2017-03-29 6:40 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: > > On Wed, 29 Mar 2017 06:32:24 +0900 > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > > >> Hi Boris, > >> > >> 2017-03-28 0:31 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: > >> > On Wed, 22 Mar 2017 23:07:27 +0900 > >> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > >> > > >> >> This will be filled by nand_scan_ident() later. > >> >> > >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > >> >> --- > >> >> > >> >> Changes in v2: None > >> >> > >> >> drivers/mtd/nand/denali.c | 1 - > >> >> 1 file changed, 1 deletion(-) > >> >> > >> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c > >> >> index 3badb1d..1706975 100644 > >> >> --- a/drivers/mtd/nand/denali.c > >> >> +++ b/drivers/mtd/nand/denali.c > >> >> @@ -1495,7 +1495,6 @@ int denali_init(struct denali_nand_info *denali) > >> >> > >> >> /* now that our ISR is registered, we can enable interrupts */ > >> >> denali_set_intr_modes(denali, true); > >> >> - mtd->name = "denali-nand"; > >> > > >> > Are you sure this is safe to do that? When mtd->name is NULL, the core > >> > takes the parent name, and in the denali_dt case it's not "denali-nand", > >> > which means you're breaking mtdparts compat. > >> > >> How big impact is this? > > > > Breaking boot on some platforms (those defining partitions through > > mtdparts= cmdline parameter), which is not negligible :P. > > > >> > >> I think a bootloader could give mtdparts=denali-nand:... > >> but, now we are able to have partitions in DT nodes. > > > > Just because you have a new way to describe partitions (using DT) does > > not mean people are not using the old one (mtdparts= parameter). > > > I thought DT-node derived name can identify the hardware > even if multiple Denali controllers exist on an SoC. > > Anyway, I admit this is a kind of breakage. > > If this one is reject, I will drop it drop v3. > Yes, please keep the existing name, changing that without extra precautions has proven to be a bad idea [1]. Note that we now have a way to give user-friendly names to MTD devices through DT definitions [2]. So, if you ever want to assing a specific name to your NAND, all you have to do is add a label property to the NAND device node, and then, in the driver: nand_set_flash_node(chip, denali->dev->of_node); /* * Fallback to the default name if no label property was * defined. */ if (!mtd->name) mtd->name = "denali-nand"; [1]https://patchwork.ozlabs.org/patch/707065/ [2]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mtd/mtd.h?id=refs/tags/v4.11-rc4#n386
Hi Boris, 2017-03-29 16:19 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: > On Wed, 29 Mar 2017 10:19:02 +0900 > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > >> Hi Boris, >> >> 2017-03-29 6:40 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: >> > On Wed, 29 Mar 2017 06:32:24 +0900 >> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: >> > >> >> Hi Boris, >> >> >> >> 2017-03-28 0:31 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>: >> >> > On Wed, 22 Mar 2017 23:07:27 +0900 >> >> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote: >> >> > >> >> >> This will be filled by nand_scan_ident() later. >> >> >> >> >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> >> >> --- >> >> >> >> >> >> Changes in v2: None >> >> >> >> >> >> drivers/mtd/nand/denali.c | 1 - >> >> >> 1 file changed, 1 deletion(-) >> >> >> >> >> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c >> >> >> index 3badb1d..1706975 100644 >> >> >> --- a/drivers/mtd/nand/denali.c >> >> >> +++ b/drivers/mtd/nand/denali.c >> >> >> @@ -1495,7 +1495,6 @@ int denali_init(struct denali_nand_info *denali) >> >> >> >> >> >> /* now that our ISR is registered, we can enable interrupts */ >> >> >> denali_set_intr_modes(denali, true); >> >> >> - mtd->name = "denali-nand"; >> >> > >> >> > Are you sure this is safe to do that? When mtd->name is NULL, the core >> >> > takes the parent name, and in the denali_dt case it's not "denali-nand", >> >> > which means you're breaking mtdparts compat. >> >> >> >> How big impact is this? >> > >> > Breaking boot on some platforms (those defining partitions through >> > mtdparts= cmdline parameter), which is not negligible :P. >> > >> >> >> >> I think a bootloader could give mtdparts=denali-nand:... >> >> but, now we are able to have partitions in DT nodes. >> > >> > Just because you have a new way to describe partitions (using DT) does >> > not mean people are not using the old one (mtdparts= parameter). >> >> >> I thought DT-node derived name can identify the hardware >> even if multiple Denali controllers exist on an SoC. >> >> Anyway, I admit this is a kind of breakage. >> >> If this one is reject, I will drop it drop v3. >> > > Yes, please keep the existing name, changing that without extra > precautions has proven to be a bad idea [1]. > > Note that we now have a way to give user-friendly names to MTD devices > through DT definitions [2]. So, if you ever want to assing a specific > name to your NAND, all you have to do is add a label property to the > NAND device node, and then, in the driver: > > nand_set_flash_node(chip, denali->dev->of_node); > > /* > * Fallback to the default name if no label property was > * defined. > */ > if (!mtd->name) > mtd->name = "denali-nand"; > > > [1]https://patchwork.ozlabs.org/patch/707065/ I will replace it with this solution. Thanks for the tip! -- Best Regards Masahiro Yamada