All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@linux-m68k.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	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: Fri, 6 May 2022 19:12:06 +1000 (AEST)	[thread overview]
Message-ID: <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> (raw)
In-Reply-To: <20220505195342.GA509942@bhelgaas>



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > 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.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

_______________________________________________
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: Finn Thain <fthain@linux-m68k.org>
To: Bjorn Helgaas <helgaas@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>,
	Arnd Bergmann <arnd@kernel.org>, 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: Fri, 6 May 2022 19:12:06 +1000 (AEST)	[thread overview]
Message-ID: <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> (raw)
In-Reply-To: <20220505195342.GA509942@bhelgaas>



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > 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.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

WARNING: multiple messages have this Message-ID (diff)
From: Finn Thain <fthain@linux-m68k.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	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: Fri, 6 May 2022 19:12:06 +1000 (AEST)	[thread overview]
Message-ID: <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> (raw)
In-Reply-To: <20220505195342.GA509942@bhelgaas>



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > 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.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

_______________________________________________
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: Finn Thain <fthain@linux-m68k.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	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: Fri, 6 May 2022 19:12:06 +1000 (AEST)	[thread overview]
Message-ID: <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> (raw)
In-Reply-To: <20220505195342.GA509942@bhelgaas>



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > 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.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

WARNING: multiple messages have this Message-ID (diff)
From: Finn Thain <fthain@linux-m68k.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	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: Fri, 06 May 2022 09:12:06 +0000	[thread overview]
Message-ID: <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> (raw)
In-Reply-To: <20220505195342.GA509942@bhelgaas>



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > 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.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

WARNING: multiple messages have this Message-ID (diff)
From: Finn Thain <fthain@linux-m68k.org>
To: Bjorn Helgaas <helgaas@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@gm>
Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Fri, 6 May 2022 19:12:06 +1000 (AEST)	[thread overview]
Message-ID: <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> (raw)
In-Reply-To: <20220505195342.GA509942@bhelgaas>



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > 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.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

  reply	other threads:[~2022-05-06  9:12 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
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 [this message]
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=22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org \
    --to=fthain@linux-m68k.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=helgaas@kernel.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.