[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v6 09/20] xen/riscv: introduce io.h
On Fri, 2024-03-22 at 12:36 +0100, Jan Beulich wrote: > On 22.03.2024 12:02, Oleksii wrote: > > 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-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. > > > > + * - 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} ). > > But where did you find a raw_readd() or raw_writed() (with no matter > how > many leading underscores)? Oh, {d} options didn't exist. Missed that, wrote it automatically. Thanks I'll update the commit message and the header comment. ~ Oleksii
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |