Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1645679

Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

Show all headers | View raw

On Fri, May 19, 2017 at 4:01 PM, David Laight <David.Laight@aculab.com> wrote:
> From: Arnd Bergmann
>> Sent: 17 May 2017 22:40
>>
>> On Wed, May 17, 2017 at 11:16 PM, Chris Packham
>> <Chris.Packham@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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32 Chris Packham <chris.packham@alliedtelesis.co.nz> - 2017-05-12 06:30 +0200
  Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with  ioread32/iowrite32 Borislav Petkov <bp@alien8.de> - 2017-05-17 20:20 +0200
    Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with  ioread32/iowrite32 Chris Packham <Chris.Packham@alliedtelesis.co.nz> - 2017-05-17 23:20 +0200
      Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32 Arnd Bergmann <arnd@arndb.de> - 2017-05-17 23:50 +0200
        RE: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with  ioread32/iowrite32 David Laight <David.Laight@ACULAB.COM> - 2017-05-19 16:10 +0200
          Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32 Arnd Bergmann <arnd@arndb.de> - 2017-05-19 17:30 +0200
      Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with  ioread32/iowrite32 Borislav Petkov <bp@alien8.de> - 2017-05-18 10:10 +0200
    Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32 Michael Ellerman <mpe@ellerman.id.au> - 2017-05-18 07:40 +0200
      Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32 Arnd Bergmann <arnd@arndb.de> - 2017-05-18 13:10 +0200
        Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32 Michael Ellerman <mpe@ellerman.id.au> - 2017-05-19 12:00 +0200

csiph-web