From: Boris Brezillon <boris.brezillon@collabora.com>
To: <Tudor.Ambarus@microchip.com>
Cc: vigneshr@ti.com, richard@nod.at, linux-kernel@vger.kernel.org,
marek.vasut@gmail.com, linux-mtd@lists.infradead.org,
miquel.raynal@bootlin.com
Subject: Re: [PATCH v2 7/7] mtd: spi-nor: Rework the disabling of block write protection
Date: Sun, 25 Aug 2019 14:24:21 +0200 [thread overview]
Message-ID: <20190825142421.35d31a9b@collabora.com> (raw)
In-Reply-To: <20190824120027.14452-8-tudor.ambarus@microchip.com>
On Sat, 24 Aug 2019 12:00:48 +0000
<Tudor.Ambarus@microchip.com> wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> Get rid of MFR handling and implement specific manufacturer
> default_init() fixup hooks.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 30 ++++++++++++++++++++----------
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index fc9e14777212..f4e9fcca619f 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -4146,6 +4146,16 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> return err;
> }
>
> +static void atmel_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.disable_block_protection = spi_nor_clear_sr_bp;
> +}
> +
> +static void intel_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.disable_block_protection = spi_nor_clear_sr_bp;
That's weird: you can unlock blocks but locking is not
explicitly flagged as supported (SNOR_F_HAS_LOCK is not set). Is that
expected?
> +}
> +
> static void macronix_set_default_init(struct spi_nor *nor)
> {
> nor->params.quad_enable = macronix_quad_enable;
> @@ -4173,6 +4183,14 @@ static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
> {
> /* Init flash parameters based on MFR */
> switch (JEDEC_MFR(nor->info)) {
> + case SNOR_MFR_ATMEL:
> + atmel_set_default_init(nor);
> + break;
> +
> + case SNOR_MFR_INTEL:
> + intel_set_default_init(nor);
> + break;
> +
> case SNOR_MFR_MACRONIX:
> macronix_set_default_init(nor);
> break;
> @@ -4760,18 +4778,10 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> if (info->flags & SPI_S3AN)
> nor->flags |= SNOR_F_READY_XSR_RDY;
>
> - if (info->flags & SPI_NOR_HAS_LOCK)
> + if (info->flags & SPI_NOR_HAS_LOCK) {
If this flag implies SR_BP-based locking we should really rename it into
SPI_NOR_HAS_SR_BP_LOCK to avoid any confusion.
> nor->flags |= SNOR_F_HAS_LOCK;
> -
> - /*
> - * Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
> - * with the software protection bits set.
> - */
> - if (JEDEC_MFR(nor->info) == SNOR_MFR_ATMEL ||
> - JEDEC_MFR(nor->info) == SNOR_MFR_INTEL ||
> - JEDEC_MFR(nor->info) == SNOR_MFR_SST ||
> - nor->info->flags & SPI_NOR_HAS_LOCK)
> nor->params.disable_block_protection = spi_nor_clear_sr_bp;
> + }
>
> /* Init flash parameters based on flash_info struct and SFDP */
> spi_nor_init_params(nor);
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: <Tudor.Ambarus@microchip.com>
Cc: <marek.vasut@gmail.com>, <vigneshr@ti.com>,
<miquel.raynal@bootlin.com>, <richard@nod.at>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 7/7] mtd: spi-nor: Rework the disabling of block write protection
Date: Sun, 25 Aug 2019 14:24:21 +0200 [thread overview]
Message-ID: <20190825142421.35d31a9b@collabora.com> (raw)
In-Reply-To: <20190824120027.14452-8-tudor.ambarus@microchip.com>
On Sat, 24 Aug 2019 12:00:48 +0000
<Tudor.Ambarus@microchip.com> wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> Get rid of MFR handling and implement specific manufacturer
> default_init() fixup hooks.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 30 ++++++++++++++++++++----------
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index fc9e14777212..f4e9fcca619f 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -4146,6 +4146,16 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> return err;
> }
>
> +static void atmel_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.disable_block_protection = spi_nor_clear_sr_bp;
> +}
> +
> +static void intel_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.disable_block_protection = spi_nor_clear_sr_bp;
That's weird: you can unlock blocks but locking is not
explicitly flagged as supported (SNOR_F_HAS_LOCK is not set). Is that
expected?
> +}
> +
> static void macronix_set_default_init(struct spi_nor *nor)
> {
> nor->params.quad_enable = macronix_quad_enable;
> @@ -4173,6 +4183,14 @@ static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
> {
> /* Init flash parameters based on MFR */
> switch (JEDEC_MFR(nor->info)) {
> + case SNOR_MFR_ATMEL:
> + atmel_set_default_init(nor);
> + break;
> +
> + case SNOR_MFR_INTEL:
> + intel_set_default_init(nor);
> + break;
> +
> case SNOR_MFR_MACRONIX:
> macronix_set_default_init(nor);
> break;
> @@ -4760,18 +4778,10 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> if (info->flags & SPI_S3AN)
> nor->flags |= SNOR_F_READY_XSR_RDY;
>
> - if (info->flags & SPI_NOR_HAS_LOCK)
> + if (info->flags & SPI_NOR_HAS_LOCK) {
If this flag implies SR_BP-based locking we should really rename it into
SPI_NOR_HAS_SR_BP_LOCK to avoid any confusion.
> nor->flags |= SNOR_F_HAS_LOCK;
> -
> - /*
> - * Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
> - * with the software protection bits set.
> - */
> - if (JEDEC_MFR(nor->info) == SNOR_MFR_ATMEL ||
> - JEDEC_MFR(nor->info) == SNOR_MFR_INTEL ||
> - JEDEC_MFR(nor->info) == SNOR_MFR_SST ||
> - nor->info->flags & SPI_NOR_HAS_LOCK)
> nor->params.disable_block_protection = spi_nor_clear_sr_bp;
> + }
>
> /* Init flash parameters based on flash_info struct and SFDP */
> spi_nor_init_params(nor);
next prev parent reply other threads:[~2019-08-25 12:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-24 12:00 [PATCH v2 0/7] mtd: spi-nor: move manuf out of the core - batch 1 Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-24 12:00 ` [PATCH v2 1/7] mtd: spi-nor: Add default_init() hook to tweak flash parameters Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-24 12:00 ` [PATCH v2 2/7] mtd: spi-nor: Add a default_init() fixup hook for gd25q256 Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-24 12:00 ` [PATCH v2 3/7] mtd: spi_nor: Move manufacturer quad_enable() in ->default_init() Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-25 11:47 ` Boris Brezillon
2019-08-25 11:47 ` Boris Brezillon
2019-08-25 13:08 ` Tudor.Ambarus
2019-08-25 13:08 ` Tudor.Ambarus
2019-08-24 12:00 ` [PATCH v2 4/7] mtd: spi-nor: Split spi_nor_init_params() Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-25 12:03 ` Boris Brezillon
2019-08-25 12:03 ` Boris Brezillon
2019-08-25 12:23 ` Tudor.Ambarus
2019-08-25 12:23 ` Tudor.Ambarus
2019-08-25 12:51 ` Boris Brezillon
2019-08-25 12:51 ` Boris Brezillon
2019-08-24 12:00 ` [PATCH v2 5/7] mtd: spi-nor: Create a ->set_4byte() method Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-24 12:00 ` [PATCH v2 6/7] mtd: spi-nor: Rework the SPI NOR lock/unlock logic Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-25 12:26 ` Boris Brezillon
2019-08-25 12:26 ` Boris Brezillon
2019-08-25 13:10 ` Tudor.Ambarus
2019-08-25 13:10 ` Tudor.Ambarus
2019-08-24 12:00 ` [PATCH v2 7/7] mtd: spi-nor: Rework the disabling of block write protection Tudor.Ambarus
2019-08-24 12:00 ` Tudor.Ambarus
2019-08-25 12:24 ` Boris Brezillon [this message]
2019-08-25 12:24 ` Boris Brezillon
2019-08-25 12:57 ` Tudor.Ambarus
2019-08-25 12:57 ` Tudor.Ambarus
2019-08-25 13:22 ` Boris Brezillon
2019-08-25 13:22 ` 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=20190825142421.35d31a9b@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.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.