| Message ID | 20211227164317.4146918-3-schnelle@linux.ibm.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
| Series | None | expand |
Hi Niklas, 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... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Em Mon, 27 Dec 2021 17:42:47 +0100 Niklas Schnelle <schnelle@linux.ibm.com> escreveu: > 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> ... > @@ -486,6 +487,9 @@ config HAS_IOMEM > depends on !NO_IOMEM > default y > > +config HAS_IOPORT > + def_bool ISA || LEGACY_PCI > + That doesn't sound right. The only dependency for LEGACY_PCI is PCI. If one selects LEGACY_PCI on an architecture that doesn't support it, this will cause problems. Instead, HAS_IOPORT should be selected at architecture level, and the dependency here should be just the opposite: LEGACY_API should depends on HAS_IOPORT. Thanks, Mauro
Hi Geert, Niklas, Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven: > Hi Niklas, > > 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. Cheers, Michael > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >
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
Hi Arnd, Am 29.12.2021 um 16:41 schrieb Arnd Bergmann: > 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. I'd hope not - we spent some effort to make sure setting ATARI_ROM_ISA does not affect other m68k platforms when e.g. building multiplatform kernels. Replacing inb() by readb() without any address translation won't do much good for m68k though - addresses in the traditional ISA I/O port range would hit the (unmapped) zero page. Cheers, Michael > > Arnd >
On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz <schmitzmic@gmail.com> wrote: > Am 29.12.2021 um 16:41 schrieb Arnd Bergmann: > > On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote: > I'd hope not - we spent some effort to make sure setting ATARI_ROM_ISA > does not affect other m68k platforms when e.g. building multiplatform > kernels. Ok > Replacing inb() by readb() without any address translation won't do much > good for m68k though - addresses in the traditional ISA I/O port range > would hit the (unmapped) zero page. Correct, this is exactly the problem that Niklas is trying to solve here: we do have drivers that hit this bug, and on s390 clang actually produces a compile-time error for drivers that cause a NULL pointer dereference this way. 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. 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. Arnd
Hi Arnd, 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: >> Am 29.12.2021 um 16:41 schrieb Arnd Bergmann: >>> On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote: >> I'd hope not - we spent some effort to make sure setting ATARI_ROM_ISA >> does not affect other m68k platforms when e.g. building multiplatform >> kernels. > > Ok > >> Replacing inb() by readb() without any address translation won't do much >> good for m68k though - addresses in the traditional ISA I/O port range >> would hit the (unmapped) zero page. > > Correct, this is exactly the problem that Niklas is trying to solve here: > we do have drivers that hit this bug, and on s390 clang actually produces > a compile-time error for drivers that cause a NULL pointer dereference > this way. Thanks for clarifying - I only saw Geert's CC and failed to go back to the start of the thread. > 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). 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 ...). 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). > > 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 ?? Cheers, Michael > > Arnd >
On Thu, 2021-12-30 at 16:44 +1300, Michael Schmitz wrote: > Hi Arnd, > > 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: > > > Am 29.12.2021 um 16:41 schrieb Arnd Bergmann: > > > > On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote: ---8<--- > > > 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). > > All other (MMU) m68k users of inb()/outb() apply an io_offset in the > platform specific address translation: > > ---8<--- > 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). > > > 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 ?? > No, HAS_IOPORT being set just means that inb() etc. exist and are functional be it as special instructions like on x86 or via an I/O address offset. As I understand it if you do have PCI, ISA or ATARI_ROM_ISA they are functional. If none of them are set and your zero offset mapping means these accessors can't actually be used you could make the declerations ifdeffed on CONFIG_HAS_IOPORT to detect the cases where somone managed to build drivers that require them and that would result in a compile time error instead of silently, or with a NULL pointer warning, compiling code that won't work.
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) > 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. > 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 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. Arnd
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 >
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 4e87783c90ad..472a0c5e4c2f 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -28,6 +28,7 @@ config ALPHA select AUDIT_ARCH select GENERIC_CPU_VULNERABILITIES select GENERIC_SMP_IDLE_THREAD + select HAS_IOPORT select HAVE_ARCH_AUDITSYSCALL select HAVE_MOD_ARCH_SPECIFIC select MODULES_USE_ELF_RELA diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index b4ae6058902a..b3911ebbd237 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -27,6 +27,7 @@ config ARC select GENERIC_PENDING_IRQ if SMP select GENERIC_SCHED_CLOCK select GENERIC_SMP_IDLE_THREAD + select HAS_IOPORT select HAVE_ARCH_KGDB select HAVE_ARCH_TRACEHOOK select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARC_MMU_V4 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c2724d986fa0..605709b6eecb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -66,6 +66,7 @@ config ARM select GENERIC_SCHED_CLOCK select GENERIC_SMP_IDLE_THREAD select HARDIRQS_SW_RESEND + select HAS_IOPORT select HAVE_ARCH_AUDITSYSCALL if AEABI && !OABI_COMPAT select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6 select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index c4207cf9bb17..a8b199a40c8f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -135,6 +135,7 @@ config ARM64 select GENERIC_GETTIMEOFDAY select GENERIC_VDSO_TIME_NS select HARDIRQS_SW_RESEND + select HAS_IOPORT select HAVE_MOVE_PMD select HAVE_MOVE_PUD select HAVE_PCI diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 1e33666fa679..672aa2a88b19 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -24,6 +24,7 @@ config IA64 select PCI_DOMAINS if PCI select PCI_MSI select PCI_SYSCALL if PCI + select HAS_IOPORT select HAVE_ASM_MODVERSIONS select HAVE_UNSTABLE_SCHED_CLOCK select HAVE_EXIT_THREAD diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 0b50da08a9c5..926d97c33828 100644 --- 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 diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index 59798e43cdb0..213ef2940079 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -21,6 +21,7 @@ config MICROBLAZE select GENERIC_IRQ_SHOW select GENERIC_PCI_IOMAP select GENERIC_SCHED_CLOCK + select HAS_IOPORT if PCI select HAVE_ARCH_HASH select HAVE_ARCH_KGDB select HAVE_ARCH_SECCOMP diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 0215dc1529e9..87e6e7c29493 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -47,6 +47,7 @@ config MIPS select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL select GUP_GET_PTE_LOW_HIGH if CPU_MIPS32 && PHYS_ADDR_T_64BIT + select HAS_IOPORT select HAVE_ARCH_COMPILER_H select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KGDB if MIPS_FP_SUPPORT diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 011dc32fdb4d..b352c6dbbead 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -43,6 +43,7 @@ config PARISC select MODULES_USE_ELF_RELA select CLONE_BACKWARDS select TTY # Needed for pdc_cons.c + select HAS_IOPORT if PCI || EISA select HAVE_DEBUG_STACKOVERFLOW select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HASH diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index dea74d7717c0..d39ba34d839a 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -185,6 +185,7 @@ config PPC select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL select GENERIC_VDSO_TIME_NS + select HAS_IOPORT if PCI select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP select HAVE_ARCH_HUGE_VMAP if PPC_RADIX_MMU || PPC_8xx diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 821252b65f89..b69cc86522fb 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -63,6 +63,7 @@ config RISCV select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL if MMU && 64BIT select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO + select HAS_IOPORT if MMU select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 70afb30e0b32..334a52535379 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -24,6 +24,7 @@ config SUPERH select GENERIC_SCHED_CLOCK select GENERIC_SMP_IDLE_THREAD select GUP_GET_PTE_LOW_HIGH if X2TLB + select HAS_IOPORT if HAS_IOPORT_MAP select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_KGDB select HAVE_ARCH_SECCOMP_FILTER diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 66fc08646be5..728598673724 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -32,6 +32,7 @@ config SPARC select GENERIC_IRQ_SHOW select ARCH_WANT_IPC_PARSE_VERSION select GENERIC_PCI_IOMAP + select HAS_IOPORT select HAVE_NMI_WATCHDOG if SPARC64 select HAVE_CBPF_JIT if SPARC32 select HAVE_EBPF_JIT if SPARC64 diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5c2ccb85f2ef..8d3cfd693559 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -153,6 +153,7 @@ config X86 select GUP_GET_PTE_LOW_HIGH if X86_PAE select HARDIRQS_SW_RESEND select HARDLOCKUP_CHECK_TIMESTAMP if X86_64 + select HAS_IOPORT select HAVE_ACPI_APEI if ACPI select HAVE_ACPI_APEI_NMI if ACPI select HAVE_ALIGNED_STRUCT_PAGE if SLUB diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 3c68e174a113..a61285100224 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -81,7 +81,7 @@ config MOXTET config HISILICON_LPC bool "Support for ISA I/O space on HiSilicon Hip06/7" depends on (ARM64 && ARCH_HISI) || (COMPILE_TEST && !ALPHA && !HEXAGON && !PARISC) - depends on HAS_IOMEM + depends on HAS_IOPORT select INDIRECT_PIO if ARM64 help Driver to enable I/O access to devices attached to the Low Pin diff --git a/lib/Kconfig b/lib/Kconfig index 5e7165e6a346..e55746625762 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -95,6 +95,7 @@ config ARCH_USE_SYM_ANNOTATIONS config INDIRECT_PIO bool "Access I/O in non-MMIO mode" depends on ARM64 + depends on HAS_IOPORT help On some platforms where no separate I/O space exists, there are I/O hosts which can not be accessed in MMIO mode. Using the logical PIO @@ -486,6 +487,9 @@ config HAS_IOMEM depends on !NO_IOMEM default y +config HAS_IOPORT + def_bool ISA || LEGACY_PCI + config HAS_IOPORT_MAP bool depends on HAS_IOMEM && !NO_IOPORT_MAP diff --git a/lib/Kconfig.kgdb b/lib/Kconfig.kgdb index 05dae05b6cc9..c68e4d9dcecb 100644 --- a/lib/Kconfig.kgdb +++ b/lib/Kconfig.kgdb @@ -121,6 +121,7 @@ config KDB_DEFAULT_ENABLE config KDB_KEYBOARD bool "KGDB_KDB: keyboard as input device" + depends on HAS_IOPORT depends on VT && KGDB_KDB default n help