[PATCH v2] mtd: spi-nor: core: Ignore -ENOTSUPP in spi_nor_init()

[Tudor.Ambarus at microchip.com]

On 9/23/22 12:34, Mika Westerberg wrote:

Hi, Mika,

> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> The Intel SPI-NOR controller does not support the 4-byte address opcode
> so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash
> chip probe fail like this:
> 
>   [ 12.291082] spi-nor: probe of spi0.0 failed with error -524
> 
> Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
> Return error code from set_4byte_addr_mode()") it worked just fine.
> 
> Fix this by ignoring -ENOTSUPP in spi_nor_init().
> 
> Fixes: 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
> Cc: stable at vger.kernel.org
> Reported-by: Hongyu Ning <hongyu.ning at intel.com>
> Signed-off-by: Mika Westerberg <mika.westerberg at linux.intel.com>
> ---
> The previous version of the patch (the revert) can be found here:
> 
>   https://lore.kernel.org/linux-mtd/20220922134824.46758-1-mika.westerberg@linux.intel.com/
> 
> In this version we ignore -ENOTSUPP but the other error codes will be
> passed to the caller.
> 
>  drivers/mtd/spi-nor/core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index f2c64006f8d7..bee8fc4c9f07 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
>                  */
>                 WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
>                           "enabling reset hack; may not recover from unexpected reboots\n");
> -               return nor->params->set_4byte_addr_mode(nor, true);
> +               err = nor->params->set_4byte_addr_mode(nor, true);
> +               if (err && err != -ENOTSUPP)
> +                       return err;
>         }

So as of now if you use a flash larger than 16 MBytes, you can't access above 16 MBytes,
right? What happens at the controller side when it receives a nor->addr_nbytes of value 4?

Shouldn't spi_mem_supports_op() trim the 4-byte ops?

The better fix to me would be to extend the SPI NOR core to support the Extended Address
Register which consists of the 4th byte of memory address when the flash is operated
in 3-byte address mode.

-- 
Cheers,
ta