On Thu, 2024-03-21 at 13:27 +0100, Jan Beulich wrote: > On 15.03.2024 19:06, Oleksii Kurochko wrote: > > --- /dev/null > > +++ b/xen/arch/riscv/include/asm/io.h > > @@ -0,0 +1,167 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * The header taken form Linux 6.4.0-rc1 and is based on > > + * arch/riscv/include/asm/mmio.h with the following changes: > > + * - drop forcing of endianess for read*(), write*() functions > > as > > + * no matter what CPU endianness, what endianness a particular > > device > > + * (and hence its MMIO region(s)) is using is entirely > > independent. > > + * Hence conversion, where necessary, needs to occur at a > > layer up. > > + * Another one reason to drop endianess conversion is: > > + * > > https://patchwork.kernel.org/project/linux-riscv/patch/20190411115623.5749-3-...@lst.de/ > > + * 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. > > + * - drop unused argument of __io_ar() macros. > > + * - drop "#define _raw_{read,write}{b,w,l,d,q} > > _raw_{read,write}{b,w,l,d,q}" > > In the commit message I'm not worried as much, but at least here the > odd mention > of d as suffixes would better be purged. Probably, I use incorrect words, but what I meant that it was dropped: #define _raw_{read,write}{b,w,l,d,q} _raw_{read,write}{b,w,l,d,q} before declaration/definition of inline functions ( __raw_{read,write}{b,w,l,d,q} ).
~ Oleksii
