lkml.org 
[lkml]   [2020]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: About commit "io: change inX() to have their own IO barrier overrides"
From
Date
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
>> here - commit 031e3601869c ("lib: Add generic PIO mapping method")
>> introduced this.
>>
>> In fact, logic pio will override these for arm64 with the vanilla
>> defconfig these days.
>
> We only looked at inX()/inY() and readX()/writeX() API because the
> semantics of these API are defined in the kernel documentation.

Could we consider adding __io_pbr() et al to the kernel Documentation? I
couldn't find them and I had to rely on checking 64e2c67738 ("io: define
several IO & PIO barrier types for the asm-generic version") commit
message to find the definition.

> We looked at how to generalize this so that there is a uniform
> behavior across different architectures.
>
> Is logic PIO subject to ordering issues?

Well the point is that we're still concerned here with using
readX/writeX for MMIO-based IO port accesses, see *** from logic_pio.c:

#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.

>
> 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.

Thanks,
John

\
 
 \ /
  Last update: 2020-03-02 13:36    [W:0.128 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site