| Message ID | 1516285721-32294-1-git-send-email-fabio.estevam@nxp.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v6,1/2] mtd: fsl-quadspi: Distinguish the mtd device names | expand |
Hi Boris, On Thu, Jan 18, 2018 at 12:28 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote: > Currently on a imx6sx-sdb board, which has two SPI NOR chips connected > to QSPI2 the following output from /proc/mtd is seen: > > # cat /proc/mtd > dev: size erasesize name > mtd0: 01000000 00010000 "21e4000.qspi" > mtd1: 01000000 00010000 "21e4000.qspi" > > Attempts to partition them on the kernel command line result in both > chips with identical (and identically named) partitions, which is > an inconvenient behavior. > > Assign a different mtd->name for each mtd device to avoid this problem. > > After this change the output from /proc/mtd becomes: > > # cat /proc/mtd > dev: size erasesize name > mtd0: 01000000 00010000 "21e4000.qspi-0" > mtd1: 01000000 00010000 "21e4000.qspi-1" > > In order to keep mtdparts compatibility keep the mtd->name > unchanged when a single SPI NOR is present. > > Reported-by: David Wolfe <david.wolfe@nxp.com> > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> > Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> > --- > Changes since v5: > - Preserve the label value, if any. (Boris) Do you plan to apply this one for 4.17? Thanks
On Thu, 25 Jan 2018 08:20:59 -0200 Fabio Estevam <festevam@gmail.com> wrote: > Hi Boris, > > On Thu, Jan 18, 2018 at 12:28 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote: > > Currently on a imx6sx-sdb board, which has two SPI NOR chips connected > > to QSPI2 the following output from /proc/mtd is seen: > > > > # cat /proc/mtd > > dev: size erasesize name > > mtd0: 01000000 00010000 "21e4000.qspi" > > mtd1: 01000000 00010000 "21e4000.qspi" > > > > Attempts to partition them on the kernel command line result in both > > chips with identical (and identically named) partitions, which is > > an inconvenient behavior. > > > > Assign a different mtd->name for each mtd device to avoid this problem. > > > > After this change the output from /proc/mtd becomes: > > > > # cat /proc/mtd > > dev: size erasesize name > > mtd0: 01000000 00010000 "21e4000.qspi-0" > > mtd1: 01000000 00010000 "21e4000.qspi-1" > > > > In order to keep mtdparts compatibility keep the mtd->name > > unchanged when a single SPI NOR is present. > > > > Reported-by: David Wolfe <david.wolfe@nxp.com> > > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> > > Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> > > --- > > Changes since v5: > > - Preserve the label value, if any. (Boris) > > Do you plan to apply this one for 4.17? I'm not applying spi-nor patches, and Cyrille already sent me his PR for 4.16. So yes, I'd say it will be queued for 4.17. Is this a problem?
Hi Boris, On Thu, Jan 25, 2018 at 8:33 AM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > I'm not applying spi-nor patches, and Cyrille already sent me his PR > for 4.16. So yes, I'd say it will be queued for 4.17. Is this a problem? No problem. Thanks for the clarification. Cyrille, I missed to add you on Cc on v6. Should I resend it with you on Cc? Thanks
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c index 2901c7b..1038842 100644 --- a/drivers/mtd/spi-nor/fsl-quadspi.c +++ b/drivers/mtd/spi-nor/fsl-quadspi.c @@ -1051,6 +1051,24 @@ static int fsl_qspi_probe(struct platform_device *pdev) spi_nor_set_flash_node(nor, np); nor->priv = q; + if (q->nor_num > 1 && !mtd->name) { + int spiflash_idx; + + ret = of_property_read_u32(np, "reg", &spiflash_idx); + if (!ret) { + mtd->name = devm_kasprintf(dev, GFP_KERNEL, + "%s-%d", + dev_name(dev), + spiflash_idx); + if (!mtd->name) { + ret = -ENOMEM; + goto mutex_failed; + } + } else { + dev_warn(dev, "reg property is missing\n"); + } + } + /* fill the hooks */ nor->read_reg = fsl_qspi_read_reg; nor->write_reg = fsl_qspi_write_reg;