Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 6 Dec 2021 19:22:47 +0530 | Subject | Re: [PATCHv5 1/4] arm64: io: Use asm-generic high level MMIO accessors | From | Sai Prakash Ranjan <> |
| |
On 12/6/2021 5:00 PM, Arnd Bergmann wrote: > On Mon, Dec 6, 2021 at 12:12 PM Sai Prakash Ranjan > <quic_saipraka@quicinc.com> wrote: >> On 12/6/2021 2:20 PM, Arnd Bergmann wrote: >>> I think it would be even better to flip these around and make the low-level >>> definitions __io_ar() and __io_bw(), and then defining the arm64 specific >>> macros based on those: >>> >>> /* arm64-specific, don't use in portable drivers */ >>> #define __iormb(v) __io_ar(v) >>> #define __iowmb() __io_bw() >>> #define __iomb() dma_mb() >>> >>> >> So __iormb on arm64 has some dummy control dependency stuff as well based on >> ("arm64: io: Ensure calls to delay routines are ordered against prior >> readX()") and then we would need to change __iormb definition to __io_ar which >> doesn't seem like __iormb definition to be exact right? > I'm not sure what you are asking here. As far as I can tell, __io_ar() > and __iormb() have the same calling conventions and the same barrier > requirements, so they should be interchangeable, we just need to decide > which one is the primary definition. > > Arnd
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.
Thanks, Sai
| ![\](/images/icornerr.gif) |