Messages in this thread | | | Subject | Re: About commit "io: change inX() to have their own IO barrier overrides" | From | John Garry <> | Date | Mon, 2 Mar 2020 12:35:17 +0000 |
| |
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
| |