All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <boris.brezillon@bootlin.com>, <marek.vasut@gmail.com>
Cc: <alexandre.belloni@bootlin.com>, <dwmw2@infradead.org>,
	<computersforpeace@gmail.com>, <richard@nod.at>,
	<linux-mtd@lists.infradead.org>, <alexander.sverdlin@nokia.com>
Subject: Re: [PATCH v5 1/3] mtd: spi-nor: Add the SNOR_F_4B_OPCODES flag
Date: Thu, 6 Dec 2018 11:29:05 +0000	[thread overview]
Message-ID: <77952075-61e8-b960-9112-9adc91457025@microchip.com> (raw)
In-Reply-To: <20181206103736.5957-2-boris.brezillon@bootlin.com>



On 12/06/2018 12:37 PM, Boris Brezillon wrote:
> Some flash_info entries have the SPI_NOR_4B_OPCODES flag set to let the
> core know that the flash supports 4B opcode. While this solution works
> fine for id-based caps detection, it doesn't work that well when relying
> on SFDP-based caps detection. Let's add an SNOR_F_4B_OPCODES flag so
> that the SFDP parsing code can set it when appropriate.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>

Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>

> ---
> Changes in v5:
> - Cosmetic changes
> 
> Changes in v4:
> - Set SNOR_F_4B_OPCODES flag outside of the if (mtd->size > 0x1000000)
>   block
> - Do not set SNOR_F_4B_OPCODES when BFPT_DWORD1_ADDRESS_BYTES_4_ONLY,
>   because 4byte only does not imply 4B opcodes are supported
> 
> Changes in v3:
> - Clear SNOR_F_4B_OPCODES flag when SFDP fails
> - Add Alexandre R-b
> 
> Changes in v2:
> - Fix the commit message
> - Fix the ->addr_width check
> - Add a comma at the end of the SNOR_F_4B_OPCODES definition
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 21 +++++++++++----------
>  include/linux/mtd/spi-nor.h   |  1 +
>  2 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 8f07430ffffa..bea122e0d731 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -3272,6 +3272,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
>  
>  		if (spi_nor_parse_sfdp(nor, &sfdp_params)) {
>  			nor->addr_width = 0;
> +			nor->flags &= ~SNOR_F_4B_OPCODES;
>  			/* restore previous erase map */
>  			memcpy(&nor->erase_map, &prev_map,
>  			       sizeof(nor->erase_map));
> @@ -3572,9 +3573,7 @@ static int spi_nor_init(struct spi_nor *nor)
>  		}
>  	}
>  
> -	if ((nor->addr_width == 4) &&
> -	    (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
> -	    !(nor->info->flags & SPI_NOR_4B_OPCODES)) {
> +	if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES)) {
>  		/*
>  		 * If the RESET# pin isn't hooked up properly, or the system
>  		 * otherwise doesn't perform a reset command in the boot
> @@ -3606,10 +3605,8 @@ static void spi_nor_resume(struct mtd_info *mtd)
>  void spi_nor_restore(struct spi_nor *nor)
>  {
>  	/* restore the addressing mode */
> -	if ((nor->addr_width == 4) &&
> -	    (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
> -	    !(nor->info->flags & SPI_NOR_4B_OPCODES) &&
> -	    (nor->flags & SNOR_F_BROKEN_RESET))
> +	if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES) &&
> +	    nor->flags & SNOR_F_BROKEN_RESET)
>  		set_4byte(nor, nor->info, 0);
>  }
>  EXPORT_SYMBOL_GPL(spi_nor_restore);
> @@ -3765,13 +3762,17 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
>  	} else if (mtd->size > 0x1000000) {
>  		/* enable 4-byte addressing if the device exceeds 16MiB */
>  		nor->addr_width = 4;
> -		if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
> -		    info->flags & SPI_NOR_4B_OPCODES)
> -			spi_nor_set_4byte_opcodes(nor, info);
>  	} else {
>  		nor->addr_width = 3;
>  	}
>  
> +	if (info->flags & SPI_NOR_4B_OPCODES ||
> +	    (JEDEC_MFR(info) == SNOR_MFR_SPANSION && mtd->size > SZ_16M))
> +		nor->flags |= SNOR_F_4B_OPCODES;
> +
> +	if (nor->addr_width == 4 && nor->flags & SNOR_F_4B_OPCODES)
> +		spi_nor_set_4byte_opcodes(nor, info);
> +
>  	if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
>  		dev_err(dev, "address width is too large: %u\n",
>  			nor->addr_width);
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 8b1acf68b7ac..981d628305a2 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -237,6 +237,7 @@ enum spi_nor_option_flags {
>  	SNOR_F_READY_XSR_RDY	= BIT(4),
>  	SNOR_F_USE_CLSR		= BIT(5),
>  	SNOR_F_BROKEN_RESET	= BIT(6),
> +	SNOR_F_4B_OPCODES	= BIT(7),
>  };
>  
>  /**
> 

  reply	other threads:[~2018-12-06 11:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 10:37 [PATCH v5 0/3] mtd: spi-nor: mx25l25635f: Use 4B opcodes Boris Brezillon
2018-12-06 10:37 ` [PATCH v5 1/3] mtd: spi-nor: Add the SNOR_F_4B_OPCODES flag Boris Brezillon
2018-12-06 11:29   ` Tudor.Ambarus [this message]
2018-12-07  9:10   ` [v5,1/3] " Boris Brezillon
2018-12-06 10:37 ` [PATCH v5 2/3] mtd: spi-nor: Add a post BFPT parsing fixup hook Boris Brezillon
2018-12-06 11:29   ` Tudor.Ambarus
2018-12-07  9:10   ` [v5,2/3] " Boris Brezillon
2018-12-06 10:37 ` [PATCH v5 3/3] mtd: spi-nor: Add a post BFPT fixup for MX25L25635E Boris Brezillon
2018-12-06 11:33   ` Tudor.Ambarus
2018-12-07  9:10   ` [v5,3/3] " Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=77952075-61e8-b960-9112-9adc91457025@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=alexander.sverdlin@nokia.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.