linux-kernel - Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK8P3a23jsT-=v8QDxSZYcj=ujhtBFXjACNLKxQybaThiBsFig@mail.gmail.com>
Date:   Fri, 17 Dec 2021 16:55:56 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     John Garry <john.garry@...wei.com>
Cc:     Niklas Schnelle <schnelle@...ux.ibm.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

On Fri, Dec 17, 2021 at 4:27 PM John Garry <john.garry@...wei.com> wrote:
> On 17/12/2021 14:32, Arnd Bergmann wrote:
>  From looking at the patch Niklas directed us at, as I understand,
> HAS_IOPORT is to decide whether the arch/platform may support PIO
> accessors - inb et al. And on that basis I am confused why it is not
> selected for arm64. And further compounded by:
>
>   config INDIRECT_PIO
>                 bool "Access I/O in non-MMIO mode"
>                 depends on ARM64
>         +       depends on HAS_IOPORT
>
> If arm64 does not select, then why depend on it?

Right, both arm32 and arm64 need to select HAS_IOPORT.

>  > If you have a better way of finding the affected drivers,
>  > that would be great.
>
> Assuming arm64 should select HAS_IOPORT, I am talking about f71805f as
> an example. According to that patch, this driver additionally depends on
> HAS_IOPORT; however I would rather arm64, like powerpc, should not allow
> that driver to be built at all.

Agreed, I missed these when I looked through the HAS_IOPORT users,
that's why I suggested to split up that part of the patch per subsystem
so they can be inspected more carefully.

My feeling is that in this case we want some other dependency, e.g. a
new CONFIG_LPC. It should actually be possible to use this driver on
any machine with an LPC bus, which would by definition be the primary
I/O space, so it should be possible to load it on Arm64.

         Arnd