On Tue, Mar 3, 2020 at 2:18 PM John Garry <john.garry@xxxxxxxxxx> wrote: > > + linux-arch > > For background, see > https://lore.kernel.org/lkml/2e80d7bc-32a0-cc40-00a9-8a383a1966c2@xxxxxxxxxx/ > > >> > >> 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. > > To be clear, I would make this change in lib/logic_pio.c since > __io_pbr() can be overridden per-arch: > > #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); > + __io_pbr(); > + ret = __raw_read##bw(PCI_IOBASE + addr); > + __io_pbr(); __io_par(); > } else if (addr >= MMIO_UPPER_LIMIT && addr < IO_SPACE_LIMIT) { > struct logic_pio_hwaddr *entry = find_io_range(addr); > > ... > > (forgetting leX_to_cpu for the moment) Yes, I suppose this is required to get consistent behavior on arm64, which overrides __io_par() but not __io_ar(), with the current code the barrier after read is weaker when LOGIC_PIO is enabled than it is otherwise. For other architectures, I suppose we would need another indirection level, as those can also override the default inb() itself to do something other than readb(PCI_IOBASE + addr), and that is not handled here either. We can do that if we need LOGIC_PIO on a second architecture. Arnd
