All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	"open list:ALPHA PORT" <linux-alpha@vger.kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,
	"open list:M68K ARCHITECTURE" <linux-m68k@lists.linux-m68k.org>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
	"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" 
	<linuxppc-dev@lists.ozlabs.org>,
	"open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	"open list:SPARC + UltraSPARC (sparc/sparc64)" 
	<sparclinux@vger.kernel.org>
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Thu, 5 May 2022 11:10:28 -0500	[thread overview]
Message-ID: <20220505161028.GA492600@bhelgaas> (raw)
In-Reply-To: <CAK8P3a0sJgMSpZB_Butx2gO0hapYZy-Dm_QH-hG5rOaq_ZgsXg@mail.gmail.com>

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, 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 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	"open list:ALPHA PORT" <linux-alpha@vger.kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,
	"open list:M68K ARCHITECTURE" <linux-m68k@lists.linux-m68k.org>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
	"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
	<linuxppc-dev@lists.ozlabs.org>,
	 "open list:RISC-V ARCHITECTURE"
	<linux-riscv@lists.infradead.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	"open list:SPARC + UltraSPARC (sparc/sparc64)"
	<sparclinux@vger.kernel.org>
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Thu, 5 May 2022 11:10:28 -0500	[thread overview]
Message-ID: <20220505161028.GA492600@bhelgaas> (raw)
In-Reply-To: <CAK8P3a0sJgMSpZB_Butx2gO0hapYZy-Dm_QH-hG5rOaq_ZgsXg@mail.gmail.com>

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, 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 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Rich Felker <dalias@libc.org>,
	"open list:IA64 \(Itanium\) PLATFORM"
	<linux-ia64@vger.kernel.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"open list:SPARC + UltraSPARC \(sparc/sparc64\)"
	<sparclinux@vger.kernel.org>,
	"open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
	Will Deacon <will@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Helge Deller <deller@gmx.de>,
	"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
	<x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
	Ingo Molnar <mingo@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Matt Turner <mattst88@gmail.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	"open list:M68K ARCHITECTURE" <linux-m68k@lists.linux-m68k.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	Richard Henderson <rth@twiddle.net>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	"open list:ALPHA PORT" <linux-alpha@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
	<linuxppc-dev@lists.ozlabs.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Thu, 5 May 2022 11:10:28 -0500	[thread overview]
Message-ID: <20220505161028.GA492600@bhelgaas> (raw)
In-Reply-To: <CAK8P3a0sJgMSpZB_Butx2gO0hapYZy-Dm_QH-hG5rOaq_ZgsXg@mail.gmail.com>

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, 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 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	"open list:ALPHA PORT" <linux-alpha@vger.kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,
	"open list:M68K ARCHITECTURE" <linux-m68k@lists.linux-m68k.org>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
	"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
	<linuxppc-dev@lists.ozlabs.org>,
	 "open list:RISC-V ARCHITECTURE"
	<linux-riscv@lists.infradead.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	"open list:SPARC + UltraSPARC (sparc/sparc64)"
	<sparclinux@vger.kernel.org>
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Thu, 5 May 2022 11:10:28 -0500	[thread overview]
Message-ID: <20220505161028.GA492600@bhelgaas> (raw)
In-Reply-To: <CAK8P3a0sJgMSpZB_Butx2gO0hapYZy-Dm_QH-hG5rOaq_ZgsXg@mail.gmail.com>

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, 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 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	"open list:ALPHA PORT" <linux-alpha@vger.kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,
	"open list:M68K ARCHITECTURE" <linux-m68k@lists.linux-m68k.org>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
	"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
	<linuxppc-dev@lists.ozlabs.org>,
	"open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	"open list:SPARC + UltraSPARC (sparc/sparc64)"
	<sparclinux@vger.kernel.org>
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Thu, 05 May 2022 16:10:28 +0000	[thread overview]
Message-ID: <20220505161028.GA492600@bhelgaas> (raw)
In-Reply-To: <CAK8P3a0sJgMSpZB_Butx2gO0hapYZy-Dm_QH-hG5rOaq_ZgsXg@mail.gmail.com>
In-Reply-To: <20220429135108.2781579-2-schnelle@linux.ibm.com>

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, 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 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Thu, 5 May 2022 11:10:28 -0500	[thread overview]
Message-ID: <20220505161028.GA492600@bhelgaas> (raw)
In-Reply-To: <CAK8P3a0sJgMSpZB_Butx2gO0hapYZy-Dm_QH-hG5rOaq_ZgsXg@mail.gmail.com>

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, 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 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

  parent reply	other threads:[~2022-05-05 16:10 UTC|newest]

