On Fri, May 19, 2017 at 4:01 PM, David Laight <david.lai...@aculab.com> wrote: > From: Arnd Bergmann >> Sent: 17 May 2017 22:40 >> >> On Wed, May 17, 2017 at 11:16 PM, Chris Packham >> <chris.pack...@alliedtelesis.co.nz> wrote: >> > On 18/05/17 06:18, Borislav Petkov wrote: >> > One thing I would like confirmation on is is in_le32 -> ioread32 the >> > correct change? I tossed up between ioread32 and readl. Looking at >> > mv643xx_eth.c which supports both the MV643XX and Orion it's using readl >> > so perhaps I should be using that. >> >> There is no easy answer: on powerpc, readl is used for PCI, >> while in_le32 is used for on-chip devices, so in_le32 is the >> right one in principle. The main difference is that readl can >> work with CONFIG_EEH on pseries, but in_le32 is cheaper. >> >> On ARM and most other architectures, readl is used for both >> PCI and on-chip devices, so that's what portable code tends >> to use. >> >> ioread32 is required to behave the same way as readl >> on all __iomem pointers returned from ioremap(), but >> is an extern function on powerpc and can be more >> expensive when CONFIG_GENERIC_IOMAP is set. > > What about x86? > Isn't ioread32() an extern function that checks for 'io' addresses > than need 'inb' (etc) instructions rather than memory ones.
Right, x86 uses CONFIG_GENERIC_IOMAP and has that extra check. > If we know a PCI slave isn't 'io' should be be using ioread32() or readl()? Generally speaking yes, though on most architectures that don't use CONFIG_GENERIC_IOMAP there is no practical difference. > Don't some architectures have different enforced barriers in both these? I'm not aware of any architecture that always adds barriers to ioread32 compared to readl, though I guess that may be a reasonable implementation depending on the architecture. PowerPC doesn't do it, though one could argue that it would be required to guarantee non-posted I/O accesses on PCI I/O space that gets mapped with pci_iomap(). On ARM, no extra barrier is needed because the difference is in the page table flags. Arnd