All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	John Garry <john.garry@huawei.com>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Chris Zankel <chris@zankel.net>,
	Karol Gugala <kgugala@antmicro.com>,
	Jeff Dike <jdike@addtoit.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Brian Cain <bcain@codeaurora.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.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>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>, 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>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	openrisc@lists.librecores.org, linux-s390@vger.kernel.org,
	linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	Greg Ungerer <gerg@linux-m68k.org>
Subject: Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Tue, 28 Dec 2021 22:41:18 -0500	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	 Bjorn Helgaas <bhelgaas@google.com>,
	John Garry <john.garry@huawei.com>,
	 Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	 Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	 Dinh Nguyen <dinguyen@kernel.org>,
	Chris Zankel <chris@zankel.net>,
	 Karol Gugala <kgugala@antmicro.com>,
	Jeff Dike <jdike@addtoit.com>,
	 Yoshinori Sato <ysato@users.sourceforge.jp>,
	Brian Cain <bcain@codeaurora.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>,
	 Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	 Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.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>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	 Paul Mackerras <paulus@samba.org>, 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>,
	x86@kernel.org,  "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	 linux-pci@vger.kernel.org, linux-riscv@lists.infradead.org,
	 linux-csky@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	 openrisc@lists.librecores.org, linux-s390@vger.kernel.org,
	 linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-ia64@vger.kernel.org,  linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,  linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,  linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,  Greg Ungerer <gerg@linux-m68k.org>
Subject: Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Tue, 28 Dec 2021 22:41:18 -0500	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	 Bjorn Helgaas <bhelgaas@google.com>,
	John Garry <john.garry@huawei.com>,
	 Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	 Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	 Dinh Nguyen <dinguyen@kernel.org>,
	Chris Zankel <chris@zankel.net>,
	 Karol Gugala <kgugala@antmicro.com>,
	Jeff Dike <jdike@addtoit.com>,
	 Yoshinori Sato <ysato@users.sourceforge.jp>,
	Brian Cain <bcain@codeaurora.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>,
	 Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	 Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.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>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	 Paul Mackerras <paulus@samba.org>, 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>,
	x86@kernel.org,  "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	 linux-pci@vger.kernel.org, linux-riscv@lists.infradead.org,
	 linux-csky@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	 openrisc@lists.librecores.org, linux-s390@vger.kernel.org,
	 linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-ia64@vger.kernel.org,  linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,  linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,  linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,  Greg Ungerer <gerg@linux-m68k.org>
Subject: Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Tue, 28 Dec 2021 22:41:18 -0500	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

_______________________________________________
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: Arnd Bergmann <arnd@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Rich Felker <dalias@libc.org>,
	linux-sh@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-mips@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	sparclinux@vger.kernel.org, Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
	linux-ia64@vger.kernel.org, linux-riscv@lists.infradead.org,
	Vincent Chen <deanbo422@gmail.com>, Will Deacon <will@kernel.org>,
	Greg Ungerer <gerg@linux-m68k.org>,
	Karol Gugala <kgugala@antmicro.com>,
	linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Helge Deller <deller@gmx.de>,
	x86@kernel.org, Russell King <linux@armlinux.org.uk>,
	linux-csky@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-parisc@vger.kernel.org, Vineet Gupta <vgupta@kernel.org>,
	Matt Turner <mattst88@gmail.com>,
	linux-snps-arc@lists.infradead.org,
	Heiko Carstens <hca@linux.ibm.com>,
	linux-xtensa@linux-xtensa.org, Albert Ou <aou@eecs.berkeley.edu>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Jeff Dike <jdike@addtoit.com>, John Garry <john.garry@huawei.com>,
	linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Greentime Hu <green.hu@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Richard Henderson <rth@twiddle.net>,
	Chris Zankel <chris@zankel.net>, Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Brian Cain <bcain@codeaurora.org>, Nick Hu <nickhu@andestech.com>,
	linux-kernel@vger.kernel.org, Dinh Nguyen <dinguyen@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	linux-alpha@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Tue, 28 Dec 2021 22:41:18 -0500	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Tue, 28 Dec 2021 22:41:18 -0500	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g at mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	John Garry <john.garry@huawei.com>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Chris Zankel <chris@zankel.net>,
	Karol Gugala <kgugala@antmicro.com>,
	Jeff Dike <jdike@addtoit.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Brian Cain <bcain@codeaurora.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.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>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>, 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>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	openrisc@lists.librecores.org, linux-s390@vger.kernel.org,
	linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	Greg Ungerer <gerg@linux-m68k.org>
