linux-kernel - Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a1W=29h+Qw=s_qEYCLC5F2bN=5W1C+xbnHo0Ebw7fxhxA@mail.gmail.com>
Date:   Fri, 19 May 2017 17:25:01 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     David Laight <David.Laight@...lab.com>
Cc:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
        Borislav Petkov <bp@...en8.de>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

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