From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <michael@walle.cc>, <linux-mtd@lists.infradead.org>
Cc: Julien Su <juliensu@mxic.com.tw>,
Jaime Liao <jaimeliao@mxic.com.tw>,
Jaime Liao <jaimeliao.tw@gmail.com>,
Alvin Zhou <alvinzhou@mxic.com.tw>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Michal Simek <monstr@monstr.eu>,
<linux-arm-kernel@lists.infradead.org>,
Miquel Raynal <miquel.raynal@bootlin.com>
Subject: [PATCH v5 5/8] mtd: spi-nor: Prepare the introduction of a new locking mechanism
Date: Tue, 28 Mar 2023 17:41:02 +0200 [thread overview]
Message-ID: <20230328154105.448540-6-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20230328154105.448540-1-miquel.raynal@bootlin.com>
This commit alone just introduces two new "prepare and lock" pairs of
helpers which do the exact same thing as before. They will soon be
improved in a followup commit which actually brings the logic, but I
figured out it was more readable to do it this way.
One new pair is suffixed _pe which stands for "program and erase" and
hence is being called by spi_nor_write() and spi_nor_erase().
The other pair is suffixed _rd which stands for "read" and hence is
being called by spi_nor_read().
One note however, these extra helpers will need to know the operation
range, so they come with two new parameters to define it. Otherwise
there is no functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/spi-nor/core.c | 59 ++++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index e80677d36a8c..daed09950ee1 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1086,6 +1086,7 @@ static void spi_nor_unprep(struct spi_nor *nor)
nor->controller_ops->unprepare(nor);
}
+/* Generic helpers for internal locking and serialization */
int spi_nor_prep_and_lock(struct spi_nor *nor)
{
int ret;
@@ -1106,6 +1107,48 @@ void spi_nor_unlock_and_unprep(struct spi_nor *nor)
spi_nor_unprep(nor);
}
+/* Internal locking helpers for program and erase operations */
+static int spi_nor_prep_and_lock_pe(struct spi_nor *nor, loff_t start, size_t len)
+{
+ int ret;
+
+ ret = spi_nor_prep(nor);
+ if (ret)
+ return ret;
+
+ mutex_lock(&nor->lock);
+
+ return 0;
+}
+
+static void spi_nor_unlock_and_unprep_pe(struct spi_nor *nor, loff_t start, size_t len)
+{
+ mutex_unlock(&nor->lock);
+
+ spi_nor_unprep(nor);
+}
+
+/* Internal locking helpers for read operations */
+static int spi_nor_prep_and_lock_rd(struct spi_nor *nor, loff_t start, size_t len)
+{
+ int ret;
+
+ ret = spi_nor_prep(nor);
+ if (ret)
+ return ret;
+
+ mutex_lock(&nor->lock);
+
+ return 0;
+}
+
+static void spi_nor_unlock_and_unprep_rd(struct spi_nor *nor, loff_t start, size_t len)
+{
+ mutex_unlock(&nor->lock);
+
+ spi_nor_unprep(nor);
+}
+
static u32 spi_nor_convert_addr(struct spi_nor *nor, loff_t addr)
{
if (!nor->params->convert_addr)
@@ -1459,7 +1502,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
addr = instr->addr;
len = instr->len;
- ret = spi_nor_prep_and_lock(nor);
+ ret = spi_nor_prep_and_lock_pe(nor, instr->addr, instr->len);
if (ret)
return ret;
@@ -1522,7 +1565,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
ret = spi_nor_write_disable(nor);
erase_err:
- spi_nor_unlock_and_unprep(nor);
+ spi_nor_unlock_and_unprep_pe(nor, instr->addr, instr->len);
return ret;
}
@@ -1715,11 +1758,13 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
+ loff_t from_lock = from;
+ size_t len_lock = len;
ssize_t ret;
dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
- ret = spi_nor_prep_and_lock(nor);
+ ret = spi_nor_prep_and_lock_rd(nor, from_lock, len_lock);
if (ret)
return ret;
@@ -1746,7 +1791,8 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
ret = 0;
read_err:
- spi_nor_unlock_and_unprep(nor);
+ spi_nor_unlock_and_unprep_rd(nor, from_lock, len_lock);
+
return ret;
}
@@ -1765,7 +1811,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
- ret = spi_nor_prep_and_lock(nor);
+ ret = spi_nor_prep_and_lock_pe(nor, to, len);
if (ret)
return ret;
@@ -1807,7 +1853,8 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
}
write_err:
- spi_nor_unlock_and_unprep(nor);
+ spi_nor_unlock_and_unprep_pe(nor, to, len);
+
return ret;
}
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-03-28 15:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 15:40 [PATCH v5 0/8] mtd: spi-nor: read while write support Miquel Raynal
2023-03-28 15:40 ` [PATCH v5 1/8] mtd: spi-nor: Introduce the concept of bank Miquel Raynal
2023-03-28 15:40 ` [PATCH v5 2/8] mtd: spi-nor: Add a macro to define more banks Miquel Raynal
2023-03-28 15:41 ` [PATCH v5 3/8] mtd: spi-nor: Reorder the preparation vs. locking steps Miquel Raynal
2023-03-28 15:41 ` [PATCH v5 4/8] mtd: spi-nor: Separate preparation and locking Miquel Raynal
2023-03-28 15:41 ` Miquel Raynal [this message]
2023-03-28 15:41 ` [PATCH v5 6/8] mtd: spi-nor: Add a RWW flag Miquel Raynal
2023-03-28 15:41 ` [PATCH v5 7/8] mtd: spi-nor: Enhance locking to support reads while writes Miquel Raynal
2023-03-28 15:41 ` [PATCH v5 8/8] mtd: spi-nor: macronix: Add support for mx25uw51245g with RWW Miquel Raynal
2023-03-28 16:31 ` Tudor Ambarus
2023-03-28 16:45 ` Miquel Raynal
2023-03-29 5:48 ` liao jaime
2023-03-29 11:12 ` Tudor Ambarus
2023-03-29 11:54 ` Miquel Raynal
2023-03-31 19:37 ` Miquel Raynal
2023-04-03 8:08 ` Tudor Ambarus
2023-03-29 10:49 ` Re (subset): [PATCH v5 0/8] mtd: spi-nor: read while write support 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=20230328154105.448540-6-miquel.raynal@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=alvinzhou@mxic.com.tw \
--cc=jaimeliao.tw@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=juliensu@mxic.com.tw \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=monstr@monstr.eu \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=thomas.petazzoni@bootlin.com \
--cc=tudor.ambarus@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox