All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <vigneshr@ti.com>, <richard@nod.at>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	<Kavyasree.Kotagiri@microchip.com>, <miquel.raynal@bootlin.com>
Subject: Re: [PATCH 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
Date: Wed, 20 Jan 2021 13:02:21 +0000	[thread overview]
Message-ID: <fb42e33b-2ad2-9607-0540-138bfd70c9ba@microchip.com> (raw)
In-Reply-To: <20210120122940.2xkiwghtszzyylnm@ti.com>

On 1/20/21 2:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Tudor,
> 
> On 20/01/21 12:54PM, Tudor Ambarus wrote:
>> Even if sst26vf shares the SPINOR_OP_GBULK opcode with
>> Macronix (ex. MX25U12835F) and Winbound (ex. W25Q128FV),
>> it has its own Individual Block Protection scheme, which
>> is also capable to read-lock individual parameter blocks.
>> Thus the sst26vf's Individual Block Protection scheme will
>> reside in the sst.c manufacturer driver.
>>
>> Add support to unlock the entire flash memory. The device
>> is write-protected by default after a power-on reset cycle
>> (volatile software protection), in order to avoid inadvertent
>> writes during power-up. Could do an erase, write, read back,
>> and compare when MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>>  drivers/mtd/spi-nor/sst.c | 38 ++++++++++++++++++++++++++++++++++++--
>>  1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> index 00e48da0744a..1cd2a360c41e 100644
>> --- a/drivers/mtd/spi-nor/sst.c
>> +++ b/drivers/mtd/spi-nor/sst.c
>> @@ -8,6 +8,39 @@
>>
>>  #include "core.h"
>>
>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> +     return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> +     if (!ofs && len == nor->params->size)
> 
> Nitpick: ofs is not a boolean value. Don't treat it as such. (ofs == 0
> && len == nor->params->size) makes the intent much clearer.

I agree, will change. Cheers,
ta

> 
>> +             return spi_nor_global_block_unlock(nor);
>> +
>> +     return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> +     return -EOPNOTSUPP;
>> +}
>> +
>> +static const struct spi_nor_locking_ops sst26vf_locking_ops = {
>> +     .lock = sst26vf_lock,
>> +     .unlock = sst26vf_unlock,
>> +     .is_locked = sst26vf_is_locked,
>> +};
>> +
>> +static void sst26vf_default_init(struct spi_nor *nor)
>> +{
>> +     nor->params->locking_ops = &sst26vf_locking_ops;
>> +}
>> +
>> +static const struct spi_nor_fixups sst26vf_fixups = {
>> +     .default_init = sst26vf_default_init,
>> +};
>> +
>>  static const struct flash_info sst_parts[] = {
>>       /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>       { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8,
>> @@ -39,8 +72,9 @@ static const struct flash_info sst_parts[] = {
>>       { "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32,
>>                             SECT_4K | SPI_NOR_DUAL_READ) },
>>       { "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128,
>> -                           SECT_4K | SPI_NOR_DUAL_READ |
>> -                           SPI_NOR_QUAD_READ) },
>> +                           SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
>> +                           SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> +             .fixups = &sst26vf_fixups },
>>  };
>>
>>  static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
>> --
>> 2.25.1
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> --
> Regards,
> Pratyush Yadav
> Texas Instruments India
> 


WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: vigneshr@ti.com, richard@nod.at, linux-kernel@vger.kernel.org,
	michael@walle.cc, linux-mtd@lists.infradead.org,
	Kavyasree.Kotagiri@microchip.com, miquel.raynal@bootlin.com
Subject: Re: [PATCH 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
Date: Wed, 20 Jan 2021 13:02:21 +0000	[thread overview]
Message-ID: <fb42e33b-2ad2-9607-0540-138bfd70c9ba@microchip.com> (raw)
In-Reply-To: <20210120122940.2xkiwghtszzyylnm@ti.com>

On 1/20/21 2:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Tudor,
> 
> On 20/01/21 12:54PM, Tudor Ambarus wrote:
>> Even if sst26vf shares the SPINOR_OP_GBULK opcode with
>> Macronix (ex. MX25U12835F) and Winbound (ex. W25Q128FV),
>> it has its own Individual Block Protection scheme, which
>> is also capable to read-lock individual parameter blocks.
>> Thus the sst26vf's Individual Block Protection scheme will
>> reside in the sst.c manufacturer driver.
>>
>> Add support to unlock the entire flash memory. The device
>> is write-protected by default after a power-on reset cycle
>> (volatile software protection), in order to avoid inadvertent
>> writes during power-up. Could do an erase, write, read back,
>> and compare when MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>>  drivers/mtd/spi-nor/sst.c | 38 ++++++++++++++++++++++++++++++++++++--
>>  1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> index 00e48da0744a..1cd2a360c41e 100644
>> --- a/drivers/mtd/spi-nor/sst.c
>> +++ b/drivers/mtd/spi-nor/sst.c
>> @@ -8,6 +8,39 @@
>>
>>  #include "core.h"
>>
>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> +     return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> +     if (!ofs && len == nor->params->size)
> 
> Nitpick: ofs is not a boolean value. Don't treat it as such. (ofs == 0
> && len == nor->params->size) makes the intent much clearer.

I agree, will change. Cheers,
ta

> 
>> +             return spi_nor_global_block_unlock(nor);
>> +
>> +     return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> +     return -EOPNOTSUPP;
>> +}
>> +
>> +static const struct spi_nor_locking_ops sst26vf_locking_ops = {
>> +     .lock = sst26vf_lock,
>> +     .unlock = sst26vf_unlock,
>> +     .is_locked = sst26vf_is_locked,
>> +};
>> +
>> +static void sst26vf_default_init(struct spi_nor *nor)
>> +{
>> +     nor->params->locking_ops = &sst26vf_locking_ops;
>> +}
>> +
>> +static const struct spi_nor_fixups sst26vf_fixups = {
>> +     .default_init = sst26vf_default_init,
>> +};
>> +
>>  static const struct flash_info sst_parts[] = {
>>       /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>       { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8,
>> @@ -39,8 +72,9 @@ static const struct flash_info sst_parts[] = {
>>       { "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32,
>>                             SECT_4K | SPI_NOR_DUAL_READ) },
>>       { "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128,
>> -                           SECT_4K | SPI_NOR_DUAL_READ |
>> -                           SPI_NOR_QUAD_READ) },
>> +                           SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
>> +                           SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> +             .fixups = &sst26vf_fixups },
>>  };
>>
>>  static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
>> --
>> 2.25.1
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> --
> Regards,
> Pratyush Yadav
> Texas Instruments India
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-01-20 14:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 10:54 [PATCH 1/2] mtd: spi-nor: Add Global Block Unlock command Tudor Ambarus
2021-01-20 10:54 ` Tudor Ambarus
2021-01-20 10:54 ` [PATCH 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf Tudor Ambarus
2021-01-20 10:54   ` Tudor Ambarus
2021-01-20 12:29   ` Pratyush Yadav
2021-01-20 12:29     ` Pratyush Yadav
2021-01-20 13:02     ` Tudor.Ambarus [this message]
2021-01-20 13:02       ` Tudor.Ambarus
2021-01-20 12:29 ` [PATCH 1/2] mtd: spi-nor: Add Global Block Unlock command Pratyush Yadav
2021-01-20 12:29   ` Pratyush Yadav
2021-01-20 13:01   ` Tudor.Ambarus
2021-01-20 13:01     ` Tudor.Ambarus

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=fb42e33b-2ad2-9607-0540-138bfd70c9ba@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Kavyasree.Kotagiri@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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.