From: "André Przywara" <andre.przywara@arm.com>
To: u-boot@lists.denx.de
Subject: [PATCH] nvme: add cache flush in get/set_features
Date: Fri, 26 Feb 2021 15:22:32 +0000 [thread overview]
Message-ID: <52e8d653-c05a-e6a8-65c6-1571f426aab1@arm.com> (raw)
In-Reply-To: <20210226141318.3882733-1-narmstrong@baylibre.com>
On 26/02/2021 14:13, Neil Armstrong wrote:
Hi,
> On Amlogic G12A platforms, the NVME probe timeouts at get/set_feature(),
> adding a cache flush solves the timeout.
I am puzzled how this is supposed to work ...
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/nvme/nvme.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 5d6331ad34..44c00a0309 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -487,11 +487,11 @@ int nvme_get_features(struct nvme_dev *dev, unsigned fid, unsigned nsid,
> c.features.nsid = cpu_to_le32(nsid);
> c.features.prp1 = cpu_to_le64(dma_addr);
> c.features.fid = cpu_to_le32(fid);
> -
> /*
> - * TODO: add cache invalidate operation when the size of
> + * TODO: add better cache invalidate operation when the size of
> * the DMA buffer is known
> */
> + invalidate_dcache_all();
Why is this? Isn't it totally dangerous, because we kill all the
information in dirty cache lines? We have extra checks in place to
prevent invalidating extra cache lines, when invalidating a single
buffer, but this is blanketly killing all of the cache?
And just ignoring for a minute that cache operations by set/way are
mostly wrong anyway? They are just meant to initialise the cache after
power state changes.
But more importantly: I don't see a single user of nvme_get_features()
in the tree? So this would never be called?
>
> return nvme_submit_admin_cmd(dev, &c, result);
> }
> @@ -508,9 +508,10 @@ int nvme_set_features(struct nvme_dev *dev, unsigned fid, unsigned dword11,
> c.features.dword11 = cpu_to_le32(dword11);
>
> /*
> - * TODO: add cache flush operation when the size of
> + * TODO: add better cache flush operation when the size of
> * the DMA buffer is known
> */
> + invalidate_dcache_all();
Same comment as above, first part: Dangerous and mostly wrong.
Besides: the comment speaks of "flush", not invalidate. So would be
extra wrong.
Also: there is exactly one caller in the whole tree, in this very same
file. And this one is passing a dma_addr of 0, apparently because it
doesn't actually use any buffer, instead passes the single piece of
information (the queue count) in the dword11 field.
So how is this supposed to work?
And if this seems to fix something, how?
Cheers,
Andre
>
> return nvme_submit_admin_cmd(dev, &c, result);
> }
>
next prev parent reply other threads:[~2021-02-26 15:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 14:13 [PATCH] nvme: add cache flush in get/set_features Neil Armstrong
2021-02-26 14:20 ` Bin Meng
2021-02-26 15:22 ` André Przywara [this message]
2021-02-26 16:11 ` Neil Armstrong
2021-03-02 15:44 ` Andre Przywara
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=52e8d653-c05a-e6a8-65c6-1571f426aab1@arm.com \
--to=andre.przywara@arm.com \
--cc=u-boot@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox