On 16.01.2024 16:20, Oleksii wrote:
> On Mon, 2024-01-15 at 17:57 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:12, Oleksii Kurochko wrote:
>>> +/*
>>> + * Unordered I/O memory access primitives. These are even more
>>> relaxed than
>>> + * the relaxed versions, as they don't even order accesses between
>>> successive
>>> + * operations to the I/O regions.
>>> + */
>>> +#define readb_cpu(c) ({ u8 __r = __raw_readb(c); __r;
>>> })
>>> +#define readw_cpu(c) ({ u16 __r = le16_to_cpu((__force
>>> __le16)__raw_readw(c)); __r; })
>>> +#define readl_cpu(c) ({ u32 __r = le32_to_cpu((__force
>>> __le32)__raw_readl(c)); __r; })
>>> +
>>> +#define
>>> writeb_cpu(v,c) ((void)__raw_writeb((v),(c)))
>>> +#define
>>> writew_cpu(v,c) ((void)__raw_writew((__force
>>> u16)cpu_to_le16(v),(c)))
>>> +#define
>>> writel_cpu(v,c) ((void)__raw_writel((__force
>>> u32)cpu_to_le32(v),(c)))
>>> +
>>> +#ifdef CONFIG_64BIT
>>> +#define readq_cpu(c) ({ u64 __r = le64_to_cpu((__force
>>> __le64)__raw_readq(c)); __r; })
>>> +#define
>>> writeq_cpu(v,c) ((void)__raw_writeq((__force
>>> u64)cpu_to_le64(v),(c)))
>>> +#endif
>>
>> How come there are endianness assumptions here on the MMIO accessed?
> It is a hard story.
>
> As you might expect it was copy from Linux Kernel where it was decided
> to follow only LE way:
> https://patchwork.kernel.org/project/linux-riscv/patch/[email protected]/
> One of the answers of the author of the commit:
> And we don't know if Linux will be around if that ever changes.
> The point is:
> a) the current RISC-V spec is LE only
> b) the current linux port is LE only except for this little bit
> There is no point in leaving just this bitrotting code around. It
> just confuses developers, (very very slightly) slows down compiles
> and will bitrot. It also won't be any significant help to a future
> developer down the road doing a hypothetical BE RISC-V Linux port.
Reads to me like a justification to _omit_ the cpu_to_le<N>().
Jan
