From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Hector Palacios <hector.palacios@digi.com>
Cc: herve.codina@bootlin.com, sashal@kernel.org,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH] nand_base: force best_mode to be >= 0
Date: Thu, 23 Feb 2023 08:51:56 +0100 [thread overview]
Message-ID: <20230223085156.76fade4e@xps-13> (raw)
In-Reply-To: <20230222152510.1064332-1-hector.palacios@digi.com>
Hi Hector,
hector.palacios@digi.com wrote on Wed, 22 Feb 2023 16:25:10 +0100:
> According to the ONFI specification, bit 0 of 'SDR timing mode support'
> (bytes 129-130) "shall be 1". That means the NAND supports at least
> timing mode 0.
>
> NAND chip Hynix H27U4G8F2GDA-BI (at least) is reading a 0 on this field
> which makes best_mode = -1 and the following loop be skipped. An error
> code is returned upstream and the NAND probe fails.
>
> Given that sdr_timing_modes *must* be 1 by specification, force best_mode
> to be 1 at least, so that this function doesn't return an error on a NAND
> that can work with such timings despite reporting an incorrect ONFI value.
Thanks for the patch!
>
> Signed-off-by: Hector Palacios <hector.palacios@digi.com>
> ---
> drivers/mtd/nand/raw/nand_base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index c3cc66039925..474850e4455c 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -947,7 +947,7 @@ int nand_choose_best_sdr_timings(struct nand_chip *chip,
> /* Fallback to slower modes */
> best_mode = iface->timings.mode;
> } else if (chip->parameters.onfi) {
> - best_mode = fls(chip->parameters.onfi->sdr_timing_modes) - 1;
> + best_mode = fls(chip->parameters.onfi->sdr_timing_modes | 1) - 1;
I fully understand the problem and how you propose to solve it but I am
a bit hesitating. I would rather prefer a per-chip/per-manufacturer fix
rather than a global solution, just because we don't really know
whether an apparently ONFI compatible device will support that mode (or
we should at least tell the user about it). Maybe reads work but not
writes? (Or not all of them?). And in general, I would prefer to keep
the core "tidy" (well, mtd contains a lot of legacy code, but you see
what I mean) and prevent "undesired" behavior by fixing what's
considered wrong in manufacturer code.
I would rather go for a fix of the parameter page in nand_hynix.c,
either in the .init() hook or in the .fixup_onfi_param_page()
depending of what is most appropriate. You can probably use a
comparison with the model string to target your specific device for
now. Here are two different ways of handling such issues:
- https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_macronix.c#L148
- https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_micron.c#L598
Please don't forget to add a comment explaining why this is a safe
assumption, also please use "BIT(0)" rather than "1" (we don't write an
integer but just add a missing bit, that's the rationale).
> }
>
> for (mode = best_mode; mode >= 0; mode--) {
Cheers,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-02-23 7:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 15:25 [PATCH] nand_base: force best_mode to be >= 0 Hector Palacios
2023-02-23 7:51 ` Miquel Raynal [this message]
2023-02-23 10:56 ` Hector Palacios
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=20230223085156.76fade4e@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=hector.palacios@digi.com \
--cc=herve.codina@bootlin.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sashal@kernel.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