From: Tom Rini <trini@konsulko.com>
To: kory.maincent@bootlin.com
Cc: u-boot@lists.denx.de, thomas.petazzoni@bootlin.com,
miquel.raynal@bootlin.com,
"Patrice Chotard" <patrice.chotard@foss.st.com>,
"Wolfgang Denk" <wd@denx.de>, "Pali Rohár" <pali@kernel.org>,
"Simon Glass" <sjg@chromium.org>,
"Marek Behún" <marek.behun@nic.cz>
Subject: Re: [PATCH v2] mtd: rawnand: Add support to dedicated function to set timings
Date: Fri, 8 Jul 2022 12:39:08 -0400 [thread overview]
Message-ID: <20220708163908.GI1146598@bill-the-cat> (raw)
In-Reply-To: <20220622091145.1207923-1-kory.maincent@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]
On Wed, Jun 22, 2022 at 11:11:45AM +0200, kory.maincent@bootlin.com wrote:
> From: Kory Maincent <kory.maincent@bootlin.com>
>
> With the current code if the board has an ONFI compliant NAND without
> support to the get and set features, U-boot returns an ENOTSUP error when
> trying to tune the timings which prevents the probe of the device.
> Indeed onfi_set_features() return ENOTSUP error if set/get features is not
> supported. In the case of timings we should not return ENOTSUP because we
> can use the default timings. The NAND is already capable of listening at
> its highest supported rate, so we assume in this case that it is fine to
> skip the operation.
>
> Fix it by adding an intermediate nand_onfi_set_timings() function which
> does not error out if set/get feature is not supported.
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to u-boot/next, thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2022-07-08 16:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 9:11 [PATCH v2] mtd: rawnand: Add support to dedicated function to set timings kory.maincent
2022-06-24 18:09 ` Miquel Raynal
2022-07-08 16:39 ` Tom Rini [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=20220708163908.GI1146598@bill-the-cat \
--to=trini@konsulko.com \
--cc=kory.maincent@bootlin.com \
--cc=marek.behun@nic.cz \
--cc=miquel.raynal@bootlin.com \
--cc=pali@kernel.org \
--cc=patrice.chotard@foss.st.com \
--cc=sjg@chromium.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=u-boot@lists.denx.de \
--cc=wd@denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.