linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tudor Ambarus <tudor.ambarus@microchip.com>
To: <michael@walle.cc>, <p.yadav@ti.com>
Cc: macromorgan@hotmail.com, vigneshr@ti.com,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	jaimeliao@mxic.com.tw, richard@nod.at, esben@geanix.com,
	linux@rasmusvillemoes.dk, knaerzche@gmail.com,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, code@reto-schneider.ch,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com, sr@denx.de,
	figgyc@figgyc.uk, mail@david-bauer.net, zhengxunli@mxic.com.tw
Subject: [PATCH v5 08/14] mtd: spi-nor: Introduce spi_nor_init_fixup_flags()
Date: Fri, 3 Dec 2021 16:22:50 +0200	[thread overview]
Message-ID: <20211203142256.47370-9-tudor.ambarus@microchip.com> (raw)
In-Reply-To: <20211203142256.47370-1-tudor.ambarus@microchip.com>

Group NOR flags initialization. Introduce a dedicated function for
setting the fixup_flags and emphasise when those flash_info flags
should be set: when the SNOR_F_4B_OPCODES/SNOR_F_IO_MODE_EN_VOLATILE
setttings can not be discovered by SFDP for this particular flash
because the SFDP table that indicates this support is not defined
in the flash.
In case the table for his support is defined but has wrong values,
one should instead use a post_sfdp() hook to set the SNOR_F equivalent
flag.

No functional change intended in this patch.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
---
 drivers/mtd/spi-nor/core.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 1ac7e8de4b8e..86bbd1ca22fc 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2692,6 +2692,25 @@ static void spi_nor_init_flags(struct spi_nor *nor)
 		nor->flags |=  SNOR_F_READY_XSR_RDY;
 }
 
+/**
+ * spi_nor_init_fixup_flags() - Initialize NOR flags for settings that can not
+ * be discovered by SFDP for this particular flash because the SFDP table that
+ * indicates this support is not defined in the flash. In case the table for
+ * this support is defined but has wrong values, one should instead use a
+ * post_sfdp() hook to set the SNOR_F equivalent flag.
+ * @nor:       pointer to a 'struct spi_nor'
+ */
+static void spi_nor_init_fixup_flags(struct spi_nor *nor)
+{
+	const u8 fixup_flags = nor->info->fixup_flags;
+
+	if (fixup_flags & SPI_NOR_4B_OPCODES)
+		nor->flags |= SNOR_F_4B_OPCODES;
+
+	if (fixup_flags & SPI_NOR_IO_MODE_EN_VOLATILE)
+		nor->flags |= SNOR_F_IO_MODE_EN_VOLATILE;
+}
+
 /**
  * spi_nor_late_init_params() - Late initialization of default flash parameters.
  * @nor:	pointer to a 'struct spi_nor'
@@ -2710,6 +2729,7 @@ static void spi_nor_late_init_params(struct spi_nor *nor)
 		nor->info->fixups->late_init(nor);
 
 	spi_nor_init_flags(nor);
+	spi_nor_init_fixup_flags(nor);
 
 	/*
 	 * NOR protection support. When locking_ops are not provided, we pick
@@ -3147,7 +3167,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
 	struct mtd_info *mtd = &nor->mtd;
 	int ret;
 	int i;
-	u8 fixup_flags;
 
 	ret = spi_nor_check(nor);
 	if (ret)
@@ -3197,13 +3216,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
 	if (ret)
 		return ret;
 
-	fixup_flags = info->fixup_flags;
-	if (fixup_flags & SPI_NOR_4B_OPCODES)
-		nor->flags |= SNOR_F_4B_OPCODES;
-
-	if (fixup_flags & SPI_NOR_IO_MODE_EN_VOLATILE)
-		nor->flags |= SNOR_F_IO_MODE_EN_VOLATILE;
-
 	ret = spi_nor_set_addr_width(nor);
 	if (ret)
 		return ret;
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-12-03 14:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 14:22 [PATCH v5 00/14] mtd: spi-nor: Clean params init Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 01/14] mtd: spi-nor: Fix mtd size for s3an flashes Tudor Ambarus
2021-12-06 11:54   ` Pratyush Yadav
2021-12-06 14:40     ` Tudor.Ambarus
2021-12-03 14:22 ` [PATCH v5 02/14] mtd: spi-nor: core: Don't use mtd_info in the NOR's probe sequence of calls Tudor Ambarus
2021-12-06 11:55   ` Pratyush Yadav
2021-12-03 14:22 ` [PATCH v5 03/14] mtd: spi-nor: Introduce spi_nor_set_mtd_info() Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 04/14] mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 05/14] mtd: spi-nor: core: Introduce flash_info mfr_flags Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 06/14] mtd: spi-nor: Rework the flash_info flags Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 07/14] mtd: spi-nor: Introduce spi_nor_init_flags() Tudor Ambarus
2021-12-03 14:22 ` Tudor Ambarus [this message]
2021-12-03 14:22 ` [PATCH v5 09/14] mtd: spi-nor: core: Init all flash parameters based on SFDP where possible Tudor Ambarus
2021-12-06 12:22   ` Pratyush Yadav
2021-12-06 13:52     ` Tudor.Ambarus
2021-12-06 15:04       ` Pratyush Yadav
2021-12-06 18:12         ` Tudor.Ambarus
2021-12-03 14:22 ` [PATCH v5 10/14] mtd: spi-nor: core: Move spi_nor_set_addr_width() in spi_nor_setup() Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 11/14] mtd: spi-nor: winbond: w25q256jvm: Init flash based on SFDP Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 12/14] mtd: spi-nor: spansion: s25fl256s0: Skip SFDP parsing Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 13/14] mtd: spi-nor: gigadevice: gd25q256: Init flash based on SFDP Tudor Ambarus
2021-12-03 14:22 ` [PATCH v5 14/14] mtd: spi-nor: issi: is25lp256: " Tudor Ambarus
2021-12-06 12:25 ` [PATCH v5 00/14] mtd: spi-nor: Clean params init Pratyush Yadav
2021-12-06 13:53   ` 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=20211203142256.47370-9-tudor.ambarus@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=code@reto-schneider.ch \
    --cc=esben@geanix.com \
    --cc=figgyc@figgyc.uk \
    --cc=heiko.thiery@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=knaerzche@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=macromorgan@hotmail.com \
    --cc=mail@david-bauer.net \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=sr@denx.de \
    --cc=vigneshr@ti.com \
    --cc=zhengxunli@mxic.com.tw \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).