Re: About commit "io: change inX() to have their own IO barrier overrides"

[Sinan Kaya <okaya@kernel.org>]

On 3/2/2020 7:35 AM, John Garry wrote:
> Hi Sinan,
> 
> Thanks for getting back to me.
> 
>> On 2/28/2020 4:52 AM, John Garry wrote:
>>> About the commit in the $subject 87fe2d543f81, would there be any
>>> specific reason why the logic pio versions of these functions did not
>>> get the same treatment 
> 
> In fact, your changes and the logic PIO changes went in at the same time.
> 
> or should not? I'm talking about lib/logic_pio.c

I think your change missed "cross-architecture" category.

> 
> #define BUILD_LOGIC_IO(bw, type)                   
> type logic_in##bw(unsigned long addr)                   
> {                                   
>     type ret = (type)~0;                       
>     if (addr < MMIO_UPPER_LIMIT) {                   
>         ret = read##bw(PCI_IOBASE + addr); ***   
>     } else if (addr >= MMIO_UPPER_LIMIT && addr < IO_SPACE_LIMIT) {
>         struct logic_pio_hwaddr *entry = find_io_range(addr);   
>                                    
>         if (entry)                       
>             ret = entry->ops->in(entry->hostdata,       
>                     addr, sizeof(type));       
>         else                           
>             WARN_ON_ONCE(1);               
>     }                               
>     return ret;                           
> }       
> 
>> How is the behavior on different architectures?
> 
> So today only ARM64 uses it for this relevant code, above. But maybe
> others in future will want to use it - any arch without native IO port
> access is a candidate.

I'm looking at Arnd here for help.

> 
>>
>> As long as the expectations are set, I see no reason why it shouldn't
>> but, I'll let Arnd comment on it too.
> 
> ok, so it looks reasonable consider replicating your change for ***, above.

Arnd is the maintainer here. We should consult first.
I believe there is also a linux-arch mailing list. Going there with this
question makes sense IMO.


> 
> Thanks,
> John