From: Andy Shevchenko <andy.shevche...@gmail.com>
Date: Fri, 29 Jun 2018 18:42:30 +0300
> On Fri, Jun 29, 2018 at 5:58 PM, Chaitra P B
> <chaitra.basa...@broadcom.com> wrote:
>> "scsi: mpt3sas: Bug fix for big endian systems"
>>
>> Above patch with commit id "cf6bf9710cabba1fe94a4349f4eb8db623c77ebc" was
>> posted to fix sparse warnings. While posting this patch it was assumed that
>> readl() & writel() APIs internally calls le32_to_cpu() & cpu_to_le32() APIs
>> respectively.
>
>> Looks like it is not true for all architecture
Sparc does. It uses endianness translating stores and loads for the MMIO
accesses.
For example, readl() does:
__asm__ __volatile__("lduwa\t[%1] %2, %0\t/* pci_readl */"
: "=r" (ret)
: "r" (addr), "i" (ASI_PHYS_BYPASS_EC_E_L)
: "memory");
That "_L" at the end of the ASI_* value means "little-endian".
So if your understanding and basis for this bug fix is that sparc64
does not endian translate, it is a false one.
>> this patch is reverting back only those hunks which removed le32_to_cpu()
>> API call while using readl() API & cpu_to_le32() API call while using
>> writel() API.
>
> Can't you move to raw variants at the same time to be more clear with
> intentions?
> It would work on all architectures in the same way and won't trigger
> sparse warnings.
If you move to the raw variants you lose the memory barriers, it doesn't
just change the endianness of the access.
