| Message ID | 20220510140232.3519184-2-michael@walle.cc |
|---|---|
| State | Changes Requested |
| Delegated to: | Ambarus Tudor |
| Headers | show |
| Series | introduce SNOR_ID3() | expand |
In "Add support for the siliconkaiser sk25lp128 chip."[0], I have tested
that this patch works on the sk25lp128.
Thanks!
Tested-by: Tom Fitzhenry <tom@tom-fitzhenry.me.uk>
0. https://lore.kernel.org/all/20220603141603.145777-1-tom@tom-fitzhenry.me.uk/
On 10/05/22 04:02PM, Michael Walle wrote: > Up until now, flashes were defined by specifying the JEDEC ID, the > sector size and the number of sectors. This can be read by parsing the > SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() > which just takes the JEDEC ID and implicitly set .parse_sfdp = true. All > new flashes which have SFDP should use this macro. > > Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
On 10/05/22 04:02PM, Michael Walle wrote: > Up until now, flashes were defined by specifying the JEDEC ID, the > sector size and the number of sectors. This can be read by parsing the > SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() > which just takes the JEDEC ID and implicitly set .parse_sfdp = true. All > new flashes which have SFDP should use this macro. > > Signed-off-by: Michael Walle <michael@walle.cc> Tested the macro with Renesas AT25QL128A serial nor flash. So, Tested-by: Biju Das <biju.das.jz@bp.renesas.com>
On 5/10/22 17:02, Michael Walle wrote: Hi! > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Up until now, flashes were defined by specifying the JEDEC ID, the > sector size and the number of sectors. This can be read by parsing the > SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() > which just takes the JEDEC ID and implicitly set .parse_sfdp = true. All > new flashes which have SFDP should use this macro. I like the idea, but you need to refine it a bit. Your assumptions are true only for flashes that are compliant with SFDP revB or later because params->page_size is initialized by querying BFPT DWORD 11. I think it would be good to specify this in the comment section. Also, I think you introduce a bug in spi_nor_select_erase() when CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not selected. wanted_size will be zero, will you select an invalid erase type? Would you please resubmit? Thanks, ta > > Signed-off-by: Michael Walle <michael@walle.cc> > --- > drivers/mtd/spi-nor/core.c | 7 +++++-- > drivers/mtd/spi-nor/core.h | 9 +++++++++ > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 402b37cdbcea..29329ed0a934 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -2104,8 +2104,11 @@ static int spi_nor_select_pp(struct spi_nor *nor, > * spi_nor_select_uniform_erase() - select optimum uniform erase type > * @map: the erase map of the SPI NOR > * @wanted_size: the erase type size to search for. Contains the value of > - * info->sector_size or of the "small sector" size in case > - * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined. > + * info->sector_size, the "small sector" size in case > + * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined or 0 if > + * there is no information about the sector size. The > + * latter is the case if the flash parameters are parsed > + * solely by SFDP. > * > * Once the optimum uniform sector erase command is found, disable all the > * other. > diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h > index 61886868cd02..fab3038c4f4a 100644 > --- a/drivers/mtd/spi-nor/core.h > +++ b/drivers/mtd/spi-nor/core.h > @@ -563,6 +563,15 @@ struct flash_info { > .n_regions = (_n_regions), \ > }, > > +#define SNOR_ID3(_jedec_id) \ > + .id = { \ > + ((_jedec_id) >> 16) & 0xff, \ > + ((_jedec_id) >> 8) & 0xff, \ > + (_jedec_id) & 0xff, \ > + }, \ > + .id_len = 3, \ > + .parse_sfdp = true, \ > + > #define PARSE_SFDP \ > .parse_sfdp = true, \ > > -- > 2.30.2 >
Am 2022-07-19 07:57, schrieb Tudor.Ambarus@microchip.com: > On 5/10/22 17:02, Michael Walle wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know >> the content is safe >> >> Up until now, flashes were defined by specifying the JEDEC ID, the >> sector size and the number of sectors. This can be read by parsing the >> SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() >> which just takes the JEDEC ID and implicitly set .parse_sfdp = true. >> All >> new flashes which have SFDP should use this macro. > > I like the idea, but you need to refine it a bit. > Your assumptions are true only for flashes that are compliant with SFDP > revB or > later because params->page_size is initialized by querying BFPT DWORD > 11. I think it would be good to specify this in the comment section. Sure. > Also, I think you introduce > a bug in spi_nor_select_erase() when CONFIG_MTD_SPI_NOR_USE_4K_SECTORS > is not > selected. wanted_size will be zero, will you select an invalid erase > type? You mean to squeeze [1] into this one? If so, sure. -michael [1] https://lore.kernel.org/linux-mtd/20220716000643.3541839-1-quic_jaehyoo@quicinc.com/
On 7/19/22 10:07, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Am 2022-07-19 07:57, schrieb Tudor.Ambarus@microchip.com: >> On 5/10/22 17:02, Michael Walle wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> Up until now, flashes were defined by specifying the JEDEC ID, the >>> sector size and the number of sectors. This can be read by parsing the >>> SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() >>> which just takes the JEDEC ID and implicitly set .parse_sfdp = true. >>> All >>> new flashes which have SFDP should use this macro. >> >> I like the idea, but you need to refine it a bit. >> Your assumptions are true only for flashes that are compliant with SFDP >> revB or >> later because params->page_size is initialized by querying BFPT DWORD >> 11. I think it would be good to specify this in the comment section. > > Sure. > >> Also, I think you introduce >> a bug in spi_nor_select_erase() when CONFIG_MTD_SPI_NOR_USE_4K_SECTORS >> is not >> selected. wanted_size will be zero, will you select an invalid erase >> type? > > You mean to squeeze [1] into this one? If so, sure. > > -michael > > [1] > https://lore.kernel.org/linux-mtd/20220716000643.3541839-1-quic_jaehyoo@quicinc.com/ No, these are orthogonal. If you keep wanted_size to zero, then spi_nor_select_uniform_erase() will return NULL, doesn't it? Maybe to adapt the code to something like diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 21cefe2864ba..dd6cd852d1ef 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2148,7 +2148,7 @@ static int spi_nor_select_erase(struct spi_nor *nor) struct spi_nor_erase_map *map = &nor->params->erase_map; const struct spi_nor_erase_type *erase = NULL; struct mtd_info *mtd = &nor->mtd; - u32 wanted_size = nor->info->sector_size; + u32 wanted_size = nor->params->sector_size; and fill nor->params->sector_size even when no SFDP Also, params->size = (u64)info->sector_size * info->n_sectors; from spi_nor_init_default_params() becomes superfluous. I would check the fields that I don't initialize in flash_info with SNOR_ID3 and check how I can mitigate their absence throughout the code.
Am 2022-07-19 09:33, schrieb Tudor.Ambarus@microchip.com: > On 7/19/22 10:07, Michael Walle wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know >> the content is safe >> >> Am 2022-07-19 07:57, schrieb Tudor.Ambarus@microchip.com: >>> On 5/10/22 17:02, Michael Walle wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you >>>> know >>>> the content is safe >>>> >>>> Up until now, flashes were defined by specifying the JEDEC ID, the >>>> sector size and the number of sectors. This can be read by parsing >>>> the >>>> SFDP, we don't have to specify it. Thus provide a new macro >>>> SNOR_ID3() >>>> which just takes the JEDEC ID and implicitly set .parse_sfdp = true. >>>> All >>>> new flashes which have SFDP should use this macro. >>> >>> I like the idea, but you need to refine it a bit. >>> Your assumptions are true only for flashes that are compliant with >>> SFDP >>> revB or >>> later because params->page_size is initialized by querying BFPT DWORD >>> 11. I think it would be good to specify this in the comment section. >> >> Sure. >> >>> Also, I think you introduce >>> a bug in spi_nor_select_erase() when >>> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS >>> is not >>> selected. wanted_size will be zero, will you select an invalid erase >>> type? >> >> You mean to squeeze [1] into this one? If so, sure. >> >> -michael >> >> [1] >> https://lore.kernel.org/linux-mtd/20220716000643.3541839-1-quic_jaehyoo@quicinc.com/ > > No, these are orthogonal. If you keep wanted_size to zero, then > spi_nor_select_uniform_erase() will return NULL, doesn't it? No, have a look at the second condition if (!erase && tested_erase->size) erase = .. So it will return the first non-empty slot. Thus it will only return NULL if all the slots are empty (given the fix is included). Actually, I'd have expected that to mask out an erase type, you clear the corresponding bit in uniform_erase_type, in which case the for loop in spi_nor_select_uniform_erase() would have just worked. But apparently there are two differnt mechanism here to mark an entry as unused, either the size is zero or the bit is not set. But that is a topic for another patch. -michael > Maybe to adapt the code to something like > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 21cefe2864ba..dd6cd852d1ef 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -2148,7 +2148,7 @@ static int spi_nor_select_erase(struct spi_nor > *nor) > struct spi_nor_erase_map *map = &nor->params->erase_map; > const struct spi_nor_erase_type *erase = NULL; > struct mtd_info *mtd = &nor->mtd; > - u32 wanted_size = nor->info->sector_size; > + u32 wanted_size = nor->params->sector_size; > > and fill nor->params->sector_size even when no SFDP > > Also, params->size = (u64)info->sector_size * info->n_sectors; from > spi_nor_init_default_params() becomes superfluous. I would check > the fields that I don't initialize in flash_info with SNOR_ID3 > and check how I can mitigate their absence throughout the code.
On 7/19/22 10:57, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Am 2022-07-19 09:33, schrieb Tudor.Ambarus@microchip.com: >> On 7/19/22 10:07, Michael Walle wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> Am 2022-07-19 07:57, schrieb Tudor.Ambarus@microchip.com: >>>> On 5/10/22 17:02, Michael Walle wrote: >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you >>>>> know >>>>> the content is safe >>>>> >>>>> Up until now, flashes were defined by specifying the JEDEC ID, the >>>>> sector size and the number of sectors. This can be read by parsing >>>>> the >>>>> SFDP, we don't have to specify it. Thus provide a new macro >>>>> SNOR_ID3() >>>>> which just takes the JEDEC ID and implicitly set .parse_sfdp = true. >>>>> All >>>>> new flashes which have SFDP should use this macro. >>>> >>>> I like the idea, but you need to refine it a bit. >>>> Your assumptions are true only for flashes that are compliant with >>>> SFDP >>>> revB or >>>> later because params->page_size is initialized by querying BFPT DWORD >>>> 11. I think it would be good to specify this in the comment section. >>> >>> Sure. >>> >>>> Also, I think you introduce >>>> a bug in spi_nor_select_erase() when >>>> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS >>>> is not >>>> selected. wanted_size will be zero, will you select an invalid erase >>>> type? >>> >>> You mean to squeeze [1] into this one? If so, sure. >>> >>> -michael >>> >>> [1] >>> https://lore.kernel.org/linux-mtd/20220716000643.3541839-1-quic_jaehyoo@quicinc.com/ >> >> No, these are orthogonal. If you keep wanted_size to zero, then >> spi_nor_select_uniform_erase() will return NULL, doesn't it? > > No, have a look at the second condition > > if (!erase && tested_erase->size) > erase = .. > > So it will return the first non-empty slot. Thus it will > only return NULL if all the slots are empty (given the > fix is included). > > Actually, I'd have expected that to mask out an erase > type, you clear the corresponding bit in uniform_erase_type, > in which case the for loop in spi_nor_select_uniform_erase() > would have just worked. But apparently there are two differnt > mechanism here to mark an entry as unused, either the size > is zero or the bit is not set. But that is a topic for another > patch. Right, I remember I leaned towards using just the erase mask to mask out an erase, but I have to reassess this. Here's a patch that is related and I left behind: https://patchwork.ozlabs.org/project/linux-mtd/patch/20211119081412.29732-1-alexander.sverdlin@nokia.com/ > something else that looks wrong: drivers/mtd/spi-nor/swp.c: return nor->info->sector_size << drivers/mtd/spi-nor/swp.c: return nor->info->sector_size; How do we progress on this? I like the SNOR_ID3 idea, but I think it should have a different form. Do you want to spend more time on this or do you think I should invest more time on this? > -michael > >> Maybe to adapt the code to something like >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c >> index 21cefe2864ba..dd6cd852d1ef 100644 >> --- a/drivers/mtd/spi-nor/core.c >> +++ b/drivers/mtd/spi-nor/core.c >> @@ -2148,7 +2148,7 @@ static int spi_nor_select_erase(struct spi_nor >> *nor) >> struct spi_nor_erase_map *map = &nor->params->erase_map; >> const struct spi_nor_erase_type *erase = NULL; >> struct mtd_info *mtd = &nor->mtd; >> - u32 wanted_size = nor->info->sector_size; >> + u32 wanted_size = nor->params->sector_size; >> >> and fill nor->params->sector_size even when no SFDP >> >> Also, params->size = (u64)info->sector_size * info->n_sectors; from >> spi_nor_init_default_params() becomes superfluous. I would check >> the fields that I don't initialize in flash_info with SNOR_ID3 >> and check how I can mitigate their absence throughout the code.
On 7/19/22 08:57, Tudor.Ambarus@microchip.com wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 5/10/22 17:02, Michael Walle wrote: > > Hi! > >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> Up until now, flashes were defined by specifying the JEDEC ID, the >> sector size and the number of sectors. This can be read by parsing the >> SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() >> which just takes the JEDEC ID and implicitly set .parse_sfdp = true. All >> new flashes which have SFDP should use this macro. > > I like the idea, but you need to refine it a bit. > Your assumptions are true only for flashes that are compliant with SFDP revB or > later because params->page_size is initialized by querying BFPT DWORD 11. I think > it would be good to specify this in the comment section. Also, I think you introduce > a bug in spi_nor_select_erase() when CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not > selected. wanted_size will be zero, will you select an invalid erase type? > Would you please resubmit? > > Thanks, > ta > >> >> Signed-off-by: Michael Walle <michael@walle.cc> >> --- >> drivers/mtd/spi-nor/core.c | 7 +++++-- >> drivers/mtd/spi-nor/core.h | 9 +++++++++ >> 2 files changed, 14 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c >> index 402b37cdbcea..29329ed0a934 100644 >> --- a/drivers/mtd/spi-nor/core.c >> +++ b/drivers/mtd/spi-nor/core.c >> @@ -2104,8 +2104,11 @@ static int spi_nor_select_pp(struct spi_nor *nor, >> * spi_nor_select_uniform_erase() - select optimum uniform erase type >> * @map: the erase map of the SPI NOR >> * @wanted_size: the erase type size to search for. Contains the value of >> - * info->sector_size or of the "small sector" size in case >> - * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined. >> + * info->sector_size, the "small sector" size in case >> + * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined or 0 if >> + * there is no information about the sector size. The >> + * latter is the case if the flash parameters are parsed >> + * solely by SFDP. >> * >> * Once the optimum uniform sector erase command is found, disable all the >> * other. >> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h >> index 61886868cd02..fab3038c4f4a 100644 >> --- a/drivers/mtd/spi-nor/core.h >> +++ b/drivers/mtd/spi-nor/core.h >> @@ -563,6 +563,15 @@ struct flash_info { >> .n_regions = (_n_regions), \ >> }, >> >> +#define SNOR_ID3(_jedec_id) How about SFDP_ID3 and SFDP_ID6 instead? \ >> + .id = { \ >> + ((_jedec_id) >> 16) & 0xff, \ >> + ((_jedec_id) >> 8) & 0xff, \ >> + (_jedec_id) & 0xff, \ >> + }, \ >> + .id_len = 3, \ >> + .parse_sfdp = true, \ >> + >> #define PARSE_SFDP \ >> .parse_sfdp = true, \ >> >> -- >> 2.30.2 >> > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>> +#define SNOR_ID3(_jedec_id) > > How about SFDP_ID3 and SFDP_ID6 instead? Yes, probably a better name. I was also thinking about splitting the id in vendor, device and additional bytes. But I haven't thought of the actual implementation that much. Such as: #define SFDP_ID(<u8 vid>, <u16 did>, <variable aux bytes>) #define SFDP_ID_FULL(<num_continuation_code>, <u8 vid>, <u16 did>, <variable aux bytes>) Couldn't make up a better name than that _FULL for now. Happy to hear suggestions :) -michael
On 7/28/22 16:12, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >>>> +#define SNOR_ID3(_jedec_id) >> >> How about SFDP_ID3 and SFDP_ID6 instead? > > Yes, probably a better name. I was also thinking about splitting > the id in vendor, device and additional bytes. But I haven't > thought of the actual implementation that much. Such as: > > #define SFDP_ID(<u8 vid>, <u16 did>, <variable aux bytes>) > #define SFDP_ID_FULL(<num_continuation_code>, <u8 vid>, <u16 did>, > <variable aux bytes>) > > Couldn't make up a better name than that _FULL for now. Happy to hear > suggestions :) > You mean splitting the ID in manufacturer ID, flash ID and extended flash ID? I'd like to understand the benefits of splitting this, can you give me an example? In the past I though about introducing some flash info macros for families of flashes of the same vendor, it will reduce the number of lines on flash definition, but not really related.
Am 2022-07-28 15:31, schrieb Tudor.Ambarus@microchip.com: > On 7/28/22 16:12, Michael Walle wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know >> the content is safe >> >>>>> +#define SNOR_ID3(_jedec_id) >>> >>> How about SFDP_ID3 and SFDP_ID6 instead? >> >> Yes, probably a better name. I was also thinking about splitting >> the id in vendor, device and additional bytes. But I haven't >> thought of the actual implementation that much. Such as: >> >> #define SFDP_ID(<u8 vid>, <u16 did>, <variable aux bytes>) >> #define SFDP_ID_FULL(<num_continuation_code>, <u8 vid>, <u16 did>, >> <variable aux bytes>) >> >> Couldn't make up a better name than that _FULL for now. Happy to hear >> suggestions :) >> > > You mean splitting the ID in manufacturer ID, flash ID and extended > flash ID? > I'd like to understand the benefits of splitting this, can you give me > an > example? In the past I though about introducing some flash info macros > for > families of flashes of the same vendor, it will reduce the number of > lines > on flash definition, but not really related. First, why would you combine the vendor and part id into one three byte field? Isn't it natural to have these as two fields? We know the did is 8 bit and the vid is 16 bit. And there might be N continuation codes. So putting that all in one value is error prone. See also below for the is25cd512. Second, the extended (so maybe SFDP_ID_EXT?) bytes is variable. I've seen flashes with one additional byte. If you want to have per vendor convenience macros you could do #define WINBOND_SFDP_ID(did, ...) SFDP_ID(0xNN, did, __VA_ARGS__) I don't see much benefit here. OTHO "#define SFDP_VID_WINBOND 0xNN" might make sense. But then we'd need to come up with support for continuation codes. So mhhh. As for the examples: SFDP_ID(SFDP_VID_WINBOND, 0x6019) SFDP_ID(SFDP_VID_MICRON, 0xba19, 0x10, 0x44, 0x00) or maybe SFDP_ID(SFDP_VID_MICRON, 0xba19, 0x10, 0x44) Currently we have the is25cd512 which (correctly) uses continuation codes. So, we'd need have something like #define SFDP_VID_ISSI_LEGACY 0x9d #define SFDP_VID_ISSI 1, 0x9d And preferrably we'd have something like: SFDP_ID(SFDP_VID_ISSI_LEGACY, 0x4013) SFDP_ID(SFDD_VID_ISSI, 0x20xx) (note that "xx" is unknown here.. we are lacking that because the entry is just using INFO() and I'm too lazy to look up the datasheet now.) Now I know that above probably won't compile, but maybe someone could come up with macros which actually work :) The following might work, but feels awful like a hack: #define SFDP_VID_ISSI_LEGACY 0, 0x9d #define SFDP_VID_ISSI 1, 0x9d -michael
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 402b37cdbcea..29329ed0a934 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2104,8 +2104,11 @@ static int spi_nor_select_pp(struct spi_nor *nor, * spi_nor_select_uniform_erase() - select optimum uniform erase type * @map: the erase map of the SPI NOR * @wanted_size: the erase type size to search for. Contains the value of - * info->sector_size or of the "small sector" size in case - * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined. + * info->sector_size, the "small sector" size in case + * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined or 0 if + * there is no information about the sector size. The + * latter is the case if the flash parameters are parsed + * solely by SFDP. * * Once the optimum uniform sector erase command is found, disable all the * other. diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h index 61886868cd02..fab3038c4f4a 100644 --- a/drivers/mtd/spi-nor/core.h +++ b/drivers/mtd/spi-nor/core.h @@ -563,6 +563,15 @@ struct flash_info { .n_regions = (_n_regions), \ }, +#define SNOR_ID3(_jedec_id) \ + .id = { \ + ((_jedec_id) >> 16) & 0xff, \ + ((_jedec_id) >> 8) & 0xff, \ + (_jedec_id) & 0xff, \ + }, \ + .id_len = 3, \ + .parse_sfdp = true, \ + #define PARSE_SFDP \ .parse_sfdp = true, \
Up until now, flashes were defined by specifying the JEDEC ID, the sector size and the number of sectors. This can be read by parsing the SFDP, we don't have to specify it. Thus provide a new macro SNOR_ID3() which just takes the JEDEC ID and implicitly set .parse_sfdp = true. All new flashes which have SFDP should use this macro. Signed-off-by: Michael Walle <michael@walle.cc> --- drivers/mtd/spi-nor/core.c | 7 +++++-- drivers/mtd/spi-nor/core.h | 9 +++++++++ 2 files changed, 14 insertions(+), 2 deletions(-)