On Wed, Jul 25, 2018 at 12:42 PM, Sreekanth Reddy
<[email protected]> wrote:
> Swap the I/O memory read value back to cpu endianness before storing it
> in a data structures which are defined in the MPI headers where
> u8 components are not defined in the endianness order.
>
> In this area from day one mpt3sas driver is using le32_to_cpu() &
> cpu_to_le32() APIs. But in the patch cf6bf9710c
> (mpt3sas: Bug fix for big endian systems) we have removed these APIs
> before reading I/O memory which we should haven't done it. So
> in this patch I am correcting it by adding these APIs back
> before accessing I/O memory.
> - __u64 data_out = b;
> + __u64 data_out = cpu_to_le64(b);
>
> spin_lock_irqsave(writeq_lock, flags);
> writel((u32)(data_out), addr);
Wouldn't be the same as
__raw_writel(data_out >> 0, addr);
__raw_writel(data_out >> 32, addr + 4);
mmiowb();
?
> _base_writeq(__u64 b, volatile void __iomem *addr, spinlock_t *writeq_lock)
> {
> - writeq(b, addr);
> + writeq(cpu_to_le64(b), addr);
Similar here
__raw_writeq(b, addr);
mmiowb();
> - writel((u32)(request[i]), &ioc->chip->Doorbell);
> + writel(cpu_to_le32(request[i]), &ioc->chip->Doorbell);
This kind of endianess play (including above) should make sparse unhappy.
Did you run it with
C=1 CF=-D__CHECK_ENDIAN__
?
--
With Best Regards,
Andy Shevchenko
