mtd: spi-nor: macronix: Add post bfpt fixup for mx25u51245g

The 64MB MX66U51235F's BFPT_WORD(1) declares
BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 and it doesn't provide
a 4BAIT table, so the address width will be set to
3-byte by default after parsing BFPT, which will make
the upper memory region unusable.

As the MX66U51235F shares the same JEDEC ID with
MX25U51245G and is identified to MX25U51245G, add a
post bfpt fix hook to correct the address width in
MX25U51245G's entry will solve this issue. It won't
affect MX25U51245G which also use 4-byte address
width and the address width will be valided when
parsing its 4BAIT table.

Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
---
 drivers/mtd/spi-nor/macronix.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

On 12/2/20 5:59 AM, Yicong Yang wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> The 64MB MX66U51235F's BFPT_WORD(1) declares
> BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 and it doesn't provide
> a 4BAIT table, so the address width will be set to
> 3-byte by default after parsing BFPT, which will make
> the upper memory region unusable.
> 
> As the MX66U51235F shares the same JEDEC ID with
> MX25U51245G and is identified to MX25U51245G, add a
> post bfpt fix hook to correct the address width in
> MX25U51245G's entry will solve this issue. It won't
> affect MX25U51245G which also use 4-byte address
> width and the address width will be valided when
> parsing its 4BAIT table.
> 

isn't this fixed by the following commit?

324f78dfb442 ("mtd: spi-nor: Fix address width on flash chips > 16MB")


> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
> ---
>  drivers/mtd/spi-nor/macronix.c | 33 ++++++++++++++++++++++++++++++++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index 9203aba..2b9065c 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -33,6 +33,36 @@ static struct spi_nor_fixups mx25l25635_fixups = {
>         .post_bfpt = mx25l25635_post_bfpt_fixups,
>  };
> 
> +static int
> +mx66u51235f_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)
> +{
> +       /*
> +        * The 64MB MX66U51235F's BFPT_WORD(1) declares
> +        * BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 and it doesn't provide
> +        * a 4BAIT table, so the address width will be set to
> +        * 3-byte by default after parsing BFPT,  which will make
> +        * the upper memory region unusable.
> +        *
> +        * As the MX66U51235F shares the same JEDEC ID with
> +        * MX25U51245G and is identified to MX25U51245G, add a
> +        * post bfpt fix hook to correct the address width in
> +        * MX25U51245G's entry will solve this issue. It won't
> +        * affect MX25U51245G which also use 4-byte address
> +        * width and the address width will be valided when
> +        * parsing its 4BAIT table.
> +        */
> +       nor->addr_width = 4;
> +
> +       return 0;
> +}
> +
> +static struct spi_nor_fixups mx66u51235f_fixups = {
> +       .post_bfpt = mx66u51235f_post_bfpt_fixups,
> +};
> +
>  static const struct flash_info macronix_parts[] = {
>         /* Macronix */
>         { "mx25l512e",   INFO(0xc22010, 0, 64 * 1024,   1, SECT_4K) },
> @@ -68,7 +98,8 @@ static const struct flash_info macronix_parts[] = {
>                               SECT_4K | SPI_NOR_4B_OPCODES) },
>         { "mx25u51245g", INFO(0xc2253a, 0, 64 * 1024, 1024,
>                               SECT_4K | SPI_NOR_DUAL_READ |
> -                             SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> +                             SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES)
> +               .fixups = &mx66u51235f_fixups },
>         { "mx25v8035f",  INFO(0xc22314, 0, 64 * 1024,  16,
>                               SECT_4K | SPI_NOR_DUAL_READ |
>                               SPI_NOR_QUAD_READ) },
> --
> 2.8.1
>

On 2020/12/2 19:14, Tudor.Ambarus@microchip.com wrote:
> On 12/2/20 5:59 AM, Yicong Yang wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> The 64MB MX66U51235F's BFPT_WORD(1) declares
>> BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 and it doesn't provide
>> a 4BAIT table, so the address width will be set to
>> 3-byte by default after parsing BFPT, which will make
>> the upper memory region unusable.
>>
>> As the MX66U51235F shares the same JEDEC ID with
>> MX25U51245G and is identified to MX25U51245G, add a
>> post bfpt fix hook to correct the address width in
>> MX25U51245G's entry will solve this issue. It won't
>> affect MX25U51245G which also use 4-byte address
>> width and the address width will be valided when
>> parsing its 4BAIT table.
>>
> isn't this fixed by the following commit?
>
> 324f78dfb442 ("mtd: spi-nor: Fix address width on flash chips > 16MB")

yes. I fall behind. Sorry to bother and thanks for the hint.