From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
To: barebox@lists.infradead.org
Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Subject: [PATCH v2] mtd: return EOPNOTSUPP when attempting to erase an MTD_NO_ERASE device
Date: Fri, 23 Nov 2018 15:50:15 +0100 [thread overview]
Message-ID: <20181123145015.20623-1-matthias.schiffer@ew.tq-group.com> (raw)
In-Reply-To: <20181123080522.5vwc4makxbhycscq@pengutronix.de>
At least some MTD_NO_ERASE devices like MRAM do not specify a sensible
erase block size; instead, erasesize is equal to the whole flash size. This
leads to an EINVAL return from mtd_erase_align() whenever a partial erase
is attempted.
At least on the MRAM I tested, a full flash erase did not return an error,
but it did not have any effect on the flash either. As erase seems to be
entirely unsupported on this class of devices, and it is not necessary
anyways, it's better to return early with EOPNOTSUPP.
This fixes envfs_save() on a partitioned MRAM.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
---
v2: handle in mtd_op_erase() instead of envfs_save()
drivers/mtd/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/core.c b/drivers/mtd/core.c
index 56e85b3d8..d3cbe502f 100644
--- a/drivers/mtd/core.c
+++ b/drivers/mtd/core.c
@@ -178,6 +178,9 @@ static int mtd_op_erase(struct cdev *cdev, loff_t count, loff_t offset)
loff_t addr;
int ret;
+ if (mtd->flags & MTD_NO_ERASE)
+ return -EOPNOTSUPP;
+
ret = mtd_erase_align(mtd, &count, &offset);
if (ret)
return ret;
--
2.17.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-11-23 14:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 9:40 [PATCH] clk: fix NULL deref without OF node in debug message matthias.schiffer
2018-11-20 9:40 ` [PATCH] environment: do not attempt to erase devices with MTD_NO_ERASE matthias.schiffer
2018-11-21 7:56 ` Sascha Hauer
2018-11-22 10:19 ` Matthias Schiffer
2018-11-23 8:05 ` Sascha Hauer
2018-11-23 14:50 ` Matthias Schiffer [this message]
2018-11-26 7:46 ` [PATCH v2] mtd: return EOPNOTSUPP when attempting to erase an MTD_NO_ERASE device Sascha Hauer
2018-11-20 9:40 ` [PATCH] FIT: look for hash-1 as well as hash@1 nodes in signature check matthias.schiffer
2018-11-21 8:01 ` Sascha Hauer
2018-11-22 10:41 ` [PATCH v2] FIT: support hash-1/signature-1 " Matthias Schiffer
2018-11-23 8:07 ` [PATCH] clk: fix NULL deref without OF node in debug message Sascha Hauer
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=20181123145015.20623-1-matthias.schiffer@ew.tq-group.com \
--to=matthias.schiffer@ew.tq-group.com \
--cc=barebox@lists.infradead.org \
/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