* [PATCH 0/2] handle RDCR opcode for Macronix @ 2025-09-22 15:56 Maarten Zanders 2025-09-22 15:56 ` [PATCH 1/2] mtd: spi-nor: add configurable RDCR opcode Maarten Zanders 2025-09-22 15:56 ` [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 Maarten Zanders 0 siblings, 2 replies; 6+ messages in thread From: Maarten Zanders @ 2025-09-22 15:56 UTC (permalink / raw) To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Boris Brezillon Cc: Maarten Zanders, linux-mtd, linux-kernel This series introduces a configurable RDCR (Read Configuration Register) opcode for spi-nor flashes and applies a fix for Macronix devices. Patch 1 adds a new flash parameter to hold the RDCR opcode, defaulting to 0x35 (JEDEC standard). Patch 2 applies a Macronix-specific fixup, setting the RDCR opcode to 0x15. Signed-off-by: Maarten Zanders <maarten@zanders.be> Maarten Zanders (2): mtd: spi-nor: add configurable RDCR opcode mtd: spi-nor: macronix: use RDCR opcode 0x15 drivers/mtd/spi-nor/core.c | 12 +++++++++--- drivers/mtd/spi-nor/core.h | 6 ++++-- drivers/mtd/spi-nor/macronix.c | 1 + include/linux/mtd/spi-nor.h | 3 +++ 4 files changed, 17 insertions(+), 5 deletions(-) base-commit: 4550d33e18112a11a740424c4eec063cd58e918c -- 2.51.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/2] mtd: spi-nor: add configurable RDCR opcode 2025-09-22 15:56 [PATCH 0/2] handle RDCR opcode for Macronix Maarten Zanders @ 2025-09-22 15:56 ` Maarten Zanders 2025-09-22 15:56 ` [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 Maarten Zanders 1 sibling, 0 replies; 6+ messages in thread From: Maarten Zanders @ 2025-09-22 15:56 UTC (permalink / raw) To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Boris Brezillon Cc: Maarten Zanders, linux-mtd, linux-kernel Introduce a new flash parameter to hold the read configuration register (RDCR) opcode. Default to 0x35, which is the JEDEC standard. This change does not alter existing behavior but prepares the driver to support flashes that use a different opcode to read the CR. Fixes: 10526d85e4c6 ("mtd: spi-nor: Move Macronix bits out of core.c") Signed-off-by: Maarten Zanders <maarten@zanders.be> --- drivers/mtd/spi-nor/core.c | 12 +++++++++--- drivers/mtd/spi-nor/core.h | 6 ++++-- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index ac4b960101cc..ff537bdad401 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -484,7 +484,7 @@ int spi_nor_read_sr(struct spi_nor *nor, u8 *sr) /** * spi_nor_read_cr() - Read the Configuration Register using the - * SPINOR_OP_RDCR (35h) command. + * SPINOR_OP_RDCR command. * @nor: pointer to 'struct spi_nor' * @cr: pointer to a DMA-able buffer where the value of the * Configuration Register will be written. @@ -496,13 +496,16 @@ int spi_nor_read_cr(struct spi_nor *nor, u8 *cr) int ret; if (nor->spimem) { - struct spi_mem_op op = SPI_NOR_RDCR_OP(cr); + struct spi_mem_op op = SPI_NOR_RDCR_OP(nor->params->rdcr_opcode, + cr); spi_nor_spimem_setup_op(nor, &op, nor->reg_proto); ret = spi_mem_exec_op(nor->spimem, &op); } else { - ret = spi_nor_controller_ops_read_reg(nor, SPINOR_OP_RDCR, cr, + ret = spi_nor_controller_ops_read_reg(nor, + nor->params->rdcr_opcode, + cr, 1); } @@ -2893,6 +2896,9 @@ static void spi_nor_init_default_params(struct spi_nor *nor) /* Default to 16-bit Write Status (01h) Command */ nor->flags |= SNOR_F_HAS_16BIT_SR; + /* Default to 0x35 to read configuration register */ + params->rdcr_opcode = SPINOR_OP_RDCR; + /* Set SPI NOR sizes. */ params->writesize = 1; params->size = info->size; diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h index ceff412f7d65..abac5fc45ca8 100644 --- a/drivers/mtd/spi-nor/core.h +++ b/drivers/mtd/spi-nor/core.h @@ -61,8 +61,8 @@ SPI_MEM_OP_NO_DUMMY, \ SPI_MEM_OP_DATA_OUT(1, buf, 0)) -#define SPI_NOR_RDCR_OP(buf) \ - SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDCR, 0), \ +#define SPI_NOR_RDCR_OP(opcode, buf) \ + SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), \ SPI_MEM_OP_NO_ADDR, \ SPI_MEM_OP_NO_DUMMY, \ SPI_MEM_OP_DATA_IN(1, buf, 0)) @@ -351,6 +351,7 @@ struct spi_nor_otp { * in octal DTR mode. * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register * command in octal DTR mode. + * @rdcr_opcode: opcode needed to read the Configuration Register * @n_banks: number of banks. * @n_dice: number of dice in the flash memory. * @die_erase_opcode: die erase opcode. Defaults to SPINOR_OP_CHIP_ERASE. @@ -384,6 +385,7 @@ struct spi_nor_flash_parameter { u8 rdsr_addr_nbytes; u8 n_banks; u8 n_dice; + u8 rdcr_opcode; u8 die_erase_opcode; u32 *vreg_offset; -- 2.51.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 2025-09-22 15:56 [PATCH 0/2] handle RDCR opcode for Macronix Maarten Zanders 2025-09-22 15:56 ` [PATCH 1/2] mtd: spi-nor: add configurable RDCR opcode Maarten Zanders @ 2025-09-22 15:56 ` Maarten Zanders 2025-09-23 14:14 ` Michael Walle 1 sibling, 1 reply; 6+ messages in thread From: Maarten Zanders @ 2025-09-22 15:56 UTC (permalink / raw) To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Boris Brezillon Cc: Maarten Zanders, linux-mtd, linux-kernel Macronix devices use opcode 0x15 to read the configuration register (CR) instead of the default 0x35. On parts such as the MX25L12833F, reading the CR with 0x35 returns garbage values, which are then written back when updating the status register (SR). This may unintentionally program OTP bits (e.g. top/bottom block protection) and change other default values. Other Macronix parts avoid this issue because their SFDP data specifies that CR is not read (BFPT_DWORD15_QER_SR2_BIT1_NO_RD), and the driver assumes CR defaults to all zeroes which matches the hardware register. Set the RDCR opcode to 0x15 for Macronix flashes to avoid corrupt CR writes in cases where it is used. Note that for affected parts, the block protection mechanism might remain broken through the OTP bit: locking an upper block (which is the only one supported by the driver) is now locking the lower block in HW. Fixes: 10526d85e4c6 ("mtd: spi-nor: Move Macronix bits out of core.c") Signed-off-by: Maarten Zanders <maarten@zanders.be> --- drivers/mtd/spi-nor/macronix.c | 1 + include/linux/mtd/spi-nor.h | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c index e97f5cbd9aad..de3f3d963f86 100644 --- a/drivers/mtd/spi-nor/macronix.c +++ b/drivers/mtd/spi-nor/macronix.c @@ -322,6 +322,7 @@ static int macronix_nor_late_init(struct spi_nor *nor) if (!nor->params->set_4byte_addr_mode) nor->params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_en4b_ex4b; nor->params->set_octal_dtr = macronix_nor_set_octal_dtr; + nor->params->rdcr_opcode = SPINOR_OP_RDCR_MX; return 0; } diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index cdcfe0fd2e7d..e35405b126c2 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -92,6 +92,9 @@ #define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ #define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ +/* Used for Macronix flashes only. */ +#define SPINOR_OP_RDCR_MX 0x15 /* Read configuration register */ + /* Used for GigaDevices and Winbond flashes. */ #define SPINOR_OP_ESECR 0x44 /* Erase Security registers */ #define SPINOR_OP_PSECR 0x42 /* Program Security registers */ -- 2.51.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 2025-09-22 15:56 ` [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 Maarten Zanders @ 2025-09-23 14:14 ` Michael Walle 2025-09-24 9:00 ` Maarten Zanders 0 siblings, 1 reply; 6+ messages in thread From: Michael Walle @ 2025-09-23 14:14 UTC (permalink / raw) To: Maarten Zanders, Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Boris Brezillon Cc: linux-mtd, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 3484 bytes --] Hi Maarten, On Mon Sep 22, 2025 at 5:56 PM CEST, Maarten Zanders wrote: > Macronix devices use opcode 0x15 to read the configuration register (CR) > instead of the default 0x35. On parts such as the MX25L12833F, reading > the CR with 0x35 returns garbage values, which are then written back > when updating the status register (SR). This may unintentionally program > OTP bits (e.g. top/bottom block protection) and change other default > values. > > Other Macronix parts avoid this issue because their SFDP data specifies > that CR is not read (BFPT_DWORD15_QER_SR2_BIT1_NO_RD), and the driver > assumes CR defaults to all zeroes which matches the hardware register. Why isn't that also true for this device? It supports SFDP. Does it have a wrong value there? Could you dump please the SFDP and post it here, see [1]. > Set the RDCR opcode to 0x15 for Macronix flashes to avoid corrupt CR > writes in cases where it is used. > > Note that for affected parts, the block protection mechanism might > remain broken through the OTP bit: locking an upper block (which is the > only one supported by the driver) is now locking the lower block in HW. > > Fixes: 10526d85e4c6 ("mtd: spi-nor: Move Macronix bits out of core.c") I doubt that this is the correct Fixes tag as this only moves code around. But I'm also not convinced that we should fix it that way. I just had a look at a random macronix flash MX25L12805D and it doesn't have that opcode. Thus, just adding that to all the macronix flashes doesn't make much sense. But it also doesn't seem to have a WRSR command that takes 16bits.. and the core unconditonally set SNOR_F_HAS_16BIT_SR. Hum. So maybe just clear the SNOR_F_HAS_16BIT_SR or add SNOR_F_NO_READ_CR for the macronix flashes by default as a fix. Not sure what's better here. Then on top of that you might add the RDCR opcode, although I'm not sure for what it is used then. In any case, there seems to be another issue with your flash and the SFDP tables. -michael [1] https://docs.kernel.org/driver-api/mtd/spi-nor.html > Signed-off-by: Maarten Zanders <maarten@zanders.be> > --- > drivers/mtd/spi-nor/macronix.c | 1 + > include/linux/mtd/spi-nor.h | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c > index e97f5cbd9aad..de3f3d963f86 100644 > --- a/drivers/mtd/spi-nor/macronix.c > +++ b/drivers/mtd/spi-nor/macronix.c > @@ -322,6 +322,7 @@ static int macronix_nor_late_init(struct spi_nor *nor) > if (!nor->params->set_4byte_addr_mode) > nor->params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_en4b_ex4b; > nor->params->set_octal_dtr = macronix_nor_set_octal_dtr; > + nor->params->rdcr_opcode = SPINOR_OP_RDCR_MX; > > return 0; > } > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > index cdcfe0fd2e7d..e35405b126c2 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -92,6 +92,9 @@ > #define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ > #define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ > > +/* Used for Macronix flashes only. */ > +#define SPINOR_OP_RDCR_MX 0x15 /* Read configuration register */ > + > /* Used for GigaDevices and Winbond flashes. */ > #define SPINOR_OP_ESECR 0x44 /* Erase Security registers */ > #define SPINOR_OP_PSECR 0x42 /* Program Security registers */ [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 297 bytes --] [-- Attachment #2: Type: text/plain, Size: 144 bytes --] ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 2025-09-23 14:14 ` Michael Walle @ 2025-09-24 9:00 ` Maarten Zanders 2025-09-24 11:57 ` Michael Walle 0 siblings, 1 reply; 6+ messages in thread From: Maarten Zanders @ 2025-09-24 9:00 UTC (permalink / raw) To: Michael Walle Cc: Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Boris Brezillon, linux-mtd, linux-kernel, chengminglin Hi Michael, > Why isn't that also true for this device? It supports SFDP. Does it > have a wrong value there? You're right. I started working on this issue in an older kernel and didn't check the full error path again on the most recent version. I noted that the CR opcode was still wrong and went ahead forward porting my patches without checking the erroneous behavior in the latest kernel. My bad! My particular part (MX25L12833F) has been working (by doing 8 bit SR writes) since 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info fields", 2025-04-07). This ensures that SFDP data is read and behavior after that is OK. Before that commit, the SFDP data wouldn't be read because the .size was filled in (and before that because of .no_sfdp_flags). That in turn triggered the 16 bit writes. > But I'm also not convinced that we should fix it that way. I just > had a look at a random macronix flash MX25L12805D and it doesn't > have that opcode. Thus, just adding that to all the macronix flashes > doesn't make much sense. But it also doesn't seem to have a WRSR > command that takes 16bits.. and the core unconditonally set > SNOR_F_HAS_16BIT_SR. Hum. Yes. That part (MX25L12805D) has the same ID code whilst it is not supporting SFDP, RDCR or 16 bit SR writes (according to the datasheet). With the current flash info & logic in core.c, it will no longer work at all as spi_nor_parse_sfdp() fails. Consider a different example: 8M devices MX25L6433F, MX25L6436F and MX25L6473F. The ID for these is 0xC22017. Flash info for this contains a .size field (probably because of the legacy MX25L6405D) so SFDP will not be parsed and we're falling back on the defaults - so it will do 16 bit SR writes. CR will get corrupted due to wrong CR read opcode. So I believe this first problem boils down to the same ID representing both flashes with and without SFDP. If we want to keep supporting the old non-SFDP devices, the .size should be filled in for those ID's. Or we drop support for them altogether and make SFDP a hard requirement (solving the other issues in one go). But it should be consistent across the different sizes. > So maybe just clear the SNOR_F_HAS_16BIT_SR or add SNOR_F_NO_READ_CR > for the macronix flashes by default as a fix. Not sure what's better > here. SNOR_F_NO_READ_CR doesn't help: this will write all 0's to the CR in a 16 bit SR write, which is not the default state of some parts mentioned earlier. Clearing SNOR_F_HAS_16BIT_SR could indeed be a solution for letting these parts work properly in this non-sfdp mode. But we probably shouldn't do it for *all* Macronix flashes? > Then on top of that you might add the RDCR opcode, although > I'm not sure for what it is used then. There wouldn't be a real use until someone starts actually implementing the features in the Macronix CR (like top/bottom SWP). Or untill someone else is changing SNOR_F_HAS_16BIT_SR logic due to additional SFDP/BFPT parsing. Which I still consider a risk due to the weak link. > > Fixes: 10526d85e4c6 ("mtd: spi-nor: Move Macronix bits out of core.c") > > I doubt that this is the correct Fixes tag as this only moves code > around. Essentially, I meant 'since the beginning of macronix introduction'. In such a case, should we dig further through file renames & stale LTS's? Thanks for your input, Maarten > > In any case, there seems to be another issue with your flash and the > SFDP tables. > > -michael > > [1] https://docs.kernel.org/driver-api/mtd/spi-nor.html > > > Signed-off-by: Maarten Zanders <maarten@zanders.be> > > --- > > drivers/mtd/spi-nor/macronix.c | 1 + > > include/linux/mtd/spi-nor.h | 3 +++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c > > index e97f5cbd9aad..de3f3d963f86 100644 > > --- a/drivers/mtd/spi-nor/macronix.c > > +++ b/drivers/mtd/spi-nor/macronix.c > > @@ -322,6 +322,7 @@ static int macronix_nor_late_init(struct spi_nor *nor) > > if (!nor->params->set_4byte_addr_mode) > > nor->params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_en4b_ex4b; > > nor->params->set_octal_dtr = macronix_nor_set_octal_dtr; > > + nor->params->rdcr_opcode = SPINOR_OP_RDCR_MX; > > > > return 0; > > } > > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > > index cdcfe0fd2e7d..e35405b126c2 100644 > > --- a/include/linux/mtd/spi-nor.h > > +++ b/include/linux/mtd/spi-nor.h > > @@ -92,6 +92,9 @@ > > #define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ > > #define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ > > > > +/* Used for Macronix flashes only. */ > > +#define SPINOR_OP_RDCR_MX 0x15 /* Read configuration register */ > > + > > /* Used for GigaDevices and Winbond flashes. */ > > #define SPINOR_OP_ESECR 0x44 /* Erase Security registers */ > > #define SPINOR_OP_PSECR 0x42 /* Program Security registers */ > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 2025-09-24 9:00 ` Maarten Zanders @ 2025-09-24 11:57 ` Michael Walle 0 siblings, 0 replies; 6+ messages in thread From: Michael Walle @ 2025-09-24 11:57 UTC (permalink / raw) To: Maarten Zanders Cc: Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Boris Brezillon, linux-mtd, linux-kernel, chengminglin [-- Attachment #1.1: Type: text/plain, Size: 5403 bytes --] Hi Maarten, Hi Cheng, On Wed Sep 24, 2025 at 11:00 AM CEST, Maarten Zanders wrote: > > Why isn't that also true for this device? It supports SFDP. Does it > > have a wrong value there? > > You're right. I started working on this issue in an older kernel and > didn't check the full error path again on the most recent version. I > noted that the CR opcode was still wrong and went ahead forward > porting my patches without checking the erroneous behavior in the > latest kernel. My bad! > > My particular part (MX25L12833F) has been working (by doing 8 bit SR > writes) since 947c86e481a0 ("mtd: spi-nor: macronix: Drop the > redundant flash info fields", 2025-04-07). This ensures that SFDP data > is read and behavior after that is OK. Before that commit, the SFDP > data wouldn't be read because the .size was filled in (and before that > because of .no_sfdp_flags). That in turn triggered the 16 bit writes. A missing size only *mandates* a configuration by SFDP. But that's not true the other way around. If there is a size, SFDP might still be evaluated and will overwrite any static configuration. But for your flash, that's not the case, because of legacy behavior this is only done for flashes which are multi i/o, see spi_nor_init_params_deprecated(). Sigh. What a mess. But in any case, commit 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info fields") is clearly wrong as it will drop support for older flashes which doesn't feature SFDP. Cheng can you look into that please? > > But I'm also not convinced that we should fix it that way. I just > > had a look at a random macronix flash MX25L12805D and it doesn't > > have that opcode. Thus, just adding that to all the macronix flashes > > doesn't make much sense. But it also doesn't seem to have a WRSR > > command that takes 16bits.. and the core unconditonally set > > SNOR_F_HAS_16BIT_SR. Hum. > > Yes. That part (MX25L12805D) has the same ID code whilst it is not > supporting SFDP, RDCR or 16 bit SR writes (according to the > datasheet). > With the current flash info & logic in core.c, it will no longer work > at all as spi_nor_parse_sfdp() fails. Yes! I fully agree. > Consider a different example: 8M devices MX25L6433F, MX25L6436F and > MX25L6473F. The ID for these is 0xC22017. Flash info for this contains > a .size field (probably because of the legacy MX25L6405D) so SFDP will > not be parsed and we're falling back on the defaults - so it will do > 16 bit SR writes. CR will get corrupted due to wrong CR read opcode. Yes, but again not because of the populated .size but because it doesn't have any multi i/o flags set. > So I believe this first problem boils down to the same ID representing > both flashes with and without SFDP. If we want to keep supporting the > old non-SFDP devices, the .size should be filled in for those ID's. Or > we drop support for them altogether and make SFDP a hard requirement > (solving the other issues in one go). But it should be consistent > across the different sizes. Honestly, Macronix is know for duplicating flash id with flashes incompatible with each other. I have mixed feelings about reverting the commit mentioned above. On one hand, it takes the very easy way to just brush off support for older flashes without even mentioning it. On the other hand, it seems that only Guenter Roeck noticed. > > So maybe just clear the SNOR_F_HAS_16BIT_SR or add SNOR_F_NO_READ_CR > > for the macronix flashes by default as a fix. Not sure what's better > > here. > > SNOR_F_NO_READ_CR doesn't help: this will write all 0's to the CR in a > 16 bit SR write, which is not the default state of some parts > mentioned earlier. Mh? You've said: Other Macronix parts avoid this issue because their SFDP data specifies that CR is not read (BFPT_DWORD15_QER_SR2_BIT1_NO_RD), and the driver assumes CR defaults to all zeroes which matches the hardware register. Also isn't that the same behavior as with the SFDP? But I agree, that if the clearing the SNOR_F_HAS_16BIT_SR is probably better. > Clearing SNOR_F_HAS_16BIT_SR could indeed be a solution for letting > these parts work properly in this non-sfdp mode. But we probably > shouldn't do it for *all* Macronix flashes? Well as I said it's a mess right now. Moving forward we should probably have a static configuration and try to parse via SFDP even on non-SFDP flashes. Pratyush, any opinions? > > > Then on top of that you might add the RDCR opcode, although > > I'm not sure for what it is used then. > > There wouldn't be a real use until someone starts actually > implementing the features in the Macronix CR (like top/bottom SWP). Or > untill someone else is changing SNOR_F_HAS_16BIT_SR logic due to > additional SFDP/BFPT parsing. Which I still consider a risk due to the > weak link. > > > > Fixes: 10526d85e4c6 ("mtd: spi-nor: Move Macronix bits out of core.c") > > > > I doubt that this is the correct Fixes tag as this only moves code > > around. > > Essentially, I meant 'since the beginning of macronix introduction'. > In such a case, should we dig further through file renames & stale > LTS's? Probably, the patches won't be backported automatically anyway because of the conflicts. But it might be a good argument to have a (manual) backported fix. -michael [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 297 bytes --] [-- Attachment #2: Type: text/plain, Size: 144 bytes --] ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-09-24 12:03 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-09-22 15:56 [PATCH 0/2] handle RDCR opcode for Macronix Maarten Zanders 2025-09-22 15:56 ` [PATCH 1/2] mtd: spi-nor: add configurable RDCR opcode Maarten Zanders 2025-09-22 15:56 ` [PATCH 2/2] mtd: spi-nor: macronix: use RDCR opcode 0x15 Maarten Zanders 2025-09-23 14:14 ` Michael Walle 2025-09-24 9:00 ` Maarten Zanders 2025-09-24 11:57 ` Michael Walle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).