[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0L2tLeF1Q0+0ijUxhGNaw+Z0fyPC1oW6_ELQfn0=i4iw@mail.gmail.com>
Date: Mon, 6 Dec 2021 16:15:44 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Sai Prakash Ranjan <quic_saipraka@...cinc.com>
Cc: Arnd Bergmann <arnd@...db.de>, Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Marc Zyngier <maz@...nel.org>,
gregkh <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
quic_psodagud@...cinc.com
Subject: Re: [PATCHv5 1/4] arm64: io: Use asm-generic high level MMIO accessors
On Mon, Dec 6, 2021 at 2:52 PM Sai Prakash Ranjan
<quic_saipraka@...cinc.com> wrote:
>
> Sorry, what I meant was the literal name of these macros, i.e.,
> __iormb() has more explicit naming as
> IO read memory barrier and __io_ar() is IO after read? So doesn't it
> make more sense that __iormb()
> should be the primary definition which is already the case and ar/bw
> should be based on them.
My reasoning was that we should ideally only have one set, and that
__io_ar()/__io_bw() are the ones used in architecture-independent code,
so I'd rather use those and deprecate the arm64 specific ones, eventually
moving all the arm64 specific code to use those directly where needed.
Arnd
Powered by blists - more mailing lists