[PATCH] nvme: Fix cache alignment

[Marek Vasut]

On 2/2/21 9:54 AM, Bin Meng wrote:
[...]
>>>> 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.

I used master, so unlikely.

>>> 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.

Right, there are various arm chips with 32B/64B alignment requirements.

>>> 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?

Definitely not, because then the rounding might flush/invalidate cache 
over areas where this could cause a problem (e.g. neighboring DMA 
descriptors). The driver must do the cache management correctly.