[PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"
Marek Vasut
marex at denx.de
Fri Sep 17 15:39:04 CEST 2021
On 9/17/21 3:06 PM, Patrick DELAUNAY wrote:
> Hi Marek,
>
> > Marek VasutSept. 16, 2021, 5:27 p.m. UTC | #3
> > On 9/16/21 4:01 PM, Patrick Delaunay wrote:
>
> > [...]
>
> > > @@ -3664,6 +3666,11 @@ int spi_nor_scan(struct spi_nor *nor)
> > > struct mtd_info *mtd = &nor->mtd;
> > > struct spi_slave *spi = nor->spi;
> > > int ret;
> > > + int cfi_mtd_nb = 0;
> > > +
> > > +#ifdef CONFIG_SYS_MAX_FLASH_BANKS
> > > + cfi_mtd_nb = CONFIG_SYS_MAX_FLASH_BANKS;
> > > +#endif
>
> > Are we covering all the NORs (HF and co.) with this ?
>
>
> Yes, except if I miss something
>
>
> any NOR (including hyperflash) wich use the CFI interface /
> CONFIG_FLASH_CFI_MTD
>
> define the the 'nor%d' name with the calling stack:
Yes
> initr_flash()
>
> => flash_init()
>
> ==> cfi_flash_init_dm()
>
> ==> cfi_mtd_init() "nor%d" wich use loop on CONFIG_SYS_MAX_FLASH_BANKS
>
>
> I have only one concern today...
>
>
> if one cfi bank is missing (not activated in DT by example)
>
> and CONFIG_SYS_MAX_FLASH_BANKS_DETECT is not activated
>
> some holes can be done in index
>
>
> example:
>
> with CONFIG_SYS_MAX_FLASH_BANKS = 2 but with only one NOR on the board
>
> => "nor1" is absent and we have only 2 MTD device named "nor"
>
> - "nor0" => NOR or HF, first CFI bank
>
> - "nor2" => SPI-NOR (first)
>
>
> but I don't think that it is blocking
Wasn't the old behavior exactly the same anyway ?
> > > /* Reset SPI protocol for all commands. */
> > > nor->reg_proto = SNOR_PROTO_1_1_1;
> > > @@ -3715,8 +3722,10 @@ int spi_nor_scan(struct spi_nor *nor)
> > > if (ret)
> > > return ret;
> > >
> > > - if (!mtd->name)
> > > - mtd->name = info->name;
> > > + if (!mtd->name) {
> > > + sprintf(nor->mtd_name, "nor%d", cfi_mtd_nb +
> dev_seq(nor->dev));
> > > + mtd->name = nor->mtd_name;
> > > + }
> > > mtd->dev = nor->dev;
> > > mtd->priv = nor;
> > > mtd->type = MTD_NORFLASH;
> > > @@ -3821,7 +3830,7 @@ int spi_nor_scan(struct spi_nor *nor)
> > >
> > > nor->rdsr_dummy = params.rdsr_dummy;
> > > nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
> > > - nor->name = mtd->name;
> > > + nor->name = info->name;
> > > nor->size = mtd->size;
> > > nor->erase_size = mtd->erasesize;
> > > nor->sector_size = mtd->erasesize;
> > > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > > index 7ddc4ba2bf..8c3d5032e3 100644
> > > --- a/include/linux/mtd/spi-nor.h
> > > +++ b/include/linux/mtd/spi-nor.h
> > > @@ -561,6 +561,7 @@ struct spi_nor {
> > > int (*ready)(struct spi_nor *nor);
> > >
> > > void *priv;
> > > + char mtd_name[10];
>
> > should be 14, because nor%d\0 can be up to 14 bytes long.
>
> normally DM_MAX_SEQ = 999 (but never used)
>
> but Ok with you for 14 with "nor" = 3 + "%d" = 10 for max u32 value +
> "/0" = 1
>
>
> for cfi_mtd_names => 16 byte used with "nor%d"
>
> static char cfi_mtd_names[CFI_MAX_FLASH_BANKS][16];
>
> for nand => 8 bytes (./drivers/mtd/nand/raw/nand.c:59)
>
> static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
>
> for spi-nand => 20 bytes (drivers/mtd/nand/spi/core.c:1169)
>
> mtd->name = malloc(20);
Maybe we need a macro for this length of DM seq string which we could
use in these embedded array cases.
More information about the U-Boot
mailing list