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: <d8686aaf-f12e-446b-9a80-335bb4266a4d@app.fastmail.com>
Date:   Wed, 05 Apr 2023 22:31:33 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "H. Peter Anvin" <hpa@...or.com>,
        "Niklas Schnelle" <schnelle@...ux.ibm.com>,
        "Richard Henderson" <richard.henderson@...aro.org>,
        "Ivan Kokshaysky" <ink@...assic.park.msu.ru>,
        "Matt Turner" <mattst88@...il.com>,
        "Russell King" <linux@...linux.org.uk>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Will Deacon" <will@...nel.org>,
        "Huacai Chen" <chenhuacai@...nel.org>,
        "WANG Xuerui" <kernel@...0n.name>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        "Michal Simek" <monstr@...str.eu>,
        "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
        "James E . J . Bottomley" <James.Bottomley@...senPartnership.com>,
        "Helge Deller" <deller@....de>,
        "Michael Ellerman" <mpe@...erman.id.au>,
        "Nicholas Piggin" <npiggin@...il.com>,
        "Christophe Leroy" <christophe.leroy@...roup.eu>,
        "Paul Walmsley" <paul.walmsley@...ive.com>,
        "Palmer Dabbelt" <palmer@...belt.com>,
        "Albert Ou" <aou@...s.berkeley.edu>,
        "Yoshinori Sato" <ysato@...rs.osdn.me>,
        "Rich Felker" <dalias@...c.org>,
        "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
        "David S . Miller" <davem@...emloft.net>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov" <bp@...en8.de>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>, x86@...nel.org
Cc:     "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Bjorn Helgaas" <bhelgaas@...gle.com>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        "Mauro Carvalho Chehab" <mchehab@...nel.org>,
        "Alan Stern" <stern@...land.harvard.edu>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org,
        Linux-Arch <linux-arch@...r.kernel.org>,
        linux-pci@...r.kernel.org, "Arnd Bergmann" <arnd@...nel.org>,
        "Johannes Berg" <johannes@...solutions.net>,
        linux-alpha@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-ia64@...r.kernel.org, loongarch@...ts.linux.dev,
        linux-m68k@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-riscv@...ts.infradead.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org
Subject: Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary

On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote:
> On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@...ux.ibm.com> wrote:
>>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
>>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
>>> Port access. In a future patch HAS_IOPORT=n will disable compilation of
>>> the I/O accessor functions inb()/outb() and friends on architectures
>>> which can not meaningfully support legacy I/O spaces such as s390.
>>> >>
>>Gentle ping. As far as I can tell this hasn't been picked to any tree
>>sp far but also hasn't seen complains so I'm wondering if I should send
>>a new version of the combined series of this patch plus the added
>>HAS_IOPORT dependencies per subsystem or wait until this is picked up.
>
> You need this on a system supporting not just ISA but also PCI.
>
> Typically on non-x86 architectures this is simply mapped into a memory window.

I'm pretty confident that the list is correct here, as the HAS_IOPORT
symbol is enabled exactly for the architectures that have a way to
map the I/O space. PCIe generally works fine without I/O space, the
only exception are drivers for devices that were around as early PCI.

      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