Re: [PATCH v3 14/34] xen/riscv: introduce io.h

[Oleksii <oleksii.kurochko@xxxxxxxxx>]

On Tue, 2024-01-16 at 17:09 +0100, Jan Beulich wrote:
> 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/20190411115623.5749-3-hch@xxxxxx/
> > 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>().
Looks like we can omit cpu_to_le<N>(). Even docs say that memory system
is little-endian except:
   However, certain application areas, such as IP networking, operate
   on big-endian data structures, and certain legacy code bases have
   been built assuming big-endian
   processors, so we expect that future specifications will describe
   big-endian or bi-endian variants
   of RISC-V.
   
~ Oleksii