From: Pratyush Yadav <pratyush@kernel.org>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: sudip.mukherjee@sifive.com, michael@walle.cc,
linux-mtd@lists.infradead.org,
Tudor Ambarus <tudor.ambarus@gmail.com>
Subject: Re: [PATCH] mtd: spi-nor: core: Update documentation for info->fixup_flags
Date: Fri, 19 Aug 2022 01:24:14 +0530 [thread overview]
Message-ID: <20220818195414.r5qwhsxb7hrij5e5@yadavpratyush.com> (raw)
In-Reply-To: <20220810155924.1366072-1-tudor.ambarus@microchip.com>
Hi,
On 10/08/22 06:59PM, Tudor Ambarus wrote:
> From: Tudor Ambarus <tudor.ambarus@gmail.com>
>
> fixup_flags should be used when the flash defines the mandatory BFPT
> table, but doesn't define an optional SFDP table from which a
> particular flash parameters is discovered.
>
> Reported-by: Sudip Mukherjee <sudip.mukherjee@sifive.com>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@gmail.com>
> ---
> drivers/mtd/spi-nor/core.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 3f841ec36e56..b87d61a105f7 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -466,10 +466,10 @@ struct spi_nor_fixups {
> *
> * @fixup_flags: flags that indicate support that can be discovered via SFDP
> * ideally, but can not be discovered for this particular flash
> - * because the SFDP table that indicates this support is not
> - * defined by 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.
> + * because the optional SFDP table that indicates this support
> + * is not defined by 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.
Not sure if it makes much of a difference adding just the word
"optional". It might be better to explicitly state that it is used when
the flash defines the mandatory tables but not the optional ones, like
you do in the commit message.
Anyway, I don't think we should spend too many cycles on this relatively
trivial patch, so either way is fine by me.
> *
> * SPI_NOR_4B_OPCODES: use dedicated 4byte address op codes to support
> * memory size above 128Mib.
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2022-08-18 19:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 15:59 [PATCH] mtd: spi-nor: core: Update documentation for info->fixup_flags Tudor Ambarus
2022-08-11 7:56 ` Michael Walle
2022-08-18 19:54 ` Pratyush Yadav [this message]
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=20220818195414.r5qwhsxb7hrij5e5@yadavpratyush.com \
--to=pratyush@kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=sudip.mukherjee@sifive.com \
--cc=tudor.ambarus@gmail.com \
--cc=tudor.ambarus@microchip.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;
as well as URLs for NNTP newsgroup(s).