Thread overview: 392+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 13:49 [RFC v2 00/39] Kconfig: Introduce HAS_IOPORT config option Niklas Schnelle
2022-04-29 13:49 ` Niklas Schnelle
2022-04-29 13:49 ` [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-05-01 22:40   ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-04 21:08   ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:31     ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-05  8:10       ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05 16:10       ` Bjorn Helgaas [this message]
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 17:39         ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 19:53           ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-06  9:12             ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06 11:18               ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-07  0:01                 ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07 13:14                   ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 23:59                     ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-08  0:15                       ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-06  9:38             ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06 11:07               ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 10:20           ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 11:33             ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 12:27               ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:53                 ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 13:08                   ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:40                     ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 14:03                     ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 15:02                       ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 13:15                   ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:28                     ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 14:44                       ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:56                         ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 15:03                           ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 12:53                 ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 13:15                   ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:16                   ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 12:55                 ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:42               ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
2022-05-04 13:23   ` Rafael J. Wysocki
2022-05-04 17:53   ` Bjorn Helgaas
2022-05-04 19:58     ` Arnd Bergmann
2022-05-05  8:20       ` Niklas Schnelle
2022-05-05 19:36         ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 02/37] ata: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:27   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 03/37] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
2022-04-29 14:28   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 03/39] ata: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT Niklas Schnelle
2022-04-29 14:23   ` Niklas Schnelle
2022-04-29 14:33     ` Ahmad Fatoum
2022-05-02 14:34       ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 04/37] parport: PC style parport depends " Niklas Schnelle
2022-04-29 14:28   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 05/37] char: impi, tpm: depend " Niklas Schnelle
2022-04-29 14:02   ` Ahmad Fatoum
2022-04-29 13:50 ` [RFC v2 05/39] comedi: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 06/39] counter: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
2022-04-29 14:28   ` Samuel Thibault
2022-04-29 14:28   ` Niklas Schnelle
2022-04-29 14:29   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 07/39] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
2022-04-29 13:50 ` [PATCH 07/37] Input: gameport: add ISA and HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:29   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 08/37] comedi: add " Niklas Schnelle
2022-04-29 14:30   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 08/39] drm: handle " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 09/37] counter: add " Niklas Schnelle
2022-04-29 14:30   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 09/39] firmware: dmi-sysfs: handle HAS_IOPORT=n Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 10/39] gpio: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:32   ` William Breathitt Gray
2022-04-29 14:46     ` Niklas Schnelle
2022-04-29 15:37       ` William Breathitt Gray
2022-05-01 21:55         ` Linus Walleij
2022-05-02 12:53           ` Niklas Schnelle
2022-05-03 13:08           ` David Laight
2022-05-03 14:03             ` William Breathitt Gray
2022-05-04 11:46             ` Maciej W. Rozycki
2022-05-04 12:45               ` David Laight
2022-05-04 13:02                 ` Maciej W. Rozycki
2022-05-02 13:21         ` Maciej W. Rozycki
2022-04-29 13:50 ` [RFC v2 11/39] hwmon: " Niklas Schnelle
2022-04-30  0:37   ` Guenter Roeck
2022-04-29 13:50 ` [PATCH 11/37] sound: " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 14:30   ` Niklas Schnelle
2022-04-29 14:30     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 12/39] i2c: " Niklas Schnelle
2022-05-14 14:06   ` Wolfram Sang
2022-04-29 13:50 ` [RFC v2 13/39] iio: adc: Kconfig: " Niklas Schnelle
2022-05-01 16:51   ` Jonathan Cameron
2022-04-29 13:50 ` [PATCH 13/37] Input: " Niklas Schnelle
2022-04-29 14:31   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 14/37] iio: adc: Kconfig: " Niklas Schnelle
2022-04-29 14:31   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 14/39] Input: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 15/37] hwmon: " Niklas Schnelle
2022-04-29 14:31   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 15/39] Input: gameport: add ISA and " Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 16/39] leds: add " Niklas Schnelle
2022-04-29 18:54   ` Pavel Machek
2022-05-02  8:31     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 17/39] media: " Niklas Schnelle
2022-04-29 15:36   ` Sean Young
2022-04-29 13:50 ` [RFC v2 18/39] misc: " Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 19/39] mISDN: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 19/37] mpt fusion: " Niklas Schnelle
2022-04-29 14:32   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 20/39] " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 20/37] net: " Niklas Schnelle
2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
2022-04-29 14:33   ` Niklas Schnelle
2022-04-29 14:33     ` [Intel-wired-lan] " Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 21/39] " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
2022-04-29 14:13   ` Marc Kleine-Budde
2022-04-29 14:13     ` Marc Kleine-Budde
2022-04-29 14:13     ` [Intel-wired-lan] " Marc Kleine-Budde
2022-05-01 22:48   ` Maciej W. Rozycki
2022-05-01 22:48     ` Maciej W. Rozycki
2022-05-01 22:48     ` [Intel-wired-lan] " Maciej W. Rozycki
2022-05-03 12:45     ` Niklas Schnelle
2022-05-03 12:45       ` Niklas Schnelle
2022-05-03 12:45       ` [Intel-wired-lan] " Niklas Schnelle
2022-05-03 13:36       ` Maciej W. Rozycki
2022-05-03 13:36         ` Maciej W. Rozycki
2022-05-03 13:36         ` [Intel-wired-lan] " Maciej W. Rozycki
2022-04-29 13:50 ` [PATCH 21/37] pcmcia: " Niklas Schnelle
2022-04-29 14:33   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 22/39] parport: PC style parport depends on HAS_IOPORT Niklas Schnelle
2022-04-29 13:50 ` [PATCH 22/37] platform: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:33   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 23/39] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
2022-06-08 18:30   ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 23/37] pnp: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:34   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 24/39] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
2022-06-08 18:32   ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 24/37] power: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:34   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 25/39] pcmcia: " Niklas Schnelle
2022-05-03 23:38   ` Bjorn Helgaas
2022-05-04 10:33     ` Arnd Bergmann
2022-05-04 12:38       ` Maciej W. Rozycki
2022-05-04 14:07         ` Arnd Bergmann
2022-05-04 14:24           ` Maciej W. Rozycki
2022-05-04 17:22             ` Bjorn Helgaas
2022-05-05  8:45               ` Maciej W. Rozycki
2022-05-05 19:38                 ` Bjorn Helgaas
2022-05-04 14:44       ` David Laight
2022-05-05 12:03         ` Maciej W. Rozycki
2022-05-04 14:59       ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 25/37] video: handle " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 14:35   ` Niklas Schnelle
2022-04-29 14:35     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 26/39] platform: add " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 26/37] rtc: " Niklas Schnelle
2022-04-29 14:46   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 27/39] pnp: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 27/37] scsi: " Niklas Schnelle
2022-04-29 14:46   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 28/39] power: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 28/37] staging: sm750fb: " Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 29/39] rtc: " Niklas Schnelle
2022-05-17 22:15   ` Alexandre Belloni
2022-05-18 13:47     ` Niklas Schnelle
2022-06-01 12:25   ` Maciej W. Rozycki
2022-04-29 13:50 ` [PATCH 29/37] tty: serial: " Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 30/39] scsi: " Niklas Schnelle
2022-05-04 20:42   ` Bjorn Helgaas
2022-05-04 21:34     ` Arnd Bergmann
2022-05-05 16:06       ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 30/37] watchdog: " Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 31/37] drm: handle " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 14:47     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 31/39] sound: add " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-05-09  8:53   ` Takashi Iwai
2022-05-09  8:53     ` Takashi Iwai
2022-05-09  9:20     ` Arnd Bergmann
2022-05-09  9:20       ` Arnd Bergmann
2022-05-09 10:07       ` Takashi Iwai
2022-05-09 10:07         ` Takashi Iwai
2022-05-09 12:14         ` Niklas Schnelle
2022-05-09 12:14           ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
2022-04-29 14:48   ` Niklas Schnelle
2022-05-05 21:41   ` Bjorn Helgaas
2022-04-29 13:50 ` [RFC v2 32/39] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
2022-04-29 13:50 ` [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
2022-04-29 14:48   ` Niklas Schnelle
2022-05-05 21:44   ` Bjorn Helgaas
2022-04-29 13:50 ` [RFC v2 33/39] staging: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 13:50 ` [PATCH 34/37] firmware: dmi-sysfs: handle HAS_IOPORT=n Niklas Schnelle
2022-04-29 14:48   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 34/39] tty: serial: add HAS_IOPORT dependencies Niklas Schnelle
2022-05-02  9:15   ` Maciej W. Rozycki
2022-04-29 13:51 ` [PATCH 35/37] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
2022-04-29 14:49   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 35/39] usb: handle HAS_IOPORT dependencies Niklas Schnelle
2022-04-30 12:56   ` Alan Stern
2022-05-02  8:26     ` Niklas Schnelle
2022-04-29 13:51 ` [PATCH 36/37] " Niklas Schnelle
2022-04-29 14:49   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 36/39] video: " Niklas Schnelle
2022-04-29 13:51   ` Niklas Schnelle
2022-04-29 13:51 ` [PATCH 37/37] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle
2022-04-29 14:49   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 37/39] watchdog: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-30  0:38   ` Guenter Roeck
2022-04-29 13:51 ` [RFC v2 38/39] wireless: " Niklas Schnelle
2022-04-29 14:40   ` Kalle Valo
2022-04-29 13:51 ` [RFC v2 39/39] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220505161028.GA492600@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mattst88@gmail.com \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rth@twiddle.net \
    --cc=schnelle@linux.ibm.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.