[PATCH] nvme: Fix cache alignment

[Bin Meng]

On Tue, Feb 2, 2021 at 4:05 PM Marek Vasut <marek.vasut at gmail.com> wrote:
>
> On 2/2/21 4:55 AM, Bin Meng wrote:
>
> Hi,
>
> >> The various structures in the driver are already correcty padded and
> >
> > typo: correctly
> >
> >> cache aligned in memory, however the cache operations are called on
> >> the structure sizes, which themselves might not be cache aligned. Add
> >> the necessary rounding to fix this, which permits the nvme to work on
> >> arm64.
> >
> > +ARM guys
> >
> > Which ARM64 SoC did you test this with?
>
> RCar3, although that's irrelevant, the problem will happen on any arm or
> arm64, and possibly any other system which needs cache management.

There was a recent change to nvme.c that fixed a cache issue on ARMv8
so I thought this might be platform related.

>
> > The round down in this patch should be unnecessary.
>
> Can you explain why ?

I just took a further look and most of the start address should be
cache line aligned (4KiB aligned) except the
nvme_read_completion_status(). It's only 16 bytes aligned which might
not be cache line aligned.

>
> > But it's better to
> > figure out which call to dcache_xxx() with an unaligned end address.
>
> If you look at the code, most of them can (and do) trigger this,
> therefore they need such alignment, as explained in the commit message.

Now I wonder what's the correct implementation of the
invalidate_dcache_range() and flush_dcache_range() in U-Boot?
Shouldn't the round down/up happen in these APIs instead of doing such
in drivers?

Regards,
Bin