[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.