public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH] nvme: Fix cache alignment
Date: Mon, 8 Feb 2021 16:51:31 +0100	[thread overview]
Message-ID: <28e3d6b0-0e32-1007-683b-07374874ff92@gmail.com> (raw)
In-Reply-To: <CAEUhbmX6m0mMf937TD6x7aQfk3qQ6dgJ=nAO8pgwTbO+ddcLEg@mail.gmail.com>

On 2/8/21 4:11 PM, Bin Meng wrote:
[...]
>> As I said: I don't see how this patch changes anything on arm64, which
>> the commit messages claims to be the reason for this post.
>> If someone please can confirm, but invalidate_dcache_range() always
>> works on arm64, in fact does the very rounding already that this patch
>> introduces here. So what is the actual fix here?
>>
>> Plus, I consider this blanket rounding more harmful than helpful, since
>> it actually just silences the check_cache_range() check.
>>
>> If we include armv7 here, which in fact would ignore(!) an unaligned
>> invalidate, this is my analysis (just for invalidate):
>> nvme_read_completion_status():          NEEDS ALIGNMENT
>>          size smaller than cache line, cqes[1] base address unaligned.
>>          fix needed, rounding *could* be a temporary fix with comments
>>          as of why this is legitimate in this case.
>>          Better alternative sketched in a previous email.
> 
> This is exactly what I mentioned before [1]. The only problematic
> routine is the nvme_read_completion_status() but I didn't have time to
> experiment with a fix.

I believe it is better to have one single function to handle all the 
cache alignment and operations in the driver instead of having copy of 
the same alignment thing all over the driver.
[...]

  reply	other threads:[~2021-02-08 15:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30 17:53 [PATCH] nvme: Fix cache alignment Marek Vasut
2021-02-02  3:55 ` Bin Meng
2021-02-02  8:05   ` Marek Vasut
2021-02-02  8:54     ` Bin Meng
2021-02-02  9:04       ` Marek Vasut
2021-02-02  9:12         ` Bin Meng
2021-02-02 16:09           ` Marek Vasut
2021-02-02 13:04   ` Andre Przywara
2021-02-02 16:08     ` Marek Vasut
2021-02-02 16:23   ` Andre Przywara
2021-02-02 21:18     ` Marek Vasut
2021-02-03 10:42       ` Andre Przywara
2021-02-03 13:08         ` Marek Vasut
2021-02-04 10:26           ` Andre Przywara
2021-02-04 16:57             ` Tom Rini
2021-02-07 18:20               ` Marek Vasut
2021-02-07 19:13                 ` Tom Rini
2021-02-08 13:32                   ` Andre Przywara
2021-02-08 15:11                     ` Bin Meng
2021-02-08 15:51                       ` Marek Vasut [this message]
2021-02-08 15:49                     ` Marek Vasut
2021-02-08 16:30                       ` 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=28e3d6b0-0e32-1007-683b-07374874ff92@gmail.com \
    --to=marek.vasut@gmail.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