lkml.org 
[lkml]   [2021]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCHv5 1/4] arm64: io: Use asm-generic high level MMIO accessors
From
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

\
 
 \ /
  Last update: 2021-12-06 14:53    [W:0.040 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site