From: Michael Walle <michael@walle.cc>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Tom Rini <trini@konsulko.com>,
Jagan Teki <jagan@amarulasolutions.com>,
chaochao2021666@163.com, Tudor.Ambarus@microchip.com,
vigneshr@ti.com, baocheng.su@siemens.com, le.jin@siemens.com,
u-boot@lists.denx.de, chao zeng <chao.zeng@siemens.com>
Subject: Re: [PATCH v4] sf: Query write-protection status before operating the flash
Date: Wed, 02 Feb 2022 09:21:02 +0100 [thread overview]
Message-ID: <f43192f8266c19073837aa0498ba33fd@walle.cc> (raw)
In-Reply-To: <6621668c-e9f0-f532-735f-f4bfbb8b00fc@siemens.com>
Am 2022-02-02 07:35, schrieb Jan Kiszka:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Do not suggest successful operation if a flash area to be changed is
> actually locked, thus will not execute the request. Rather report an
> error and bail out. That's way more user-friendly than asking them to
> manually check for this case.
>
> Derived from original patch by Chao Zeng.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>
> This is the successor of "[PATCH V3] sf: Querying write-protect status
> before operating the flash", moving the test into the CLI API, see
> https://lore.kernel.org/u-boot/20220117175628.GQ2631111@bill-the-cat/.
>
> cmd/sf.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/cmd/sf.c b/cmd/sf.c
> index 8bdebd9fd8f..a24e04c690b 100644
> --- a/cmd/sf.c
> +++ b/cmd/sf.c
> @@ -287,6 +287,12 @@ static int do_spi_flash_read_write(int argc, char
> *const argv[])
> return 1;
> }
>
> + if (strncmp(argv[0], "read", 4) != 0 && flash->flash_is_locked &&
> + flash->flash_is_locked(flash, offset, len)) {
> + printf("ERROR: flash area is locked\n");
> + return 1;
> + }
Much better to handle it here. But I'm not sure if this is doing
the right thing:
Eventually, this function is called:
/*
* Return 1 if the entire region is locked (if @locked is true) or
unlocked (if
* @locked is false); 0 otherwise
*/
static int stm_check_lock_status_sr(struct spi_nor *nor, loff_t ofs, u64
len,
u8 sr, bool locked)
So I'd guess if you try to write to an area of the flash where only
parts
are locked, you still see it as unlocked and thus there will be no
error.
Which IMHO is even more confusing for a user.
-michael
next prev parent reply other threads:[~2022-02-02 8:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-02 6:35 [PATCH v4] sf: Query write-protection status before operating the flash Jan Kiszka
2022-02-02 8:21 ` Michael Walle [this message]
2022-02-02 9:38 ` Jan Kiszka
2022-02-02 9:55 ` Michael Walle
2022-02-02 9:57 ` Jan Kiszka
2022-02-04 12:55 ` Jan Kiszka
2022-02-07 12:43 ` Michael Walle
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=f43192f8266c19073837aa0498ba33fd@walle.cc \
--to=michael@walle.cc \
--cc=Tudor.Ambarus@microchip.com \
--cc=baocheng.su@siemens.com \
--cc=chao.zeng@siemens.com \
--cc=chaochao2021666@163.com \
--cc=jagan@amarulasolutions.com \
--cc=jan.kiszka@siemens.com \
--cc=le.jin@siemens.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--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