| Message ID | 1490191680-14481-21-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| State | Superseded |
| Delegated to: | Boris Brezillon |
| Headers | show |
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. > nand_set_flash_node(chip, denali->dev->of_node); > > /* register the driver with the NAND core subsystem */
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.
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.
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!
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"; nand_set_flash_node(chip, denali->dev->of_node); /* register the driver with the NAND core subsystem */
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(-)