arch/alpha/Kconfig | 1 + arch/arm/Kconfig | 1 + arch/arm64/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/loongarch/Kconfig | 1 + arch/m68k/Kconfig | 1 + arch/microblaze/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/parisc/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/riscv/Kconfig | 1 + arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/x86/Kconfig | 1 + drivers/bus/Kconfig | 2 +- drivers/parisc/Kconfig | 1 + lib/Kconfig | 4 ++++ 17 files changed, 20 insertions(+), 1 deletion(-)
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)
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/loongarch/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 1 +
drivers/bus/Kconfig | 2 +-
drivers/parisc/Kconfig | 1 +
lib/Kconfig | 4 ++++
17 files changed, 20 insertions(+), 1 deletion(-)
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
base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65
--
2.37.2On 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 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 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 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
--
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
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)
© 2016 - 2026 Red Hat, Inc.