All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
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>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:TENSILICA XTENSA PORT (xtensa)" 
	<linux-xtensa@linux-xtensa.org>,
	Openrisc <openrisc@lists.librecores.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE" 
	<linux-snps-arc@lists.infradead.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <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: Sat, 1 Jan 2022 10:55:27 +1300	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        Arnd
>

WARNING: multiple messages have this Message-ID (diff)
From: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
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>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:TENSILICA XTENSA PORT (xtensa)"
	<linux-xtensa@linux-xtensa.org>,
	Openrisc <openrisc@lists.librecores.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <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: Sat, 1 Jan 2022 10:55:27 +1300	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        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: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
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>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:TENSILICA XTENSA PORT (xtensa)"
	<linux-xtensa@linux-xtensa.org>,
	Openrisc <openrisc@lists.librecores.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <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: Sat, 1 Jan 2022 10:55:27 +1300	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        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: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Rich Felker <dalias@libc.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	sparclinux <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 <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 <linux-arch@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Helge Deller <deller@gmx.de>,
	the arch/x86 maintainers <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>,
	Parisc List <linux-parisc@vger.kernel.org>,
	Vineet Gupta <vgupta@kernel.org>,
	Matt Turner <mattst88@gmail.com>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	"open list:TENSILICA XTENSA PORT \(xtensa\)"
	<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 <linux-m68k@lists.linux-m68k.org>,
	Openrisc <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 <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 Mailing List <linux-kernel@vger.kernel.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	alpha <linux-alpha@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev <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: Sat, 1 Jan 2022 10:55:27 +1300	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        Arnd
>

WARNING: multiple messages have this Message-ID (diff)
From: Michael Schmitz <schmitzmic@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Date: Sat, 1 Jan 2022 10:55:27 +1300	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        Arnd
>

WARNING: multiple messages have this Message-ID (diff)
From: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
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>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:TENSILICA XTENSA PORT (xtensa)"
	<linux-xtensa@linux-xtensa.org>,
	Openrisc <openrisc@lists.librecores.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <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: Fri, 31 Dec 2021 21:55:27 +0000	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        Arnd
>

WARNING: multiple messages have this Message-ID (diff)
From: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
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: Sat, 1 Jan 2022 10:55:27 +1300	[thread overview]
Message-ID: <a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com> (raw)
In-Reply-To: <CAK8P3a2GGGuP0miLRy8w2+8vdSsGRNioBHEZ-ervSBrYbuZ+5w@mail.gmail.com>

Hi Arnd,

Am 01.01.2022 um 05:04 schrieb Arnd Bergmann:
> On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
>>> On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> What some other architectures do is to rely on inb()/outb() to have a
>>> zero-based offset, and use an io_offset in PCI buses to ensure that a
>>> low port number on the bus gets translated into a pointer value for the
>>> virtual mapping in the kernel, which is then represented as an unsigned
>>> int.
>>
>> M54xx does just that for Coldfire:
>>
>> arch/m68k/include/asm/io_no.h:
>> #define PCI_IO_PA       0xf8000000              /* Host physical address */
>>
>> (used to set PCI BAR mappings, so matches your definition above).
>
> I think coldfire gets it right here, using PCI_IOBASE to find the start of
> the window and a zero io_offset:
>
> #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)

Good - I bear that in mind if I ever get around to reactivating my 060 
accelerator and the PCI board for that.

>> All other (MMU) m68k users of inb()/outb() apply an io_offset in the
>> platform specific address translation:
>>
>> arch/m68k/include/asm/io_mm.h:
>>
>> #define q40_isa_io_base  0xff400000
>> #define enec_isa_read_base  0xfffa0000
>> #define enec_isa_write_base 0xfffb0000
>>
>> arch/m68k/include/asm/amigayle.h:
>>
>> #define GAYLE_IO                (0xa20000+zTwoBase)     /* 16bit and
>> even 8bit registers */
>> #define GAYLE_IO_8BITODD        (0xa30000+zTwoBase)     /* odd 8bit
>> registers */
>>
>> (all constants used in address translation inlines that are used by the
>> m68k inb()/outb() macros - you can call that the poor man's version of
>> PCI BAR mappings ...).
>
> This still looks like the same thing to me, where you have inb() take a
> zero-based port number, not a pointer. The effect is the same as the
> coldfire version, it just uses a custom inline function instead of the
> version from asm-generic/io.h.

Right.

>> So as long as support for any of the m68k PCI or ISA bridges is selected
>> in the kernel config, the appropriate IO space mapping is applied. If no
>> support for PCI or ISA bridges is selected, we already fall back to zero
>> offset mapping (but as far as I can tell, it shouldn't be possible to
>> build a kernel without bridge support but drivers that require it).
>
> Right.
>
>>> As this is indistinguishable from architectures that just don't have
>>> a base address for I/O ports (we unfortunately picked 0 as the default
>>> PCI_IOBASE value), my suggestion was to start marking architectures
>>> that may have this problem as using HAS_IOPORT in order to keep
>>> the existing behavior unchanged. If m68k does not suffer from this,
>>> making HAS_IOPORT conditional on those config options that actually
>>> need it would of course be best.
>>
>> Following your description, HAS_IOPORT would be required for neither of
>> PCI, ISA or ATARI_ROM_ISA ??
>
> For these three options, we definitely need HAS_IOPORT, which would
> imply that some version of inb()/outb() is provided. The difference between

Thanks for clarifying that (and to Niklas as well). Did sound a little 
counter-intuitive to me...

> using a custom PCI_IOBASE (or an open-coded equivalent) and using
> a zero PCI_IOBASE in combination with registering PCI using a custom
> io_offset is whether we can use drivers with hardcoded port numbers.
> These should depend on a different Kconfig symbol to be introduced
> (CONFIG_HARDCODED_IOPORT or similar) once we introduce them,
> and you could decide for m68k whether to allow those or not, I would
> assume you do want them in order to use certain legacy ISA drivers.

That's exactly the purpose (though we're overmuch pushing the envelope 
trying to accomodate legacy ISA drivers on too many platforms).

Cheers,

	Michael


>        Arnd
>

  reply	other threads:[~2021-12-31 21:55 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
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 [this message]
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=a635e885-c365-8bdc-bf3c-e74d7d39a786@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@kernel.org \
    --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=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.