[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM4PR12MB610982CB7D66D9DEF758188E8C1CA@DM4PR12MB6109.namprd12.prod.outlook.com>
Date: Wed, 24 Sep 2025 08:59:33 +0000
From: "Guntupalli, Manikanta" <manikanta.guntupalli@....com>
To: Arnd Bergmann <arnd@...db.de>, "git (AMD-Xilinx)" <git@....com>, "Simek,
Michal" <michal.simek@....com>, Alexandre Belloni
<alexandre.belloni@...tlin.com>, Frank Li <Frank.Li@....com>, Rob Herring
<robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Przemysław Gaj <pgaj@...ence.com>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
"tommaso.merciai.xr@...renesas.com" <tommaso.merciai.xr@...renesas.com>,
"quic_msavaliy@...cinc.com" <quic_msavaliy@...cinc.com>, "S-k, Shyam-sundar"
<Shyam-sundar.S-k@....com>, Sakari Ailus <sakari.ailus@...ux.intel.com>,
"'billy_tsai@...eedtech.com'" <billy_tsai@...eedtech.com>, Kees Cook
<kees@...nel.org>, "Gustavo A. R. Silva" <gustavoars@...nel.org>, Jarkko
Nikula <jarkko.nikula@...ux.intel.com>, Jorge Marques
<jorge.marques@...log.com>, "linux-i3c@...ts.infradead.org"
<linux-i3c@...ts.infradead.org>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, Linux-Arch <linux-arch@...r.kernel.org>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
CC: "Pandey, Radhey Shyam" <radhey.shyam.pandey@....com>, "Goud, Srinivas"
<srinivas.goud@....com>, "Datta, Shubhrajyoti" <shubhrajyoti.datta@....com>,
"manion05gk@...il.com" <manion05gk@...il.com>
Subject: RE: [PATCH V7 2/4] asm-generic/io.h: Add big-endian MMIO accessors
[Public]
Hi,
> -----Original Message-----
> From: Arnd Bergmann <arnd@...db.de>
> Sent: Wednesday, September 24, 2025 12:08 AM
> To: Guntupalli, Manikanta <manikanta.guntupalli@....com>; git (AMD-Xilinx)
> <git@....com>; Simek, Michal <michal.simek@....com>; Alexandre Belloni
> <alexandre.belloni@...tlin.com>; Frank Li <Frank.Li@....com>; Rob Herring
> <robh@...nel.org>; krzk+dt@...nel.org; Conor Dooley <conor+dt@...nel.org>;
> Przemysław Gaj <pgaj@...ence.com>; Wolfram Sang <wsa+renesas@...g-
> engineering.com>; tommaso.merciai.xr@...renesas.com;
> quic_msavaliy@...cinc.com; S-k, Shyam-sundar <Shyam-sundar.S-k@....com>;
> Sakari Ailus <sakari.ailus@...ux.intel.com>; 'billy_tsai@...eedtech.com'
> <billy_tsai@...eedtech.com>; Kees Cook <kees@...nel.org>; Gustavo A. R. Silva
> <gustavoars@...nel.org>; Jarkko Nikula <jarkko.nikula@...ux.intel.com>; Jorge
> Marques <jorge.marques@...log.com>; linux-i3c@...ts.infradead.org;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; Linux-Arch <linux-
> arch@...r.kernel.org>; linux-hardening@...r.kernel.org
> Cc: Pandey, Radhey Shyam <radhey.shyam.pandey@....com>; Goud, Srinivas
> <srinivas.goud@....com>; Datta, Shubhrajyoti <shubhrajyoti.datta@....com>;
> manion05gk@...il.com
> Subject: Re: [PATCH V7 2/4] asm-generic/io.h: Add big-endian MMIO accessors
>
> On Tue, Sep 23, 2025, at 17:45, Manikanta Guntupalli wrote:
> > Add MMIO accessors to support big-endian memory operations. These
> > helpers include {read, write}{w, l, q}_be() and {read, write}s{w, l,
> > q}_be(), which allows to access big-endian memory regions while
> > returning the results in the CPU’s native endianness.
> >
> > This provides a consistent interface to interact with hardware using
> > big-endian register layouts.
> >
> > Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@....com>
>
> I feel like we already have too many accessor functions like these, what's wrong with
> just using io{read,write}{8,16,32,64}be() in your driver?
>
> On most architectures (including arm, riscv, powerpc and microblaze, but not x86),
> the ioread/write helpers are identical to the readl/writel style helpers, the only
> difference being that on x86 they add an extra indirection for the port I/O check.
>
> At the moment, there are only six drivers that use the
> io{read,write}{8,16,32,64}be() style helpers. They are all powerpc specific and can
> probably be changed to io{read,write}be.
The existing helpers io{read,write}{8,16,32,64}be() internally rely on {read,write}{b,w,l,q}().
From both description and implementation, {read,write}{b,w,l,q}() access little-endian memory and return the result in native endianness:
/*
* {read,write}{b,w,l,q}() access little endian memory
* and return result in native endianness.
*/
static inline u32 readl(const volatile void __iomem *addr)
{
u32 val;
log_read_mmio(32, addr, _THIS_IP_, _RET_IP_);
__io_br();
val = __le32_to_cpu((__le32 __force)__raw_readl(addr));
__io_ar(val);
log_post_read_mmio(val, 32, addr, _THIS_IP_, _RET_IP_);
return val;
}
The io{read,write}*be() helpers then perform a byte swap, e.g.:
static inline u32 ioread32be(const volatile void __iomem *addr)
{
return swab32(readl(addr));
}
This works on little-endian CPUs, but on big-endian CPUs the {read,write}{b,w,l,q}() helpers already return data in big-endian format. The extra byte swap in io{read,write}*be() therefore corrupts the data, producing little-endian values when big-endian is expected.
The newly introduced {read,write}{w,l,q}_be() helpers directly access big-endian IO memory and return results in native endianness, avoiding this mismatch.
Thanks,
Manikanta.
Powered by blists - more mailing lists