All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	computersforpeace@gmail.com, linux-mtd@lists.infradead.org
Cc: nicolas.ferre@atmel.com, boris.brezillon@free-electrons.com,
	richard@nod.at, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 9/9] mtd: spi-nor: add support to SST sst26* QSPI memories
Date: Tue, 25 Oct 2016 00:17:57 +0200	[thread overview]
Message-ID: <ca306f33-2eb7-a268-49f3-9b515a04f318@denx.de> (raw)
In-Reply-To: <74fedab98fba683d3563ac8c93d1fac6108ba278.1477325128.git.cyrille.pitchen@atmel.com>

On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
> This patch adds support to the SST sst26* QSPI memories.
> It also adds a new SST_BLOCK_PROTECT flag so spi_nor_scan() sends
> a SST Global Block Protection Unlock (98h) command once for all
> otherwise later Sector Erase and Page Program commands would fail.
> 
> It was tested with sst26vf016b, sst26vf032b, sst26vf032ba and sst26vf064b
> on a sama5d2 xplained board at 55.3MHz and 3.3V.
> 
> sst26wf040b and sst26wf080b were not tested since they are 1.8V memories
> hence don't fit the sama5d2 xplained board requirements.
> 
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 20 ++++++++++++++++++++
>  include/linux/mtd/spi-nor.h   |  1 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index eb21d3d4e4e6..300ee38f4e9a 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -81,6 +81,7 @@ struct flash_info {
>  					 * to support memory size above 128Mib.
>  					 */
>  #define SPI_NOR_SKIP_SFDP	BIT(11) /* Skip read of SFDP tables */
> +#define SST_BLOCK_PROTECT	BIT(12)	/* use SST Unlock Block-Protection */
>  };
>  
>  #define JEDEC_MFR(info)	((info)->id[0])
> @@ -999,6 +1000,11 @@ static const struct flash_info spi_nor_ids[] = {
>  	{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024,  8, SECT_4K) },
>  	{ "sst25wf040",  INFO(0xbf2504, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
>  	{ "sst25wf080",  INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
> +	{ "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32, SECT_4K | SST_BLOCK_PROTECT) },
> +	{ "sst26vf032b", INFO(0xbf2642, 0, 64 * 1024, 64, SECT_4K | SST_BLOCK_PROTECT) },
> +	{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128, SECT_4K | SST_BLOCK_PROTECT) },
> +	{ "sst26wf040b", INFO(0xbf2654, 0, 64 * 1024,  8, SECT_4K | SST_BLOCK_PROTECT) },
> +	{ "sst26wf080b", INFO(0xbf2658, 0, 64 * 1024, 16, SECT_4K | SST_BLOCK_PROTECT) },

You should split adding the chip and adding the sst block protection
into two separate patches.

>  	/* ST Microelectronics -- newer production may have feature updates */
>  	{ "m25p05",  INFO(0x202010,  0,  32 * 1024,   2, 0) },
> @@ -1135,6 +1141,14 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
>  	return ret;
>  }
>  
> +static int sst_unlock_block_protection(struct spi_nor *nor)
> +{
> +	int ret;
> +
> +	ret = write_enable(nor);
> +	return ret ? ret : nor->write_reg(nor, SPINOR_OP_ULBPR, NULL, 0);

I'm not a big fan of the ternary here, what about:

ret = write_enable()
if (!ret)
  ret = nor->write_reg();
return ret;

> +}
> +
>  static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
>  		size_t *retlen, const u_char *buf)
>  {
> @@ -2321,6 +2335,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
>  		return -EINVAL;
>  	}
>  
> +	if (info->flags & SST_BLOCK_PROTECT) {
> +		ret = sst_unlock_block_protection(nor);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	dev_info(dev, "%s (%lld Kbytes)\n", info->name,
>  			(long long)mtd->size >> 10);
>  
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 8fd9619dabff..c8f7e231a25c 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -80,6 +80,7 @@
>  #define SPINOR_OP_BP		0x02	/* Byte program */
>  #define SPINOR_OP_WRDI		0x04	/* Write disable */
>  #define SPINOR_OP_AAI_WP	0xad	/* Auto address increment word program */
> +#define SPINOR_OP_ULBPR		0x98	/* Global Block Protection Unlock */
>  
>  /* Used for Macronix and Winbond flashes. */
>  #define SPINOR_OP_EN4B		0xb7	/* Enter 4-byte mode */
> 


-- 
Best regards,
Marek Vasut

      reply	other threads:[~2016-10-24 22:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 16:34 [PATCH v3 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories Cyrille Pitchen
2016-10-24 16:34 ` [PATCH v3 1/9] mtd: spi-nor: improve macronix_quad_enable() Cyrille Pitchen
2016-10-24 22:00   ` Marek Vasut
2016-10-25  8:52     ` Cyrille Pitchen
2016-10-25 14:49       ` Marek Vasut
2016-10-24 16:34 ` [PATCH v3 2/9] mtd: spi-nor: add an alternative method to support memory >16MiB Cyrille Pitchen
2016-10-24 22:10   ` Marek Vasut
2016-10-25  9:18     ` Cyrille Pitchen
2016-10-25 14:53       ` Marek Vasut
2016-10-31 18:51   ` Jagan Teki
2016-11-02 10:49     ` Cyrille Pitchen
2016-11-02 11:11       ` Jagan Teki
2016-11-02 13:34         ` Cyrille Pitchen
2016-10-24 16:34 ` [PATCH v3 3/9] mtd: spi-nor: add support of SPI protocols like SPI 1-2-2 and SPI 1-4-4 Cyrille Pitchen
2016-10-24 16:34 ` [PATCH v3 4/9] mtd: spi-nor: remove unused set_quad_mode() function Cyrille Pitchen
2016-10-24 16:34 ` [PATCH v3 5/9] mtd: m25p80: add support of dual and quad spi protocols to all commands Cyrille Pitchen
2016-10-24 22:15   ` Marek Vasut
2016-10-24 16:34 ` [PATCH v3 6/9] mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables Cyrille Pitchen
2016-10-24 16:34 ` [PATCH v3 7/9] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table Cyrille Pitchen
2016-10-24 16:34 ` [PATCH v3 8/9] mtd: spi-nor: add support to Macronix mx66l1g45g Cyrille Pitchen
2016-10-24 22:16   ` Marek Vasut
2016-10-25  9:39     ` Cyrille Pitchen
2016-10-25 14:58       ` Marek Vasut
2016-10-24 16:34 ` [PATCH v3 9/9] mtd: spi-nor: add support to SST sst26* QSPI memories Cyrille Pitchen
2016-10-24 22:17   ` Marek Vasut [this message]

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=ca306f33-2eb7-a268-49f3-9b515a04f318@denx.de \
    --to=marex@denx.de \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nicolas.ferre@atmel.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.