Subject: Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Wed, 29 Dec 2021 03:41:18 +0000	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	John Garry <john.garry@huawei.com>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Chris Zankel <chris@zankel.net>,
	Karol Gugala <kgugala@antmicro.com>,
	Jeff Dike <jdike@addtoit.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Brian Cain <bcain@codeaurora.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt
Subject: Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Tue, 28 Dec 2021 22:41:18 -0500	[thread overview]
Message-ID: <CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com> (raw)
In-Reply-To: <d406b93a-0f76-d056-3380-65d459d05ea9@gmail.com>

On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >>         select GENERIC_CPU_DEVICES
> >>         select GENERIC_IOMAP
> >>         select GENERIC_IRQ_SHOW
> >> +       select HAS_IOPORT
> >>         select HAVE_AOUT if MMU
> >>         select HAVE_ASM_MODVERSIONS
> >>         select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> >     select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
>         select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.

Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.

Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.

          Arnd

  reply	other threads:[~2021-12-29  3:41 UTC|newest]

Thread overview: 323+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27 16:42 [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options Niklas Schnelle
2021-12-27 16:42 ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI Niklas Schnelle
2021-12-27 16:42   ` [Intel-wired-lan] " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 17:48   ` Guenter Roeck
2021-12-27 17:48     ` [Intel-wired-lan] " Guenter Roeck
2021-12-27 17:48     ` Guenter Roeck
2021-12-27 17:48     ` Guenter Roeck
2021-12-28  2:09   ` Mauro Carvalho Chehab
2021-12-28  2:09     ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28  2:09     ` Mauro Carvalho Chehab
2021-12-28  2:09     ` Mauro Carvalho Chehab
2021-12-28  2:09     ` Mauro Carvalho Chehab
2021-12-28  8:21   ` Greg Kroah-Hartman
2021-12-28  8:21     ` [Intel-wired-lan] " Greg Kroah-Hartman
2021-12-28  8:21     ` Greg Kroah-Hartman
2021-12-28  8:21     ` Greg Kroah-Hartman
2021-12-28  8:21     ` Greg Kroah-Hartman
2021-12-28  9:15     ` Mauro Carvalho Chehab
2021-12-28  9:15       ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28  9:15       ` Mauro Carvalho Chehab
2021-12-28  9:15       ` Mauro Carvalho Chehab
2021-12-28  9:15       ` Mauro Carvalho Chehab
2021-12-28 10:58       ` Niklas Schnelle
2021-12-28 10:58         ` [Intel-wired-lan] " Niklas Schnelle
2021-12-28 10:58         ` Niklas Schnelle
2021-12-28 10:58         ` Niklas Schnelle
2021-12-28 10:58         ` Niklas Schnelle
2021-12-28 12:01         ` Greg Kroah-Hartman
2021-12-28 12:01           ` [Intel-wired-lan] " Greg Kroah-Hartman
2021-12-28 12:01           ` Greg Kroah-Hartman
2021-12-28 12:01           ` Greg Kroah-Hartman
2021-12-28 12:01           ` Greg Kroah-Hartman
2021-12-28 12:54         ` Mauro Carvalho Chehab
2021-12-28 12:54           ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28 12:54           ` Mauro Carvalho Chehab
2021-12-28 12:54           ` Mauro Carvalho Chehab
2021-12-28 12:54           ` Mauro Carvalho Chehab
2021-12-28 15:06           ` Niklas Schnelle
2021-12-28 15:06             ` [Intel-wired-lan] " Niklas Schnelle
2021-12-28 15:06             ` Niklas Schnelle
2021-12-28 15:06             ` Niklas Schnelle
2021-12-28 15:06             ` Niklas Schnelle
2021-12-28 17:12             ` Mauro Carvalho Chehab
2021-12-28 17:12               ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-28 17:12               ` Mauro Carvalho Chehab
2021-12-28 17:12               ` Mauro Carvalho Chehab
2021-12-28 17:12               ` Mauro Carvalho Chehab
2021-12-29 11:45               ` Niklas Schnelle
2021-12-29 11:45                 ` [Intel-wired-lan] " Niklas Schnelle
2021-12-29 11:45                 ` Niklas Schnelle
2021-12-29 11:45                 ` Niklas Schnelle
2021-12-29 12:12                 ` Mauro Carvalho Chehab
2021-12-29 12:12                   ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-12-29 12:12                   ` Mauro Carvalho Chehab
2021-12-29 12:12                   ` Mauro Carvalho Chehab
2021-12-29 16:03                   ` Bjorn Helgaas
2021-12-29 16:03                     ` [Intel-wired-lan] " Bjorn Helgaas
2021-12-29 16:03                     ` Bjorn Helgaas
2021-12-29 16:03                     ` Bjorn Helgaas
2021-12-29 16:55                     ` Niklas Schnelle
2021-12-29 16:55                       ` [Intel-wired-lan] " Niklas Schnelle
2021-12-29 16:55                       ` Niklas Schnelle
2021-12-29 16:55                       ` Niklas Schnelle
2022-01-05 17:42                       ` John Garry
2022-01-05 17:42                         ` [Intel-wired-lan] " John Garry
2022-01-05 17:42                         ` John Garry
2022-01-05 17:42                         ` John Garry
2022-01-05 19:47                         ` Bjorn Helgaas
2022-01-05 19:47                           ` [Intel-wired-lan] " Bjorn Helgaas
2022-01-05 19:47                           ` Bjorn Helgaas
2022-01-05 19:47                           ` Bjorn Helgaas
2022-01-06 17:41                           ` John Garry
2022-01-06 17:41                             ` [Intel-wired-lan] " John Garry
2022-01-06 17:41                             ` John Garry
2022-01-06 18:14                             ` Bjorn Helgaas
2022-01-06 18:14                               ` [Intel-wired-lan] " Bjorn Helgaas
2022-01-06 18:14                               ` Bjorn Helgaas
2022-01-06 18:14                               ` Bjorn Helgaas
2022-01-07 17:16                               ` John Garry
2022-01-07 17:16                                 ` [Intel-wired-lan] " John Garry
2022-01-07 17:16                                 ` John Garry
2022-01-07 17:16                                 ` John Garry
2022-01-10  9:34                             ` Niklas Schnelle
2022-01-10  9:34                               ` [Intel-wired-lan] " Niklas Schnelle
2022-01-10  9:34                               ` Niklas Schnelle
2022-01-10  9:34                               ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` [OpenRISC] " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:08   ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` [OpenRISC] " Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-28 10:08     ` Geert Uytterhoeven
2021-12-29  1:20     ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` [OpenRISC] " Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  1:20       ` Michael Schmitz
2021-12-29  3:41       ` Arnd Bergmann [this message]
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` [OpenRISC] " Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  3:41         ` Arnd Bergmann
2021-12-29  4:15         ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` [OpenRISC] " Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-29  4:15           ` Michael Schmitz
2021-12-30  1:48           ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` [OpenRISC] " Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  1:48             ` Arnd Bergmann
2021-12-30  3:44             ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` [OpenRISC] " Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-30  3:44               ` Michael Schmitz
2021-12-31 11:28               ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` [OpenRISC] " Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 11:28                 ` Niklas Schnelle
2021-12-31 16:04               ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` [OpenRISC] " Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 16:04                 ` Arnd Bergmann
2021-12-31 21:55                 ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` [OpenRISC] " Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-31 21:55                   ` Michael Schmitz
2021-12-28 16:32   ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` [OpenRISC] " Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-28 16:32     ` Mauro Carvalho Chehab
2021-12-27 16:42 ` [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:47   ` Rafael J. Wysocki
2021-12-27 16:47     ` Rafael J. Wysocki
2021-12-27 17:02     ` Niklas Schnelle
2021-12-27 17:02       ` Niklas Schnelle
2021-12-27 17:12       ` Rafael J. Wysocki
2021-12-27 17:12         ` Rafael J. Wysocki
2021-12-27 17:15         ` Rafael J. Wysocki
2021-12-27 17:15           ` Rafael J. Wysocki
2021-12-27 17:43           ` Niklas Schnelle
2021-12-27 17:43             ` Niklas Schnelle
2021-12-28 15:20             ` Rafael J. Wysocki
2021-12-28 15:20               ` Rafael J. Wysocki
2021-12-28 16:31               ` Niklas Schnelle
2021-12-28 16:31                 ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 04/32] parport: PC style parport depends on HAS_IOPORT Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:14   ` Geert Uytterhoeven
2021-12-28 10:14     ` Geert Uytterhoeven
2021-12-28 14:21     ` Niklas Schnelle
2021-12-28 14:21       ` Niklas Schnelle
2021-12-29  2:58     ` Arnd Bergmann
2021-12-29  2:58       ` Arnd Bergmann
2021-12-27 16:42 ` [RFC 05/32] char: impi, tpm: depend " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:17   ` Geert Uytterhoeven
2021-12-28 10:17     ` Geert Uytterhoeven
2021-12-28 12:13     ` Niklas Schnelle
2021-12-28 12:13       ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 06/32] speakup: Kconfig: add HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 17:52   ` Samuel Thibault
2021-12-27 17:52     ` Samuel Thibault
2021-12-27 16:42 ` [RFC 07/32] Input: gameport: add ISA and " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 08/32] comedi: Kconfig: add " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 09/32] sound: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 10/32] i2c: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:21   ` Geert Uytterhoeven
2021-12-28 10:21     ` Geert Uytterhoeven
2021-12-28 12:13     ` Niklas Schnelle
2021-12-28 12:13       ` Niklas Schnelle
2021-12-27 16:42 ` [RFC 11/32] Input: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:23   ` Geert Uytterhoeven
2021-12-28 10:23     ` Geert Uytterhoeven
2021-12-27 16:42 ` [RFC 12/32] iio: adc: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-28 10:32   ` Geert Uytterhoeven
2021-12-28 10:32     ` Geert Uytterhoeven
2021-12-28 12:50     ` Niklas Schnelle
2021-12-28 12:50       ` Niklas Schnelle
2021-12-28 17:01       ` Jonathan Cameron
2021-12-28 17:01         ` Jonathan Cameron
2022-01-30 15:05         ` Jonathan Cameron
2022-01-30 15:05           ` Jonathan Cameron
2021-12-27 16:42 ` [RFC 13/32] hwmon: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 18:07   ` Guenter Roeck
2021-12-27 18:07     ` Guenter Roeck
2021-12-27 16:42 ` [RFC 14/32] leds: " Niklas Schnelle
2021-12-27 16:42   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 15/32] media: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 16/32] misc: handle " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-28  8:15   ` Greg Kroah-Hartman
2021-12-28  8:15     ` Greg Kroah-Hartman
2021-12-27 16:43 ` [RFC 17/32] net: Kconfig: add " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 17:28   ` Marc Kleine-Budde
2021-12-27 17:28     ` Marc Kleine-Budde
2021-12-27 16:43 ` [RFC 18/32] pcmcia: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 18:41   ` Dominik Brodowski
2021-12-27 18:41     ` Dominik Brodowski
2021-12-27 16:43 ` [RFC 19/32] platform: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 20/32] pnp: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 21/32] power: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 22/32] video: handle " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 23/32] rtc: Kconfig: add " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 24/32] scsi: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-28 10:40   ` Geert Uytterhoeven
2021-12-28 10:40     ` Geert Uytterhoeven
2021-12-27 16:43 ` [RFC 25/32] watchdog: " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 18:03   ` Guenter Roeck
2021-12-27 18:03     ` Guenter Roeck
2021-12-28  9:58     ` Niklas Schnelle
2021-12-28  9:58       ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 26/32] drm: handle " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2022-01-03  6:11   ` Gerd Hoffmann
2022-01-03  6:11     ` Gerd Hoffmann
2022-01-03  6:11     ` Gerd Hoffmann
2022-01-03  6:11     ` Gerd Hoffmann
2021-12-27 16:43 ` [RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 22:04   ` Bjorn Helgaas
2021-12-27 22:04     ` Bjorn Helgaas
2021-12-27 16:43 ` [RFC 28/32] PCI: make quirk using inw() " Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 22:33   ` Bjorn Helgaas
2021-12-27 22:33     ` Bjorn Helgaas
2021-12-28 15:25     ` Niklas Schnelle
2021-12-28 15:25       ` Niklas Schnelle
2021-12-28 16:35       ` Bjorn Helgaas
2021-12-28 16:35         ` Bjorn Helgaas
2021-12-28 16:52         ` Niklas Schnelle
2021-12-28 16:52           ` Niklas Schnelle
2021-12-28 17:28           ` Bjorn Helgaas
2021-12-28 17:28             ` Bjorn Helgaas
2021-12-27 16:43 ` [RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 16:43 ` [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-28  8:17   ` Greg Kroah-Hartman
2021-12-28  8:17     ` Greg Kroah-Hartman
2021-12-29 10:25     ` Niklas Schnelle
2021-12-29 10:25       ` Niklas Schnelle
2021-12-29 10:38       ` Greg Kroah-Hartman
2021-12-29 10:38         ` Greg Kroah-Hartman
2021-12-30 16:19         ` Arnd Bergmann
2021-12-30 16:19           ` Arnd Bergmann
2021-12-27 16:43 ` [RFC 31/32] usb: handle HAS_IOPORT dependencies Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2021-12-27 20:36   ` Alan Stern
2021-12-27 20:36     ` Alan Stern
2021-12-31 11:06     ` Niklas Schnelle
2021-12-31 11:06       ` Niklas Schnelle
2021-12-31 17:15       ` Alan Stern
2021-12-31 17:15         ` Alan Stern
2022-01-03 11:35         ` Niklas Schnelle
2022-01-03 11:35           ` Niklas Schnelle
2022-01-03 16:15           ` Alan Stern
2022-01-03 16:15             ` Alan Stern
2021-12-27 16:43 ` [RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle
2021-12-27 16:43   ` Niklas Schnelle
2022-01-06 17:45 ` [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options John Garry
2022-01-06 17:45   ` John Garry
2022-01-07  7:21   ` Niklas Schnelle
2022-01-07  7:21     ` Niklas Schnelle
2022-01-07 16:57     ` John Garry
2022-01-07 16:57       ` John Garry

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=CAK8P3a2j-OFUUp+haHoV4PyL-On4EASZ9+59SDqNqmL8Gv_k7Q@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bcain@codeaurora.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chris@zankel.net \
    --cc=dalias@libc.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deanbo422@gmail.com \
    --cc=deller@gmx.de \
    --cc=dinguyen@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jdike@addtoit.com \
    --cc=john.garry@huawei.com \
    --cc=kgugala@antmicro.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.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-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.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=nickhu@andestech.com \
    --cc=openrisc@lists.librecores.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulus@samba.org \
    --cc=rth@twiddle.net \
    --cc=schmitzmic@gmail.com \
    --cc=schnelle@linux.ibm.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=vgupta@kernel.org \
    --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.