| Message ID | 20230323163354.1454196-1-schnelle@linux.ibm.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | [v4] Kconfig: introduce HAS_IOPORT option and select it as necessary | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/github-powerpc_selftests | success | Successfully ran 8 jobs. |
| snowpatch_ozlabs/github-powerpc_ppctests | success | Successfully ran 8 jobs. |
| snowpatch_ozlabs/github-powerpc_sparse | success | Successfully ran 4 jobs. |
| snowpatch_ozlabs/github-powerpc_kernel_qemu | success | Successfully ran 24 jobs. |
| snowpatch_ozlabs/github-powerpc_clang | success | Successfully ran 6 jobs. |
On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O > Port access. In a future patch HAS_IOPORT=n will disable compilation of > the I/O accessor functions inb()/outb() and friends on architectures > which can not meaningfully support legacy I/O spaces such as s390. > > The following architectures do not select HAS_IOPORT: > > * ARC > * C-SKY > * Hexagon > * Nios II > * OpenRISC > * s390 > * User-Mode Linux > * Xtensa > > All other architectures select HAS_IOPORT at least conditionally. > > The "depends on" relations 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. > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > Acked-by: Johannes Berg <johannes@sipsolutions.net> # for ARCH=um > Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > --- > Note: This patch is the initial patch of a larger series[0]. This patch > introduces the HAS_IOPORT config option while the rest of the series adds > driver dependencies and the final patch removes inb() / outb() and friends on > platforms that don't support them. > > Thus each of the per-subsystem patches is independent from each other but > depends on this patch while the final patch depends on the whole series. Thus > splitting this initial patch off allows the per-subsytem HAS_IOPORT dependency > addition be merged separately via different trees without breaking the build. > > [0] https://lore.kernel.org/lkml/20230314121216.413434-1-schnelle@linux.ibm.com/ > > Changes since v3: > - List archs without HAS_IOPORT in commit message (Arnd) > - Select HAS_IOPORT for LoongArch (Arnd) > - Use "select HAS_IOPORT if (E)ISA || .." instead of a "depends on" for (E)ISA > for m68k and parisc > - Select HAS_IOPORT with config GSC on parisc (Arnd) > - Drop "depends on HAS_IOPORT" for um's config ISA (Johannes) > - Drop "depends on HAS_IOPORT" for config ISA on x86 and parisc where it is > always selected (Arnd) > Gentle ping. As far as I can tell this hasn't been picked to any tree sp far but also hasn't seen complains so I'm wondering if I should send a new version of the combined series of this patch plus the added HAS_IOPORT dependencies per subsystem or wait until this is picked up. Thanks, Niklas
On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@linux.ibm.com> wrote: >On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: >> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O >> Port access. In a future patch HAS_IOPORT=n will disable compilation of >> the I/O accessor functions inb()/outb() and friends on architectures >> which can not meaningfully support legacy I/O spaces such as s390. >> >> The following architectures do not select HAS_IOPORT: >> >> * ARC >> * C-SKY >> * Hexagon >> * Nios II >> * OpenRISC >> * s390 >> * User-Mode Linux >> * Xtensa >> >> All other architectures select HAS_IOPORT at least conditionally. >> >> The "depends on" relations 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. >> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org> >> Acked-by: Johannes Berg <johannes@sipsolutions.net> # for ARCH=um >> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> >> --- >> Note: This patch is the initial patch of a larger series[0]. This patch >> introduces the HAS_IOPORT config option while the rest of the series adds >> driver dependencies and the final patch removes inb() / outb() and friends on >> platforms that don't support them. >> >> Thus each of the per-subsystem patches is independent from each other but >> depends on this patch while the final patch depends on the whole series. Thus >> splitting this initial patch off allows the per-subsytem HAS_IOPORT dependency >> addition be merged separately via different trees without breaking the build. >> >> [0] https://lore.kernel.org/lkml/20230314121216.413434-1-schnelle@linux.ibm.com/ >> >> Changes since v3: >> - List archs without HAS_IOPORT in commit message (Arnd) >> - Select HAS_IOPORT for LoongArch (Arnd) >> - Use "select HAS_IOPORT if (E)ISA || .." instead of a "depends on" for (E)ISA >> for m68k and parisc >> - Select HAS_IOPORT with config GSC on parisc (Arnd) >> - Drop "depends on HAS_IOPORT" for um's config ISA (Johannes) >> - Drop "depends on HAS_IOPORT" for config ISA on x86 and parisc where it is >> always selected (Arnd) >> > >Gentle ping. As far as I can tell this hasn't been picked to any tree >sp far but also hasn't seen complains so I'm wondering if I should send >a new version of the combined series of this patch plus the added >HAS_IOPORT dependencies per subsystem or wait until this is picked up. > >Thanks, >Niklas > > You need this on a system supporting not just ISA but also PCI. Typically on non-x86 architectures this is simply mapped into a memory window.
On Wed, Apr 5, 2023, at 17:12, Niklas Schnelle wrote: > On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > > Gentle ping. As far as I can tell this hasn't been picked to any tree > sp far but also hasn't seen complains so I'm wondering if I should send > a new version of the combined series of this patch plus the added > HAS_IOPORT dependencies per subsystem or wait until this is picked up. My bad, I've created an 'asm-generic-io' branch in the asm-generic tree now and merged that into the master branch for 6.4. If anyone wants to merge the later patches for 6.4, feel free to pull in https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git asm-generic-io as a stable base. Arnd
On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote: > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@linux.ibm.com> wrote: >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of >>> the I/O accessor functions inb()/outb() and friends on architectures >>> which can not meaningfully support legacy I/O spaces such as s390. >>> >> >>Gentle ping. As far as I can tell this hasn't been picked to any tree >>sp far but also hasn't seen complains so I'm wondering if I should send >>a new version of the combined series of this patch plus the added >>HAS_IOPORT dependencies per subsystem or wait until this is picked up. > > You need this on a system supporting not just ISA but also PCI. > > Typically on non-x86 architectures this is simply mapped into a memory window. I'm pretty confident that the list is correct here, as the HAS_IOPORT symbol is enabled exactly for the architectures that have a way to map the I/O space. PCIe generally works fine without I/O space, the only exception are drivers for devices that were around as early PCI. Arnd
From: Linuxppc-dev Arnd Bergmann > Sent: 05 April 2023 21:32 > > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote: > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@linux.ibm.com> wrote: > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of > >>> the I/O accessor functions inb()/outb() and friends on architectures > >>> which can not meaningfully support legacy I/O spaces such as s390. > >>> >> > >>Gentle ping. As far as I can tell this hasn't been picked to any tree > >>sp far but also hasn't seen complains so I'm wondering if I should send > >>a new version of the combined series of this patch plus the added > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up. > > > > You need this on a system supporting not just ISA but also PCI. > > > > Typically on non-x86 architectures this is simply mapped into a memory window. > > I'm pretty confident that the list is correct here, as the HAS_IOPORT > symbol is enabled exactly for the architectures that have a way to > map the I/O space. PCIe generally works fine without I/O space, the > only exception are drivers for devices that were around as early PCI. Isn't there a difference between cpu that have inb()/outb() (probably only x86?) and architectures (well computer designs) that can generate PCI 'I/O' cycles by some means. It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100) that mapped a chuck of physical address space onto PCMCIA I/O cycles. If the hardware can map a PCI 'IO' bar into normal kernel address space then the bar and accesses can be treated exactly like a memory bar. This probably leaves x86 as the outlier where you need (IIRC) io_readl() and friends that can generate in/out instructions for those accesses. There are also all the x86 ISA devices which need in/out instructions. But (with the likely exception of the UART) they are pretty much platform specific. So, to my mind at least, HAS_IOPORT is just the wrong question. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Hi David, On Wed, Apr 5, 2023 at 11:37 PM David Laight <David.Laight@aculab.com> wrote: > From: Linuxppc-dev Arnd Bergmann > > Sent: 05 April 2023 21:32 > > > > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote: > > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@linux.ibm.com> wrote: > > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O > > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of > > >>> the I/O accessor functions inb()/outb() and friends on architectures > > >>> which can not meaningfully support legacy I/O spaces such as s390. > > >>> >> > > >>Gentle ping. As far as I can tell this hasn't been picked to any tree > > >>sp far but also hasn't seen complains so I'm wondering if I should send > > >>a new version of the combined series of this patch plus the added > > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up. > > > > > > You need this on a system supporting not just ISA but also PCI. > > > > > > Typically on non-x86 architectures this is simply mapped into a memory window. > > > > I'm pretty confident that the list is correct here, as the HAS_IOPORT > > symbol is enabled exactly for the architectures that have a way to > > map the I/O space. PCIe generally works fine without I/O space, the > > only exception are drivers for devices that were around as early PCI. > > Isn't there a difference between cpu that have inb()/outb() (probably > only x86?) and architectures (well computer designs) that can generate > PCI 'I/O' cycles by some means. > It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100) > that mapped a chuck of physical address space onto PCMCIA I/O cycles. > > If the hardware can map a PCI 'IO' bar into normal kernel address > space then the bar and accesses can be treated exactly like a memory bar. > This probably leaves x86 as the outlier where you need (IIRC) io_readl() > and friends that can generate in/out instructions for those accesses. > > There are also all the x86 ISA devices which need in/out instructions. > But (with the likely exception of the UART) they are pretty much > platform specific. > > So, to my mind at least, HAS_IOPORT is just the wrong question. Not all PCI controllers support mapping the I/O bar in MMIO space, so in general you cannot say that CONFIG_PCI=y means CONFIG_HAS_IOPORT=y. Gr{oetje,eeting}s, Geert
From: Geert Uytterhoeven > Sent: 11 April 2023 09:50 > > Hi David, > > On Wed, Apr 5, 2023 at 11:37 PM David Laight <David.Laight@aculab.com> wrote: > > From: Linuxppc-dev Arnd Bergmann > > > Sent: 05 April 2023 21:32 > > > > > > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote: > > > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@linux.ibm.com> wrote: > > > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > > > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O > > > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of > > > >>> the I/O accessor functions inb()/outb() and friends on architectures > > > >>> which can not meaningfully support legacy I/O spaces such as s390. > > > >>> >> > > > >>Gentle ping. As far as I can tell this hasn't been picked to any tree > > > >>sp far but also hasn't seen complains so I'm wondering if I should send > > > >>a new version of the combined series of this patch plus the added > > > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up. > > > > > > > > You need this on a system supporting not just ISA but also PCI. > > > > > > > > Typically on non-x86 architectures this is simply mapped into a memory window. > > > > > > I'm pretty confident that the list is correct here, as the HAS_IOPORT > > > symbol is enabled exactly for the architectures that have a way to > > > map the I/O space. PCIe generally works fine without I/O space, the > > > only exception are drivers for devices that were around as early PCI. > > > > Isn't there a difference between cpu that have inb()/outb() (probably > > only x86?) and architectures (well computer designs) that can generate > > PCI 'I/O' cycles by some means. > > It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100) > > that mapped a chuck of physical address space onto PCMCIA I/O cycles. > > > > If the hardware can map a PCI 'IO' bar into normal kernel address > > space then the bar and accesses can be treated exactly like a memory bar. > > This probably leaves x86 as the outlier where you need (IIRC) io_readl() > > and friends that can generate in/out instructions for those accesses. > > > > There are also all the x86 ISA devices which need in/out instructions. > > But (with the likely exception of the UART) they are pretty much > > platform specific. > > > > So, to my mind at least, HAS_IOPORT is just the wrong question. > > Not all PCI controllers support mapping the I/O bar in MMIO space, so > in general you cannot say that CONFIG_PCI=y means CONFIG_HAS_IOPORT=y. But a CONFIG_HAS_PCI_IO=y would imply CONFIG_HAS_IOPORT=y. It is the former that is more interesting for driver support. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 780d4673c3ca..a5c2b1aa46b0 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -27,6 +27,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/arm/Kconfig b/arch/arm/Kconfig index e24a9820e12f..4acb5bc4b52a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -70,6 +70,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 1023e896d46b..b740019c4aee 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -145,6 +145,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 d7e4a24e8644..2e13ec8263b9 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -25,6 +25,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/loongarch/Kconfig b/arch/loongarch/Kconfig index 7fd51257e0ed..e1615dfb5437 100644 --- a/arch/loongarch/Kconfig +++ b/arch/loongarch/Kconfig @@ -80,6 +80,7 @@ config LOONGARCH select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL select GPIOLIB + select HAS_IOPORT select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_MMAP_RND_BITS if MMU select HAVE_ARCH_SECCOMP_FILTER diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 82154952e574..40198a1ebe27 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -18,6 +18,7 @@ config M68K select GENERIC_CPU_DEVICES select GENERIC_IOMAP select GENERIC_IRQ_SHOW + select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA select HAVE_ARCH_SECCOMP select HAVE_ARCH_SECCOMP_FILTER select HAVE_ASM_MODVERSIONS diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index cc88af6fa7a4..211f338d6235 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 e2f3ca73f40d..2ea3539a07ad 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_PXX_LOW_HIGH if CPU_MIPS32 && PHYS_ADDR_T_64BIT + select HAS_IOPORT if !NO_IOPORT_MAP || ISA 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 a98940e64243..466a25525364 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -47,6 +47,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 a6c4407d3ec8..02fd9bcd9215 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -188,6 +188,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 c5e42cc37604..b957d12a171b 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -74,6 +74,7 @@ config RISCV select GENERIC_TIME_VSYSCALL if MMU && 64BIT select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO select HARDIRQS_SW_RESEND + select HAS_IOPORT if MMU select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT && !XIP_KERNEL diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 0665ac0add0b..cfb797bc4200 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -25,6 +25,7 @@ config SUPERH select GENERIC_SCHED_CLOCK select GENERIC_SMP_IDLE_THREAD select GUP_GET_PXX_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 84437a4c6545..d4c1d96f85cd 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 a825bf031f49..44514c63a476 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -162,6 +162,7 @@ config X86 select GUP_GET_PXX_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 7bfe998f3514..fcfa280df98a 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/drivers/parisc/Kconfig b/drivers/parisc/Kconfig index 9eb2c1b5de7d..2fc3222d2634 100644 --- a/drivers/parisc/Kconfig +++ b/drivers/parisc/Kconfig @@ -4,6 +4,7 @@ menu "Bus options (PCI, PCMCIA, EISA, GSC, ISA)" config GSC bool "VSC/GSC/HSC bus support" select HAVE_EISA + select HAS_IOPORT default y help The VSC, GSC and HSC busses were used from the earliest 700-series diff --git a/lib/Kconfig b/lib/Kconfig index ce2abffb9ed8..5c2da561c516 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -92,6 +92,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 @@ -509,6 +510,9 @@ config HAS_IOMEM depends on !NO_IOMEM default y +config HAS_IOPORT + bool + config HAS_IOPORT_MAP bool depends on HAS_IOMEM && !NO_IOPORT_MAP