Message ID | 1554018157-10860-1-git-send-email-liu.xiang6@zte.com.cn |
---|---|
State | Changes Requested |
Delegated to: | Ambarus Tudor |
Headers | show |
Series | [v3] mtd: spi-nor: fix nor->addr_width when its value configured from SFDP does not match the actual width | expand |
Hi, Liu, On 03/31/2019 10:42 AM, Liu Xiang wrote: > Some is25lp256 get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for > address width. But in actual fact the flash can support 4-byte address. > So we should fix it. It's better to be imperative. Substitute "So we should fix it" with something like "Use a post bfpt fixup hook to overwrite the address width advertised by the BFPT". > We'll need a fixes tag here.> Suggested-by: Boris Brezillon <bbrezillon@kernel.org> > Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> When? If they didn't explicitly suggested this approach, lets drop the S-b tags. > Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn> > --- > > Changes in v3: > add a fixup for is25lp256 to solve the address width problem. > > drivers/mtd/spi-nor/spi-nor.c | 25 ++++++++++++++++++++++++- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index 6e13bbd..d252a66 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -1682,6 +1682,28 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor) > .flags = SPI_NOR_NO_FR | SPI_S3AN, > > static int > +is25lp256_post_bfpt_fixups(struct spi_nor *nor, > + const struct sfdp_parameter_header *bfpt_header, > + const struct sfdp_bfpt *bfpt, > + struct spi_nor_flash_parameter *params) > +{ > + /* > + * IS25LP256 supports 4B opcodes. > + * Unfortunately, some devices get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY ^ which devices, did you get a list from issi? > + * from BFPT table for address width. We should fix it. How about "IS25LP256 supports 4B opcodes, but the BFPT advertises a BFPT_DWORD1_ADDRESS_BYTES_3_ONLY address width. Overwrite the address width advertised by the BFPT." > + */ > + if ((bfpt->dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) == > + BFPT_DWORD1_ADDRESS_BYTES_3_ONLY) > + nor->addr_width = 4; > + > + return 0; > +} > + > +static struct spi_nor_fixups is25lp256_fixups = { Naga will use "is25lp256_fixups" for the is25wp256 too, but it's not the case to change the name yet. All good here. I really want to have this in next, can I have an update in the next few days? Cheers, ta
On 22/06/19 5:19 PM, Tudor.Ambarus@microchip.com wrote: > Hi, Liu, > > On 03/31/2019 10:42 AM, Liu Xiang wrote: > >> Some is25lp256 get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for >> address width. But in actual fact the flash can support 4-byte address. >> So we should fix it. > > It's better to be imperative. Substitute "So we should fix it" with something > like "Use a post bfpt fixup hook to overwrite the address width advertised by > the BFPT". > >> > > We'll need a fixes tag here.> Suggested-by: Boris Brezillon <bbrezillon@kernel.org> >> Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> > > When? If they didn't explicitly suggested this approach, lets drop the S-b tags. > IIRC, this was actually Boris's patch. No need for my S-b tag me :) Regards Vignesh >> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn> >> --- >> >> Changes in v3: >> add a fixup for is25lp256 to solve the address width problem. >> >> drivers/mtd/spi-nor/spi-nor.c | 25 ++++++++++++++++++++++++- >> 1 file changed, 24 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index 6e13bbd..d252a66 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -1682,6 +1682,28 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor) >> .flags = SPI_NOR_NO_FR | SPI_S3AN, >> >> static int >> +is25lp256_post_bfpt_fixups(struct spi_nor *nor, >> + const struct sfdp_parameter_header *bfpt_header, >> + const struct sfdp_bfpt *bfpt, >> + struct spi_nor_flash_parameter *params) >> +{ >> + /* >> + * IS25LP256 supports 4B opcodes. >> + * Unfortunately, some devices get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY > ^ which devices, did you get a list from issi? > >> + * from BFPT table for address width. We should fix it. > > How about "IS25LP256 supports 4B opcodes, but the BFPT advertises a > BFPT_DWORD1_ADDRESS_BYTES_3_ONLY address width. Overwrite the address width > advertised by the BFPT." > >> + */ >> + if ((bfpt->dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) == >> + BFPT_DWORD1_ADDRESS_BYTES_3_ONLY) >> + nor->addr_width = 4; >> + >> + return 0; >> +} >> + >> +static struct spi_nor_fixups is25lp256_fixups = { > > Naga will use "is25lp256_fixups" for the is25wp256 too, but it's not the case to > change the name yet. All good here. > > I really want to have this in next, can I have an update in the next few days? > > Cheers, > ta >
Hi, ta Thanks for your advice! I will send the update patch in soon. At 2019-06-22 19:49:25, Tudor.Ambarus@microchip.com wrote: >Hi, Liu, > >On 03/31/2019 10:42 AM, Liu Xiang wrote: > >> Some is25lp256 get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for >> address width. But in actual fact the flash can support 4-byte address. >> So we should fix it. > >It's better to be imperative. Substitute "So we should fix it" with something >like "Use a post bfpt fixup hook to overwrite the address width advertised by >the BFPT". > >> > >We'll need a fixes tag here.> Suggested-by: Boris Brezillon <bbrezillon@kernel.org> >> Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> > >When? If they didn't explicitly suggested this approach, lets drop the S-b tags. > >> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn> >> --- >> >> Changes in v3: >> add a fixup for is25lp256 to solve the address width problem. >> >> drivers/mtd/spi-nor/spi-nor.c | 25 ++++++++++++++++++++++++- >> 1 file changed, 24 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index 6e13bbd..d252a66 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -1682,6 +1682,28 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor) >> .flags = SPI_NOR_NO_FR | SPI_S3AN, >> >> static int >> +is25lp256_post_bfpt_fixups(struct spi_nor *nor, >> + const struct sfdp_parameter_header *bfpt_header, >> + const struct sfdp_bfpt *bfpt, >> + struct spi_nor_flash_parameter *params) >> +{ >> + /* >> + * IS25LP256 supports 4B opcodes. >> + * Unfortunately, some devices get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY > ^ which devices, did you get a list from issi? > >> + * from BFPT table for address width. We should fix it. > >How about "IS25LP256 supports 4B opcodes, but the BFPT advertises a >BFPT_DWORD1_ADDRESS_BYTES_3_ONLY address width. Overwrite the address width >advertised by the BFPT." > >> + */ >> + if ((bfpt->dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) == >> + BFPT_DWORD1_ADDRESS_BYTES_3_ONLY) >> + nor->addr_width = 4; >> + >> + return 0; >> +} >> + >> +static struct spi_nor_fixups is25lp256_fixups = { > >Naga will use "is25lp256_fixups" for the is25wp256 too, but it's not the case to >change the name yet. All good here. > >I really want to have this in next, can I have an update in the next few days? > >Cheers, >ta
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 6e13bbd..d252a66 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -1682,6 +1682,28 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor) .flags = SPI_NOR_NO_FR | SPI_S3AN, static int +is25lp256_post_bfpt_fixups(struct spi_nor *nor, + const struct sfdp_parameter_header *bfpt_header, + const struct sfdp_bfpt *bfpt, + struct spi_nor_flash_parameter *params) +{ + /* + * IS25LP256 supports 4B opcodes. + * Unfortunately, some devices get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY + * from BFPT table for address width. We should fix it. + */ + if ((bfpt->dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) == + BFPT_DWORD1_ADDRESS_BYTES_3_ONLY) + nor->addr_width = 4; + + return 0; +} + +static struct spi_nor_fixups is25lp256_fixups = { + .post_bfpt = is25lp256_post_bfpt_fixups, +}; + +static int mx25l25635_post_bfpt_fixups(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, const struct sfdp_bfpt *bfpt, @@ -1818,7 +1840,8 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor) SECT_4K | SPI_NOR_DUAL_READ) }, { "is25lp256", INFO(0x9d6019, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | - SPI_NOR_4B_OPCODES) }, + SPI_NOR_4B_OPCODES) + .fixups = &is25lp256_fixups }, { "is25wp032", INFO(0x9d7016, 0, 64 * 1024, 64, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, { "is25wp064", INFO(0x9d7017, 0, 64 * 1024, 128,
Some is25lp256 get BFPT_DWORD1_ADDRESS_BYTES_3_ONLY from BFPT table for address width. But in actual fact the flash can support 4-byte address. So we should fix it. Suggested-by: Boris Brezillon <bbrezillon@kernel.org> Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn> --- Changes in v3: add a fixup for is25lp256 to solve the address width problem. drivers/mtd/spi-nor/spi-nor.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-)