* [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Hello Kernel Hackers,
Some platforms such as s390 do not support legacy PCI devices nor PCI I/O
spaces. On such platforms I/O space accessors like inb()/outb() are merely
stubs that can never actually work. The way these stubs are implemented in
asm-generic/io.h leads to compiler warnings because any use will
essentially lead to a NULL pointer access. In a previous patch we tried
handling this case by generating a run-time warning on access. This
approach however was rejected by Linus in tha mail below with the argument
that this really should be a compile-time check and, though a much more
invasive change, we believe that is indeed the right approach.
https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
This patch series aims to do exactly that by introducing a HAS_IOPORT
config option akin to the existing HAS_IOMEM. When this is unset
inb()/outb() and friends may not be defined. Now since I/O port access is
not only used in legacy PCI devices or with legacy I/O spaces for backwards
compatible PCI Express devices, but also for example in ACPI we also
introduce another config option LEGACY_PCI to specifically disable the
compilation of drivers for legacy PCI devices and legacy I/O space uses
while keeping I/O port accessors for non-legacy uses. This allows modern
systems which do not need legacy PCI support to skip building drivers for
legacy devices while keeping e.g. ACPI support.
This series builts heavily on an original patch for demonstating the
concept by Arnd Bergmann and was created in collaboration with him as
discussed in the follow up to his original patch here:
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
It rebases his patch on v5.16-rc7, adds the missing arch selects for
HAS_IOPORT, fixes a few trivial findings from the original patch discussion
and splits the patch into more manageable patches. One other thing that
came up during the discussion is the idea of adding a separate
HARDCODED_IOPORTS config option for drivers which use hardcoded I/O port
numbers, this is not currently implemented but could still be added if we
find enough drivers that should not be compiled on platforms where
HAS_IOPORT is set but these hardcoded I/O ports will not work. According to
the above discussion John Garry is looking into this but I wanted to get
the discussion going on this proposal.
The series is split up into multiple patches as follows:
- Patch 01: Adds the LEGACY_PCI config and selects it for all remaining
drivers for legacy PCI devices.
- Patch 02: Adds the HAS_IOPORT config option and selects it for those
architectures supporting the I/O space access. It is currently not
selected for s390, nds32, um, h8300, nios2, openrisc, hexagon, csky, and
xtensa
- Patches 03-26: Add HAS_IOPORT dependencies on a per subsystem basis.
These dependencies are either Kconfig "depends on" or ifdefs where I/O
port access is an alternative path or required e.g. for a sysfs file.
- Patches 27-31: Handle HAS_IOPORT dependencies for some special cases such
as sysfs files, PCI quirks and in USB code.
- Patch 32: Removes the inb()/outb() etc. definitions in asm-generic/io.h
when HAS_IOPORT is not selected e.g. on s390.
I performed the following testing:
- On s390 this series on top of v5.16-rc7 builds with allyesconfig i.e. the
HAS_IOPORT=n case. It also builds with defconfig and the resulting kernel
appears fully functional including tests with PCI devices.
- On x86_64 with a config based on Arch Linux' standard config and
LEGACY_PCI=n it builds and I've been running kernels with this
configuration for over a week without issue on my Ryzen 3990X based
workstation (initially based on v5.16-rc6). I also tested LEGACY_PCI=y
though I do not have any legacy PCI devices, I did confirm though that
the additional modules are built as expected.
- For ARM64 I cross-compiled based on the current Arch Linux ARM generic
kernel config and LEGACY_PCI=n and have been running a v5.16-rc6 based
version of this patch on my Raspberry Pi 4 (DT not UEFI) and checked that
the PCI based USB still works.
For easy consumption a branch on top of v5.16-rc7 is also available from my
Github here https://github.com/niklas88/linux/tree/has_ioport_rfc_v1
Thanks,
Niklas Schnelle
Niklas Schnelle (32):
Kconfig: introduce and depend on LEGACY_PCI
Kconfig: introduce HAS_IOPORT option and select it as necessary
ACPI: Kconfig: add HAS_IOPORT dependencies
parport: PC style parport depends on HAS_IOPORT
char: impi, tpm: depend on HAS_IOPORT
speakup: Kconfig: add HAS_IOPORT dependencies
Input: gameport: add ISA and HAS_IOPORT dependencies
comedi: Kconfig: add HAS_IOPORT dependencies
sound: Kconfig: add HAS_IOPORT dependencies
i2c: Kconfig: add HAS_IOPORT dependencies
Input: Kconfig: add HAS_IOPORT dependencies
iio: adc: Kconfig: add HAS_IOPORT dependencies
hwmon: Kconfig: add HAS_IOPORT dependencies
leds: Kconfig: add HAS_IOPORT dependencies
media: Kconfig: add HAS_IOPORT dependencies
misc: handle HAS_IOPORT dependencies
net: Kconfig: add HAS_IOPORT dependencies
pcmcia: Kconfig: add HAS_IOPORT dependencies
platform: Kconfig: add HAS_IOPORT dependencies
pnp: Kconfig: add HAS_IOPORT dependencies
power: Kconfig: add HAS_IOPORT dependencies
video: handle HAS_IOPORT dependencies
rtc: Kconfig: add HAS_IOPORT dependencies
scsi: Kconfig: add HAS_IOPORT dependencies
watchdog: Kconfig: add HAS_IOPORT dependencies
drm: handle HAS_IOPORT dependencies
PCI/sysfs: make I/O resource depend on HAS_IOPORT
PCI: make quirk using inw() depend on HAS_IOPORT
firmware: dmi-sysfs: handle HAS_IOPORT dependencies
/dev/port: don't compile file operations without CONFIG_DEVPORT
usb: handle HAS_IOPORT dependencies
asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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/accessibility/speakup/Kconfig | 1 +
drivers/acpi/Kconfig | 1 +
drivers/ata/Kconfig | 34 ++---
drivers/ata/ata_generic.c | 3 +-
drivers/ata/libata-sff.c | 2 +
drivers/bus/Kconfig | 2 +-
drivers/char/Kconfig | 3 +-
drivers/char/ipmi/Makefile | 11 +-
drivers/char/ipmi/ipmi_si_intf.c | 3 +-
drivers/char/ipmi/ipmi_si_pci.c | 3 +
drivers/char/mem.c | 6 +-
drivers/char/tpm/Kconfig | 1 +
drivers/char/tpm/tpm_infineon.c | 14 +-
drivers/char/tpm/tpm_tis_core.c | 19 ++-
drivers/comedi/Kconfig | 53 ++++++++
drivers/firmware/dmi-sysfs.c | 4 +
drivers/gpio/Kconfig | 2 +-
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/cirrus.c | 2 +
drivers/hwmon/Kconfig | 21 ++-
drivers/i2c/busses/Kconfig | 29 +++--
drivers/iio/adc/Kconfig | 2 +-
drivers/input/gameport/Kconfig | 6 +-
drivers/input/serio/Kconfig | 2 +
drivers/input/touchscreen/Kconfig | 1 +
drivers/isdn/hardware/mISDN/Kconfig | 14 +-
drivers/leds/Kconfig | 2 +-
drivers/media/cec/platform/Kconfig | 2 +-
drivers/media/pci/dm1105/Kconfig | 2 +-
drivers/media/radio/Kconfig | 15 ++-
drivers/media/rc/Kconfig | 6 +
drivers/message/fusion/Kconfig | 8 +-
drivers/misc/altera-stapl/Makefile | 3 +-
drivers/misc/altera-stapl/altera.c | 6 +-
drivers/net/Kconfig | 2 +-
drivers/net/arcnet/Kconfig | 2 +-
drivers/net/can/cc770/Kconfig | 1 +
drivers/net/can/sja1000/Kconfig | 1 +
drivers/net/ethernet/8390/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 4 +-
drivers/net/ethernet/sis/Kconfig | 6 +-
drivers/net/ethernet/ti/Kconfig | 4 +-
drivers/net/ethernet/via/Kconfig | 5 +-
drivers/net/fddi/Kconfig | 4 +-
drivers/net/hamradio/Kconfig | 6 +-
drivers/net/wan/Kconfig | 2 +-
drivers/net/wireless/atmel/Kconfig | 4 +-
drivers/net/wireless/intersil/hostap/Kconfig | 4 +-
drivers/parport/Kconfig | 2 +-
drivers/pci/Kconfig | 11 ++
drivers/pci/pci-sysfs.c | 16 +++
drivers/pci/quirks.c | 2 +
drivers/pcmcia/Kconfig | 2 +-
drivers/platform/chrome/Kconfig | 1 +
drivers/platform/chrome/wilco_ec/Kconfig | 1 +
drivers/pnp/isapnp/Kconfig | 2 +-
drivers/power/reset/Kconfig | 1 +
drivers/rtc/Kconfig | 4 +-
drivers/scsi/Kconfig | 21 +--
drivers/scsi/aic7xxx/Kconfig.aic79xx | 2 +-
drivers/scsi/aic7xxx/Kconfig.aic7xxx | 2 +-
drivers/scsi/aic94xx/Kconfig | 2 +-
drivers/scsi/megaraid/Kconfig.megaraid | 2 +-
drivers/scsi/mvsas/Kconfig | 2 +-
drivers/scsi/qla2xxx/Kconfig | 2 +-
drivers/spi/Kconfig | 1 +
drivers/staging/sm750fb/Kconfig | 2 +-
drivers/staging/vt6655/Kconfig | 2 +-
drivers/tty/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/usb/core/hcd-pci.c | 3 +-
drivers/usb/host/Kconfig | 4 +-
drivers/usb/host/pci-quirks.c | 127 ++++++++++---------
drivers/usb/host/pci-quirks.h | 33 +++--
drivers/usb/host/uhci-hcd.c | 2 +-
drivers/usb/host/uhci-hcd.h | 77 +++++++----
drivers/video/fbdev/Kconfig | 23 ++--
drivers/watchdog/Kconfig | 6 +-
include/asm-generic/io.h | 5 +
include/linux/gameport.h | 9 +-
include/linux/parport.h | 2 +-
include/video/vga.h | 8 ++
lib/Kconfig | 4 +
lib/Kconfig.kgdb | 1 +
sound/drivers/Kconfig | 3 +
sound/pci/Kconfig | 43 +++++--
102 files changed, 532 insertions(+), 250 deletions(-)
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-27 16:42 ` Niklas Schnelle
(?)
(?)
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Mauro Carvalho Chehab, Sathya Prakash,
Sreekanth Reddy, Suganath Prabu Subramani, Michael Grzeschik,
David S. Miller, Jakub Kicinski, Jesse Brandeburg, Tony Nguyen,
Kalle Valo, Jouni Malinen, James E.J. Bottomley,
Martin K. Petersen, Hannes Reinecke, Kashyap Desai, Sumit Saxena,
Shivasharan S, Nilesh Javali, GR-QLogic-Storage-Upstream,
Mark Brown, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
Forest Bond, Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela,
Takashi Iwai
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-ide, linux-gpio, linux-hwmon, linux-i2c, linux-input,
netdev, linux-media, MPT-FusionLinux.pdl, linux-scsi,
intel-wired-lan, linux-wireless, megaraidlinux.pdl, linux-spi,
linux-fbdev, linux-staging, linux-serial, dri-devel,
linux-watchdog, alsa-devel
Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
PCI devices including those attached to a PCI-to-PCI Express bridge and
PCI Express devices using legacy I/O spaces. Note that this is different
from non PCI uses of I/O ports such as by ACPI.
Add dependencies on LEGACY_PCI for all PCI drivers which only target
legacy PCI devices and ifdef legacy PCI specific functions in ata
handling.
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>
---
drivers/ata/Kconfig | 34 ++++++++--------
drivers/ata/ata_generic.c | 3 +-
drivers/ata/libata-sff.c | 2 +
drivers/comedi/Kconfig | 42 +++++++++++++++++++
drivers/gpio/Kconfig | 2 +-
drivers/hwmon/Kconfig | 6 +--
drivers/i2c/busses/Kconfig | 24 +++++------
drivers/input/gameport/Kconfig | 4 +-
drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
drivers/media/cec/platform/Kconfig | 2 +-
drivers/media/pci/dm1105/Kconfig | 2 +-
drivers/media/radio/Kconfig | 2 +-
drivers/message/fusion/Kconfig | 8 ++--
drivers/net/arcnet/Kconfig | 2 +-
drivers/net/ethernet/8390/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 4 +-
drivers/net/ethernet/sis/Kconfig | 6 +--
drivers/net/ethernet/ti/Kconfig | 4 +-
drivers/net/ethernet/via/Kconfig | 4 +-
drivers/net/fddi/Kconfig | 4 +-
drivers/net/wan/Kconfig | 2 +-
drivers/net/wireless/atmel/Kconfig | 4 +-
drivers/net/wireless/intersil/hostap/Kconfig | 4 +-
drivers/pci/Kconfig | 11 +++++
drivers/scsi/Kconfig | 20 ++++-----
drivers/scsi/aic7xxx/Kconfig.aic79xx | 2 +-
drivers/scsi/aic7xxx/Kconfig.aic7xxx | 2 +-
drivers/scsi/aic94xx/Kconfig | 2 +-
drivers/scsi/megaraid/Kconfig.megaraid | 2 +-
drivers/scsi/mvsas/Kconfig | 2 +-
drivers/scsi/qla2xxx/Kconfig | 2 +-
drivers/spi/Kconfig | 1 +
drivers/staging/sm750fb/Kconfig | 2 +-
drivers/staging/vt6655/Kconfig | 2 +-
drivers/tty/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 22 +++++-----
drivers/watchdog/Kconfig | 4 +-
sound/pci/Kconfig | 43 ++++++++++++++++----
40 files changed, 194 insertions(+), 110 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7da8ea7b3ed..32e0489bd01c 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -556,7 +556,7 @@ comment "PATA SFF controllers with BMDMA"
config PATA_ALI
tristate "ALi PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the ALi ATA interfaces
@@ -566,7 +566,7 @@ config PATA_ALI
config PATA_AMD
tristate "AMD/NVidia PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the AMD and NVidia PATA
@@ -584,7 +584,7 @@ config PATA_ARASAN_CF
config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for ARTOP PATA controllers.
@@ -621,7 +621,7 @@ config PATA_BK3710
config PATA_CMD64X
tristate "CMD64x PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD64x series chips
@@ -667,7 +667,7 @@ config PATA_CS5536
config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the Cypress/Contaq CY82C693
@@ -707,7 +707,7 @@ config PATA_FTIDE010
config PATA_HPT366
tristate "HPT 366/368 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the HPT 366 and 368
PATA controllers via the new ATA layer.
@@ -716,7 +716,7 @@ config PATA_HPT366
config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the majority of the later HPT
PATA controllers via the new ATA layer.
@@ -725,7 +725,7 @@ config PATA_HPT37X
config PATA_HPT3X2N
tristate "HPT 371N/372N/302N PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the N variant HPT PATA
controllers via the new ATA layer.
@@ -828,7 +828,7 @@ config PATA_MPC52xx
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Netcell Revolution RAID
PATA controller.
@@ -864,7 +864,7 @@ config PATA_OLDPIIX
config PATA_OPTIDMA
tristate "OPTI FireStar PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables DMA/PIO support for the later OPTi
controllers found on some old motherboards and in some
@@ -874,7 +874,7 @@ config PATA_OPTIDMA
config PATA_PDC2027X
tristate "Promise PATA 2027x support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for Promise PATA pdc20268 to pdc20277 host adapters.
@@ -882,7 +882,7 @@ config PATA_PDC2027X
config PATA_PDC_OLD
tristate "Older Promise PATA controller support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.
@@ -910,7 +910,7 @@ config PATA_RDC
config PATA_SC1200
tristate "SC1200 PATA support"
- depends on PCI && (X86_32 || COMPILE_TEST)
+ depends on LEGACY_PCI && (X86_32 || COMPILE_TEST)
help
This option enables support for the NatSemi/AMD SC1200 SoC
companion chip used with the Geode processor family.
@@ -928,7 +928,7 @@ config PATA_SCH
config PATA_SERVERWORKS
tristate "SERVERWORKS OSB4/CSB5/CSB6/HT1000 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Serverworks OSB4/CSB5/CSB6 and
HT1000 PATA controllers, via the new ATA layer.
@@ -1005,7 +1005,7 @@ comment "PIO-only SFF controllers"
config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD640 PCI IDE
@@ -1086,7 +1086,7 @@ config PATA_NS87410
config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables full PIO support for the early Opti ATA
controllers found on some old motherboards.
@@ -1197,7 +1197,7 @@ config ATA_GENERIC
config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
- depends on (ISA || PCI)
+ depends on (ISA || LEGACY_PCI)
select PATA_TIMINGS
help
This option enables support for ISA/VLB/PCI bus legacy PATA
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 20a32e4d501d..791942217e2c 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -197,7 +197,8 @@ static int ata_generic_init_one(struct pci_dev *dev, const struct pci_device_id
if (!(command & PCI_COMMAND_IO))
return -ENODEV;
- if (dev->vendor == PCI_VENDOR_ID_AL)
+ if (IS_ENABLED(CONFIG_LEGACY_PCI) &&
+ dev->vendor == PCI_VENDOR_ID_AL)
ata_pci_bmdma_clear_simplex(dev);
if (dev->vendor == PCI_VENDOR_ID_ATI) {
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index b71ea4a680b0..636848ab6839 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -3107,6 +3107,7 @@ EXPORT_SYMBOL_GPL(ata_bmdma_port_start32);
#ifdef CONFIG_PCI
+#ifdef CONFIG_LEGACY_PCI
/**
* ata_pci_bmdma_clear_simplex - attempt to kick device out of simplex
* @pdev: PCI device
@@ -3132,6 +3133,7 @@ int ata_pci_bmdma_clear_simplex(struct pci_dev *pdev)
return 0;
}
EXPORT_SYMBOL_GPL(ata_pci_bmdma_clear_simplex);
+#endif
static void ata_bmdma_nodma(struct ata_host *host, const char *reason)
{
diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 3cb61fa2c5c3..1b642716c5d3 100644
--- a/drivers/comedi/Kconfig
+++ b/drivers/comedi/Kconfig
@@ -572,6 +572,7 @@ if COMEDI_PCI_DRIVERS
config COMEDI_8255_PCI
tristate "Generic PCI based 8255 digital i/o board support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for PCI based 8255 digital i/o boards. This driver
@@ -589,6 +590,7 @@ config COMEDI_8255_PCI
config COMEDI_ADDI_WATCHDOG
tristate
+ depends on LEGACY_PCI
help
Provides support for the watchdog subdevice found on many ADDI-DATA
boards. This module will be automatically selected when needed. The
@@ -596,6 +598,7 @@ config COMEDI_ADDI_WATCHDOG
config COMEDI_ADDI_APCI_1032
tristate "ADDI-DATA APCI_1032 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1032 cards
@@ -604,6 +607,7 @@ config COMEDI_ADDI_APCI_1032
config COMEDI_ADDI_APCI_1500
tristate "ADDI-DATA APCI_1500 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1500 cards
@@ -612,6 +616,7 @@ config COMEDI_ADDI_APCI_1500
config COMEDI_ADDI_APCI_1516
tristate "ADDI-DATA APCI-1016/1516/2016 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI-1016, APCI-1516 and APCI-2016 boards.
@@ -623,6 +628,7 @@ config COMEDI_ADDI_APCI_1516
config COMEDI_ADDI_APCI_1564
tristate "ADDI-DATA APCI_1564 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_1564 cards
@@ -632,6 +638,7 @@ config COMEDI_ADDI_APCI_1564
config COMEDI_ADDI_APCI_16XX
tristate "ADDI-DATA APCI_16xx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_16xx cards
@@ -640,6 +647,7 @@ config COMEDI_ADDI_APCI_16XX
config COMEDI_ADDI_APCI_2032
tristate "ADDI-DATA APCI_2032 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2032 cards
@@ -649,6 +657,7 @@ config COMEDI_ADDI_APCI_2032
config COMEDI_ADDI_APCI_2200
tristate "ADDI-DATA APCI_2200 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2200 cards
@@ -658,6 +667,7 @@ config COMEDI_ADDI_APCI_2200
config COMEDI_ADDI_APCI_3120
tristate "ADDI-DATA APCI_3120/3001 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
help
Enable support for ADDI-DATA APCI_3120/3001 cards
@@ -667,6 +677,7 @@ config COMEDI_ADDI_APCI_3120
config COMEDI_ADDI_APCI_3501
tristate "ADDI-DATA APCI_3501 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3501 cards
@@ -675,6 +686,7 @@ config COMEDI_ADDI_APCI_3501
config COMEDI_ADDI_APCI_3XXX
tristate "ADDI-DATA APCI_3xxx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3xxx cards
@@ -683,6 +695,7 @@ config COMEDI_ADDI_APCI_3XXX
config COMEDI_ADL_PCI6208
tristate "ADLink PCI-6208A support"
+ depends on LEGACY_PCI
help
Enable support for ADLink PCI-6208A cards
@@ -691,6 +704,7 @@ config COMEDI_ADL_PCI6208
config COMEDI_ADL_PCI7X3X
tristate "ADLink PCI-723X/743X isolated digital i/o board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-723X/743X isolated digital i/o boards.
Supported boards include the 32-channel PCI-7230 (16 in/16 out),
@@ -702,6 +716,7 @@ config COMEDI_ADL_PCI7X3X
config COMEDI_ADL_PCI8164
tristate "ADLink PCI-8164 4 Axes Motion Control board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-8164 4 Axes Motion Control board
@@ -710,6 +725,7 @@ config COMEDI_ADL_PCI8164
config COMEDI_ADL_PCI9111
tristate "ADLink PCI-9111HR support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for ADlink PCI9111 cards
@@ -719,6 +735,7 @@ config COMEDI_ADL_PCI9111
config COMEDI_ADL_PCI9118
tristate "ADLink PCI-9118DG, PCI-9118HG, PCI-9118HR support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_8254
help
@@ -729,6 +746,7 @@ config COMEDI_ADL_PCI9118
config COMEDI_ADV_PCI1710
tristate "Advantech PCI-171x and PCI-1731 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Advantech PCI-1710, PCI-1710HG, PCI-1711,
@@ -739,6 +757,7 @@ config COMEDI_ADV_PCI1710
config COMEDI_ADV_PCI1720
tristate "Advantech PCI-1720 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1720 Analog Output board.
@@ -747,6 +766,7 @@ config COMEDI_ADV_PCI1720
config COMEDI_ADV_PCI1723
tristate "Advantech PCI-1723 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1723 cards
@@ -755,6 +775,7 @@ config COMEDI_ADV_PCI1723
config COMEDI_ADV_PCI1724
tristate "Advantech PCI-1724U support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1724U cards. These are 32-channel
analog output cards with voltage and current loop output ranges and
@@ -765,6 +786,7 @@ config COMEDI_ADV_PCI1724
config COMEDI_ADV_PCI1760
tristate "Advantech PCI-1760 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1760 board.
@@ -773,6 +795,7 @@ config COMEDI_ADV_PCI1760
config COMEDI_ADV_PCI_DIO
tristate "Advantech PCI DIO card support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -786,6 +809,7 @@ config COMEDI_ADV_PCI_DIO
config COMEDI_AMPLC_DIO200_PCI
tristate "Amplicon PCI215/PCI272/PCIe215/PCIe236/PCIe296 DIO support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_DIO200
help
Enable support for Amplicon PCI215, PCI272, PCIe215, PCIe236
@@ -796,6 +820,7 @@ config COMEDI_AMPLC_DIO200_PCI
config COMEDI_AMPLC_PC236_PCI
tristate "Amplicon PCI236 DIO board support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_PC236
help
Enable support for Amplicon PCI236 DIO board.
@@ -805,6 +830,7 @@ config COMEDI_AMPLC_PC236_PCI
config COMEDI_AMPLC_PC263_PCI
tristate "Amplicon PCI263 relay board support"
+ depends on LEGACY_PCI
help
Enable support for Amplicon PCI263 relay board. This is a PCI board
with 16 reed relay output channels.
@@ -814,6 +840,7 @@ config COMEDI_AMPLC_PC263_PCI
config COMEDI_AMPLC_PCI224
tristate "Amplicon PCI224 and PCI234 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Amplicon PCI224 and PCI234 AO boards
@@ -823,6 +850,7 @@ config COMEDI_AMPLC_PCI224
config COMEDI_AMPLC_PCI230
tristate "Amplicon PCI230 and PCI260 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -834,6 +862,7 @@ config COMEDI_AMPLC_PCI230
config COMEDI_CONTEC_PCI_DIO
tristate "Contec PIO1616L digital I/O board support"
+ depends on LEGACY_PCI
help
Enable support for the Contec PIO1616L digital I/O board
@@ -842,6 +871,7 @@ config COMEDI_CONTEC_PCI_DIO
config COMEDI_DAS08_PCI
tristate "DAS-08 PCI support"
+ depends on LEGACY_PCI
select COMEDI_DAS08
help
Enable support for PCI DAS-08 cards.
@@ -861,6 +891,7 @@ config COMEDI_DT3000
config COMEDI_DYNA_PCI10XX
tristate "Dynalog PCI DAQ series support"
+ depends on LEGACY_PCI
help
Enable support for Dynalog PCI DAQ series
PCI-1050
@@ -894,6 +925,7 @@ config COMEDI_ICP_MULTI
config COMEDI_DAQBOARD2000
tristate "IOtech DAQboard/2000 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for the IOtech DAQboard/2000
@@ -911,6 +943,7 @@ config COMEDI_JR3_PCI
config COMEDI_KE_COUNTER
tristate "Kolter-Electronic PCI Counter 1 card support"
+ depends on LEGACY_PCI
help
Enable support for Kolter-Electronic PCI Counter 1 cards
@@ -919,6 +952,7 @@ config COMEDI_KE_COUNTER
config COMEDI_CB_PCIDAS64
tristate "MeasurementComputing PCI-DAS 64xx, 60xx, and 4020 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DAS 64xx,
@@ -929,6 +963,7 @@ config COMEDI_CB_PCIDAS64
config COMEDI_CB_PCIDAS
tristate "MeasurementComputing PCI-DAS support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -942,6 +977,7 @@ config COMEDI_CB_PCIDAS
config COMEDI_CB_PCIDDA
tristate "MeasurementComputing PCI-DDA series support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DDA
@@ -953,6 +989,7 @@ config COMEDI_CB_PCIDDA
config COMEDI_CB_PCIMDAS
tristate "MeasurementComputing PCIM-DAS1602/16, PCIe-DAS1602/16 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -964,6 +1001,7 @@ config COMEDI_CB_PCIMDAS
config COMEDI_CB_PCIMDDA
tristate "MeasurementComputing PCIM-DDA06-16 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCIM-DDA06-16
@@ -973,6 +1011,7 @@ config COMEDI_CB_PCIMDDA
config COMEDI_ME4000
tristate "Meilhaus ME-4000 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Meilhaus PCI data acquisition cards
@@ -1031,6 +1070,7 @@ config COMEDI_NI_670X
config COMEDI_NI_LABPC_PCI
tristate "NI Lab-PC PCI-1200 support"
+ depends on LEGACY_PCI
select COMEDI_NI_LABPC
help
Enable support for National Instruments Lab-PC PCI-1200.
@@ -1040,6 +1080,7 @@ config COMEDI_NI_LABPC_PCI
config COMEDI_NI_PCIDIO
tristate "NI PCI-DIO32HS, PCI-6533, PCI-6534 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_MITE
select COMEDI_8255
@@ -1052,6 +1093,7 @@ config COMEDI_NI_PCIDIO
config COMEDI_NI_PCIMIO
tristate "NI PCI-MIO-E series and M series support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_NI_TIOCMD
select COMEDI_8255
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 60d9374c72c0..d36afa5ac6fc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -687,7 +687,7 @@ config GPIO_VR41XX
config GPIO_VX855
tristate "VIA VX855/VX875 GPIO"
- depends on (X86 || COMPILE_TEST) && PCI
+ depends on (X86 || COMPILE_TEST) && LEGACY_PCI
select MFD_CORE
select MFD_VX855
help
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 64bd3dfba2c4..09397562c396 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1654,7 +1654,7 @@ config SENSORS_S3C_RAW
config SENSORS_SIS5595
tristate "Silicon Integrated Systems Corp. SiS5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
SiS5595 South Bridges.
@@ -1985,7 +1985,7 @@ config SENSORS_VIA_CPUTEMP
config SENSORS_VIA686A
tristate "VIA686A"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
Via 686A/B South Bridges.
@@ -2006,7 +2006,7 @@ config SENSORS_VT1211
config SENSORS_VT8231
tristate "VIA VT8231"
- depends on PCI
+ depends on LEGACY_PCI
select HWMON_VID
help
If you say yes here then you get support for the integrated sensors
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index dce392839017..a8d6274dc965 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -11,7 +11,7 @@ comment "PC SMBus host controller drivers"
config I2C_ALI1535
tristate "ALI 1535"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1535 South Bridges. The SMB
@@ -23,7 +23,7 @@ config I2C_ALI1535
config I2C_ALI1563
tristate "ALI 1563"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1563 South Bridges. The SMB
@@ -35,7 +35,7 @@ config I2C_ALI1563
config I2C_ALI15X3
tristate "ALI 15x3"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
Acer Labs Inc. (ALI) M1514 and M1543 motherboard I2C interfaces.
@@ -45,7 +45,7 @@ config I2C_ALI15X3
config I2C_AMD756
tristate "AMD 756/766/768/8111 and nVidia nForce"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the AMD
756/766/768 mainboard I2C interfaces. The driver also includes
@@ -70,7 +70,7 @@ config I2C_AMD756_S4882
config I2C_AMD8111
tristate "AMD 8111"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
second (SMBus 2.0) AMD 8111 mainboard I2C interface.
@@ -154,7 +154,7 @@ config I2C_I801
config I2C_ISCH
tristate "Intel SCH SMBus 1.0"
- depends on PCI
+ depends on LEGACY_PCI
select LPC_SCH
help
Say Y here if you want to use SMBus controller on the Intel SCH
@@ -221,7 +221,7 @@ config I2C_CHT_WC
config I2C_NFORCE2
tristate "Nvidia nForce2, nForce3 and nForce4"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the Nvidia
nForce2, nForce3 and nForce4 families of mainboard I2C interfaces.
@@ -253,7 +253,7 @@ config I2C_NVIDIA_GPU
config I2C_SIS5595
tristate "SiS 5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS5595 SMBus (a subset of I2C) interface.
@@ -263,7 +263,7 @@ config I2C_SIS5595
config I2C_SIS630
tristate "SiS 630/730/964"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS630, SiS730 and SiS964 SMBus (a subset of I2C) interface.
@@ -273,7 +273,7 @@ config I2C_SIS630
config I2C_SIS96X
tristate "SiS 96x"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SiS
96x SMBus (a subset of I2C) interfaces. Specifically, the following
@@ -291,7 +291,7 @@ config I2C_SIS96X
config I2C_VIA
tristate "VIA VT82C586B"
- depends on PCI
+ depends on LEGACY_PCI
select I2C_ALGOBIT
help
If you say yes to this option, support will be included for the VIA
@@ -302,7 +302,7 @@ config I2C_VIA
config I2C_VIAPRO
tristate "VIA VT82C596/82C686/82xx and CX700/VX8xx/VX900"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the VIA
VT82C596 and later SMBus interface. Specifically, the following
diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 5a2c2fb3217d..082280f95333 100644
--- a/drivers/input/gameport/Kconfig
+++ b/drivers/input/gameport/Kconfig
@@ -43,7 +43,7 @@ config GAMEPORT_L4
config GAMEPORT_EMU10K1
tristate "SB Live and Audigy gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have a SoundBlaster Live! or SoundBlaster
Audigy card and want to use its gameport.
@@ -53,7 +53,7 @@ config GAMEPORT_EMU10K1
config GAMEPORT_FM801
tristate "ForteMedia FM801 gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have ForteMedia FM801 PCI audio controller
(Abit AU10, Genius Sound Maker, HP Workstation zx2000,
diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig
index 078eeadf707a..2c5e16483179 100644
--- a/drivers/isdn/hardware/mISDN/Kconfig
+++ b/drivers/isdn/hardware/mISDN/Kconfig
@@ -7,14 +7,14 @@ comment "mISDN hardware drivers"
config MISDN_HFCPCI
tristate "Support for HFC PCI cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for cards with Cologne Chip AG's
HFC PCI chip.
config MISDN_HFCMULTI
tristate "Support for HFC multiport cards (HFC-4S/8S/E1)"
- depends on PCI || CPM1
+ depends on LEGACY_PCI || CPM1
depends on MISDN
help
Enable support for cards with Cologne Chip AG's HFC multiport
@@ -43,7 +43,7 @@ config MISDN_HFCUSB
config MISDN_AVMFRITZ
tristate "Support for AVM FRITZ!CARD PCI"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for AVMs FRITZ!CARD PCI cards
@@ -51,7 +51,7 @@ config MISDN_AVMFRITZ
config MISDN_SPEEDFAX
tristate "Support for Sedlbauer Speedfax+"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
select MISDN_ISAR
help
@@ -60,7 +60,7 @@ config MISDN_SPEEDFAX
config MISDN_INFINEON
tristate "Support for cards with Infineon chipset"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for cards with ISAC + HSCX, IPAC or IPAC-SX
@@ -69,14 +69,14 @@ config MISDN_INFINEON
config MISDN_W6692
tristate "Support for cards with Winbond 6692"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for Winbond 6692 PCI chip based cards.
config MISDN_NETJET
tristate "Support for NETJet cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
depends on TTY
select MISDN_IPAC
select MISDN_HDLC
diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
index b672d3142eb7..5e92ece5b104 100644
--- a/drivers/media/cec/platform/Kconfig
+++ b/drivers/media/cec/platform/Kconfig
@@ -100,7 +100,7 @@ config CEC_TEGRA
config CEC_SECO
tristate "SECO Boards HDMI CEC driver"
depends on (X86 || IA64) || COMPILE_TEST
- depends on PCI && DMI
+ depends on LEGACY_PCI && DMI
select CEC_CORE
select CEC_NOTIFIER
help
diff --git a/drivers/media/pci/dm1105/Kconfig b/drivers/media/pci/dm1105/Kconfig
index e0e3af67c99c..9ecab93685d4 100644
--- a/drivers/media/pci/dm1105/Kconfig
+++ b/drivers/media/pci/dm1105/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
- depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
+ depends on DVB_CORE && LEGACY_PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index d29e29645e04..32eb73993998 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -67,7 +67,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate "Guillemot MAXI Radio FM 2000 radio"
- depends on VIDEO_V4L2 && PCI
+ depends on VIDEO_V4L2 && LEGACY_PCI
select RADIO_TEA575X
help
Choose Y here if you have this radio card. This card may also be
diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index a3d0288fd0e2..cec5995e1911 100644
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -2,7 +2,7 @@
menuconfig FUSION
bool "Fusion MPT device support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here to get to see options for Fusion Message
Passing Technology (MPT) drivers.
@@ -14,7 +14,7 @@ if FUSION
config FUSION_SPI
tristate "Fusion MPT ScsiHost drivers for SPI"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
SCSI HOST support for a parallel SCSI host adapters.
@@ -29,7 +29,7 @@ config FUSION_SPI
config FUSION_FC
tristate "Fusion MPT ScsiHost drivers for FC"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
help
SCSI HOST support for a Fiber Channel host adapters.
@@ -48,7 +48,7 @@ config FUSION_FC
config FUSION_SAS
tristate "Fusion MPT ScsiHost drivers for SAS"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SAS_ATTRS
help
SCSI HOST support for a SAS host adapters.
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..b8038287c4f2 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -4,7 +4,7 @@
#
menuconfig ARCNET
- depends on NETDEVICES && (ISA || PCI || PCMCIA)
+ depends on NETDEVICES && (ISA || LEGACY_PCI || PCMCIA)
tristate "ARCnet support"
help
If you have a network card of this type, say Y and check out the
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..0fa43943ea74 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -117,7 +117,7 @@ config NE2000
config NE2K_PCI
tristate "PCI NE2000 and clones support (see help)"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
help
This driver is for NE2000 compatible PCI cards. It will not work
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 899c8a2a34b6..0ac61a5f1a37 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -56,7 +56,7 @@ config LANCE
config PCNET32
tristate "AMD PCnet32 PCI support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 0b274d8fa45b..45a3c42945fc 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_INTEL
config E100
tristate "Intel(R) PRO/100+ support"
- depends on PCI
+ depends on LEGACY_PCI
select MII
help
This driver supports Intel(R) PRO/100 family of adapters.
@@ -41,7 +41,7 @@ config E100
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
help
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
diff --git a/drivers/net/ethernet/sis/Kconfig b/drivers/net/ethernet/sis/Kconfig
index 775d76d9890e..bd1b1b81b0e8 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_SIS
bool "Silicon Integrated Systems (SiS) devices"
default y
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
config SIS900
tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
@@ -35,7 +35,7 @@ config SIS900
config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..8b1d67b00e68 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_TI
bool "Texas Instruments (TI) devices"
default y
- depends on PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ depends on LEGACY_PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
config TLAN
tristate "TI ThunderLAN support"
- depends on (PCI || EISA)
+ depends on (LEGACY_PCI || EISA)
help
If you have a PCI Ethernet network card based on the ThunderLAN chip
which is supported by this driver, say Y here.
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index da287ef65be7..0ca7d8f7bfde 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -18,8 +18,8 @@ if NET_VENDOR_VIA
config VIA_RHINE
tristate "VIA Rhine support"
- depends on PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
- depends on PCI || ARCH_VT8500 || COMPILE_TEST
+ depends on LEGACY_PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
+ depends on LEGACY_PCI || ARCH_VT8500 || COMPILE_TEST
depends on HAS_DMA
select CRC32
select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..1753c08d6423 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -5,7 +5,7 @@
config FDDI
tristate "FDDI driver support"
- depends on PCI || EISA || TC
+ depends on LEGACY_PCI || EISA || TC
help
Fiber Distributed Data Interface is a high speed local area network
design; essentially a replacement for high speed Ethernet. FDDI can
@@ -29,7 +29,7 @@ config DEFZA
config DEFXX
tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
- depends on FDDI && (PCI || EISA || TC)
+ depends on FDDI && (LEGACY_PCI || EISA || TC)
help
This is support for the DIGITAL series of TURBOchannel (DEFTA),
EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 592a8389fc5a..631c4c1c56c8 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -250,7 +250,7 @@ config C101
config FARSYNC
tristate "FarSync T-Series support"
- depends on HDLC && PCI
+ depends on HDLC && LEGACY_PCI
help
Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
FarSite Communications Ltd.
diff --git a/drivers/net/wireless/atmel/Kconfig b/drivers/net/wireless/atmel/Kconfig
index ca45a1021cf4..9baa4a19dd38 100644
--- a/drivers/net/wireless/atmel/Kconfig
+++ b/drivers/net/wireless/atmel/Kconfig
@@ -14,7 +14,7 @@ if WLAN_VENDOR_ATMEL
config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
- depends on CFG80211 && (PCI || PCMCIA)
+ depends on CFG80211 && (LEGACY_PCI || PCMCIA)
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
@@ -32,7 +32,7 @@ config ATMEL
config PCI_ATMEL
tristate "Atmel at76c506 PCI cards"
- depends on ATMEL && PCI
+ depends on ATMEL && LEGACY_PCI
help
Enable support for PCI and mini-PCI cards containing the
Atmel at76c506 chip.
diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig
index c865d3156cea..9bcd1c8546ff 100644
--- a/drivers/net/wireless/intersil/hostap/Kconfig
+++ b/drivers/net/wireless/intersil/hostap/Kconfig
@@ -56,7 +56,7 @@ config HOSTAP_FIRMWARE_NVRAM
config HOSTAP_PLX
tristate "Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2/2.5/3 PC Cards in PLX9052 based
PCI adaptors.
@@ -70,7 +70,7 @@ config HOSTAP_PLX
config HOSTAP_PCI
tristate "Host AP driver for Prism2.5 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2.5 PCI adaptors.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 43e615aa12ff..e0c99ddc145c 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -23,6 +23,17 @@ menuconfig PCI
if PCI
+config LEGACY_PCI
+ bool "Enable support for legacy PCI devices"
+ depends on HAVE_PCI
+ help
+ This option enables support for legacy PCI devices. This includes
+ PCI devices attached directly or via a bridge on a PCI Express bus.
+ It also includes compatibility features on PCI Express devices which
+ make use of legacy I/O spaces.
+
+ For maximum compatibility with old hardware say 'Y'
+
config PCI_DOMAINS
bool
depends on PCI
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..5436b2be2c73 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -333,7 +333,7 @@ config SGIWD93_SCSI
config BLK_DEV_3W_XXXX_RAID
tristate "3ware 5/6/7/8xxx ATA-RAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
3ware is the only hardware ATA-Raid product in Linux to date.
This card is 2,4, or 8 channel master mode support only.
@@ -380,7 +380,7 @@ config SCSI_3W_SAS
config SCSI_ACARD
tristate "ACARD SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the ACARD SCSI host adapter.
Support Chip <ATP870 ATP876 ATP880 ATP885>
@@ -472,7 +472,7 @@ config SCSI_DPT_I2O
config SCSI_ADVANSYS
tristate "AdvanSys SCSI support"
depends on SCSI
- depends on ISA || EISA || PCI
+ depends on ISA || EISA || LEGACY_PCI
depends on ISA_DMA_API || !ISA
help
This is a driver for all SCSI host adapters manufactured by
@@ -643,7 +643,7 @@ config SCSI_SNIC_DEBUG_FS
config SCSI_DMX3191D
tristate "DMX3191D SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This is support for Domex DMX3191D SCSI Host Adapters.
@@ -657,7 +657,7 @@ config SCSI_FDOMAIN
config SCSI_FDOMAIN_PCI
tristate "Future Domain TMC-3260/AHA-2920A PCI SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_FDOMAIN
help
This is support for Future Domain's PCI SCSI host adapters (TMC-3260)
@@ -710,7 +710,7 @@ config SCSI_GENERIC_NCR5380
config SCSI_IPS
tristate "IBM ServeRAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the IBM ServeRAID hardware RAID controllers.
See <http://www.developer.ibm.com/welcome/netfinity/serveraid.html>
@@ -770,7 +770,7 @@ config SCSI_IBMVFC_TRACE
config SCSI_INITIO
tristate "Initio 9100U(W) support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio 91XXU(W) SCSI host adapter. Please
read the SCSI-HOWTO, available from
@@ -781,7 +781,7 @@ config SCSI_INITIO
config SCSI_INIA100
tristate "Initio INI-A100U2W support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio INI-A100U2W SCSI host adapter.
Please read the SCSI-HOWTO, available from
@@ -1130,7 +1130,7 @@ config SCSI_QLOGIC_FAS
config SCSI_QLOGIC_1280
tristate "Qlogic QLA 1240/1x80/1x160 SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
Say Y if you have a QLogic ISP1240/1x80/1x160 SCSI host adapter.
@@ -1187,7 +1187,7 @@ config SCSI_SIM710
config SCSI_DC395x
tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports PCI SCSI host adapters based on the ASIC
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic79xx b/drivers/scsi/aic7xxx/Kconfig.aic79xx
index a47dbd500e9a..64332cc73ea0 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic79xx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic79xx
@@ -5,7 +5,7 @@
#
config SCSI_AIC79XX
tristate "Adaptec AIC79xx U320 support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Ultra 320 PCI-X
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic7xxx b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
index 0cfd92ce750a..3fa5dc1d1186 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic7xxx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
@@ -5,7 +5,7 @@
#
config SCSI_AIC7XXX
tristate "Adaptec AIC7xxx Fast -> U160 support"
- depends on (PCI || EISA) && SCSI
+ depends on (LEGACY_PCI || EISA) && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Fast through Ultra 160 PCI
diff --git a/drivers/scsi/aic94xx/Kconfig b/drivers/scsi/aic94xx/Kconfig
index 71931c371b1c..b0cbf65dbe5b 100644
--- a/drivers/scsi/aic94xx/Kconfig
+++ b/drivers/scsi/aic94xx/Kconfig
@@ -8,7 +8,7 @@
config SCSI_AIC94XX
tristate "Adaptec AIC94xx SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
index 2adc2afd9f91..4ec46aede490 100644
--- a/drivers/scsi/megaraid/Kconfig.megaraid
+++ b/drivers/scsi/megaraid/Kconfig.megaraid
@@ -67,7 +67,7 @@ config MEGARAID_MAILBOX
config MEGARAID_LEGACY
tristate "LSI Logic Legacy MegaRAID Driver"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the LSI MegaRAID 418, 428, 438, 466, 762, 490
and 467 SCSI host adapters. This driver also support the all U320
diff --git a/drivers/scsi/mvsas/Kconfig b/drivers/scsi/mvsas/Kconfig
index 79812b80743b..f41f3f4a9f34 100644
--- a/drivers/scsi/mvsas/Kconfig
+++ b/drivers/scsi/mvsas/Kconfig
@@ -9,7 +9,7 @@
config SCSI_MVSAS
tristate "Marvell 88SE64XX/88SE94XX SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 802c373fd6d9..93afb73858ce 100644
--- a/drivers/scsi/qla2xxx/Kconfig
+++ b/drivers/scsi/qla2xxx/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
depends on NVME_FC || !NVME_FC
select FW_LOADER
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 596705d24400..cfbd45767095 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -204,6 +204,7 @@ config SPI_BITBANG
config SPI_BUTTERFLY
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
depends on PARPORT
+ depends on HAS_IOPORT
select SPI_BITBANG
help
This uses a custom parallel port cable to connect to an AVR
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 8c0d8a873d5b..d332f912b964 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/staging/vt6655/Kconfig b/drivers/staging/vt6655/Kconfig
index d1cd5de46dcf..dd236f54d3a2 100644
--- a/drivers/staging/vt6655/Kconfig
+++ b/drivers/staging/vt6655/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
config VT6655
tristate "VIA Technologies VT6655 support"
- depends on PCI && MAC80211 && m
+ depends on LEGACY_PCI && MAC80211 && m
help
This is a vendor-written driver for VIA VT6655.
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc30ff93e2e4..460326a529d6 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -203,7 +203,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on SERIAL_NONSTANDARD && LEGACY_PCI
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index fc543ac97c13..607791b7f693 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -908,7 +908,7 @@ config SERIAL_VR41XX_CONSOLE
config SERIAL_JSM
tristate "Digi International NEO and Classic PCI Support"
- depends on PCI
+ depends on LEGACY_PCI
select SERIAL_CORE
help
This is a driver for Digi International's Neo and Classic series
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6ed5e608dd04..a3446d44c118 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -343,7 +343,7 @@ config FB_IMX
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
- depends on FB && PCI && (BROKEN || !SPARC64)
+ depends on FB && LEGACY_PCI && (BROKEN || !SPARC64)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1264,7 +1264,7 @@ config FB_ATY128_BACKLIGHT
Say Y here if you want to control the backlight of your display.
config FB_ATY
- tristate "ATI Mach64 display support" if PCI || ATARI
+ tristate "ATI Mach64 display support" if LEGACY_PCI || ATARI
depends on FB && !SPARC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1315,7 +1315,7 @@ config FB_ATY_BACKLIGHT
config FB_S3
tristate "S3 Trio/Virge support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1374,7 +1374,7 @@ config FB_SAVAGE_ACCEL
config FB_SIS
tristate "SiS/XGI display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1404,7 +1404,7 @@ config FB_SIS_315
config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
- depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
+ depends on FB && LEGACY_PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1442,7 +1442,7 @@ endif
config FB_NEOMAGIC
tristate "NeoMagic display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1470,7 +1470,7 @@ config FB_KYRO
config FB_3DFX
tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1518,7 +1518,7 @@ config FB_VOODOO1
config FB_VT8623
tristate "VIA VT8623 support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1532,7 +1532,7 @@ config FB_VT8623
config FB_TRIDENT
tristate "Trident/CyberXXX/CyberBlade support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1554,7 +1554,7 @@ config FB_TRIDENT
config FB_ARK
tristate "ARK 2000PV support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2226,7 +2226,7 @@ config FB_SSD1307
config FB_SM712
tristate "Silicon Motion SM712 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9d222ba17ec6..05258109bcc2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -2053,7 +2053,7 @@ comment "PCI-based Watchdog Cards"
config PCIPCWATCHDOG
tristate "Berkshire Products PCI-PC Watchdog"
- depends on PCI
+ depends on LEGACY_PCI
help
This is the driver for the Berkshire Products PCI-PC Watchdog card.
This card simply watches your kernel to make sure it doesn't freeze,
@@ -2068,7 +2068,7 @@ config PCIPCWATCHDOG
config WDTPCI
tristate "PCI-WDT500/501 Watchdog timer"
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 41ce12597177..07d9587eede4 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -23,10 +23,10 @@ config SND_AD1889
config SND_ALS300
tristate "Avance Logic ALS300/ALS300+"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_PCM
select SND_AC97_CODEC
select SND_OPL3_LIB
- depends on ZONE_DMA
help
Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
@@ -35,6 +35,7 @@ config SND_ALS300
config SND_ALS4000
tristate "Avance Logic ALS4000"
+ depends on LEGACY_PCI
depends on ISA_DMA_API
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -49,6 +50,7 @@ config SND_ALS4000
config SND_ALI5451
tristate "ALi M5451 PCI Audio Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
depends on ZONE_DMA
@@ -96,6 +98,7 @@ config SND_ATIIXP_MODEM
config SND_AU8810
tristate "Aureal Advantage"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -110,6 +113,7 @@ config SND_AU8810
config SND_AU8820
tristate "Aureal Vortex"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -123,6 +127,7 @@ config SND_AU8820
config SND_AU8830
tristate "Aureal Vortex 2"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -151,13 +156,13 @@ config SND_AW2
config SND_AZT3328
tristate "Aztech AZF3328 / PCI168"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
- depends on ZONE_DMA
help
Say Y here to include support for Aztech AZF3328 (PCI168)
soundcards.
@@ -172,6 +177,7 @@ config SND_AZT3328
config SND_BT87X
tristate "Bt87x Audio Capture"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to record audio from TV cards based on
@@ -193,6 +199,7 @@ config SND_BT87X_OVERCLOCK
config SND_CA0106
tristate "SB Audigy LS / Live 24bit"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
select SND_VMASTER
@@ -205,6 +212,7 @@ config SND_CA0106
config SND_CMIPCI
tristate "C-Media 8338, 8738, 8768, 8770"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
@@ -221,6 +229,7 @@ config SND_OXYGEN_LIB
config SND_OXYGEN
tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -246,6 +255,7 @@ config SND_OXYGEN
config SND_CS4281
tristate "Cirrus Logic (Sound Fusion) CS4281"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_RAWMIDI
select SND_AC97_CODEC
@@ -257,6 +267,7 @@ config SND_CS4281
config SND_CS46XX
tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
select FW_LOADER
@@ -290,6 +301,7 @@ config SND_CS5530
config SND_CS5535AUDIO
tristate "CS5535/CS5536 Audio"
depends on X86_32 || MIPS || COMPILE_TEST
+ depends on LEGACY_PCI
select SND_PCM
select SND_AC97_CODEC
help
@@ -307,6 +319,7 @@ config SND_CS5535AUDIO
config SND_CTXFI
tristate "Creative Sound Blaster X-Fi"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -462,13 +475,13 @@ config SND_INDIGODJX
config SND_EMU10K1
tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
+ depends on LEGACY_PCI && ZONE_DMA
select FW_LOADER
select SND_HWDEP
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
select SND_SEQ_DEVICE if SND_SEQUENCER != n
- depends on ZONE_DMA
help
Say Y to include support for Sound Blaster PCI 512, Live!,
Audigy and E-mu APS (partially supported) soundcards.
@@ -489,6 +502,7 @@ config SND_EMU10K1_SEQ
config SND_EMU10K1X
tristate "Emu10k1X (Dell OEM Version)"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
depends on ZONE_DMA
@@ -501,6 +515,7 @@ config SND_EMU10K1X
config SND_ENS1370
tristate "(Creative) Ensoniq AudioPCI 1370"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_PCM
help
@@ -511,6 +526,7 @@ config SND_ENS1370
config SND_ENS1371
tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
help
@@ -522,10 +538,10 @@ config SND_ENS1371
config SND_ES1938
tristate "ESS ES1938/1946/1969 (Solo-1)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Solo-1
(ES1938, ES1946, ES1969) chips.
@@ -535,9 +551,9 @@ config SND_ES1938
config SND_ES1968
tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro
1/2/2E chips.
@@ -569,6 +585,7 @@ config SND_ES1968_RADIO
config SND_FM801
tristate "ForteMedia FM801"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
@@ -621,10 +638,10 @@ config SND_HDSPM
config SND_ICE1712
tristate "ICEnsemble ICE1712 (Envy24)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
select BITREVERSE
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the
ICE1712 (Envy24) chip.
@@ -640,6 +657,7 @@ config SND_ICE1712
config SND_ICE1724
tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_VMASTER
@@ -712,6 +730,7 @@ config SND_LX6464ES
config SND_MAESTRO3
tristate "ESS Allegro/Maestro3"
select SND_AC97_CODEC
+ depends on LEGACY_PCI
depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro 3
@@ -753,6 +772,7 @@ config SND_NM256
config SND_PCXHR
tristate "Digigram PCXHR"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_PCM
select SND_HWDEP
@@ -764,6 +784,7 @@ config SND_PCXHR
config SND_RIPTIDE
tristate "Conexant Riptide"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -808,6 +829,7 @@ config SND_RME9652
config SND_SE6X
tristate "Studio Evolution SE6X"
depends on SND_OXYGEN=n && SND_VIRTUOSO=n # PCI ID conflict
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -827,10 +849,10 @@ config SND_SIS7019
config SND_SONICVIBES
tristate "S3 SonicVibes"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the S3
SonicVibes chip.
@@ -840,9 +862,9 @@ config SND_SONICVIBES
config SND_TRIDENT
tristate "Trident 4D-Wave DX/NX; SiS 7018"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on Trident
4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +874,7 @@ config SND_TRIDENT
config SND_VIA82XX
tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -863,6 +886,7 @@ config SND_VIA82XX
config SND_VIA82XX_MODEM
tristate "VIA 82C686A/B, 8233 based Modems"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
help
Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +897,7 @@ config SND_VIA82XX_MODEM
config SND_VIRTUOSO
tristate "Asus Virtuoso 66/100/200 (Xonar)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -889,6 +914,7 @@ config SND_VIRTUOSO
config SND_VX222
tristate "Digigram VX222"
+ depends on LEGACY_PCI
select SND_VX_LIB
help
Say Y here to include support for Digigram VX222 soundcards.
@@ -898,6 +924,7 @@ config SND_VX222
config SND_YMFPCI
tristate "Yamaha YMF724/740/744/754"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: intel-wired-lan
Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
PCI devices including those attached to a PCI-to-PCI Express bridge and
PCI Express devices using legacy I/O spaces. Note that this is different
from non PCI uses of I/O ports such as by ACPI.
Add dependencies on LEGACY_PCI for all PCI drivers which only target
legacy PCI devices and ifdef legacy PCI specific functions in ata
handling.
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>
---
drivers/ata/Kconfig | 34 ++++++++--------
drivers/ata/ata_generic.c | 3 +-
drivers/ata/libata-sff.c | 2 +
drivers/comedi/Kconfig | 42 +++++++++++++++++++
drivers/gpio/Kconfig | 2 +-
drivers/hwmon/Kconfig | 6 +--
drivers/i2c/busses/Kconfig | 24 +++++------
drivers/input/gameport/Kconfig | 4 +-
drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
drivers/media/cec/platform/Kconfig | 2 +-
drivers/media/pci/dm1105/Kconfig | 2 +-
drivers/media/radio/Kconfig | 2 +-
drivers/message/fusion/Kconfig | 8 ++--
drivers/net/arcnet/Kconfig | 2 +-
drivers/net/ethernet/8390/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 4 +-
drivers/net/ethernet/sis/Kconfig | 6 +--
drivers/net/ethernet/ti/Kconfig | 4 +-
drivers/net/ethernet/via/Kconfig | 4 +-
drivers/net/fddi/Kconfig | 4 +-
drivers/net/wan/Kconfig | 2 +-
drivers/net/wireless/atmel/Kconfig | 4 +-
drivers/net/wireless/intersil/hostap/Kconfig | 4 +-
drivers/pci/Kconfig | 11 +++++
drivers/scsi/Kconfig | 20 ++++-----
drivers/scsi/aic7xxx/Kconfig.aic79xx | 2 +-
drivers/scsi/aic7xxx/Kconfig.aic7xxx | 2 +-
drivers/scsi/aic94xx/Kconfig | 2 +-
drivers/scsi/megaraid/Kconfig.megaraid | 2 +-
drivers/scsi/mvsas/Kconfig | 2 +-
drivers/scsi/qla2xxx/Kconfig | 2 +-
drivers/spi/Kconfig | 1 +
drivers/staging/sm750fb/Kconfig | 2 +-
drivers/staging/vt6655/Kconfig | 2 +-
drivers/tty/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 22 +++++-----
drivers/watchdog/Kconfig | 4 +-
sound/pci/Kconfig | 43 ++++++++++++++++----
40 files changed, 194 insertions(+), 110 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7da8ea7b3ed..32e0489bd01c 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -556,7 +556,7 @@ comment "PATA SFF controllers with BMDMA"
config PATA_ALI
tristate "ALi PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the ALi ATA interfaces
@@ -566,7 +566,7 @@ config PATA_ALI
config PATA_AMD
tristate "AMD/NVidia PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the AMD and NVidia PATA
@@ -584,7 +584,7 @@ config PATA_ARASAN_CF
config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for ARTOP PATA controllers.
@@ -621,7 +621,7 @@ config PATA_BK3710
config PATA_CMD64X
tristate "CMD64x PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD64x series chips
@@ -667,7 +667,7 @@ config PATA_CS5536
config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the Cypress/Contaq CY82C693
@@ -707,7 +707,7 @@ config PATA_FTIDE010
config PATA_HPT366
tristate "HPT 366/368 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the HPT 366 and 368
PATA controllers via the new ATA layer.
@@ -716,7 +716,7 @@ config PATA_HPT366
config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the majority of the later HPT
PATA controllers via the new ATA layer.
@@ -725,7 +725,7 @@ config PATA_HPT37X
config PATA_HPT3X2N
tristate "HPT 371N/372N/302N PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the N variant HPT PATA
controllers via the new ATA layer.
@@ -828,7 +828,7 @@ config PATA_MPC52xx
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Netcell Revolution RAID
PATA controller.
@@ -864,7 +864,7 @@ config PATA_OLDPIIX
config PATA_OPTIDMA
tristate "OPTI FireStar PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables DMA/PIO support for the later OPTi
controllers found on some old motherboards and in some
@@ -874,7 +874,7 @@ config PATA_OPTIDMA
config PATA_PDC2027X
tristate "Promise PATA 2027x support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for Promise PATA pdc20268 to pdc20277 host adapters.
@@ -882,7 +882,7 @@ config PATA_PDC2027X
config PATA_PDC_OLD
tristate "Older Promise PATA controller support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.
@@ -910,7 +910,7 @@ config PATA_RDC
config PATA_SC1200
tristate "SC1200 PATA support"
- depends on PCI && (X86_32 || COMPILE_TEST)
+ depends on LEGACY_PCI && (X86_32 || COMPILE_TEST)
help
This option enables support for the NatSemi/AMD SC1200 SoC
companion chip used with the Geode processor family.
@@ -928,7 +928,7 @@ config PATA_SCH
config PATA_SERVERWORKS
tristate "SERVERWORKS OSB4/CSB5/CSB6/HT1000 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Serverworks OSB4/CSB5/CSB6 and
HT1000 PATA controllers, via the new ATA layer.
@@ -1005,7 +1005,7 @@ comment "PIO-only SFF controllers"
config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD640 PCI IDE
@@ -1086,7 +1086,7 @@ config PATA_NS87410
config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables full PIO support for the early Opti ATA
controllers found on some old motherboards.
@@ -1197,7 +1197,7 @@ config ATA_GENERIC
config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
- depends on (ISA || PCI)
+ depends on (ISA || LEGACY_PCI)
select PATA_TIMINGS
help
This option enables support for ISA/VLB/PCI bus legacy PATA
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 20a32e4d501d..791942217e2c 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -197,7 +197,8 @@ static int ata_generic_init_one(struct pci_dev *dev, const struct pci_device_id
if (!(command & PCI_COMMAND_IO))
return -ENODEV;
- if (dev->vendor == PCI_VENDOR_ID_AL)
+ if (IS_ENABLED(CONFIG_LEGACY_PCI) &&
+ dev->vendor == PCI_VENDOR_ID_AL)
ata_pci_bmdma_clear_simplex(dev);
if (dev->vendor == PCI_VENDOR_ID_ATI) {
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index b71ea4a680b0..636848ab6839 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -3107,6 +3107,7 @@ EXPORT_SYMBOL_GPL(ata_bmdma_port_start32);
#ifdef CONFIG_PCI
+#ifdef CONFIG_LEGACY_PCI
/**
* ata_pci_bmdma_clear_simplex - attempt to kick device out of simplex
* @pdev: PCI device
@@ -3132,6 +3133,7 @@ int ata_pci_bmdma_clear_simplex(struct pci_dev *pdev)
return 0;
}
EXPORT_SYMBOL_GPL(ata_pci_bmdma_clear_simplex);
+#endif
static void ata_bmdma_nodma(struct ata_host *host, const char *reason)
{
diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 3cb61fa2c5c3..1b642716c5d3 100644
--- a/drivers/comedi/Kconfig
+++ b/drivers/comedi/Kconfig
@@ -572,6 +572,7 @@ if COMEDI_PCI_DRIVERS
config COMEDI_8255_PCI
tristate "Generic PCI based 8255 digital i/o board support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for PCI based 8255 digital i/o boards. This driver
@@ -589,6 +590,7 @@ config COMEDI_8255_PCI
config COMEDI_ADDI_WATCHDOG
tristate
+ depends on LEGACY_PCI
help
Provides support for the watchdog subdevice found on many ADDI-DATA
boards. This module will be automatically selected when needed. The
@@ -596,6 +598,7 @@ config COMEDI_ADDI_WATCHDOG
config COMEDI_ADDI_APCI_1032
tristate "ADDI-DATA APCI_1032 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1032 cards
@@ -604,6 +607,7 @@ config COMEDI_ADDI_APCI_1032
config COMEDI_ADDI_APCI_1500
tristate "ADDI-DATA APCI_1500 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1500 cards
@@ -612,6 +616,7 @@ config COMEDI_ADDI_APCI_1500
config COMEDI_ADDI_APCI_1516
tristate "ADDI-DATA APCI-1016/1516/2016 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI-1016, APCI-1516 and APCI-2016 boards.
@@ -623,6 +628,7 @@ config COMEDI_ADDI_APCI_1516
config COMEDI_ADDI_APCI_1564
tristate "ADDI-DATA APCI_1564 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_1564 cards
@@ -632,6 +638,7 @@ config COMEDI_ADDI_APCI_1564
config COMEDI_ADDI_APCI_16XX
tristate "ADDI-DATA APCI_16xx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_16xx cards
@@ -640,6 +647,7 @@ config COMEDI_ADDI_APCI_16XX
config COMEDI_ADDI_APCI_2032
tristate "ADDI-DATA APCI_2032 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2032 cards
@@ -649,6 +657,7 @@ config COMEDI_ADDI_APCI_2032
config COMEDI_ADDI_APCI_2200
tristate "ADDI-DATA APCI_2200 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2200 cards
@@ -658,6 +667,7 @@ config COMEDI_ADDI_APCI_2200
config COMEDI_ADDI_APCI_3120
tristate "ADDI-DATA APCI_3120/3001 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
help
Enable support for ADDI-DATA APCI_3120/3001 cards
@@ -667,6 +677,7 @@ config COMEDI_ADDI_APCI_3120
config COMEDI_ADDI_APCI_3501
tristate "ADDI-DATA APCI_3501 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3501 cards
@@ -675,6 +686,7 @@ config COMEDI_ADDI_APCI_3501
config COMEDI_ADDI_APCI_3XXX
tristate "ADDI-DATA APCI_3xxx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3xxx cards
@@ -683,6 +695,7 @@ config COMEDI_ADDI_APCI_3XXX
config COMEDI_ADL_PCI6208
tristate "ADLink PCI-6208A support"
+ depends on LEGACY_PCI
help
Enable support for ADLink PCI-6208A cards
@@ -691,6 +704,7 @@ config COMEDI_ADL_PCI6208
config COMEDI_ADL_PCI7X3X
tristate "ADLink PCI-723X/743X isolated digital i/o board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-723X/743X isolated digital i/o boards.
Supported boards include the 32-channel PCI-7230 (16 in/16 out),
@@ -702,6 +716,7 @@ config COMEDI_ADL_PCI7X3X
config COMEDI_ADL_PCI8164
tristate "ADLink PCI-8164 4 Axes Motion Control board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-8164 4 Axes Motion Control board
@@ -710,6 +725,7 @@ config COMEDI_ADL_PCI8164
config COMEDI_ADL_PCI9111
tristate "ADLink PCI-9111HR support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for ADlink PCI9111 cards
@@ -719,6 +735,7 @@ config COMEDI_ADL_PCI9111
config COMEDI_ADL_PCI9118
tristate "ADLink PCI-9118DG, PCI-9118HG, PCI-9118HR support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_8254
help
@@ -729,6 +746,7 @@ config COMEDI_ADL_PCI9118
config COMEDI_ADV_PCI1710
tristate "Advantech PCI-171x and PCI-1731 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Advantech PCI-1710, PCI-1710HG, PCI-1711,
@@ -739,6 +757,7 @@ config COMEDI_ADV_PCI1710
config COMEDI_ADV_PCI1720
tristate "Advantech PCI-1720 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1720 Analog Output board.
@@ -747,6 +766,7 @@ config COMEDI_ADV_PCI1720
config COMEDI_ADV_PCI1723
tristate "Advantech PCI-1723 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1723 cards
@@ -755,6 +775,7 @@ config COMEDI_ADV_PCI1723
config COMEDI_ADV_PCI1724
tristate "Advantech PCI-1724U support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1724U cards. These are 32-channel
analog output cards with voltage and current loop output ranges and
@@ -765,6 +786,7 @@ config COMEDI_ADV_PCI1724
config COMEDI_ADV_PCI1760
tristate "Advantech PCI-1760 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1760 board.
@@ -773,6 +795,7 @@ config COMEDI_ADV_PCI1760
config COMEDI_ADV_PCI_DIO
tristate "Advantech PCI DIO card support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -786,6 +809,7 @@ config COMEDI_ADV_PCI_DIO
config COMEDI_AMPLC_DIO200_PCI
tristate "Amplicon PCI215/PCI272/PCIe215/PCIe236/PCIe296 DIO support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_DIO200
help
Enable support for Amplicon PCI215, PCI272, PCIe215, PCIe236
@@ -796,6 +820,7 @@ config COMEDI_AMPLC_DIO200_PCI
config COMEDI_AMPLC_PC236_PCI
tristate "Amplicon PCI236 DIO board support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_PC236
help
Enable support for Amplicon PCI236 DIO board.
@@ -805,6 +830,7 @@ config COMEDI_AMPLC_PC236_PCI
config COMEDI_AMPLC_PC263_PCI
tristate "Amplicon PCI263 relay board support"
+ depends on LEGACY_PCI
help
Enable support for Amplicon PCI263 relay board. This is a PCI board
with 16 reed relay output channels.
@@ -814,6 +840,7 @@ config COMEDI_AMPLC_PC263_PCI
config COMEDI_AMPLC_PCI224
tristate "Amplicon PCI224 and PCI234 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Amplicon PCI224 and PCI234 AO boards
@@ -823,6 +850,7 @@ config COMEDI_AMPLC_PCI224
config COMEDI_AMPLC_PCI230
tristate "Amplicon PCI230 and PCI260 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -834,6 +862,7 @@ config COMEDI_AMPLC_PCI230
config COMEDI_CONTEC_PCI_DIO
tristate "Contec PIO1616L digital I/O board support"
+ depends on LEGACY_PCI
help
Enable support for the Contec PIO1616L digital I/O board
@@ -842,6 +871,7 @@ config COMEDI_CONTEC_PCI_DIO
config COMEDI_DAS08_PCI
tristate "DAS-08 PCI support"
+ depends on LEGACY_PCI
select COMEDI_DAS08
help
Enable support for PCI DAS-08 cards.
@@ -861,6 +891,7 @@ config COMEDI_DT3000
config COMEDI_DYNA_PCI10XX
tristate "Dynalog PCI DAQ series support"
+ depends on LEGACY_PCI
help
Enable support for Dynalog PCI DAQ series
PCI-1050
@@ -894,6 +925,7 @@ config COMEDI_ICP_MULTI
config COMEDI_DAQBOARD2000
tristate "IOtech DAQboard/2000 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for the IOtech DAQboard/2000
@@ -911,6 +943,7 @@ config COMEDI_JR3_PCI
config COMEDI_KE_COUNTER
tristate "Kolter-Electronic PCI Counter 1 card support"
+ depends on LEGACY_PCI
help
Enable support for Kolter-Electronic PCI Counter 1 cards
@@ -919,6 +952,7 @@ config COMEDI_KE_COUNTER
config COMEDI_CB_PCIDAS64
tristate "MeasurementComputing PCI-DAS 64xx, 60xx, and 4020 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DAS 64xx,
@@ -929,6 +963,7 @@ config COMEDI_CB_PCIDAS64
config COMEDI_CB_PCIDAS
tristate "MeasurementComputing PCI-DAS support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -942,6 +977,7 @@ config COMEDI_CB_PCIDAS
config COMEDI_CB_PCIDDA
tristate "MeasurementComputing PCI-DDA series support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DDA
@@ -953,6 +989,7 @@ config COMEDI_CB_PCIDDA
config COMEDI_CB_PCIMDAS
tristate "MeasurementComputing PCIM-DAS1602/16, PCIe-DAS1602/16 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -964,6 +1001,7 @@ config COMEDI_CB_PCIMDAS
config COMEDI_CB_PCIMDDA
tristate "MeasurementComputing PCIM-DDA06-16 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCIM-DDA06-16
@@ -973,6 +1011,7 @@ config COMEDI_CB_PCIMDDA
config COMEDI_ME4000
tristate "Meilhaus ME-4000 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Meilhaus PCI data acquisition cards
@@ -1031,6 +1070,7 @@ config COMEDI_NI_670X
config COMEDI_NI_LABPC_PCI
tristate "NI Lab-PC PCI-1200 support"
+ depends on LEGACY_PCI
select COMEDI_NI_LABPC
help
Enable support for National Instruments Lab-PC PCI-1200.
@@ -1040,6 +1080,7 @@ config COMEDI_NI_LABPC_PCI
config COMEDI_NI_PCIDIO
tristate "NI PCI-DIO32HS, PCI-6533, PCI-6534 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_MITE
select COMEDI_8255
@@ -1052,6 +1093,7 @@ config COMEDI_NI_PCIDIO
config COMEDI_NI_PCIMIO
tristate "NI PCI-MIO-E series and M series support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_NI_TIOCMD
select COMEDI_8255
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 60d9374c72c0..d36afa5ac6fc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -687,7 +687,7 @@ config GPIO_VR41XX
config GPIO_VX855
tristate "VIA VX855/VX875 GPIO"
- depends on (X86 || COMPILE_TEST) && PCI
+ depends on (X86 || COMPILE_TEST) && LEGACY_PCI
select MFD_CORE
select MFD_VX855
help
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 64bd3dfba2c4..09397562c396 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1654,7 +1654,7 @@ config SENSORS_S3C_RAW
config SENSORS_SIS5595
tristate "Silicon Integrated Systems Corp. SiS5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
SiS5595 South Bridges.
@@ -1985,7 +1985,7 @@ config SENSORS_VIA_CPUTEMP
config SENSORS_VIA686A
tristate "VIA686A"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
Via 686A/B South Bridges.
@@ -2006,7 +2006,7 @@ config SENSORS_VT1211
config SENSORS_VT8231
tristate "VIA VT8231"
- depends on PCI
+ depends on LEGACY_PCI
select HWMON_VID
help
If you say yes here then you get support for the integrated sensors
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index dce392839017..a8d6274dc965 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -11,7 +11,7 @@ comment "PC SMBus host controller drivers"
config I2C_ALI1535
tristate "ALI 1535"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1535 South Bridges. The SMB
@@ -23,7 +23,7 @@ config I2C_ALI1535
config I2C_ALI1563
tristate "ALI 1563"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1563 South Bridges. The SMB
@@ -35,7 +35,7 @@ config I2C_ALI1563
config I2C_ALI15X3
tristate "ALI 15x3"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
Acer Labs Inc. (ALI) M1514 and M1543 motherboard I2C interfaces.
@@ -45,7 +45,7 @@ config I2C_ALI15X3
config I2C_AMD756
tristate "AMD 756/766/768/8111 and nVidia nForce"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the AMD
756/766/768 mainboard I2C interfaces. The driver also includes
@@ -70,7 +70,7 @@ config I2C_AMD756_S4882
config I2C_AMD8111
tristate "AMD 8111"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
second (SMBus 2.0) AMD 8111 mainboard I2C interface.
@@ -154,7 +154,7 @@ config I2C_I801
config I2C_ISCH
tristate "Intel SCH SMBus 1.0"
- depends on PCI
+ depends on LEGACY_PCI
select LPC_SCH
help
Say Y here if you want to use SMBus controller on the Intel SCH
@@ -221,7 +221,7 @@ config I2C_CHT_WC
config I2C_NFORCE2
tristate "Nvidia nForce2, nForce3 and nForce4"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the Nvidia
nForce2, nForce3 and nForce4 families of mainboard I2C interfaces.
@@ -253,7 +253,7 @@ config I2C_NVIDIA_GPU
config I2C_SIS5595
tristate "SiS 5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS5595 SMBus (a subset of I2C) interface.
@@ -263,7 +263,7 @@ config I2C_SIS5595
config I2C_SIS630
tristate "SiS 630/730/964"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS630, SiS730 and SiS964 SMBus (a subset of I2C) interface.
@@ -273,7 +273,7 @@ config I2C_SIS630
config I2C_SIS96X
tristate "SiS 96x"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SiS
96x SMBus (a subset of I2C) interfaces. Specifically, the following
@@ -291,7 +291,7 @@ config I2C_SIS96X
config I2C_VIA
tristate "VIA VT82C586B"
- depends on PCI
+ depends on LEGACY_PCI
select I2C_ALGOBIT
help
If you say yes to this option, support will be included for the VIA
@@ -302,7 +302,7 @@ config I2C_VIA
config I2C_VIAPRO
tristate "VIA VT82C596/82C686/82xx and CX700/VX8xx/VX900"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the VIA
VT82C596 and later SMBus interface. Specifically, the following
diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 5a2c2fb3217d..082280f95333 100644
--- a/drivers/input/gameport/Kconfig
+++ b/drivers/input/gameport/Kconfig
@@ -43,7 +43,7 @@ config GAMEPORT_L4
config GAMEPORT_EMU10K1
tristate "SB Live and Audigy gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have a SoundBlaster Live! or SoundBlaster
Audigy card and want to use its gameport.
@@ -53,7 +53,7 @@ config GAMEPORT_EMU10K1
config GAMEPORT_FM801
tristate "ForteMedia FM801 gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have ForteMedia FM801 PCI audio controller
(Abit AU10, Genius Sound Maker, HP Workstation zx2000,
diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig
index 078eeadf707a..2c5e16483179 100644
--- a/drivers/isdn/hardware/mISDN/Kconfig
+++ b/drivers/isdn/hardware/mISDN/Kconfig
@@ -7,14 +7,14 @@ comment "mISDN hardware drivers"
config MISDN_HFCPCI
tristate "Support for HFC PCI cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for cards with Cologne Chip AG's
HFC PCI chip.
config MISDN_HFCMULTI
tristate "Support for HFC multiport cards (HFC-4S/8S/E1)"
- depends on PCI || CPM1
+ depends on LEGACY_PCI || CPM1
depends on MISDN
help
Enable support for cards with Cologne Chip AG's HFC multiport
@@ -43,7 +43,7 @@ config MISDN_HFCUSB
config MISDN_AVMFRITZ
tristate "Support for AVM FRITZ!CARD PCI"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for AVMs FRITZ!CARD PCI cards
@@ -51,7 +51,7 @@ config MISDN_AVMFRITZ
config MISDN_SPEEDFAX
tristate "Support for Sedlbauer Speedfax+"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
select MISDN_ISAR
help
@@ -60,7 +60,7 @@ config MISDN_SPEEDFAX
config MISDN_INFINEON
tristate "Support for cards with Infineon chipset"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for cards with ISAC + HSCX, IPAC or IPAC-SX
@@ -69,14 +69,14 @@ config MISDN_INFINEON
config MISDN_W6692
tristate "Support for cards with Winbond 6692"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for Winbond 6692 PCI chip based cards.
config MISDN_NETJET
tristate "Support for NETJet cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
depends on TTY
select MISDN_IPAC
select MISDN_HDLC
diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
index b672d3142eb7..5e92ece5b104 100644
--- a/drivers/media/cec/platform/Kconfig
+++ b/drivers/media/cec/platform/Kconfig
@@ -100,7 +100,7 @@ config CEC_TEGRA
config CEC_SECO
tristate "SECO Boards HDMI CEC driver"
depends on (X86 || IA64) || COMPILE_TEST
- depends on PCI && DMI
+ depends on LEGACY_PCI && DMI
select CEC_CORE
select CEC_NOTIFIER
help
diff --git a/drivers/media/pci/dm1105/Kconfig b/drivers/media/pci/dm1105/Kconfig
index e0e3af67c99c..9ecab93685d4 100644
--- a/drivers/media/pci/dm1105/Kconfig
+++ b/drivers/media/pci/dm1105/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
- depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
+ depends on DVB_CORE && LEGACY_PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index d29e29645e04..32eb73993998 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -67,7 +67,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate "Guillemot MAXI Radio FM 2000 radio"
- depends on VIDEO_V4L2 && PCI
+ depends on VIDEO_V4L2 && LEGACY_PCI
select RADIO_TEA575X
help
Choose Y here if you have this radio card. This card may also be
diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index a3d0288fd0e2..cec5995e1911 100644
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -2,7 +2,7 @@
menuconfig FUSION
bool "Fusion MPT device support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here to get to see options for Fusion Message
Passing Technology (MPT) drivers.
@@ -14,7 +14,7 @@ if FUSION
config FUSION_SPI
tristate "Fusion MPT ScsiHost drivers for SPI"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
SCSI HOST support for a parallel SCSI host adapters.
@@ -29,7 +29,7 @@ config FUSION_SPI
config FUSION_FC
tristate "Fusion MPT ScsiHost drivers for FC"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
help
SCSI HOST support for a Fiber Channel host adapters.
@@ -48,7 +48,7 @@ config FUSION_FC
config FUSION_SAS
tristate "Fusion MPT ScsiHost drivers for SAS"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SAS_ATTRS
help
SCSI HOST support for a SAS host adapters.
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..b8038287c4f2 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -4,7 +4,7 @@
#
menuconfig ARCNET
- depends on NETDEVICES && (ISA || PCI || PCMCIA)
+ depends on NETDEVICES && (ISA || LEGACY_PCI || PCMCIA)
tristate "ARCnet support"
help
If you have a network card of this type, say Y and check out the
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..0fa43943ea74 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -117,7 +117,7 @@ config NE2000
config NE2K_PCI
tristate "PCI NE2000 and clones support (see help)"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
help
This driver is for NE2000 compatible PCI cards. It will not work
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 899c8a2a34b6..0ac61a5f1a37 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -56,7 +56,7 @@ config LANCE
config PCNET32
tristate "AMD PCnet32 PCI support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 0b274d8fa45b..45a3c42945fc 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_INTEL
config E100
tristate "Intel(R) PRO/100+ support"
- depends on PCI
+ depends on LEGACY_PCI
select MII
help
This driver supports Intel(R) PRO/100 family of adapters.
@@ -41,7 +41,7 @@ config E100
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
help
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
diff --git a/drivers/net/ethernet/sis/Kconfig b/drivers/net/ethernet/sis/Kconfig
index 775d76d9890e..bd1b1b81b0e8 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_SIS
bool "Silicon Integrated Systems (SiS) devices"
default y
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
config SIS900
tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
@@ -35,7 +35,7 @@ config SIS900
config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..8b1d67b00e68 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_TI
bool "Texas Instruments (TI) devices"
default y
- depends on PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ depends on LEGACY_PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
config TLAN
tristate "TI ThunderLAN support"
- depends on (PCI || EISA)
+ depends on (LEGACY_PCI || EISA)
help
If you have a PCI Ethernet network card based on the ThunderLAN chip
which is supported by this driver, say Y here.
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index da287ef65be7..0ca7d8f7bfde 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -18,8 +18,8 @@ if NET_VENDOR_VIA
config VIA_RHINE
tristate "VIA Rhine support"
- depends on PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
- depends on PCI || ARCH_VT8500 || COMPILE_TEST
+ depends on LEGACY_PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
+ depends on LEGACY_PCI || ARCH_VT8500 || COMPILE_TEST
depends on HAS_DMA
select CRC32
select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..1753c08d6423 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -5,7 +5,7 @@
config FDDI
tristate "FDDI driver support"
- depends on PCI || EISA || TC
+ depends on LEGACY_PCI || EISA || TC
help
Fiber Distributed Data Interface is a high speed local area network
design; essentially a replacement for high speed Ethernet. FDDI can
@@ -29,7 +29,7 @@ config DEFZA
config DEFXX
tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
- depends on FDDI && (PCI || EISA || TC)
+ depends on FDDI && (LEGACY_PCI || EISA || TC)
help
This is support for the DIGITAL series of TURBOchannel (DEFTA),
EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 592a8389fc5a..631c4c1c56c8 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -250,7 +250,7 @@ config C101
config FARSYNC
tristate "FarSync T-Series support"
- depends on HDLC && PCI
+ depends on HDLC && LEGACY_PCI
help
Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
FarSite Communications Ltd.
diff --git a/drivers/net/wireless/atmel/Kconfig b/drivers/net/wireless/atmel/Kconfig
index ca45a1021cf4..9baa4a19dd38 100644
--- a/drivers/net/wireless/atmel/Kconfig
+++ b/drivers/net/wireless/atmel/Kconfig
@@ -14,7 +14,7 @@ if WLAN_VENDOR_ATMEL
config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
- depends on CFG80211 && (PCI || PCMCIA)
+ depends on CFG80211 && (LEGACY_PCI || PCMCIA)
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
@@ -32,7 +32,7 @@ config ATMEL
config PCI_ATMEL
tristate "Atmel at76c506 PCI cards"
- depends on ATMEL && PCI
+ depends on ATMEL && LEGACY_PCI
help
Enable support for PCI and mini-PCI cards containing the
Atmel at76c506 chip.
diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig
index c865d3156cea..9bcd1c8546ff 100644
--- a/drivers/net/wireless/intersil/hostap/Kconfig
+++ b/drivers/net/wireless/intersil/hostap/Kconfig
@@ -56,7 +56,7 @@ config HOSTAP_FIRMWARE_NVRAM
config HOSTAP_PLX
tristate "Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2/2.5/3 PC Cards in PLX9052 based
PCI adaptors.
@@ -70,7 +70,7 @@ config HOSTAP_PLX
config HOSTAP_PCI
tristate "Host AP driver for Prism2.5 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2.5 PCI adaptors.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 43e615aa12ff..e0c99ddc145c 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -23,6 +23,17 @@ menuconfig PCI
if PCI
+config LEGACY_PCI
+ bool "Enable support for legacy PCI devices"
+ depends on HAVE_PCI
+ help
+ This option enables support for legacy PCI devices. This includes
+ PCI devices attached directly or via a bridge on a PCI Express bus.
+ It also includes compatibility features on PCI Express devices which
+ make use of legacy I/O spaces.
+
+ For maximum compatibility with old hardware say 'Y'
+
config PCI_DOMAINS
bool
depends on PCI
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..5436b2be2c73 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -333,7 +333,7 @@ config SGIWD93_SCSI
config BLK_DEV_3W_XXXX_RAID
tristate "3ware 5/6/7/8xxx ATA-RAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
3ware is the only hardware ATA-Raid product in Linux to date.
This card is 2,4, or 8 channel master mode support only.
@@ -380,7 +380,7 @@ config SCSI_3W_SAS
config SCSI_ACARD
tristate "ACARD SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the ACARD SCSI host adapter.
Support Chip <ATP870 ATP876 ATP880 ATP885>
@@ -472,7 +472,7 @@ config SCSI_DPT_I2O
config SCSI_ADVANSYS
tristate "AdvanSys SCSI support"
depends on SCSI
- depends on ISA || EISA || PCI
+ depends on ISA || EISA || LEGACY_PCI
depends on ISA_DMA_API || !ISA
help
This is a driver for all SCSI host adapters manufactured by
@@ -643,7 +643,7 @@ config SCSI_SNIC_DEBUG_FS
config SCSI_DMX3191D
tristate "DMX3191D SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This is support for Domex DMX3191D SCSI Host Adapters.
@@ -657,7 +657,7 @@ config SCSI_FDOMAIN
config SCSI_FDOMAIN_PCI
tristate "Future Domain TMC-3260/AHA-2920A PCI SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_FDOMAIN
help
This is support for Future Domain's PCI SCSI host adapters (TMC-3260)
@@ -710,7 +710,7 @@ config SCSI_GENERIC_NCR5380
config SCSI_IPS
tristate "IBM ServeRAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the IBM ServeRAID hardware RAID controllers.
See <http://www.developer.ibm.com/welcome/netfinity/serveraid.html>
@@ -770,7 +770,7 @@ config SCSI_IBMVFC_TRACE
config SCSI_INITIO
tristate "Initio 9100U(W) support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio 91XXU(W) SCSI host adapter. Please
read the SCSI-HOWTO, available from
@@ -781,7 +781,7 @@ config SCSI_INITIO
config SCSI_INIA100
tristate "Initio INI-A100U2W support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio INI-A100U2W SCSI host adapter.
Please read the SCSI-HOWTO, available from
@@ -1130,7 +1130,7 @@ config SCSI_QLOGIC_FAS
config SCSI_QLOGIC_1280
tristate "Qlogic QLA 1240/1x80/1x160 SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
Say Y if you have a QLogic ISP1240/1x80/1x160 SCSI host adapter.
@@ -1187,7 +1187,7 @@ config SCSI_SIM710
config SCSI_DC395x
tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports PCI SCSI host adapters based on the ASIC
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic79xx b/drivers/scsi/aic7xxx/Kconfig.aic79xx
index a47dbd500e9a..64332cc73ea0 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic79xx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic79xx
@@ -5,7 +5,7 @@
#
config SCSI_AIC79XX
tristate "Adaptec AIC79xx U320 support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Ultra 320 PCI-X
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic7xxx b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
index 0cfd92ce750a..3fa5dc1d1186 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic7xxx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
@@ -5,7 +5,7 @@
#
config SCSI_AIC7XXX
tristate "Adaptec AIC7xxx Fast -> U160 support"
- depends on (PCI || EISA) && SCSI
+ depends on (LEGACY_PCI || EISA) && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Fast through Ultra 160 PCI
diff --git a/drivers/scsi/aic94xx/Kconfig b/drivers/scsi/aic94xx/Kconfig
index 71931c371b1c..b0cbf65dbe5b 100644
--- a/drivers/scsi/aic94xx/Kconfig
+++ b/drivers/scsi/aic94xx/Kconfig
@@ -8,7 +8,7 @@
config SCSI_AIC94XX
tristate "Adaptec AIC94xx SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
index 2adc2afd9f91..4ec46aede490 100644
--- a/drivers/scsi/megaraid/Kconfig.megaraid
+++ b/drivers/scsi/megaraid/Kconfig.megaraid
@@ -67,7 +67,7 @@ config MEGARAID_MAILBOX
config MEGARAID_LEGACY
tristate "LSI Logic Legacy MegaRAID Driver"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the LSI MegaRAID 418, 428, 438, 466, 762, 490
and 467 SCSI host adapters. This driver also support the all U320
diff --git a/drivers/scsi/mvsas/Kconfig b/drivers/scsi/mvsas/Kconfig
index 79812b80743b..f41f3f4a9f34 100644
--- a/drivers/scsi/mvsas/Kconfig
+++ b/drivers/scsi/mvsas/Kconfig
@@ -9,7 +9,7 @@
config SCSI_MVSAS
tristate "Marvell 88SE64XX/88SE94XX SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 802c373fd6d9..93afb73858ce 100644
--- a/drivers/scsi/qla2xxx/Kconfig
+++ b/drivers/scsi/qla2xxx/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
depends on NVME_FC || !NVME_FC
select FW_LOADER
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 596705d24400..cfbd45767095 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -204,6 +204,7 @@ config SPI_BITBANG
config SPI_BUTTERFLY
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
depends on PARPORT
+ depends on HAS_IOPORT
select SPI_BITBANG
help
This uses a custom parallel port cable to connect to an AVR
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 8c0d8a873d5b..d332f912b964 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/staging/vt6655/Kconfig b/drivers/staging/vt6655/Kconfig
index d1cd5de46dcf..dd236f54d3a2 100644
--- a/drivers/staging/vt6655/Kconfig
+++ b/drivers/staging/vt6655/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
config VT6655
tristate "VIA Technologies VT6655 support"
- depends on PCI && MAC80211 && m
+ depends on LEGACY_PCI && MAC80211 && m
help
This is a vendor-written driver for VIA VT6655.
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc30ff93e2e4..460326a529d6 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -203,7 +203,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on SERIAL_NONSTANDARD && LEGACY_PCI
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index fc543ac97c13..607791b7f693 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -908,7 +908,7 @@ config SERIAL_VR41XX_CONSOLE
config SERIAL_JSM
tristate "Digi International NEO and Classic PCI Support"
- depends on PCI
+ depends on LEGACY_PCI
select SERIAL_CORE
help
This is a driver for Digi International's Neo and Classic series
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6ed5e608dd04..a3446d44c118 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -343,7 +343,7 @@ config FB_IMX
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
- depends on FB && PCI && (BROKEN || !SPARC64)
+ depends on FB && LEGACY_PCI && (BROKEN || !SPARC64)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1264,7 +1264,7 @@ config FB_ATY128_BACKLIGHT
Say Y here if you want to control the backlight of your display.
config FB_ATY
- tristate "ATI Mach64 display support" if PCI || ATARI
+ tristate "ATI Mach64 display support" if LEGACY_PCI || ATARI
depends on FB && !SPARC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1315,7 +1315,7 @@ config FB_ATY_BACKLIGHT
config FB_S3
tristate "S3 Trio/Virge support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1374,7 +1374,7 @@ config FB_SAVAGE_ACCEL
config FB_SIS
tristate "SiS/XGI display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1404,7 +1404,7 @@ config FB_SIS_315
config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
- depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
+ depends on FB && LEGACY_PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1442,7 +1442,7 @@ endif
config FB_NEOMAGIC
tristate "NeoMagic display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1470,7 +1470,7 @@ config FB_KYRO
config FB_3DFX
tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1518,7 +1518,7 @@ config FB_VOODOO1
config FB_VT8623
tristate "VIA VT8623 support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1532,7 +1532,7 @@ config FB_VT8623
config FB_TRIDENT
tristate "Trident/CyberXXX/CyberBlade support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1554,7 +1554,7 @@ config FB_TRIDENT
config FB_ARK
tristate "ARK 2000PV support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2226,7 +2226,7 @@ config FB_SSD1307
config FB_SM712
tristate "Silicon Motion SM712 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9d222ba17ec6..05258109bcc2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -2053,7 +2053,7 @@ comment "PCI-based Watchdog Cards"
config PCIPCWATCHDOG
tristate "Berkshire Products PCI-PC Watchdog"
- depends on PCI
+ depends on LEGACY_PCI
help
This is the driver for the Berkshire Products PCI-PC Watchdog card.
This card simply watches your kernel to make sure it doesn't freeze,
@@ -2068,7 +2068,7 @@ config PCIPCWATCHDOG
config WDTPCI
tristate "PCI-WDT500/501 Watchdog timer"
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 41ce12597177..07d9587eede4 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -23,10 +23,10 @@ config SND_AD1889
config SND_ALS300
tristate "Avance Logic ALS300/ALS300+"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_PCM
select SND_AC97_CODEC
select SND_OPL3_LIB
- depends on ZONE_DMA
help
Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
@@ -35,6 +35,7 @@ config SND_ALS300
config SND_ALS4000
tristate "Avance Logic ALS4000"
+ depends on LEGACY_PCI
depends on ISA_DMA_API
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -49,6 +50,7 @@ config SND_ALS4000
config SND_ALI5451
tristate "ALi M5451 PCI Audio Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
depends on ZONE_DMA
@@ -96,6 +98,7 @@ config SND_ATIIXP_MODEM
config SND_AU8810
tristate "Aureal Advantage"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -110,6 +113,7 @@ config SND_AU8810
config SND_AU8820
tristate "Aureal Vortex"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -123,6 +127,7 @@ config SND_AU8820
config SND_AU8830
tristate "Aureal Vortex 2"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -151,13 +156,13 @@ config SND_AW2
config SND_AZT3328
tristate "Aztech AZF3328 / PCI168"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
- depends on ZONE_DMA
help
Say Y here to include support for Aztech AZF3328 (PCI168)
soundcards.
@@ -172,6 +177,7 @@ config SND_AZT3328
config SND_BT87X
tristate "Bt87x Audio Capture"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to record audio from TV cards based on
@@ -193,6 +199,7 @@ config SND_BT87X_OVERCLOCK
config SND_CA0106
tristate "SB Audigy LS / Live 24bit"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
select SND_VMASTER
@@ -205,6 +212,7 @@ config SND_CA0106
config SND_CMIPCI
tristate "C-Media 8338, 8738, 8768, 8770"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
@@ -221,6 +229,7 @@ config SND_OXYGEN_LIB
config SND_OXYGEN
tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -246,6 +255,7 @@ config SND_OXYGEN
config SND_CS4281
tristate "Cirrus Logic (Sound Fusion) CS4281"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_RAWMIDI
select SND_AC97_CODEC
@@ -257,6 +267,7 @@ config SND_CS4281
config SND_CS46XX
tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
select FW_LOADER
@@ -290,6 +301,7 @@ config SND_CS5530
config SND_CS5535AUDIO
tristate "CS5535/CS5536 Audio"
depends on X86_32 || MIPS || COMPILE_TEST
+ depends on LEGACY_PCI
select SND_PCM
select SND_AC97_CODEC
help
@@ -307,6 +319,7 @@ config SND_CS5535AUDIO
config SND_CTXFI
tristate "Creative Sound Blaster X-Fi"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -462,13 +475,13 @@ config SND_INDIGODJX
config SND_EMU10K1
tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
+ depends on LEGACY_PCI && ZONE_DMA
select FW_LOADER
select SND_HWDEP
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
select SND_SEQ_DEVICE if SND_SEQUENCER != n
- depends on ZONE_DMA
help
Say Y to include support for Sound Blaster PCI 512, Live!,
Audigy and E-mu APS (partially supported) soundcards.
@@ -489,6 +502,7 @@ config SND_EMU10K1_SEQ
config SND_EMU10K1X
tristate "Emu10k1X (Dell OEM Version)"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
depends on ZONE_DMA
@@ -501,6 +515,7 @@ config SND_EMU10K1X
config SND_ENS1370
tristate "(Creative) Ensoniq AudioPCI 1370"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_PCM
help
@@ -511,6 +526,7 @@ config SND_ENS1370
config SND_ENS1371
tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
help
@@ -522,10 +538,10 @@ config SND_ENS1371
config SND_ES1938
tristate "ESS ES1938/1946/1969 (Solo-1)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Solo-1
(ES1938, ES1946, ES1969) chips.
@@ -535,9 +551,9 @@ config SND_ES1938
config SND_ES1968
tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro
1/2/2E chips.
@@ -569,6 +585,7 @@ config SND_ES1968_RADIO
config SND_FM801
tristate "ForteMedia FM801"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
@@ -621,10 +638,10 @@ config SND_HDSPM
config SND_ICE1712
tristate "ICEnsemble ICE1712 (Envy24)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
select BITREVERSE
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the
ICE1712 (Envy24) chip.
@@ -640,6 +657,7 @@ config SND_ICE1712
config SND_ICE1724
tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_VMASTER
@@ -712,6 +730,7 @@ config SND_LX6464ES
config SND_MAESTRO3
tristate "ESS Allegro/Maestro3"
select SND_AC97_CODEC
+ depends on LEGACY_PCI
depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro 3
@@ -753,6 +772,7 @@ config SND_NM256
config SND_PCXHR
tristate "Digigram PCXHR"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_PCM
select SND_HWDEP
@@ -764,6 +784,7 @@ config SND_PCXHR
config SND_RIPTIDE
tristate "Conexant Riptide"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -808,6 +829,7 @@ config SND_RME9652
config SND_SE6X
tristate "Studio Evolution SE6X"
depends on SND_OXYGEN=n && SND_VIRTUOSO=n # PCI ID conflict
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -827,10 +849,10 @@ config SND_SIS7019
config SND_SONICVIBES
tristate "S3 SonicVibes"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the S3
SonicVibes chip.
@@ -840,9 +862,9 @@ config SND_SONICVIBES
config SND_TRIDENT
tristate "Trident 4D-Wave DX/NX; SiS 7018"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on Trident
4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +874,7 @@ config SND_TRIDENT
config SND_VIA82XX
tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -863,6 +886,7 @@ config SND_VIA82XX
config SND_VIA82XX_MODEM
tristate "VIA 82C686A/B, 8233 based Modems"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
help
Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +897,7 @@ config SND_VIA82XX_MODEM
config SND_VIRTUOSO
tristate "Asus Virtuoso 66/100/200 (Xonar)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -889,6 +914,7 @@ config SND_VIRTUOSO
config SND_VX222
tristate "Digigram VX222"
+ depends on LEGACY_PCI
select SND_VX_LIB
help
Say Y here to include support for Digigram VX222 soundcards.
@@ -898,6 +924,7 @@ config SND_VX222
config SND_YMFPCI
tristate "Yamaha YMF724/740/744/754"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Mauro Carvalho Chehab, Sathya Prakash,
Sreekanth Reddy, Suganath Prabu Subramani, Michael Grzeschik,
David S. Miller, Jakub Kicinski, Jesse Brandeburg, Tony Nguyen,
Kalle Valo, Jouni Malinen, James E.J. Bottomley,
Martin K. Petersen, Hannes Reinecke, Kashyap Desai, Sumit Saxena,
Shivasharan S, Nilesh Javali, GR-QLogic-Storage-Upstream,
Mark Brown, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
Forest Bond, Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela,
Takashi Iwai
Cc: linux-fbdev, linux-pci, alsa-devel, dri-devel, linux-ide,
linux-i2c, linux-riscv, linux-arch, linux-scsi, linux-staging,
linux-csky, intel-wired-lan, linux-serial, linux-input,
MPT-FusionLinux.pdl, linux-media, linux-watchdog, linux-gpio,
megaraidlinux.pdl, linux-hwmon, netdev, linux-wireless,
linux-kernel, linux-spi
Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
PCI devices including those attached to a PCI-to-PCI Express bridge and
PCI Express devices using legacy I/O spaces. Note that this is different
from non PCI uses of I/O ports such as by ACPI.
Add dependencies on LEGACY_PCI for all PCI drivers which only target
legacy PCI devices and ifdef legacy PCI specific functions in ata
handling.
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>
---
drivers/ata/Kconfig | 34 ++++++++--------
drivers/ata/ata_generic.c | 3 +-
drivers/ata/libata-sff.c | 2 +
drivers/comedi/Kconfig | 42 +++++++++++++++++++
drivers/gpio/Kconfig | 2 +-
drivers/hwmon/Kconfig | 6 +--
drivers/i2c/busses/Kconfig | 24 +++++------
drivers/input/gameport/Kconfig | 4 +-
drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
drivers/media/cec/platform/Kconfig | 2 +-
drivers/media/pci/dm1105/Kconfig | 2 +-
drivers/media/radio/Kconfig | 2 +-
drivers/message/fusion/Kconfig | 8 ++--
drivers/net/arcnet/Kconfig | 2 +-
drivers/net/ethernet/8390/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 4 +-
drivers/net/ethernet/sis/Kconfig | 6 +--
drivers/net/ethernet/ti/Kconfig | 4 +-
drivers/net/ethernet/via/Kconfig | 4 +-
drivers/net/fddi/Kconfig | 4 +-
drivers/net/wan/Kconfig | 2 +-
drivers/net/wireless/atmel/Kconfig | 4 +-
drivers/net/wireless/intersil/hostap/Kconfig | 4 +-
drivers/pci/Kconfig | 11 +++++
drivers/scsi/Kconfig | 20 ++++-----
drivers/scsi/aic7xxx/Kconfig.aic79xx | 2 +-
drivers/scsi/aic7xxx/Kconfig.aic7xxx | 2 +-
drivers/scsi/aic94xx/Kconfig | 2 +-
drivers/scsi/megaraid/Kconfig.megaraid | 2 +-
drivers/scsi/mvsas/Kconfig | 2 +-
drivers/scsi/qla2xxx/Kconfig | 2 +-
drivers/spi/Kconfig | 1 +
drivers/staging/sm750fb/Kconfig | 2 +-
drivers/staging/vt6655/Kconfig | 2 +-
drivers/tty/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 22 +++++-----
drivers/watchdog/Kconfig | 4 +-
sound/pci/Kconfig | 43 ++++++++++++++++----
40 files changed, 194 insertions(+), 110 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7da8ea7b3ed..32e0489bd01c 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -556,7 +556,7 @@ comment "PATA SFF controllers with BMDMA"
config PATA_ALI
tristate "ALi PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the ALi ATA interfaces
@@ -566,7 +566,7 @@ config PATA_ALI
config PATA_AMD
tristate "AMD/NVidia PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the AMD and NVidia PATA
@@ -584,7 +584,7 @@ config PATA_ARASAN_CF
config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for ARTOP PATA controllers.
@@ -621,7 +621,7 @@ config PATA_BK3710
config PATA_CMD64X
tristate "CMD64x PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD64x series chips
@@ -667,7 +667,7 @@ config PATA_CS5536
config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the Cypress/Contaq CY82C693
@@ -707,7 +707,7 @@ config PATA_FTIDE010
config PATA_HPT366
tristate "HPT 366/368 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the HPT 366 and 368
PATA controllers via the new ATA layer.
@@ -716,7 +716,7 @@ config PATA_HPT366
config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the majority of the later HPT
PATA controllers via the new ATA layer.
@@ -725,7 +725,7 @@ config PATA_HPT37X
config PATA_HPT3X2N
tristate "HPT 371N/372N/302N PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the N variant HPT PATA
controllers via the new ATA layer.
@@ -828,7 +828,7 @@ config PATA_MPC52xx
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Netcell Revolution RAID
PATA controller.
@@ -864,7 +864,7 @@ config PATA_OLDPIIX
config PATA_OPTIDMA
tristate "OPTI FireStar PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables DMA/PIO support for the later OPTi
controllers found on some old motherboards and in some
@@ -874,7 +874,7 @@ config PATA_OPTIDMA
config PATA_PDC2027X
tristate "Promise PATA 2027x support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for Promise PATA pdc20268 to pdc20277 host adapters.
@@ -882,7 +882,7 @@ config PATA_PDC2027X
config PATA_PDC_OLD
tristate "Older Promise PATA controller support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.
@@ -910,7 +910,7 @@ config PATA_RDC
config PATA_SC1200
tristate "SC1200 PATA support"
- depends on PCI && (X86_32 || COMPILE_TEST)
+ depends on LEGACY_PCI && (X86_32 || COMPILE_TEST)
help
This option enables support for the NatSemi/AMD SC1200 SoC
companion chip used with the Geode processor family.
@@ -928,7 +928,7 @@ config PATA_SCH
config PATA_SERVERWORKS
tristate "SERVERWORKS OSB4/CSB5/CSB6/HT1000 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Serverworks OSB4/CSB5/CSB6 and
HT1000 PATA controllers, via the new ATA layer.
@@ -1005,7 +1005,7 @@ comment "PIO-only SFF controllers"
config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD640 PCI IDE
@@ -1086,7 +1086,7 @@ config PATA_NS87410
config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables full PIO support for the early Opti ATA
controllers found on some old motherboards.
@@ -1197,7 +1197,7 @@ config ATA_GENERIC
config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
- depends on (ISA || PCI)
+ depends on (ISA || LEGACY_PCI)
select PATA_TIMINGS
help
This option enables support for ISA/VLB/PCI bus legacy PATA
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 20a32e4d501d..791942217e2c 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -197,7 +197,8 @@ static int ata_generic_init_one(struct pci_dev *dev, const struct pci_device_id
if (!(command & PCI_COMMAND_IO))
return -ENODEV;
- if (dev->vendor == PCI_VENDOR_ID_AL)
+ if (IS_ENABLED(CONFIG_LEGACY_PCI) &&
+ dev->vendor == PCI_VENDOR_ID_AL)
ata_pci_bmdma_clear_simplex(dev);
if (dev->vendor == PCI_VENDOR_ID_ATI) {
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index b71ea4a680b0..636848ab6839 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -3107,6 +3107,7 @@ EXPORT_SYMBOL_GPL(ata_bmdma_port_start32);
#ifdef CONFIG_PCI
+#ifdef CONFIG_LEGACY_PCI
/**
* ata_pci_bmdma_clear_simplex - attempt to kick device out of simplex
* @pdev: PCI device
@@ -3132,6 +3133,7 @@ int ata_pci_bmdma_clear_simplex(struct pci_dev *pdev)
return 0;
}
EXPORT_SYMBOL_GPL(ata_pci_bmdma_clear_simplex);
+#endif
static void ata_bmdma_nodma(struct ata_host *host, const char *reason)
{
diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 3cb61fa2c5c3..1b642716c5d3 100644
--- a/drivers/comedi/Kconfig
+++ b/drivers/comedi/Kconfig
@@ -572,6 +572,7 @@ if COMEDI_PCI_DRIVERS
config COMEDI_8255_PCI
tristate "Generic PCI based 8255 digital i/o board support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for PCI based 8255 digital i/o boards. This driver
@@ -589,6 +590,7 @@ config COMEDI_8255_PCI
config COMEDI_ADDI_WATCHDOG
tristate
+ depends on LEGACY_PCI
help
Provides support for the watchdog subdevice found on many ADDI-DATA
boards. This module will be automatically selected when needed. The
@@ -596,6 +598,7 @@ config COMEDI_ADDI_WATCHDOG
config COMEDI_ADDI_APCI_1032
tristate "ADDI-DATA APCI_1032 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1032 cards
@@ -604,6 +607,7 @@ config COMEDI_ADDI_APCI_1032
config COMEDI_ADDI_APCI_1500
tristate "ADDI-DATA APCI_1500 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1500 cards
@@ -612,6 +616,7 @@ config COMEDI_ADDI_APCI_1500
config COMEDI_ADDI_APCI_1516
tristate "ADDI-DATA APCI-1016/1516/2016 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI-1016, APCI-1516 and APCI-2016 boards.
@@ -623,6 +628,7 @@ config COMEDI_ADDI_APCI_1516
config COMEDI_ADDI_APCI_1564
tristate "ADDI-DATA APCI_1564 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_1564 cards
@@ -632,6 +638,7 @@ config COMEDI_ADDI_APCI_1564
config COMEDI_ADDI_APCI_16XX
tristate "ADDI-DATA APCI_16xx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_16xx cards
@@ -640,6 +647,7 @@ config COMEDI_ADDI_APCI_16XX
config COMEDI_ADDI_APCI_2032
tristate "ADDI-DATA APCI_2032 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2032 cards
@@ -649,6 +657,7 @@ config COMEDI_ADDI_APCI_2032
config COMEDI_ADDI_APCI_2200
tristate "ADDI-DATA APCI_2200 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2200 cards
@@ -658,6 +667,7 @@ config COMEDI_ADDI_APCI_2200
config COMEDI_ADDI_APCI_3120
tristate "ADDI-DATA APCI_3120/3001 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
help
Enable support for ADDI-DATA APCI_3120/3001 cards
@@ -667,6 +677,7 @@ config COMEDI_ADDI_APCI_3120
config COMEDI_ADDI_APCI_3501
tristate "ADDI-DATA APCI_3501 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3501 cards
@@ -675,6 +686,7 @@ config COMEDI_ADDI_APCI_3501
config COMEDI_ADDI_APCI_3XXX
tristate "ADDI-DATA APCI_3xxx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3xxx cards
@@ -683,6 +695,7 @@ config COMEDI_ADDI_APCI_3XXX
config COMEDI_ADL_PCI6208
tristate "ADLink PCI-6208A support"
+ depends on LEGACY_PCI
help
Enable support for ADLink PCI-6208A cards
@@ -691,6 +704,7 @@ config COMEDI_ADL_PCI6208
config COMEDI_ADL_PCI7X3X
tristate "ADLink PCI-723X/743X isolated digital i/o board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-723X/743X isolated digital i/o boards.
Supported boards include the 32-channel PCI-7230 (16 in/16 out),
@@ -702,6 +716,7 @@ config COMEDI_ADL_PCI7X3X
config COMEDI_ADL_PCI8164
tristate "ADLink PCI-8164 4 Axes Motion Control board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-8164 4 Axes Motion Control board
@@ -710,6 +725,7 @@ config COMEDI_ADL_PCI8164
config COMEDI_ADL_PCI9111
tristate "ADLink PCI-9111HR support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for ADlink PCI9111 cards
@@ -719,6 +735,7 @@ config COMEDI_ADL_PCI9111
config COMEDI_ADL_PCI9118
tristate "ADLink PCI-9118DG, PCI-9118HG, PCI-9118HR support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_8254
help
@@ -729,6 +746,7 @@ config COMEDI_ADL_PCI9118
config COMEDI_ADV_PCI1710
tristate "Advantech PCI-171x and PCI-1731 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Advantech PCI-1710, PCI-1710HG, PCI-1711,
@@ -739,6 +757,7 @@ config COMEDI_ADV_PCI1710
config COMEDI_ADV_PCI1720
tristate "Advantech PCI-1720 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1720 Analog Output board.
@@ -747,6 +766,7 @@ config COMEDI_ADV_PCI1720
config COMEDI_ADV_PCI1723
tristate "Advantech PCI-1723 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1723 cards
@@ -755,6 +775,7 @@ config COMEDI_ADV_PCI1723
config COMEDI_ADV_PCI1724
tristate "Advantech PCI-1724U support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1724U cards. These are 32-channel
analog output cards with voltage and current loop output ranges and
@@ -765,6 +786,7 @@ config COMEDI_ADV_PCI1724
config COMEDI_ADV_PCI1760
tristate "Advantech PCI-1760 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1760 board.
@@ -773,6 +795,7 @@ config COMEDI_ADV_PCI1760
config COMEDI_ADV_PCI_DIO
tristate "Advantech PCI DIO card support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -786,6 +809,7 @@ config COMEDI_ADV_PCI_DIO
config COMEDI_AMPLC_DIO200_PCI
tristate "Amplicon PCI215/PCI272/PCIe215/PCIe236/PCIe296 DIO support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_DIO200
help
Enable support for Amplicon PCI215, PCI272, PCIe215, PCIe236
@@ -796,6 +820,7 @@ config COMEDI_AMPLC_DIO200_PCI
config COMEDI_AMPLC_PC236_PCI
tristate "Amplicon PCI236 DIO board support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_PC236
help
Enable support for Amplicon PCI236 DIO board.
@@ -805,6 +830,7 @@ config COMEDI_AMPLC_PC236_PCI
config COMEDI_AMPLC_PC263_PCI
tristate "Amplicon PCI263 relay board support"
+ depends on LEGACY_PCI
help
Enable support for Amplicon PCI263 relay board. This is a PCI board
with 16 reed relay output channels.
@@ -814,6 +840,7 @@ config COMEDI_AMPLC_PC263_PCI
config COMEDI_AMPLC_PCI224
tristate "Amplicon PCI224 and PCI234 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Amplicon PCI224 and PCI234 AO boards
@@ -823,6 +850,7 @@ config COMEDI_AMPLC_PCI224
config COMEDI_AMPLC_PCI230
tristate "Amplicon PCI230 and PCI260 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -834,6 +862,7 @@ config COMEDI_AMPLC_PCI230
config COMEDI_CONTEC_PCI_DIO
tristate "Contec PIO1616L digital I/O board support"
+ depends on LEGACY_PCI
help
Enable support for the Contec PIO1616L digital I/O board
@@ -842,6 +871,7 @@ config COMEDI_CONTEC_PCI_DIO
config COMEDI_DAS08_PCI
tristate "DAS-08 PCI support"
+ depends on LEGACY_PCI
select COMEDI_DAS08
help
Enable support for PCI DAS-08 cards.
@@ -861,6 +891,7 @@ config COMEDI_DT3000
config COMEDI_DYNA_PCI10XX
tristate "Dynalog PCI DAQ series support"
+ depends on LEGACY_PCI
help
Enable support for Dynalog PCI DAQ series
PCI-1050
@@ -894,6 +925,7 @@ config COMEDI_ICP_MULTI
config COMEDI_DAQBOARD2000
tristate "IOtech DAQboard/2000 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for the IOtech DAQboard/2000
@@ -911,6 +943,7 @@ config COMEDI_JR3_PCI
config COMEDI_KE_COUNTER
tristate "Kolter-Electronic PCI Counter 1 card support"
+ depends on LEGACY_PCI
help
Enable support for Kolter-Electronic PCI Counter 1 cards
@@ -919,6 +952,7 @@ config COMEDI_KE_COUNTER
config COMEDI_CB_PCIDAS64
tristate "MeasurementComputing PCI-DAS 64xx, 60xx, and 4020 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DAS 64xx,
@@ -929,6 +963,7 @@ config COMEDI_CB_PCIDAS64
config COMEDI_CB_PCIDAS
tristate "MeasurementComputing PCI-DAS support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -942,6 +977,7 @@ config COMEDI_CB_PCIDAS
config COMEDI_CB_PCIDDA
tristate "MeasurementComputing PCI-DDA series support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DDA
@@ -953,6 +989,7 @@ config COMEDI_CB_PCIDDA
config COMEDI_CB_PCIMDAS
tristate "MeasurementComputing PCIM-DAS1602/16, PCIe-DAS1602/16 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -964,6 +1001,7 @@ config COMEDI_CB_PCIMDAS
config COMEDI_CB_PCIMDDA
tristate "MeasurementComputing PCIM-DDA06-16 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCIM-DDA06-16
@@ -973,6 +1011,7 @@ config COMEDI_CB_PCIMDDA
config COMEDI_ME4000
tristate "Meilhaus ME-4000 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Meilhaus PCI data acquisition cards
@@ -1031,6 +1070,7 @@ config COMEDI_NI_670X
config COMEDI_NI_LABPC_PCI
tristate "NI Lab-PC PCI-1200 support"
+ depends on LEGACY_PCI
select COMEDI_NI_LABPC
help
Enable support for National Instruments Lab-PC PCI-1200.
@@ -1040,6 +1080,7 @@ config COMEDI_NI_LABPC_PCI
config COMEDI_NI_PCIDIO
tristate "NI PCI-DIO32HS, PCI-6533, PCI-6534 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_MITE
select COMEDI_8255
@@ -1052,6 +1093,7 @@ config COMEDI_NI_PCIDIO
config COMEDI_NI_PCIMIO
tristate "NI PCI-MIO-E series and M series support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_NI_TIOCMD
select COMEDI_8255
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 60d9374c72c0..d36afa5ac6fc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -687,7 +687,7 @@ config GPIO_VR41XX
config GPIO_VX855
tristate "VIA VX855/VX875 GPIO"
- depends on (X86 || COMPILE_TEST) && PCI
+ depends on (X86 || COMPILE_TEST) && LEGACY_PCI
select MFD_CORE
select MFD_VX855
help
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 64bd3dfba2c4..09397562c396 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1654,7 +1654,7 @@ config SENSORS_S3C_RAW
config SENSORS_SIS5595
tristate "Silicon Integrated Systems Corp. SiS5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
SiS5595 South Bridges.
@@ -1985,7 +1985,7 @@ config SENSORS_VIA_CPUTEMP
config SENSORS_VIA686A
tristate "VIA686A"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
Via 686A/B South Bridges.
@@ -2006,7 +2006,7 @@ config SENSORS_VT1211
config SENSORS_VT8231
tristate "VIA VT8231"
- depends on PCI
+ depends on LEGACY_PCI
select HWMON_VID
help
If you say yes here then you get support for the integrated sensors
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index dce392839017..a8d6274dc965 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -11,7 +11,7 @@ comment "PC SMBus host controller drivers"
config I2C_ALI1535
tristate "ALI 1535"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1535 South Bridges. The SMB
@@ -23,7 +23,7 @@ config I2C_ALI1535
config I2C_ALI1563
tristate "ALI 1563"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1563 South Bridges. The SMB
@@ -35,7 +35,7 @@ config I2C_ALI1563
config I2C_ALI15X3
tristate "ALI 15x3"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
Acer Labs Inc. (ALI) M1514 and M1543 motherboard I2C interfaces.
@@ -45,7 +45,7 @@ config I2C_ALI15X3
config I2C_AMD756
tristate "AMD 756/766/768/8111 and nVidia nForce"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the AMD
756/766/768 mainboard I2C interfaces. The driver also includes
@@ -70,7 +70,7 @@ config I2C_AMD756_S4882
config I2C_AMD8111
tristate "AMD 8111"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
second (SMBus 2.0) AMD 8111 mainboard I2C interface.
@@ -154,7 +154,7 @@ config I2C_I801
config I2C_ISCH
tristate "Intel SCH SMBus 1.0"
- depends on PCI
+ depends on LEGACY_PCI
select LPC_SCH
help
Say Y here if you want to use SMBus controller on the Intel SCH
@@ -221,7 +221,7 @@ config I2C_CHT_WC
config I2C_NFORCE2
tristate "Nvidia nForce2, nForce3 and nForce4"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the Nvidia
nForce2, nForce3 and nForce4 families of mainboard I2C interfaces.
@@ -253,7 +253,7 @@ config I2C_NVIDIA_GPU
config I2C_SIS5595
tristate "SiS 5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS5595 SMBus (a subset of I2C) interface.
@@ -263,7 +263,7 @@ config I2C_SIS5595
config I2C_SIS630
tristate "SiS 630/730/964"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS630, SiS730 and SiS964 SMBus (a subset of I2C) interface.
@@ -273,7 +273,7 @@ config I2C_SIS630
config I2C_SIS96X
tristate "SiS 96x"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SiS
96x SMBus (a subset of I2C) interfaces. Specifically, the following
@@ -291,7 +291,7 @@ config I2C_SIS96X
config I2C_VIA
tristate "VIA VT82C586B"
- depends on PCI
+ depends on LEGACY_PCI
select I2C_ALGOBIT
help
If you say yes to this option, support will be included for the VIA
@@ -302,7 +302,7 @@ config I2C_VIA
config I2C_VIAPRO
tristate "VIA VT82C596/82C686/82xx and CX700/VX8xx/VX900"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the VIA
VT82C596 and later SMBus interface. Specifically, the following
diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 5a2c2fb3217d..082280f95333 100644
--- a/drivers/input/gameport/Kconfig
+++ b/drivers/input/gameport/Kconfig
@@ -43,7 +43,7 @@ config GAMEPORT_L4
config GAMEPORT_EMU10K1
tristate "SB Live and Audigy gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have a SoundBlaster Live! or SoundBlaster
Audigy card and want to use its gameport.
@@ -53,7 +53,7 @@ config GAMEPORT_EMU10K1
config GAMEPORT_FM801
tristate "ForteMedia FM801 gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have ForteMedia FM801 PCI audio controller
(Abit AU10, Genius Sound Maker, HP Workstation zx2000,
diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig
index 078eeadf707a..2c5e16483179 100644
--- a/drivers/isdn/hardware/mISDN/Kconfig
+++ b/drivers/isdn/hardware/mISDN/Kconfig
@@ -7,14 +7,14 @@ comment "mISDN hardware drivers"
config MISDN_HFCPCI
tristate "Support for HFC PCI cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for cards with Cologne Chip AG's
HFC PCI chip.
config MISDN_HFCMULTI
tristate "Support for HFC multiport cards (HFC-4S/8S/E1)"
- depends on PCI || CPM1
+ depends on LEGACY_PCI || CPM1
depends on MISDN
help
Enable support for cards with Cologne Chip AG's HFC multiport
@@ -43,7 +43,7 @@ config MISDN_HFCUSB
config MISDN_AVMFRITZ
tristate "Support for AVM FRITZ!CARD PCI"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for AVMs FRITZ!CARD PCI cards
@@ -51,7 +51,7 @@ config MISDN_AVMFRITZ
config MISDN_SPEEDFAX
tristate "Support for Sedlbauer Speedfax+"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
select MISDN_ISAR
help
@@ -60,7 +60,7 @@ config MISDN_SPEEDFAX
config MISDN_INFINEON
tristate "Support for cards with Infineon chipset"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for cards with ISAC + HSCX, IPAC or IPAC-SX
@@ -69,14 +69,14 @@ config MISDN_INFINEON
config MISDN_W6692
tristate "Support for cards with Winbond 6692"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for Winbond 6692 PCI chip based cards.
config MISDN_NETJET
tristate "Support for NETJet cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
depends on TTY
select MISDN_IPAC
select MISDN_HDLC
diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
index b672d3142eb7..5e92ece5b104 100644
--- a/drivers/media/cec/platform/Kconfig
+++ b/drivers/media/cec/platform/Kconfig
@@ -100,7 +100,7 @@ config CEC_TEGRA
config CEC_SECO
tristate "SECO Boards HDMI CEC driver"
depends on (X86 || IA64) || COMPILE_TEST
- depends on PCI && DMI
+ depends on LEGACY_PCI && DMI
select CEC_CORE
select CEC_NOTIFIER
help
diff --git a/drivers/media/pci/dm1105/Kconfig b/drivers/media/pci/dm1105/Kconfig
index e0e3af67c99c..9ecab93685d4 100644
--- a/drivers/media/pci/dm1105/Kconfig
+++ b/drivers/media/pci/dm1105/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
- depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
+ depends on DVB_CORE && LEGACY_PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index d29e29645e04..32eb73993998 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -67,7 +67,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate "Guillemot MAXI Radio FM 2000 radio"
- depends on VIDEO_V4L2 && PCI
+ depends on VIDEO_V4L2 && LEGACY_PCI
select RADIO_TEA575X
help
Choose Y here if you have this radio card. This card may also be
diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index a3d0288fd0e2..cec5995e1911 100644
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -2,7 +2,7 @@
menuconfig FUSION
bool "Fusion MPT device support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here to get to see options for Fusion Message
Passing Technology (MPT) drivers.
@@ -14,7 +14,7 @@ if FUSION
config FUSION_SPI
tristate "Fusion MPT ScsiHost drivers for SPI"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
SCSI HOST support for a parallel SCSI host adapters.
@@ -29,7 +29,7 @@ config FUSION_SPI
config FUSION_FC
tristate "Fusion MPT ScsiHost drivers for FC"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
help
SCSI HOST support for a Fiber Channel host adapters.
@@ -48,7 +48,7 @@ config FUSION_FC
config FUSION_SAS
tristate "Fusion MPT ScsiHost drivers for SAS"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SAS_ATTRS
help
SCSI HOST support for a SAS host adapters.
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..b8038287c4f2 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -4,7 +4,7 @@
#
menuconfig ARCNET
- depends on NETDEVICES && (ISA || PCI || PCMCIA)
+ depends on NETDEVICES && (ISA || LEGACY_PCI || PCMCIA)
tristate "ARCnet support"
help
If you have a network card of this type, say Y and check out the
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..0fa43943ea74 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -117,7 +117,7 @@ config NE2000
config NE2K_PCI
tristate "PCI NE2000 and clones support (see help)"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
help
This driver is for NE2000 compatible PCI cards. It will not work
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 899c8a2a34b6..0ac61a5f1a37 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -56,7 +56,7 @@ config LANCE
config PCNET32
tristate "AMD PCnet32 PCI support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 0b274d8fa45b..45a3c42945fc 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_INTEL
config E100
tristate "Intel(R) PRO/100+ support"
- depends on PCI
+ depends on LEGACY_PCI
select MII
help
This driver supports Intel(R) PRO/100 family of adapters.
@@ -41,7 +41,7 @@ config E100
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
help
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
diff --git a/drivers/net/ethernet/sis/Kconfig b/drivers/net/ethernet/sis/Kconfig
index 775d76d9890e..bd1b1b81b0e8 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_SIS
bool "Silicon Integrated Systems (SiS) devices"
default y
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
config SIS900
tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
@@ -35,7 +35,7 @@ config SIS900
config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..8b1d67b00e68 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_TI
bool "Texas Instruments (TI) devices"
default y
- depends on PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ depends on LEGACY_PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
config TLAN
tristate "TI ThunderLAN support"
- depends on (PCI || EISA)
+ depends on (LEGACY_PCI || EISA)
help
If you have a PCI Ethernet network card based on the ThunderLAN chip
which is supported by this driver, say Y here.
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index da287ef65be7..0ca7d8f7bfde 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -18,8 +18,8 @@ if NET_VENDOR_VIA
config VIA_RHINE
tristate "VIA Rhine support"
- depends on PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
- depends on PCI || ARCH_VT8500 || COMPILE_TEST
+ depends on LEGACY_PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
+ depends on LEGACY_PCI || ARCH_VT8500 || COMPILE_TEST
depends on HAS_DMA
select CRC32
select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..1753c08d6423 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -5,7 +5,7 @@
config FDDI
tristate "FDDI driver support"
- depends on PCI || EISA || TC
+ depends on LEGACY_PCI || EISA || TC
help
Fiber Distributed Data Interface is a high speed local area network
design; essentially a replacement for high speed Ethernet. FDDI can
@@ -29,7 +29,7 @@ config DEFZA
config DEFXX
tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
- depends on FDDI && (PCI || EISA || TC)
+ depends on FDDI && (LEGACY_PCI || EISA || TC)
help
This is support for the DIGITAL series of TURBOchannel (DEFTA),
EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 592a8389fc5a..631c4c1c56c8 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -250,7 +250,7 @@ config C101
config FARSYNC
tristate "FarSync T-Series support"
- depends on HDLC && PCI
+ depends on HDLC && LEGACY_PCI
help
Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
FarSite Communications Ltd.
diff --git a/drivers/net/wireless/atmel/Kconfig b/drivers/net/wireless/atmel/Kconfig
index ca45a1021cf4..9baa4a19dd38 100644
--- a/drivers/net/wireless/atmel/Kconfig
+++ b/drivers/net/wireless/atmel/Kconfig
@@ -14,7 +14,7 @@ if WLAN_VENDOR_ATMEL
config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
- depends on CFG80211 && (PCI || PCMCIA)
+ depends on CFG80211 && (LEGACY_PCI || PCMCIA)
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
@@ -32,7 +32,7 @@ config ATMEL
config PCI_ATMEL
tristate "Atmel at76c506 PCI cards"
- depends on ATMEL && PCI
+ depends on ATMEL && LEGACY_PCI
help
Enable support for PCI and mini-PCI cards containing the
Atmel at76c506 chip.
diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig
index c865d3156cea..9bcd1c8546ff 100644
--- a/drivers/net/wireless/intersil/hostap/Kconfig
+++ b/drivers/net/wireless/intersil/hostap/Kconfig
@@ -56,7 +56,7 @@ config HOSTAP_FIRMWARE_NVRAM
config HOSTAP_PLX
tristate "Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2/2.5/3 PC Cards in PLX9052 based
PCI adaptors.
@@ -70,7 +70,7 @@ config HOSTAP_PLX
config HOSTAP_PCI
tristate "Host AP driver for Prism2.5 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2.5 PCI adaptors.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 43e615aa12ff..e0c99ddc145c 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -23,6 +23,17 @@ menuconfig PCI
if PCI
+config LEGACY_PCI
+ bool "Enable support for legacy PCI devices"
+ depends on HAVE_PCI
+ help
+ This option enables support for legacy PCI devices. This includes
+ PCI devices attached directly or via a bridge on a PCI Express bus.
+ It also includes compatibility features on PCI Express devices which
+ make use of legacy I/O spaces.
+
+ For maximum compatibility with old hardware say 'Y'
+
config PCI_DOMAINS
bool
depends on PCI
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..5436b2be2c73 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -333,7 +333,7 @@ config SGIWD93_SCSI
config BLK_DEV_3W_XXXX_RAID
tristate "3ware 5/6/7/8xxx ATA-RAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
3ware is the only hardware ATA-Raid product in Linux to date.
This card is 2,4, or 8 channel master mode support only.
@@ -380,7 +380,7 @@ config SCSI_3W_SAS
config SCSI_ACARD
tristate "ACARD SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the ACARD SCSI host adapter.
Support Chip <ATP870 ATP876 ATP880 ATP885>
@@ -472,7 +472,7 @@ config SCSI_DPT_I2O
config SCSI_ADVANSYS
tristate "AdvanSys SCSI support"
depends on SCSI
- depends on ISA || EISA || PCI
+ depends on ISA || EISA || LEGACY_PCI
depends on ISA_DMA_API || !ISA
help
This is a driver for all SCSI host adapters manufactured by
@@ -643,7 +643,7 @@ config SCSI_SNIC_DEBUG_FS
config SCSI_DMX3191D
tristate "DMX3191D SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This is support for Domex DMX3191D SCSI Host Adapters.
@@ -657,7 +657,7 @@ config SCSI_FDOMAIN
config SCSI_FDOMAIN_PCI
tristate "Future Domain TMC-3260/AHA-2920A PCI SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_FDOMAIN
help
This is support for Future Domain's PCI SCSI host adapters (TMC-3260)
@@ -710,7 +710,7 @@ config SCSI_GENERIC_NCR5380
config SCSI_IPS
tristate "IBM ServeRAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the IBM ServeRAID hardware RAID controllers.
See <http://www.developer.ibm.com/welcome/netfinity/serveraid.html>
@@ -770,7 +770,7 @@ config SCSI_IBMVFC_TRACE
config SCSI_INITIO
tristate "Initio 9100U(W) support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio 91XXU(W) SCSI host adapter. Please
read the SCSI-HOWTO, available from
@@ -781,7 +781,7 @@ config SCSI_INITIO
config SCSI_INIA100
tristate "Initio INI-A100U2W support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio INI-A100U2W SCSI host adapter.
Please read the SCSI-HOWTO, available from
@@ -1130,7 +1130,7 @@ config SCSI_QLOGIC_FAS
config SCSI_QLOGIC_1280
tristate "Qlogic QLA 1240/1x80/1x160 SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
Say Y if you have a QLogic ISP1240/1x80/1x160 SCSI host adapter.
@@ -1187,7 +1187,7 @@ config SCSI_SIM710
config SCSI_DC395x
tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports PCI SCSI host adapters based on the ASIC
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic79xx b/drivers/scsi/aic7xxx/Kconfig.aic79xx
index a47dbd500e9a..64332cc73ea0 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic79xx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic79xx
@@ -5,7 +5,7 @@
#
config SCSI_AIC79XX
tristate "Adaptec AIC79xx U320 support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Ultra 320 PCI-X
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic7xxx b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
index 0cfd92ce750a..3fa5dc1d1186 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic7xxx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
@@ -5,7 +5,7 @@
#
config SCSI_AIC7XXX
tristate "Adaptec AIC7xxx Fast -> U160 support"
- depends on (PCI || EISA) && SCSI
+ depends on (LEGACY_PCI || EISA) && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Fast through Ultra 160 PCI
diff --git a/drivers/scsi/aic94xx/Kconfig b/drivers/scsi/aic94xx/Kconfig
index 71931c371b1c..b0cbf65dbe5b 100644
--- a/drivers/scsi/aic94xx/Kconfig
+++ b/drivers/scsi/aic94xx/Kconfig
@@ -8,7 +8,7 @@
config SCSI_AIC94XX
tristate "Adaptec AIC94xx SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
index 2adc2afd9f91..4ec46aede490 100644
--- a/drivers/scsi/megaraid/Kconfig.megaraid
+++ b/drivers/scsi/megaraid/Kconfig.megaraid
@@ -67,7 +67,7 @@ config MEGARAID_MAILBOX
config MEGARAID_LEGACY
tristate "LSI Logic Legacy MegaRAID Driver"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the LSI MegaRAID 418, 428, 438, 466, 762, 490
and 467 SCSI host adapters. This driver also support the all U320
diff --git a/drivers/scsi/mvsas/Kconfig b/drivers/scsi/mvsas/Kconfig
index 79812b80743b..f41f3f4a9f34 100644
--- a/drivers/scsi/mvsas/Kconfig
+++ b/drivers/scsi/mvsas/Kconfig
@@ -9,7 +9,7 @@
config SCSI_MVSAS
tristate "Marvell 88SE64XX/88SE94XX SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 802c373fd6d9..93afb73858ce 100644
--- a/drivers/scsi/qla2xxx/Kconfig
+++ b/drivers/scsi/qla2xxx/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
depends on NVME_FC || !NVME_FC
select FW_LOADER
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 596705d24400..cfbd45767095 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -204,6 +204,7 @@ config SPI_BITBANG
config SPI_BUTTERFLY
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
depends on PARPORT
+ depends on HAS_IOPORT
select SPI_BITBANG
help
This uses a custom parallel port cable to connect to an AVR
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 8c0d8a873d5b..d332f912b964 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/staging/vt6655/Kconfig b/drivers/staging/vt6655/Kconfig
index d1cd5de46dcf..dd236f54d3a2 100644
--- a/drivers/staging/vt6655/Kconfig
+++ b/drivers/staging/vt6655/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
config VT6655
tristate "VIA Technologies VT6655 support"
- depends on PCI && MAC80211 && m
+ depends on LEGACY_PCI && MAC80211 && m
help
This is a vendor-written driver for VIA VT6655.
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc30ff93e2e4..460326a529d6 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -203,7 +203,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on SERIAL_NONSTANDARD && LEGACY_PCI
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index fc543ac97c13..607791b7f693 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -908,7 +908,7 @@ config SERIAL_VR41XX_CONSOLE
config SERIAL_JSM
tristate "Digi International NEO and Classic PCI Support"
- depends on PCI
+ depends on LEGACY_PCI
select SERIAL_CORE
help
This is a driver for Digi International's Neo and Classic series
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6ed5e608dd04..a3446d44c118 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -343,7 +343,7 @@ config FB_IMX
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
- depends on FB && PCI && (BROKEN || !SPARC64)
+ depends on FB && LEGACY_PCI && (BROKEN || !SPARC64)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1264,7 +1264,7 @@ config FB_ATY128_BACKLIGHT
Say Y here if you want to control the backlight of your display.
config FB_ATY
- tristate "ATI Mach64 display support" if PCI || ATARI
+ tristate "ATI Mach64 display support" if LEGACY_PCI || ATARI
depends on FB && !SPARC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1315,7 +1315,7 @@ config FB_ATY_BACKLIGHT
config FB_S3
tristate "S3 Trio/Virge support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1374,7 +1374,7 @@ config FB_SAVAGE_ACCEL
config FB_SIS
tristate "SiS/XGI display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1404,7 +1404,7 @@ config FB_SIS_315
config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
- depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
+ depends on FB && LEGACY_PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1442,7 +1442,7 @@ endif
config FB_NEOMAGIC
tristate "NeoMagic display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1470,7 +1470,7 @@ config FB_KYRO
config FB_3DFX
tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1518,7 +1518,7 @@ config FB_VOODOO1
config FB_VT8623
tristate "VIA VT8623 support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1532,7 +1532,7 @@ config FB_VT8623
config FB_TRIDENT
tristate "Trident/CyberXXX/CyberBlade support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1554,7 +1554,7 @@ config FB_TRIDENT
config FB_ARK
tristate "ARK 2000PV support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2226,7 +2226,7 @@ config FB_SSD1307
config FB_SM712
tristate "Silicon Motion SM712 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9d222ba17ec6..05258109bcc2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -2053,7 +2053,7 @@ comment "PCI-based Watchdog Cards"
config PCIPCWATCHDOG
tristate "Berkshire Products PCI-PC Watchdog"
- depends on PCI
+ depends on LEGACY_PCI
help
This is the driver for the Berkshire Products PCI-PC Watchdog card.
This card simply watches your kernel to make sure it doesn't freeze,
@@ -2068,7 +2068,7 @@ config PCIPCWATCHDOG
config WDTPCI
tristate "PCI-WDT500/501 Watchdog timer"
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 41ce12597177..07d9587eede4 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -23,10 +23,10 @@ config SND_AD1889
config SND_ALS300
tristate "Avance Logic ALS300/ALS300+"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_PCM
select SND_AC97_CODEC
select SND_OPL3_LIB
- depends on ZONE_DMA
help
Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
@@ -35,6 +35,7 @@ config SND_ALS300
config SND_ALS4000
tristate "Avance Logic ALS4000"
+ depends on LEGACY_PCI
depends on ISA_DMA_API
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -49,6 +50,7 @@ config SND_ALS4000
config SND_ALI5451
tristate "ALi M5451 PCI Audio Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
depends on ZONE_DMA
@@ -96,6 +98,7 @@ config SND_ATIIXP_MODEM
config SND_AU8810
tristate "Aureal Advantage"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -110,6 +113,7 @@ config SND_AU8810
config SND_AU8820
tristate "Aureal Vortex"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -123,6 +127,7 @@ config SND_AU8820
config SND_AU8830
tristate "Aureal Vortex 2"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -151,13 +156,13 @@ config SND_AW2
config SND_AZT3328
tristate "Aztech AZF3328 / PCI168"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
- depends on ZONE_DMA
help
Say Y here to include support for Aztech AZF3328 (PCI168)
soundcards.
@@ -172,6 +177,7 @@ config SND_AZT3328
config SND_BT87X
tristate "Bt87x Audio Capture"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to record audio from TV cards based on
@@ -193,6 +199,7 @@ config SND_BT87X_OVERCLOCK
config SND_CA0106
tristate "SB Audigy LS / Live 24bit"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
select SND_VMASTER
@@ -205,6 +212,7 @@ config SND_CA0106
config SND_CMIPCI
tristate "C-Media 8338, 8738, 8768, 8770"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
@@ -221,6 +229,7 @@ config SND_OXYGEN_LIB
config SND_OXYGEN
tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -246,6 +255,7 @@ config SND_OXYGEN
config SND_CS4281
tristate "Cirrus Logic (Sound Fusion) CS4281"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_RAWMIDI
select SND_AC97_CODEC
@@ -257,6 +267,7 @@ config SND_CS4281
config SND_CS46XX
tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
select FW_LOADER
@@ -290,6 +301,7 @@ config SND_CS5530
config SND_CS5535AUDIO
tristate "CS5535/CS5536 Audio"
depends on X86_32 || MIPS || COMPILE_TEST
+ depends on LEGACY_PCI
select SND_PCM
select SND_AC97_CODEC
help
@@ -307,6 +319,7 @@ config SND_CS5535AUDIO
config SND_CTXFI
tristate "Creative Sound Blaster X-Fi"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -462,13 +475,13 @@ config SND_INDIGODJX
config SND_EMU10K1
tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
+ depends on LEGACY_PCI && ZONE_DMA
select FW_LOADER
select SND_HWDEP
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
select SND_SEQ_DEVICE if SND_SEQUENCER != n
- depends on ZONE_DMA
help
Say Y to include support for Sound Blaster PCI 512, Live!,
Audigy and E-mu APS (partially supported) soundcards.
@@ -489,6 +502,7 @@ config SND_EMU10K1_SEQ
config SND_EMU10K1X
tristate "Emu10k1X (Dell OEM Version)"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
depends on ZONE_DMA
@@ -501,6 +515,7 @@ config SND_EMU10K1X
config SND_ENS1370
tristate "(Creative) Ensoniq AudioPCI 1370"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_PCM
help
@@ -511,6 +526,7 @@ config SND_ENS1370
config SND_ENS1371
tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
help
@@ -522,10 +538,10 @@ config SND_ENS1371
config SND_ES1938
tristate "ESS ES1938/1946/1969 (Solo-1)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Solo-1
(ES1938, ES1946, ES1969) chips.
@@ -535,9 +551,9 @@ config SND_ES1938
config SND_ES1968
tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro
1/2/2E chips.
@@ -569,6 +585,7 @@ config SND_ES1968_RADIO
config SND_FM801
tristate "ForteMedia FM801"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
@@ -621,10 +638,10 @@ config SND_HDSPM
config SND_ICE1712
tristate "ICEnsemble ICE1712 (Envy24)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
select BITREVERSE
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the
ICE1712 (Envy24) chip.
@@ -640,6 +657,7 @@ config SND_ICE1712
config SND_ICE1724
tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_VMASTER
@@ -712,6 +730,7 @@ config SND_LX6464ES
config SND_MAESTRO3
tristate "ESS Allegro/Maestro3"
select SND_AC97_CODEC
+ depends on LEGACY_PCI
depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro 3
@@ -753,6 +772,7 @@ config SND_NM256
config SND_PCXHR
tristate "Digigram PCXHR"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_PCM
select SND_HWDEP
@@ -764,6 +784,7 @@ config SND_PCXHR
config SND_RIPTIDE
tristate "Conexant Riptide"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -808,6 +829,7 @@ config SND_RME9652
config SND_SE6X
tristate "Studio Evolution SE6X"
depends on SND_OXYGEN=n && SND_VIRTUOSO=n # PCI ID conflict
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -827,10 +849,10 @@ config SND_SIS7019
config SND_SONICVIBES
tristate "S3 SonicVibes"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the S3
SonicVibes chip.
@@ -840,9 +862,9 @@ config SND_SONICVIBES
config SND_TRIDENT
tristate "Trident 4D-Wave DX/NX; SiS 7018"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on Trident
4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +874,7 @@ config SND_TRIDENT
config SND_VIA82XX
tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -863,6 +886,7 @@ config SND_VIA82XX
config SND_VIA82XX_MODEM
tristate "VIA 82C686A/B, 8233 based Modems"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
help
Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +897,7 @@ config SND_VIA82XX_MODEM
config SND_VIRTUOSO
tristate "Asus Virtuoso 66/100/200 (Xonar)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -889,6 +914,7 @@ config SND_VIRTUOSO
config SND_VX222
tristate "Digigram VX222"
+ depends on LEGACY_PCI
select SND_VX_LIB
help
Say Y here to include support for Digigram VX222 soundcards.
@@ -898,6 +924,7 @@ config SND_VX222
config SND_YMFPCI
tristate "Yamaha YMF724/740/744/754"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Mauro Carvalho Chehab, Sathya Prakash,
Sreekanth Reddy, Suganath Prabu Subramani, Michael Grzeschik,
David S. Miller, Jakub Kicinski, Jesse Brandeburg, Tony Nguyen,
Kalle Valo, Jouni Malinen, James E.J. Bottomley,
Martin K. Petersen, Hannes Reinecke, Kashyap Desai, Sumit Saxena,
Shivasharan S, Nilesh Javali, GR-QLogic-Storage-Upstream,
Mark Brown, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
Forest Bond, Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela,
Takashi Iwai
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-ide, linux-gpio, linux-hwmon, linux-i2c, linux-input,
netdev, linux-media, MPT-FusionLinux.pdl, linux-scsi,
intel-wired-lan, linux-wireless, megaraidlinux.pdl, linux-spi,
linux-fbdev, linux-staging, linux-serial, dri-devel,
linux-watchdog, alsa-devel
Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
PCI devices including those attached to a PCI-to-PCI Express bridge and
PCI Express devices using legacy I/O spaces. Note that this is different
from non PCI uses of I/O ports such as by ACPI.
Add dependencies on LEGACY_PCI for all PCI drivers which only target
legacy PCI devices and ifdef legacy PCI specific functions in ata
handling.
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>
---
drivers/ata/Kconfig | 34 ++++++++--------
drivers/ata/ata_generic.c | 3 +-
drivers/ata/libata-sff.c | 2 +
drivers/comedi/Kconfig | 42 +++++++++++++++++++
drivers/gpio/Kconfig | 2 +-
drivers/hwmon/Kconfig | 6 +--
drivers/i2c/busses/Kconfig | 24 +++++------
drivers/input/gameport/Kconfig | 4 +-
drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
drivers/media/cec/platform/Kconfig | 2 +-
drivers/media/pci/dm1105/Kconfig | 2 +-
drivers/media/radio/Kconfig | 2 +-
drivers/message/fusion/Kconfig | 8 ++--
drivers/net/arcnet/Kconfig | 2 +-
drivers/net/ethernet/8390/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 4 +-
drivers/net/ethernet/sis/Kconfig | 6 +--
drivers/net/ethernet/ti/Kconfig | 4 +-
drivers/net/ethernet/via/Kconfig | 4 +-
drivers/net/fddi/Kconfig | 4 +-
drivers/net/wan/Kconfig | 2 +-
drivers/net/wireless/atmel/Kconfig | 4 +-
drivers/net/wireless/intersil/hostap/Kconfig | 4 +-
drivers/pci/Kconfig | 11 +++++
drivers/scsi/Kconfig | 20 ++++-----
drivers/scsi/aic7xxx/Kconfig.aic79xx | 2 +-
drivers/scsi/aic7xxx/Kconfig.aic7xxx | 2 +-
drivers/scsi/aic94xx/Kconfig | 2 +-
drivers/scsi/megaraid/Kconfig.megaraid | 2 +-
drivers/scsi/mvsas/Kconfig | 2 +-
drivers/scsi/qla2xxx/Kconfig | 2 +-
drivers/spi/Kconfig | 1 +
drivers/staging/sm750fb/Kconfig | 2 +-
drivers/staging/vt6655/Kconfig | 2 +-
drivers/tty/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 22 +++++-----
drivers/watchdog/Kconfig | 4 +-
sound/pci/Kconfig | 43 ++++++++++++++++----
40 files changed, 194 insertions(+), 110 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7da8ea7b3ed..32e0489bd01c 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -556,7 +556,7 @@ comment "PATA SFF controllers with BMDMA"
config PATA_ALI
tristate "ALi PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the ALi ATA interfaces
@@ -566,7 +566,7 @@ config PATA_ALI
config PATA_AMD
tristate "AMD/NVidia PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the AMD and NVidia PATA
@@ -584,7 +584,7 @@ config PATA_ARASAN_CF
config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for ARTOP PATA controllers.
@@ -621,7 +621,7 @@ config PATA_BK3710
config PATA_CMD64X
tristate "CMD64x PATA support"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD64x series chips
@@ -667,7 +667,7 @@ config PATA_CS5536
config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the Cypress/Contaq CY82C693
@@ -707,7 +707,7 @@ config PATA_FTIDE010
config PATA_HPT366
tristate "HPT 366/368 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the HPT 366 and 368
PATA controllers via the new ATA layer.
@@ -716,7 +716,7 @@ config PATA_HPT366
config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the majority of the later HPT
PATA controllers via the new ATA layer.
@@ -725,7 +725,7 @@ config PATA_HPT37X
config PATA_HPT3X2N
tristate "HPT 371N/372N/302N PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the N variant HPT PATA
controllers via the new ATA layer.
@@ -828,7 +828,7 @@ config PATA_MPC52xx
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Netcell Revolution RAID
PATA controller.
@@ -864,7 +864,7 @@ config PATA_OLDPIIX
config PATA_OPTIDMA
tristate "OPTI FireStar PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables DMA/PIO support for the later OPTi
controllers found on some old motherboards and in some
@@ -874,7 +874,7 @@ config PATA_OPTIDMA
config PATA_PDC2027X
tristate "Promise PATA 2027x support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for Promise PATA pdc20268 to pdc20277 host adapters.
@@ -882,7 +882,7 @@ config PATA_PDC2027X
config PATA_PDC_OLD
tristate "Older Promise PATA controller support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.
@@ -910,7 +910,7 @@ config PATA_RDC
config PATA_SC1200
tristate "SC1200 PATA support"
- depends on PCI && (X86_32 || COMPILE_TEST)
+ depends on LEGACY_PCI && (X86_32 || COMPILE_TEST)
help
This option enables support for the NatSemi/AMD SC1200 SoC
companion chip used with the Geode processor family.
@@ -928,7 +928,7 @@ config PATA_SCH
config PATA_SERVERWORKS
tristate "SERVERWORKS OSB4/CSB5/CSB6/HT1000 PATA support"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables support for the Serverworks OSB4/CSB5/CSB6 and
HT1000 PATA controllers, via the new ATA layer.
@@ -1005,7 +1005,7 @@ comment "PIO-only SFF controllers"
config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
select PATA_TIMINGS
help
This option enables support for the CMD640 PCI IDE
@@ -1086,7 +1086,7 @@ config PATA_NS87410
config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
- depends on PCI
+ depends on LEGACY_PCI
help
This option enables full PIO support for the early Opti ATA
controllers found on some old motherboards.
@@ -1197,7 +1197,7 @@ config ATA_GENERIC
config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
- depends on (ISA || PCI)
+ depends on (ISA || LEGACY_PCI)
select PATA_TIMINGS
help
This option enables support for ISA/VLB/PCI bus legacy PATA
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 20a32e4d501d..791942217e2c 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -197,7 +197,8 @@ static int ata_generic_init_one(struct pci_dev *dev, const struct pci_device_id
if (!(command & PCI_COMMAND_IO))
return -ENODEV;
- if (dev->vendor == PCI_VENDOR_ID_AL)
+ if (IS_ENABLED(CONFIG_LEGACY_PCI) &&
+ dev->vendor == PCI_VENDOR_ID_AL)
ata_pci_bmdma_clear_simplex(dev);
if (dev->vendor == PCI_VENDOR_ID_ATI) {
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index b71ea4a680b0..636848ab6839 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -3107,6 +3107,7 @@ EXPORT_SYMBOL_GPL(ata_bmdma_port_start32);
#ifdef CONFIG_PCI
+#ifdef CONFIG_LEGACY_PCI
/**
* ata_pci_bmdma_clear_simplex - attempt to kick device out of simplex
* @pdev: PCI device
@@ -3132,6 +3133,7 @@ int ata_pci_bmdma_clear_simplex(struct pci_dev *pdev)
return 0;
}
EXPORT_SYMBOL_GPL(ata_pci_bmdma_clear_simplex);
+#endif
static void ata_bmdma_nodma(struct ata_host *host, const char *reason)
{
diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 3cb61fa2c5c3..1b642716c5d3 100644
--- a/drivers/comedi/Kconfig
+++ b/drivers/comedi/Kconfig
@@ -572,6 +572,7 @@ if COMEDI_PCI_DRIVERS
config COMEDI_8255_PCI
tristate "Generic PCI based 8255 digital i/o board support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for PCI based 8255 digital i/o boards. This driver
@@ -589,6 +590,7 @@ config COMEDI_8255_PCI
config COMEDI_ADDI_WATCHDOG
tristate
+ depends on LEGACY_PCI
help
Provides support for the watchdog subdevice found on many ADDI-DATA
boards. This module will be automatically selected when needed. The
@@ -596,6 +598,7 @@ config COMEDI_ADDI_WATCHDOG
config COMEDI_ADDI_APCI_1032
tristate "ADDI-DATA APCI_1032 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1032 cards
@@ -604,6 +607,7 @@ config COMEDI_ADDI_APCI_1032
config COMEDI_ADDI_APCI_1500
tristate "ADDI-DATA APCI_1500 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_1500 cards
@@ -612,6 +616,7 @@ config COMEDI_ADDI_APCI_1500
config COMEDI_ADDI_APCI_1516
tristate "ADDI-DATA APCI-1016/1516/2016 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI-1016, APCI-1516 and APCI-2016 boards.
@@ -623,6 +628,7 @@ config COMEDI_ADDI_APCI_1516
config COMEDI_ADDI_APCI_1564
tristate "ADDI-DATA APCI_1564 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_1564 cards
@@ -632,6 +638,7 @@ config COMEDI_ADDI_APCI_1564
config COMEDI_ADDI_APCI_16XX
tristate "ADDI-DATA APCI_16xx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_16xx cards
@@ -640,6 +647,7 @@ config COMEDI_ADDI_APCI_16XX
config COMEDI_ADDI_APCI_2032
tristate "ADDI-DATA APCI_2032 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2032 cards
@@ -649,6 +657,7 @@ config COMEDI_ADDI_APCI_2032
config COMEDI_ADDI_APCI_2200
tristate "ADDI-DATA APCI_2200 support"
+ depends on LEGACY_PCI
select COMEDI_ADDI_WATCHDOG
help
Enable support for ADDI-DATA APCI_2200 cards
@@ -658,6 +667,7 @@ config COMEDI_ADDI_APCI_2200
config COMEDI_ADDI_APCI_3120
tristate "ADDI-DATA APCI_3120/3001 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
help
Enable support for ADDI-DATA APCI_3120/3001 cards
@@ -667,6 +677,7 @@ config COMEDI_ADDI_APCI_3120
config COMEDI_ADDI_APCI_3501
tristate "ADDI-DATA APCI_3501 support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3501 cards
@@ -675,6 +686,7 @@ config COMEDI_ADDI_APCI_3501
config COMEDI_ADDI_APCI_3XXX
tristate "ADDI-DATA APCI_3xxx support"
+ depends on LEGACY_PCI
help
Enable support for ADDI-DATA APCI_3xxx cards
@@ -683,6 +695,7 @@ config COMEDI_ADDI_APCI_3XXX
config COMEDI_ADL_PCI6208
tristate "ADLink PCI-6208A support"
+ depends on LEGACY_PCI
help
Enable support for ADLink PCI-6208A cards
@@ -691,6 +704,7 @@ config COMEDI_ADL_PCI6208
config COMEDI_ADL_PCI7X3X
tristate "ADLink PCI-723X/743X isolated digital i/o board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-723X/743X isolated digital i/o boards.
Supported boards include the 32-channel PCI-7230 (16 in/16 out),
@@ -702,6 +716,7 @@ config COMEDI_ADL_PCI7X3X
config COMEDI_ADL_PCI8164
tristate "ADLink PCI-8164 4 Axes Motion Control board support"
+ depends on LEGACY_PCI
help
Enable support for ADlink PCI-8164 4 Axes Motion Control board
@@ -710,6 +725,7 @@ config COMEDI_ADL_PCI8164
config COMEDI_ADL_PCI9111
tristate "ADLink PCI-9111HR support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for ADlink PCI9111 cards
@@ -719,6 +735,7 @@ config COMEDI_ADL_PCI9111
config COMEDI_ADL_PCI9118
tristate "ADLink PCI-9118DG, PCI-9118HG, PCI-9118HR support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_8254
help
@@ -729,6 +746,7 @@ config COMEDI_ADL_PCI9118
config COMEDI_ADV_PCI1710
tristate "Advantech PCI-171x and PCI-1731 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Advantech PCI-1710, PCI-1710HG, PCI-1711,
@@ -739,6 +757,7 @@ config COMEDI_ADV_PCI1710
config COMEDI_ADV_PCI1720
tristate "Advantech PCI-1720 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1720 Analog Output board.
@@ -747,6 +766,7 @@ config COMEDI_ADV_PCI1720
config COMEDI_ADV_PCI1723
tristate "Advantech PCI-1723 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1723 cards
@@ -755,6 +775,7 @@ config COMEDI_ADV_PCI1723
config COMEDI_ADV_PCI1724
tristate "Advantech PCI-1724U support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1724U cards. These are 32-channel
analog output cards with voltage and current loop output ranges and
@@ -765,6 +786,7 @@ config COMEDI_ADV_PCI1724
config COMEDI_ADV_PCI1760
tristate "Advantech PCI-1760 support"
+ depends on LEGACY_PCI
help
Enable support for Advantech PCI-1760 board.
@@ -773,6 +795,7 @@ config COMEDI_ADV_PCI1760
config COMEDI_ADV_PCI_DIO
tristate "Advantech PCI DIO card support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -786,6 +809,7 @@ config COMEDI_ADV_PCI_DIO
config COMEDI_AMPLC_DIO200_PCI
tristate "Amplicon PCI215/PCI272/PCIe215/PCIe236/PCIe296 DIO support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_DIO200
help
Enable support for Amplicon PCI215, PCI272, PCIe215, PCIe236
@@ -796,6 +820,7 @@ config COMEDI_AMPLC_DIO200_PCI
config COMEDI_AMPLC_PC236_PCI
tristate "Amplicon PCI236 DIO board support"
+ depends on LEGACY_PCI
select COMEDI_AMPLC_PC236
help
Enable support for Amplicon PCI236 DIO board.
@@ -805,6 +830,7 @@ config COMEDI_AMPLC_PC236_PCI
config COMEDI_AMPLC_PC263_PCI
tristate "Amplicon PCI263 relay board support"
+ depends on LEGACY_PCI
help
Enable support for Amplicon PCI263 relay board. This is a PCI board
with 16 reed relay output channels.
@@ -814,6 +840,7 @@ config COMEDI_AMPLC_PC263_PCI
config COMEDI_AMPLC_PCI224
tristate "Amplicon PCI224 and PCI234 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Amplicon PCI224 and PCI234 AO boards
@@ -823,6 +850,7 @@ config COMEDI_AMPLC_PCI224
config COMEDI_AMPLC_PCI230
tristate "Amplicon PCI230 and PCI260 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -834,6 +862,7 @@ config COMEDI_AMPLC_PCI230
config COMEDI_CONTEC_PCI_DIO
tristate "Contec PIO1616L digital I/O board support"
+ depends on LEGACY_PCI
help
Enable support for the Contec PIO1616L digital I/O board
@@ -842,6 +871,7 @@ config COMEDI_CONTEC_PCI_DIO
config COMEDI_DAS08_PCI
tristate "DAS-08 PCI support"
+ depends on LEGACY_PCI
select COMEDI_DAS08
help
Enable support for PCI DAS-08 cards.
@@ -861,6 +891,7 @@ config COMEDI_DT3000
config COMEDI_DYNA_PCI10XX
tristate "Dynalog PCI DAQ series support"
+ depends on LEGACY_PCI
help
Enable support for Dynalog PCI DAQ series
PCI-1050
@@ -894,6 +925,7 @@ config COMEDI_ICP_MULTI
config COMEDI_DAQBOARD2000
tristate "IOtech DAQboard/2000 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for the IOtech DAQboard/2000
@@ -911,6 +943,7 @@ config COMEDI_JR3_PCI
config COMEDI_KE_COUNTER
tristate "Kolter-Electronic PCI Counter 1 card support"
+ depends on LEGACY_PCI
help
Enable support for Kolter-Electronic PCI Counter 1 cards
@@ -919,6 +952,7 @@ config COMEDI_KE_COUNTER
config COMEDI_CB_PCIDAS64
tristate "MeasurementComputing PCI-DAS 64xx, 60xx, and 4020 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DAS 64xx,
@@ -929,6 +963,7 @@ config COMEDI_CB_PCIDAS64
config COMEDI_CB_PCIDAS
tristate "MeasurementComputing PCI-DAS support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -942,6 +977,7 @@ config COMEDI_CB_PCIDAS
config COMEDI_CB_PCIDDA
tristate "MeasurementComputing PCI-DDA series support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCI-DDA
@@ -953,6 +989,7 @@ config COMEDI_CB_PCIDDA
config COMEDI_CB_PCIMDAS
tristate "MeasurementComputing PCIM-DAS1602/16, PCIe-DAS1602/16 support"
+ depends on LEGACY_PCI
select COMEDI_8254
select COMEDI_8255
help
@@ -964,6 +1001,7 @@ config COMEDI_CB_PCIMDAS
config COMEDI_CB_PCIMDDA
tristate "MeasurementComputing PCIM-DDA06-16 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for ComputerBoards/MeasurementComputing PCIM-DDA06-16
@@ -973,6 +1011,7 @@ config COMEDI_CB_PCIMDDA
config COMEDI_ME4000
tristate "Meilhaus ME-4000 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Meilhaus PCI data acquisition cards
@@ -1031,6 +1070,7 @@ config COMEDI_NI_670X
config COMEDI_NI_LABPC_PCI
tristate "NI Lab-PC PCI-1200 support"
+ depends on LEGACY_PCI
select COMEDI_NI_LABPC
help
Enable support for National Instruments Lab-PC PCI-1200.
@@ -1040,6 +1080,7 @@ config COMEDI_NI_LABPC_PCI
config COMEDI_NI_PCIDIO
tristate "NI PCI-DIO32HS, PCI-6533, PCI-6534 support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_MITE
select COMEDI_8255
@@ -1052,6 +1093,7 @@ config COMEDI_NI_PCIDIO
config COMEDI_NI_PCIMIO
tristate "NI PCI-MIO-E series and M series support"
+ depends on LEGACY_PCI
depends on HAS_DMA
select COMEDI_NI_TIOCMD
select COMEDI_8255
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 60d9374c72c0..d36afa5ac6fc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -687,7 +687,7 @@ config GPIO_VR41XX
config GPIO_VX855
tristate "VIA VX855/VX875 GPIO"
- depends on (X86 || COMPILE_TEST) && PCI
+ depends on (X86 || COMPILE_TEST) && LEGACY_PCI
select MFD_CORE
select MFD_VX855
help
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 64bd3dfba2c4..09397562c396 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1654,7 +1654,7 @@ config SENSORS_S3C_RAW
config SENSORS_SIS5595
tristate "Silicon Integrated Systems Corp. SiS5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
SiS5595 South Bridges.
@@ -1985,7 +1985,7 @@ config SENSORS_VIA_CPUTEMP
config SENSORS_VIA686A
tristate "VIA686A"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes here you get support for the integrated sensors in
Via 686A/B South Bridges.
@@ -2006,7 +2006,7 @@ config SENSORS_VT1211
config SENSORS_VT8231
tristate "VIA VT8231"
- depends on PCI
+ depends on LEGACY_PCI
select HWMON_VID
help
If you say yes here then you get support for the integrated sensors
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index dce392839017..a8d6274dc965 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -11,7 +11,7 @@ comment "PC SMBus host controller drivers"
config I2C_ALI1535
tristate "ALI 1535"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1535 South Bridges. The SMB
@@ -23,7 +23,7 @@ config I2C_ALI1535
config I2C_ALI1563
tristate "ALI 1563"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SMB
Host controller on Acer Labs Inc. (ALI) M1563 South Bridges. The SMB
@@ -35,7 +35,7 @@ config I2C_ALI1563
config I2C_ALI15X3
tristate "ALI 15x3"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
Acer Labs Inc. (ALI) M1514 and M1543 motherboard I2C interfaces.
@@ -45,7 +45,7 @@ config I2C_ALI15X3
config I2C_AMD756
tristate "AMD 756/766/768/8111 and nVidia nForce"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the AMD
756/766/768 mainboard I2C interfaces. The driver also includes
@@ -70,7 +70,7 @@ config I2C_AMD756_S4882
config I2C_AMD8111
tristate "AMD 8111"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
second (SMBus 2.0) AMD 8111 mainboard I2C interface.
@@ -154,7 +154,7 @@ config I2C_I801
config I2C_ISCH
tristate "Intel SCH SMBus 1.0"
- depends on PCI
+ depends on LEGACY_PCI
select LPC_SCH
help
Say Y here if you want to use SMBus controller on the Intel SCH
@@ -221,7 +221,7 @@ config I2C_CHT_WC
config I2C_NFORCE2
tristate "Nvidia nForce2, nForce3 and nForce4"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the Nvidia
nForce2, nForce3 and nForce4 families of mainboard I2C interfaces.
@@ -253,7 +253,7 @@ config I2C_NVIDIA_GPU
config I2C_SIS5595
tristate "SiS 5595"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS5595 SMBus (a subset of I2C) interface.
@@ -263,7 +263,7 @@ config I2C_SIS5595
config I2C_SIS630
tristate "SiS 630/730/964"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the
SiS630, SiS730 and SiS964 SMBus (a subset of I2C) interface.
@@ -273,7 +273,7 @@ config I2C_SIS630
config I2C_SIS96X
tristate "SiS 96x"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the SiS
96x SMBus (a subset of I2C) interfaces. Specifically, the following
@@ -291,7 +291,7 @@ config I2C_SIS96X
config I2C_VIA
tristate "VIA VT82C586B"
- depends on PCI
+ depends on LEGACY_PCI
select I2C_ALGOBIT
help
If you say yes to this option, support will be included for the VIA
@@ -302,7 +302,7 @@ config I2C_VIA
config I2C_VIAPRO
tristate "VIA VT82C596/82C686/82xx and CX700/VX8xx/VX900"
- depends on PCI
+ depends on LEGACY_PCI
help
If you say yes to this option, support will be included for the VIA
VT82C596 and later SMBus interface. Specifically, the following
diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 5a2c2fb3217d..082280f95333 100644
--- a/drivers/input/gameport/Kconfig
+++ b/drivers/input/gameport/Kconfig
@@ -43,7 +43,7 @@ config GAMEPORT_L4
config GAMEPORT_EMU10K1
tristate "SB Live and Audigy gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have a SoundBlaster Live! or SoundBlaster
Audigy card and want to use its gameport.
@@ -53,7 +53,7 @@ config GAMEPORT_EMU10K1
config GAMEPORT_FM801
tristate "ForteMedia FM801 gameport support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here if you have ForteMedia FM801 PCI audio controller
(Abit AU10, Genius Sound Maker, HP Workstation zx2000,
diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig
index 078eeadf707a..2c5e16483179 100644
--- a/drivers/isdn/hardware/mISDN/Kconfig
+++ b/drivers/isdn/hardware/mISDN/Kconfig
@@ -7,14 +7,14 @@ comment "mISDN hardware drivers"
config MISDN_HFCPCI
tristate "Support for HFC PCI cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for cards with Cologne Chip AG's
HFC PCI chip.
config MISDN_HFCMULTI
tristate "Support for HFC multiport cards (HFC-4S/8S/E1)"
- depends on PCI || CPM1
+ depends on LEGACY_PCI || CPM1
depends on MISDN
help
Enable support for cards with Cologne Chip AG's HFC multiport
@@ -43,7 +43,7 @@ config MISDN_HFCUSB
config MISDN_AVMFRITZ
tristate "Support for AVM FRITZ!CARD PCI"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for AVMs FRITZ!CARD PCI cards
@@ -51,7 +51,7 @@ config MISDN_AVMFRITZ
config MISDN_SPEEDFAX
tristate "Support for Sedlbauer Speedfax+"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
select MISDN_ISAR
help
@@ -60,7 +60,7 @@ config MISDN_SPEEDFAX
config MISDN_INFINEON
tristate "Support for cards with Infineon chipset"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
select MISDN_IPAC
help
Enable support for cards with ISAC + HSCX, IPAC or IPAC-SX
@@ -69,14 +69,14 @@ config MISDN_INFINEON
config MISDN_W6692
tristate "Support for cards with Winbond 6692"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
help
Enable support for Winbond 6692 PCI chip based cards.
config MISDN_NETJET
tristate "Support for NETJet cards"
depends on MISDN
- depends on PCI
+ depends on LEGACY_PCI
depends on TTY
select MISDN_IPAC
select MISDN_HDLC
diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
index b672d3142eb7..5e92ece5b104 100644
--- a/drivers/media/cec/platform/Kconfig
+++ b/drivers/media/cec/platform/Kconfig
@@ -100,7 +100,7 @@ config CEC_TEGRA
config CEC_SECO
tristate "SECO Boards HDMI CEC driver"
depends on (X86 || IA64) || COMPILE_TEST
- depends on PCI && DMI
+ depends on LEGACY_PCI && DMI
select CEC_CORE
select CEC_NOTIFIER
help
diff --git a/drivers/media/pci/dm1105/Kconfig b/drivers/media/pci/dm1105/Kconfig
index e0e3af67c99c..9ecab93685d4 100644
--- a/drivers/media/pci/dm1105/Kconfig
+++ b/drivers/media/pci/dm1105/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
- depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
+ depends on DVB_CORE && LEGACY_PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index d29e29645e04..32eb73993998 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -67,7 +67,7 @@ config USB_DSBR
config RADIO_MAXIRADIO
tristate "Guillemot MAXI Radio FM 2000 radio"
- depends on VIDEO_V4L2 && PCI
+ depends on VIDEO_V4L2 && LEGACY_PCI
select RADIO_TEA575X
help
Choose Y here if you have this radio card. This card may also be
diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index a3d0288fd0e2..cec5995e1911 100644
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -2,7 +2,7 @@
menuconfig FUSION
bool "Fusion MPT device support"
- depends on PCI
+ depends on LEGACY_PCI
help
Say Y here to get to see options for Fusion Message
Passing Technology (MPT) drivers.
@@ -14,7 +14,7 @@ if FUSION
config FUSION_SPI
tristate "Fusion MPT ScsiHost drivers for SPI"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
SCSI HOST support for a parallel SCSI host adapters.
@@ -29,7 +29,7 @@ config FUSION_SPI
config FUSION_FC
tristate "Fusion MPT ScsiHost drivers for FC"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
help
SCSI HOST support for a Fiber Channel host adapters.
@@ -48,7 +48,7 @@ config FUSION_FC
config FUSION_SAS
tristate "Fusion MPT ScsiHost drivers for SAS"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SAS_ATTRS
help
SCSI HOST support for a SAS host adapters.
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..b8038287c4f2 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -4,7 +4,7 @@
#
menuconfig ARCNET
- depends on NETDEVICES && (ISA || PCI || PCMCIA)
+ depends on NETDEVICES && (ISA || LEGACY_PCI || PCMCIA)
tristate "ARCnet support"
help
If you have a network card of this type, say Y and check out the
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..0fa43943ea74 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -117,7 +117,7 @@ config NE2000
config NE2K_PCI
tristate "PCI NE2000 and clones support (see help)"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
help
This driver is for NE2000 compatible PCI cards. It will not work
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 899c8a2a34b6..0ac61a5f1a37 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -56,7 +56,7 @@ config LANCE
config PCNET32
tristate "AMD PCnet32 PCI support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 0b274d8fa45b..45a3c42945fc 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_INTEL
config E100
tristate "Intel(R) PRO/100+ support"
- depends on PCI
+ depends on LEGACY_PCI
select MII
help
This driver supports Intel(R) PRO/100 family of adapters.
@@ -41,7 +41,7 @@ config E100
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
help
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
diff --git a/drivers/net/ethernet/sis/Kconfig b/drivers/net/ethernet/sis/Kconfig
index 775d76d9890e..bd1b1b81b0e8 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_SIS
bool "Silicon Integrated Systems (SiS) devices"
default y
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
config SIS900
tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
@@ -35,7 +35,7 @@ config SIS900
config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
- depends on PCI
+ depends on LEGACY_PCI
select CRC32
select MII
help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..8b1d67b00e68 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -6,7 +6,7 @@
config NET_VENDOR_TI
bool "Texas Instruments (TI) devices"
default y
- depends on PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ depends on LEGACY_PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
help
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
config TLAN
tristate "TI ThunderLAN support"
- depends on (PCI || EISA)
+ depends on (LEGACY_PCI || EISA)
help
If you have a PCI Ethernet network card based on the ThunderLAN chip
which is supported by this driver, say Y here.
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index da287ef65be7..0ca7d8f7bfde 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -18,8 +18,8 @@ if NET_VENDOR_VIA
config VIA_RHINE
tristate "VIA Rhine support"
- depends on PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
- depends on PCI || ARCH_VT8500 || COMPILE_TEST
+ depends on LEGACY_PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
+ depends on LEGACY_PCI || ARCH_VT8500 || COMPILE_TEST
depends on HAS_DMA
select CRC32
select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..1753c08d6423 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -5,7 +5,7 @@
config FDDI
tristate "FDDI driver support"
- depends on PCI || EISA || TC
+ depends on LEGACY_PCI || EISA || TC
help
Fiber Distributed Data Interface is a high speed local area network
design; essentially a replacement for high speed Ethernet. FDDI can
@@ -29,7 +29,7 @@ config DEFZA
config DEFXX
tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
- depends on FDDI && (PCI || EISA || TC)
+ depends on FDDI && (LEGACY_PCI || EISA || TC)
help
This is support for the DIGITAL series of TURBOchannel (DEFTA),
EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 592a8389fc5a..631c4c1c56c8 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -250,7 +250,7 @@ config C101
config FARSYNC
tristate "FarSync T-Series support"
- depends on HDLC && PCI
+ depends on HDLC && LEGACY_PCI
help
Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
FarSite Communications Ltd.
diff --git a/drivers/net/wireless/atmel/Kconfig b/drivers/net/wireless/atmel/Kconfig
index ca45a1021cf4..9baa4a19dd38 100644
--- a/drivers/net/wireless/atmel/Kconfig
+++ b/drivers/net/wireless/atmel/Kconfig
@@ -14,7 +14,7 @@ if WLAN_VENDOR_ATMEL
config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
- depends on CFG80211 && (PCI || PCMCIA)
+ depends on CFG80211 && (LEGACY_PCI || PCMCIA)
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
@@ -32,7 +32,7 @@ config ATMEL
config PCI_ATMEL
tristate "Atmel at76c506 PCI cards"
- depends on ATMEL && PCI
+ depends on ATMEL && LEGACY_PCI
help
Enable support for PCI and mini-PCI cards containing the
Atmel at76c506 chip.
diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig
index c865d3156cea..9bcd1c8546ff 100644
--- a/drivers/net/wireless/intersil/hostap/Kconfig
+++ b/drivers/net/wireless/intersil/hostap/Kconfig
@@ -56,7 +56,7 @@ config HOSTAP_FIRMWARE_NVRAM
config HOSTAP_PLX
tristate "Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2/2.5/3 PC Cards in PLX9052 based
PCI adaptors.
@@ -70,7 +70,7 @@ config HOSTAP_PLX
config HOSTAP_PCI
tristate "Host AP driver for Prism2.5 PCI adaptors"
- depends on PCI && HOSTAP
+ depends on LEGACY_PCI && HOSTAP
help
Host AP driver's version for Prism2.5 PCI adaptors.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 43e615aa12ff..e0c99ddc145c 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -23,6 +23,17 @@ menuconfig PCI
if PCI
+config LEGACY_PCI
+ bool "Enable support for legacy PCI devices"
+ depends on HAVE_PCI
+ help
+ This option enables support for legacy PCI devices. This includes
+ PCI devices attached directly or via a bridge on a PCI Express bus.
+ It also includes compatibility features on PCI Express devices which
+ make use of legacy I/O spaces.
+
+ For maximum compatibility with old hardware say 'Y'
+
config PCI_DOMAINS
bool
depends on PCI
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..5436b2be2c73 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -333,7 +333,7 @@ config SGIWD93_SCSI
config BLK_DEV_3W_XXXX_RAID
tristate "3ware 5/6/7/8xxx ATA-RAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
3ware is the only hardware ATA-Raid product in Linux to date.
This card is 2,4, or 8 channel master mode support only.
@@ -380,7 +380,7 @@ config SCSI_3W_SAS
config SCSI_ACARD
tristate "ACARD SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the ACARD SCSI host adapter.
Support Chip <ATP870 ATP876 ATP880 ATP885>
@@ -472,7 +472,7 @@ config SCSI_DPT_I2O
config SCSI_ADVANSYS
tristate "AdvanSys SCSI support"
depends on SCSI
- depends on ISA || EISA || PCI
+ depends on ISA || EISA || LEGACY_PCI
depends on ISA_DMA_API || !ISA
help
This is a driver for all SCSI host adapters manufactured by
@@ -643,7 +643,7 @@ config SCSI_SNIC_DEBUG_FS
config SCSI_DMX3191D
tristate "DMX3191D SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This is support for Domex DMX3191D SCSI Host Adapters.
@@ -657,7 +657,7 @@ config SCSI_FDOMAIN
config SCSI_FDOMAIN_PCI
tristate "Future Domain TMC-3260/AHA-2920A PCI SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_FDOMAIN
help
This is support for Future Domain's PCI SCSI host adapters (TMC-3260)
@@ -710,7 +710,7 @@ config SCSI_GENERIC_NCR5380
config SCSI_IPS
tristate "IBM ServeRAID support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the IBM ServeRAID hardware RAID controllers.
See <http://www.developer.ibm.com/welcome/netfinity/serveraid.html>
@@ -770,7 +770,7 @@ config SCSI_IBMVFC_TRACE
config SCSI_INITIO
tristate "Initio 9100U(W) support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio 91XXU(W) SCSI host adapter. Please
read the SCSI-HOWTO, available from
@@ -781,7 +781,7 @@ config SCSI_INITIO
config SCSI_INIA100
tristate "Initio INI-A100U2W support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This is support for the Initio INI-A100U2W SCSI host adapter.
Please read the SCSI-HOWTO, available from
@@ -1130,7 +1130,7 @@ config SCSI_QLOGIC_FAS
config SCSI_QLOGIC_1280
tristate "Qlogic QLA 1240/1x80/1x160 SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
Say Y if you have a QLogic ISP1240/1x80/1x160 SCSI host adapter.
@@ -1187,7 +1187,7 @@ config SCSI_SIM710
config SCSI_DC395x
tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports PCI SCSI host adapters based on the ASIC
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic79xx b/drivers/scsi/aic7xxx/Kconfig.aic79xx
index a47dbd500e9a..64332cc73ea0 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic79xx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic79xx
@@ -5,7 +5,7 @@
#
config SCSI_AIC79XX
tristate "Adaptec AIC79xx U320 support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Ultra 320 PCI-X
diff --git a/drivers/scsi/aic7xxx/Kconfig.aic7xxx b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
index 0cfd92ce750a..3fa5dc1d1186 100644
--- a/drivers/scsi/aic7xxx/Kconfig.aic7xxx
+++ b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
@@ -5,7 +5,7 @@
#
config SCSI_AIC7XXX
tristate "Adaptec AIC7xxx Fast -> U160 support"
- depends on (PCI || EISA) && SCSI
+ depends on (LEGACY_PCI || EISA) && SCSI
select SCSI_SPI_ATTRS
help
This driver supports all of Adaptec's Fast through Ultra 160 PCI
diff --git a/drivers/scsi/aic94xx/Kconfig b/drivers/scsi/aic94xx/Kconfig
index 71931c371b1c..b0cbf65dbe5b 100644
--- a/drivers/scsi/aic94xx/Kconfig
+++ b/drivers/scsi/aic94xx/Kconfig
@@ -8,7 +8,7 @@
config SCSI_AIC94XX
tristate "Adaptec AIC94xx SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
index 2adc2afd9f91..4ec46aede490 100644
--- a/drivers/scsi/megaraid/Kconfig.megaraid
+++ b/drivers/scsi/megaraid/Kconfig.megaraid
@@ -67,7 +67,7 @@ config MEGARAID_MAILBOX
config MEGARAID_LEGACY
tristate "LSI Logic Legacy MegaRAID Driver"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
help
This driver supports the LSI MegaRAID 418, 428, 438, 466, 762, 490
and 467 SCSI host adapters. This driver also support the all U320
diff --git a/drivers/scsi/mvsas/Kconfig b/drivers/scsi/mvsas/Kconfig
index 79812b80743b..f41f3f4a9f34 100644
--- a/drivers/scsi/mvsas/Kconfig
+++ b/drivers/scsi/mvsas/Kconfig
@@ -9,7 +9,7 @@
config SCSI_MVSAS
tristate "Marvell 88SE64XX/88SE94XX SAS/SATA support"
- depends on PCI
+ depends on LEGACY_PCI
select SCSI_SAS_LIBSAS
select FW_LOADER
help
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 802c373fd6d9..93afb73858ce 100644
--- a/drivers/scsi/qla2xxx/Kconfig
+++ b/drivers/scsi/qla2xxx/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support"
- depends on PCI && SCSI
+ depends on LEGACY_PCI && SCSI
depends on SCSI_FC_ATTRS
depends on NVME_FC || !NVME_FC
select FW_LOADER
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 596705d24400..cfbd45767095 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -204,6 +204,7 @@ config SPI_BITBANG
config SPI_BUTTERFLY
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
depends on PARPORT
+ depends on HAS_IOPORT
select SPI_BITBANG
help
This uses a custom parallel port cable to connect to an AVR
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 8c0d8a873d5b..d332f912b964 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/staging/vt6655/Kconfig b/drivers/staging/vt6655/Kconfig
index d1cd5de46dcf..dd236f54d3a2 100644
--- a/drivers/staging/vt6655/Kconfig
+++ b/drivers/staging/vt6655/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
config VT6655
tristate "VIA Technologies VT6655 support"
- depends on PCI && MAC80211 && m
+ depends on LEGACY_PCI && MAC80211 && m
help
This is a vendor-written driver for VIA VT6655.
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc30ff93e2e4..460326a529d6 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -203,7 +203,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on SERIAL_NONSTANDARD && LEGACY_PCI
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index fc543ac97c13..607791b7f693 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -908,7 +908,7 @@ config SERIAL_VR41XX_CONSOLE
config SERIAL_JSM
tristate "Digi International NEO and Classic PCI Support"
- depends on PCI
+ depends on LEGACY_PCI
select SERIAL_CORE
help
This is a driver for Digi International's Neo and Classic series
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6ed5e608dd04..a3446d44c118 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -343,7 +343,7 @@ config FB_IMX
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
- depends on FB && PCI && (BROKEN || !SPARC64)
+ depends on FB && LEGACY_PCI && (BROKEN || !SPARC64)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1264,7 +1264,7 @@ config FB_ATY128_BACKLIGHT
Say Y here if you want to control the backlight of your display.
config FB_ATY
- tristate "ATI Mach64 display support" if PCI || ATARI
+ tristate "ATI Mach64 display support" if LEGACY_PCI || ATARI
depends on FB && !SPARC32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1315,7 +1315,7 @@ config FB_ATY_BACKLIGHT
config FB_S3
tristate "S3 Trio/Virge support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1374,7 +1374,7 @@ config FB_SAVAGE_ACCEL
config FB_SIS
tristate "SiS/XGI display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1404,7 +1404,7 @@ config FB_SIS_315
config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
- depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
+ depends on FB && LEGACY_PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1442,7 +1442,7 @@ endif
config FB_NEOMAGIC
tristate "NeoMagic display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1470,7 +1470,7 @@ config FB_KYRO
config FB_3DFX
tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1518,7 +1518,7 @@ config FB_VOODOO1
config FB_VT8623
tristate "VIA VT8623 support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1532,7 +1532,7 @@ config FB_VT8623
config FB_TRIDENT
tristate "Trident/CyberXXX/CyberBlade support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1554,7 +1554,7 @@ config FB_TRIDENT
config FB_ARK
tristate "ARK 2000PV support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2226,7 +2226,7 @@ config FB_SSD1307
config FB_SM712
tristate "Silicon Motion SM712 framebuffer support"
- depends on FB && PCI
+ depends on FB && LEGACY_PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9d222ba17ec6..05258109bcc2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -2053,7 +2053,7 @@ comment "PCI-based Watchdog Cards"
config PCIPCWATCHDOG
tristate "Berkshire Products PCI-PC Watchdog"
- depends on PCI
+ depends on LEGACY_PCI
help
This is the driver for the Berkshire Products PCI-PC Watchdog card.
This card simply watches your kernel to make sure it doesn't freeze,
@@ -2068,7 +2068,7 @@ config PCIPCWATCHDOG
config WDTPCI
tristate "PCI-WDT500/501 Watchdog timer"
- depends on PCI
+ depends on LEGACY_PCI
help
If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 41ce12597177..07d9587eede4 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -23,10 +23,10 @@ config SND_AD1889
config SND_ALS300
tristate "Avance Logic ALS300/ALS300+"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_PCM
select SND_AC97_CODEC
select SND_OPL3_LIB
- depends on ZONE_DMA
help
Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
@@ -35,6 +35,7 @@ config SND_ALS300
config SND_ALS4000
tristate "Avance Logic ALS4000"
+ depends on LEGACY_PCI
depends on ISA_DMA_API
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -49,6 +50,7 @@ config SND_ALS4000
config SND_ALI5451
tristate "ALi M5451 PCI Audio Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
depends on ZONE_DMA
@@ -96,6 +98,7 @@ config SND_ATIIXP_MODEM
config SND_AU8810
tristate "Aureal Advantage"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -110,6 +113,7 @@ config SND_AU8810
config SND_AU8820
tristate "Aureal Vortex"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -123,6 +127,7 @@ config SND_AU8820
config SND_AU8830
tristate "Aureal Vortex 2"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -151,13 +156,13 @@ config SND_AW2
config SND_AZT3328
tristate "Aztech AZF3328 / PCI168"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
- depends on ZONE_DMA
help
Say Y here to include support for Aztech AZF3328 (PCI168)
soundcards.
@@ -172,6 +177,7 @@ config SND_AZT3328
config SND_BT87X
tristate "Bt87x Audio Capture"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to record audio from TV cards based on
@@ -193,6 +199,7 @@ config SND_BT87X_OVERCLOCK
config SND_CA0106
tristate "SB Audigy LS / Live 24bit"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
select SND_VMASTER
@@ -205,6 +212,7 @@ config SND_CA0106
config SND_CMIPCI
tristate "C-Media 8338, 8738, 8768, 8770"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
@@ -221,6 +229,7 @@ config SND_OXYGEN_LIB
config SND_OXYGEN
tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -246,6 +255,7 @@ config SND_OXYGEN
config SND_CS4281
tristate "Cirrus Logic (Sound Fusion) CS4281"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_RAWMIDI
select SND_AC97_CODEC
@@ -257,6 +267,7 @@ config SND_CS4281
config SND_CS46XX
tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
select FW_LOADER
@@ -290,6 +301,7 @@ config SND_CS5530
config SND_CS5535AUDIO
tristate "CS5535/CS5536 Audio"
depends on X86_32 || MIPS || COMPILE_TEST
+ depends on LEGACY_PCI
select SND_PCM
select SND_AC97_CODEC
help
@@ -307,6 +319,7 @@ config SND_CS5535AUDIO
config SND_CTXFI
tristate "Creative Sound Blaster X-Fi"
+ depends on LEGACY_PCI
select SND_PCM
help
If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -462,13 +475,13 @@ config SND_INDIGODJX
config SND_EMU10K1
tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
+ depends on LEGACY_PCI && ZONE_DMA
select FW_LOADER
select SND_HWDEP
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_TIMER
select SND_SEQ_DEVICE if SND_SEQUENCER != n
- depends on ZONE_DMA
help
Say Y to include support for Sound Blaster PCI 512, Live!,
Audigy and E-mu APS (partially supported) soundcards.
@@ -489,6 +502,7 @@ config SND_EMU10K1_SEQ
config SND_EMU10K1X
tristate "Emu10k1X (Dell OEM Version)"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
select SND_RAWMIDI
depends on ZONE_DMA
@@ -501,6 +515,7 @@ config SND_EMU10K1X
config SND_ENS1370
tristate "(Creative) Ensoniq AudioPCI 1370"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_PCM
help
@@ -511,6 +526,7 @@ config SND_ENS1370
config SND_ENS1371
tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+ depends on LEGACY_PCI
select SND_RAWMIDI
select SND_AC97_CODEC
help
@@ -522,10 +538,10 @@ config SND_ENS1371
config SND_ES1938
tristate "ESS ES1938/1946/1969 (Solo-1)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Solo-1
(ES1938, ES1946, ES1969) chips.
@@ -535,9 +551,9 @@ config SND_ES1938
config SND_ES1968
tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro
1/2/2E chips.
@@ -569,6 +585,7 @@ config SND_ES1968_RADIO
config SND_FM801
tristate "ForteMedia FM801"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
@@ -621,10 +638,10 @@ config SND_HDSPM
config SND_ICE1712
tristate "ICEnsemble ICE1712 (Envy24)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
select BITREVERSE
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the
ICE1712 (Envy24) chip.
@@ -640,6 +657,7 @@ config SND_ICE1712
config SND_ICE1724
tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_RAWMIDI
select SND_AC97_CODEC
select SND_VMASTER
@@ -712,6 +730,7 @@ config SND_LX6464ES
config SND_MAESTRO3
tristate "ESS Allegro/Maestro3"
select SND_AC97_CODEC
+ depends on LEGACY_PCI
depends on ZONE_DMA
help
Say Y here to include support for soundcards based on ESS Maestro 3
@@ -753,6 +772,7 @@ config SND_NM256
config SND_PCXHR
tristate "Digigram PCXHR"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_PCM
select SND_HWDEP
@@ -764,6 +784,7 @@ config SND_PCXHR
config SND_RIPTIDE
tristate "Conexant Riptide"
+ depends on LEGACY_PCI
select FW_LOADER
select SND_OPL3_LIB
select SND_MPU401_UART
@@ -808,6 +829,7 @@ config SND_RME9652
config SND_SE6X
tristate "Studio Evolution SE6X"
depends on SND_OXYGEN=n && SND_VIRTUOSO=n # PCI ID conflict
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -827,10 +849,10 @@ config SND_SIS7019
config SND_SONICVIBES
tristate "S3 SonicVibes"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on the S3
SonicVibes chip.
@@ -840,9 +862,9 @@ config SND_SONICVIBES
config SND_TRIDENT
tristate "Trident 4D-Wave DX/NX; SiS 7018"
+ depends on LEGACY_PCI && ZONE_DMA
select SND_MPU401_UART
select SND_AC97_CODEC
- depends on ZONE_DMA
help
Say Y here to include support for soundcards based on Trident
4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +874,7 @@ config SND_TRIDENT
config SND_VIA82XX
tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+ depends on LEGACY_PCI
select SND_MPU401_UART
select SND_AC97_CODEC
help
@@ -863,6 +886,7 @@ config SND_VIA82XX
config SND_VIA82XX_MODEM
tristate "VIA 82C686A/B, 8233 based Modems"
+ depends on LEGACY_PCI
select SND_AC97_CODEC
help
Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +897,7 @@ config SND_VIA82XX_MODEM
config SND_VIRTUOSO
tristate "Asus Virtuoso 66/100/200 (Xonar)"
+ depends on LEGACY_PCI
select SND_OXYGEN_LIB
select SND_PCM
select SND_MPU401_UART
@@ -889,6 +914,7 @@ config SND_VIRTUOSO
config SND_VX222
tristate "Digigram VX222"
+ depends on LEGACY_PCI
select SND_VX_LIB
help
Say Y here to include support for Digigram VX222 soundcards.
@@ -898,6 +924,7 @@ config SND_VX222
config SND_YMFPCI
tristate "Yamaha YMF724/740/744/754"
+ depends on LEGACY_PCI
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_AC97_CODEC
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-27 16:42 ` Niklas Schnelle
(?)
(?)
@ 2021-12-27 17:48 ` Guenter Roeck
-1 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 17:48 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Dmitry Torokhov, Karsten Keil, Hans Verkuil,
Mauro Carvalho Chehab, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, Forest Bond,
Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-ide, linux-gpio, linux-hwmon, linux-i2c, linux-input,
netdev, linux-media, MPT-FusionLinux.pdl, linux-scsi,
intel-wired-lan, linux-wireless, megaraidlinux.pdl, linux-spi,
linux-fbdev, linux-staging, linux-serial, dri-devel,
linux-watchdog, alsa-devel
On 12/27/21 8:42 AM, Niklas Schnelle wrote:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
This effectively disables all default configurations which now depend
on CONFIG_LEGACY_PCI. Yet, I don't see CONFIG_LEGACY_PCI added to
configuration files which explicitly enable any of the affected
configurations. Is that on purpose ? If so, I think it should at least
be mentioned in the commit description. However, I think it would be
more appropriate to either delete all affected configuration flags from
the affected configuration files, or to add CONFIG_LEGACY_PCI=y to those
files.
Guenter
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-27 17:48 ` Guenter Roeck
0 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 17:48 UTC (permalink / raw)
To: intel-wired-lan
On 12/27/21 8:42 AM, Niklas Schnelle wrote:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
This effectively disables all default configurations which now depend
on CONFIG_LEGACY_PCI. Yet, I don't see CONFIG_LEGACY_PCI added to
configuration files which explicitly enable any of the affected
configurations. Is that on purpose ? If so, I think it should at least
be mentioned in the commit description. However, I think it would be
more appropriate to either delete all affected configuration flags from
the affected configuration files, or to add CONFIG_LEGACY_PCI=y to those
files.
Guenter
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-27 17:48 ` Guenter Roeck
0 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 17:48 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Dmitry Torokhov, Karsten Keil, Hans Verkuil,
Mauro Carvalho Chehab, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, Forest Bond,
Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-ide, linux-gpio, linux-hwmon, linux-i2c, linux-input,
netdev, linux-media, MPT-FusionLinux.pdl, linux-scsi,
intel-wired-lan, linux-wireless, megaraidlinux.pdl, linux-spi,
linux-fbdev, linux-staging, linux-serial, dri-devel,
linux-watchdog, alsa-devel
On 12/27/21 8:42 AM, Niklas Schnelle wrote:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
This effectively disables all default configurations which now depend
on CONFIG_LEGACY_PCI. Yet, I don't see CONFIG_LEGACY_PCI added to
configuration files which explicitly enable any of the affected
configurations. Is that on purpose ? If so, I think it should at least
be mentioned in the commit description. However, I think it would be
more appropriate to either delete all affected configuration flags from
the affected configuration files, or to add CONFIG_LEGACY_PCI=y to those
files.
Guenter
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-27 17:48 ` Guenter Roeck
0 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 17:48 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Dmitry Torokhov, Karsten Keil, Hans Verkuil,
Mauro Carvalho Chehab, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, Forest Bond,
Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai
Cc: linux-fbdev, linux-pci, alsa-devel, dri-devel, linux-ide,
linux-i2c, linux-riscv, linux-arch, linux-scsi, linux-staging,
linux-csky, intel-wired-lan, linux-serial, linux-input,
MPT-FusionLinux.pdl, linux-media, linux-watchdog, linux-gpio,
megaraidlinux.pdl, linux-hwmon, netdev, linux-wireless,
linux-kernel, linux-spi
On 12/27/21 8:42 AM, Niklas Schnelle wrote:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
This effectively disables all default configurations which now depend
on CONFIG_LEGACY_PCI. Yet, I don't see CONFIG_LEGACY_PCI added to
configuration files which explicitly enable any of the affected
configurations. Is that on purpose ? If so, I think it should at least
be mentioned in the commit description. However, I think it would be
more appropriate to either delete all affected configuration flags from
the affected configuration files, or to add CONFIG_LEGACY_PCI=y to those
files.
Guenter
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-27 16:42 ` Niklas Schnelle
` (2 preceding siblings ...)
(?)
@ 2021-12-28 2:09 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 2:09 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, Forest Bond,
Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-ide, linux-gpio, linux-hwmon, linux-i2c, linux-input,
netdev, linux-media, MPT-FusionLinux.pdl, linux-scsi,
intel-wired-lan, linux-wireless, megaraidlinux.pdl, linux-spi,
linux-fbdev, linux-staging, linux-serial, dri-devel,
linux-watchdog, alsa-devel
Em Mon, 27 Dec 2021 17:42:46 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
> 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>
> ---
> drivers/ata/Kconfig | 34 ++++++++--------
> drivers/ata/ata_generic.c | 3 +-
> drivers/ata/libata-sff.c | 2 +
> drivers/comedi/Kconfig | 42 +++++++++++++++++++
> drivers/gpio/Kconfig | 2 +-
> drivers/hwmon/Kconfig | 6 +--
> drivers/i2c/busses/Kconfig | 24 +++++------
> drivers/input/gameport/Kconfig | 4 +-
> drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
> drivers/media/cec/platform/Kconfig | 2 +-
> drivers/media/pci/dm1105/Kconfig | 2 +-
> drivers/media/radio/Kconfig | 2 +-
Not sure what you meant by "legacy I/O spaces" on this patch.
I mean, I would expect non-PCIe devices - like bttv and other
devices developed at the past millennium or so to be "legacy",
but at least on media, it is touching some drivers that aren't
that old, while keeping the really old ones untouched. Instead,
it is touching a driver developed in 2017 plus two other ones
that are a way newer than other drivers.
The support for the Bt8xx chipset, in particular, is really
weird, as a sound driver for such chipset:
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
was marked as dependent of LEGACY_PCI, while the DVB and V4L2 ones
weren't.
Sounds confusing to me, as the PCI bridge used by a Bt87x device
should be the same for all three subdevices.
I'm confused...
Regards,
Mauro
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 2:09 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 2:09 UTC (permalink / raw)
To: intel-wired-lan
Em Mon, 27 Dec 2021 17:42:46 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
> 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>
> ---
> drivers/ata/Kconfig | 34 ++++++++--------
> drivers/ata/ata_generic.c | 3 +-
> drivers/ata/libata-sff.c | 2 +
> drivers/comedi/Kconfig | 42 +++++++++++++++++++
> drivers/gpio/Kconfig | 2 +-
> drivers/hwmon/Kconfig | 6 +--
> drivers/i2c/busses/Kconfig | 24 +++++------
> drivers/input/gameport/Kconfig | 4 +-
> drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
> drivers/media/cec/platform/Kconfig | 2 +-
> drivers/media/pci/dm1105/Kconfig | 2 +-
> drivers/media/radio/Kconfig | 2 +-
Not sure what you meant by "legacy I/O spaces" on this patch.
I mean, I would expect non-PCIe devices - like bttv and other
devices developed at the past millennium or so to be "legacy",
but at least on media, it is touching some drivers that aren't
that old, while keeping the really old ones untouched. Instead,
it is touching a driver developed in 2017 plus two other ones
that are a way newer than other drivers.
The support for the Bt8xx chipset, in particular, is really
weird, as a sound driver for such chipset:
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
was marked as dependent of LEGACY_PCI, while the DVB and V4L2 ones
weren't.
Sounds confusing to me, as the PCI bridge used by a Bt87x device
should be the same for all three subdevices.
I'm confused...
Regards,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 2:09 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 2:09 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
dri-devel, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
Em Mon, 27 Dec 2021 17:42:46 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
> 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>
> ---
> drivers/ata/Kconfig | 34 ++++++++--------
> drivers/ata/ata_generic.c | 3 +-
> drivers/ata/libata-sff.c | 2 +
> drivers/comedi/Kconfig | 42 +++++++++++++++++++
> drivers/gpio/Kconfig | 2 +-
> drivers/hwmon/Kconfig | 6 +--
> drivers/i2c/busses/Kconfig | 24 +++++------
> drivers/input/gameport/Kconfig | 4 +-
> drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
> drivers/media/cec/platform/Kconfig | 2 +-
> drivers/media/pci/dm1105/Kconfig | 2 +-
> drivers/media/radio/Kconfig | 2 +-
Not sure what you meant by "legacy I/O spaces" on this patch.
I mean, I would expect non-PCIe devices - like bttv and other
devices developed at the past millennium or so to be "legacy",
but at least on media, it is touching some drivers that aren't
that old, while keeping the really old ones untouched. Instead,
it is touching a driver developed in 2017 plus two other ones
that are a way newer than other drivers.
The support for the Bt8xx chipset, in particular, is really
weird, as a sound driver for such chipset:
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
was marked as dependent of LEGACY_PCI, while the DVB and V4L2 ones
weren't.
Sounds confusing to me, as the PCI bridge used by a Bt87x device
should be the same for all three subdevices.
I'm confused...
Regards,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 2:09 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 2:09 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, Forest Bond,
Jiri Slaby, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-ide, linux-gpio, linux-hwmon, linux-i2c, linux-input,
netdev, linux-media, MPT-FusionLinux.pdl, linux-scsi,
intel-wired-lan, linux-wireless, megaraidlinux.pdl, linux-spi,
linux-fbdev, linux-staging, linux-serial, dri-devel,
linux-watchdog, alsa-devel
Em Mon, 27 Dec 2021 17:42:46 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
> 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>
> ---
> drivers/ata/Kconfig | 34 ++++++++--------
> drivers/ata/ata_generic.c | 3 +-
> drivers/ata/libata-sff.c | 2 +
> drivers/comedi/Kconfig | 42 +++++++++++++++++++
> drivers/gpio/Kconfig | 2 +-
> drivers/hwmon/Kconfig | 6 +--
> drivers/i2c/busses/Kconfig | 24 +++++------
> drivers/input/gameport/Kconfig | 4 +-
> drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
> drivers/media/cec/platform/Kconfig | 2 +-
> drivers/media/pci/dm1105/Kconfig | 2 +-
> drivers/media/radio/Kconfig | 2 +-
Not sure what you meant by "legacy I/O spaces" on this patch.
I mean, I would expect non-PCIe devices - like bttv and other
devices developed at the past millennium or so to be "legacy",
but at least on media, it is touching some drivers that aren't
that old, while keeping the really old ones untouched. Instead,
it is touching a driver developed in 2017 plus two other ones
that are a way newer than other drivers.
The support for the Bt8xx chipset, in particular, is really
weird, as a sound driver for such chipset:
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
was marked as dependent of LEGACY_PCI, while the DVB and V4L2 ones
weren't.
Sounds confusing to me, as the PCI bridge used by a Bt87x device
should be the same for all three subdevices.
I'm confused...
Regards,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 2:09 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 2:09 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel, dri-devel,
Jaroslav Kysela, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
Em Mon, 27 Dec 2021 17:42:46 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> Introduce a new LEGACY_PCI Kconfig option which gates support for legacy
> PCI devices including those attached to a PCI-to-PCI Express bridge and
> PCI Express devices using legacy I/O spaces. Note that this is different
> from non PCI uses of I/O ports such as by ACPI.
>
> Add dependencies on LEGACY_PCI for all PCI drivers which only target
> legacy PCI devices and ifdef legacy PCI specific functions in ata
> handling.
>
> 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>
> ---
> drivers/ata/Kconfig | 34 ++++++++--------
> drivers/ata/ata_generic.c | 3 +-
> drivers/ata/libata-sff.c | 2 +
> drivers/comedi/Kconfig | 42 +++++++++++++++++++
> drivers/gpio/Kconfig | 2 +-
> drivers/hwmon/Kconfig | 6 +--
> drivers/i2c/busses/Kconfig | 24 +++++------
> drivers/input/gameport/Kconfig | 4 +-
> drivers/isdn/hardware/mISDN/Kconfig | 14 +++----
> drivers/media/cec/platform/Kconfig | 2 +-
> drivers/media/pci/dm1105/Kconfig | 2 +-
> drivers/media/radio/Kconfig | 2 +-
Not sure what you meant by "legacy I/O spaces" on this patch.
I mean, I would expect non-PCIe devices - like bttv and other
devices developed at the past millennium or so to be "legacy",
but at least on media, it is touching some drivers that aren't
that old, while keeping the really old ones untouched. Instead,
it is touching a driver developed in 2017 plus two other ones
that are a way newer than other drivers.
The support for the Bt8xx chipset, in particular, is really
weird, as a sound driver for such chipset:
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
was marked as dependent of LEGACY_PCI, while the DVB and V4L2 ones
weren't.
Sounds confusing to me, as the PCI bridge used by a Bt87x device
should be the same for all three subdevices.
I'm confused...
Regards,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-27 16:42 ` Niklas Schnelle
` (2 preceding siblings ...)
(?)
@ 2021-12-28 8:21 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:21 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Mauro Carvalho Chehab, Sathya Prakash,
Sreekanth Reddy, Suganath Prabu Subramani, Michael Grzeschik,
David S. Miller, Jakub Kicinski, Jesse Brandeburg, Tony Nguyen,
Kalle Valo, Jouni Malinen, James E.J. Bottomley,
Martin K. Petersen, Hannes Reinecke, Kashyap Desai, Sumit Saxena,
Shivasharan S, Nilesh Javali, GR-QLogic-Storage-Upstream,
Mark Brown, Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -23,6 +23,17 @@ menuconfig PCI
>
> if PCI
>
> +config LEGACY_PCI
> + bool "Enable support for legacy PCI devices"
> + depends on HAVE_PCI
> + help
> + This option enables support for legacy PCI devices. This includes
> + PCI devices attached directly or via a bridge on a PCI Express bus.
> + It also includes compatibility features on PCI Express devices which
> + make use of legacy I/O spaces.
All you really care about is the "legacy" I/O spaces here, this isn't
tied to PCI specifically at all, right?
So why not just have a OLD_STYLE_IO config option or something like
that, to show that it's the i/o functions we care about here, not PCI at
all?
And maybe not call it "old" or "legacy" as time constantly goes forward,
just describe it as it is, "DIRECT_IO"?
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 8:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:21 UTC (permalink / raw)
To: intel-wired-lan
On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -23,6 +23,17 @@ menuconfig PCI
>
> if PCI
>
> +config LEGACY_PCI
> + bool "Enable support for legacy PCI devices"
> + depends on HAVE_PCI
> + help
> + This option enables support for legacy PCI devices. This includes
> + PCI devices attached directly or via a bridge on a PCI Express bus.
> + It also includes compatibility features on PCI Express devices which
> + make use of legacy I/O spaces.
All you really care about is the "legacy" I/O spaces here, this isn't
tied to PCI specifically at all, right?
So why not just have a OLD_STYLE_IO config option or something like
that, to show that it's the i/o functions we care about here, not PCI at
all?
And maybe not call it "old" or "legacy" as time constantly goes forward,
just describe it as it is, "DIRECT_IO"?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 8:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:21 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
Wim Van Sebroeck, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Mauro Carvalho Chehab, megaraidlinux.pdl,
Teddy Wang, linux-hwmon, Arnd Bergmann, Karsten Keil,
Sreekanth Reddy, Martin K. Petersen, Nick Hu, Sudip Mukherjee,
Shivasharan S, netdev, dri-devel, Dmitry Torokhov, linux-wireless,
Takashi Iwai, David S. Miller, H Hartley Sweeten, Palmer Dabbelt,
Forest Bond, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -23,6 +23,17 @@ menuconfig PCI
>
> if PCI
>
> +config LEGACY_PCI
> + bool "Enable support for legacy PCI devices"
> + depends on HAVE_PCI
> + help
> + This option enables support for legacy PCI devices. This includes
> + PCI devices attached directly or via a bridge on a PCI Express bus.
> + It also includes compatibility features on PCI Express devices which
> + make use of legacy I/O spaces.
All you really care about is the "legacy" I/O spaces here, this isn't
tied to PCI specifically at all, right?
So why not just have a OLD_STYLE_IO config option or something like
that, to show that it's the i/o functions we care about here, not PCI at
all?
And maybe not call it "old" or "legacy" as time constantly goes forward,
just describe it as it is, "DIRECT_IO"?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 8:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:21 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Mauro Carvalho Chehab, Sathya Prakash,
Sreekanth Reddy, Suganath Prabu Subramani, Michael Grzeschik,
David S. Miller, Jakub Kicinski, Jesse Brandeburg, Tony Nguyen,
Kalle Valo, Jouni Malinen, James E.J. Bottomley,
Martin K. Petersen, Hannes Reinecke, Kashyap Desai, Sumit Saxena,
Shivasharan S, Nilesh Javali, GR-QLogic-Storage-Upstream,
Mark Brown, Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -23,6 +23,17 @@ menuconfig PCI
>
> if PCI
>
> +config LEGACY_PCI
> + bool "Enable support for legacy PCI devices"
> + depends on HAVE_PCI
> + help
> + This option enables support for legacy PCI devices. This includes
> + PCI devices attached directly or via a bridge on a PCI Express bus.
> + It also includes compatibility features on PCI Express devices which
> + make use of legacy I/O spaces.
All you really care about is the "legacy" I/O spaces here, this isn't
tied to PCI specifically at all, right?
So why not just have a OLD_STYLE_IO config option or something like
that, to show that it's the i/o functions we care about here, not PCI at
all?
And maybe not call it "old" or "legacy" as time constantly goes forward,
just describe it as it is, "DIRECT_IO"?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 8:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:21 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel,
Wim Van Sebroeck, Jaroslav Kysela, linux-ide, Jean Delvare,
Guo Ren, linux-i2c, linux-riscv, Vincent Chen, Jiri Slaby,
linux-kernel, linux-arch, Hannes Reinecke, Michael Grzeschik,
linux-scsi, Sumit Saxena, Damien Le Moal, Sathya Prakash,
Jesse Brandeburg, linux-csky, Kashyap Desai, Nilesh Javali,
intel-wired-lan, linux-serial, GR-QLogic-Storage-Upstream,
Jakub Kicinski, MPT-FusionLinux.pdl, James E.J. Bottomley,
Guenter Roeck, linux-media, linux-input, Albert Ou,
linux-watchdog, Jouni Malinen, Suganath Prabu Subramani,
Kalle Valo, John Garry, linux-spi, linux-gpio, Ian Abbott,
Mark Brown, Greentime Hu, Paul Walmsley, Bjorn Helgaas,
Mauro Carvalho Chehab, megaraidlinux.pdl, Teddy Wang, linux-hwmon,
Arnd Bergmann, Karsten Keil, Sreekanth Reddy, Martin K. Petersen,
Nick Hu, Sudip Mukherjee, Shivasharan S, netdev, dri-devel,
Dmitry Torokhov, linux-wireless, Takashi Iwai, David S. Miller,
H Hartley Sweeten, Palmer Dabbelt, Forest Bond, Hans Verkuil,
Tony Nguyen, Bartosz Golaszewski
On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -23,6 +23,17 @@ menuconfig PCI
>
> if PCI
>
> +config LEGACY_PCI
> + bool "Enable support for legacy PCI devices"
> + depends on HAVE_PCI
> + help
> + This option enables support for legacy PCI devices. This includes
> + PCI devices attached directly or via a bridge on a PCI Express bus.
> + It also includes compatibility features on PCI Express devices which
> + make use of legacy I/O spaces.
All you really care about is the "legacy" I/O spaces here, this isn't
tied to PCI specifically at all, right?
So why not just have a OLD_STYLE_IO config option or something like
that, to show that it's the i/o functions we care about here, not PCI at
all?
And maybe not call it "old" or "legacy" as time constantly goes forward,
just describe it as it is, "DIRECT_IO"?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 8:21 ` Greg Kroah-Hartman
` (2 preceding siblings ...)
(?)
@ 2021-12-28 9:15 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 9:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
Em Tue, 28 Dec 2021 09:21:23 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -23,6 +23,17 @@ menuconfig PCI
> >
> > if PCI
> >
> > +config LEGACY_PCI
> > + bool "Enable support for legacy PCI devices"
> > + depends on HAVE_PCI
> > + help
> > + This option enables support for legacy PCI devices. This includes
> > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > + It also includes compatibility features on PCI Express devices which
> > + make use of legacy I/O spaces.
This Kconfig doesn't seem what it is needed there, as this should be an
arch-dependent feature, and not something that the poor user should be
aware if a given architecture supports it or not. Also, the above will keep
causing warnings or errors with randconfigs.
Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
HAVE_PCI:
menuconfig PCI
bool "PCI support"
depends on HAVE_PCI
help
This option enables support for the PCI local bus, including
support for PCI-X and the foundations for PCI Express support.
Say 'Y' here unless you know what you are doing.
So, instead, I would expect that a new HAVE_xxx option would be
added at arch/*/Kconfig, like:
config X86
...
select HAVE_PCI_DIRECT_IO
It would also make sense to document it at Documentation/features/.
>
> All you really care about is the "legacy" I/O spaces here, this isn't
> tied to PCI specifically at all, right?
>
> So why not just have a OLD_STYLE_IO config option or something like
> that, to show that it's the i/o functions we care about here, not PCI at
> all?
>
> And maybe not call it "old" or "legacy" as time constantly goes forward,
> just describe it as it is, "DIRECT_IO"?
Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
name for it.
Thanks,
Mauro
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 9:15 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 9:15 UTC (permalink / raw)
To: intel-wired-lan
Em Tue, 28 Dec 2021 09:21:23 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -23,6 +23,17 @@ menuconfig PCI
> >
> > if PCI
> >
> > +config LEGACY_PCI
> > + bool "Enable support for legacy PCI devices"
> > + depends on HAVE_PCI
> > + help
> > + This option enables support for legacy PCI devices. This includes
> > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > + It also includes compatibility features on PCI Express devices which
> > + make use of legacy I/O spaces.
This Kconfig doesn't seem what it is needed there, as this should be an
arch-dependent feature, and not something that the poor user should be
aware if a given architecture supports it or not. Also, the above will keep
causing warnings or errors with randconfigs.
Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
HAVE_PCI:
menuconfig PCI
bool "PCI support"
depends on HAVE_PCI
help
This option enables support for the PCI local bus, including
support for PCI-X and the foundations for PCI Express support.
Say 'Y' here unless you know what you are doing.
So, instead, I would expect that a new HAVE_xxx option would be
added at arch/*/Kconfig, like:
config X86
...
select HAVE_PCI_DIRECT_IO
It would also make sense to document it at Documentation/features/.
>
> All you really care about is the "legacy" I/O spaces here, this isn't
> tied to PCI specifically at all, right?
>
> So why not just have a OLD_STYLE_IO config option or something like
> that, to show that it's the i/o functions we care about here, not PCI at
> all?
>
> And maybe not call it "old" or "legacy" as time constantly goes forward,
> just describe it as it is, "DIRECT_IO"?
Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
name for it.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 9:15 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 9:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
dri-devel, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Niklas Schnelle, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
netdev, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
Em Tue, 28 Dec 2021 09:21:23 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -23,6 +23,17 @@ menuconfig PCI
> >
> > if PCI
> >
> > +config LEGACY_PCI
> > + bool "Enable support for legacy PCI devices"
> > + depends on HAVE_PCI
> > + help
> > + This option enables support for legacy PCI devices. This includes
> > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > + It also includes compatibility features on PCI Express devices which
> > + make use of legacy I/O spaces.
This Kconfig doesn't seem what it is needed there, as this should be an
arch-dependent feature, and not something that the poor user should be
aware if a given architecture supports it or not. Also, the above will keep
causing warnings or errors with randconfigs.
Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
HAVE_PCI:
menuconfig PCI
bool "PCI support"
depends on HAVE_PCI
help
This option enables support for the PCI local bus, including
support for PCI-X and the foundations for PCI Express support.
Say 'Y' here unless you know what you are doing.
So, instead, I would expect that a new HAVE_xxx option would be
added at arch/*/Kconfig, like:
config X86
...
select HAVE_PCI_DIRECT_IO
It would also make sense to document it at Documentation/features/.
>
> All you really care about is the "legacy" I/O spaces here, this isn't
> tied to PCI specifically at all, right?
>
> So why not just have a OLD_STYLE_IO config option or something like
> that, to show that it's the i/o functions we care about here, not PCI at
> all?
>
> And maybe not call it "old" or "legacy" as time constantly goes forward,
> just describe it as it is, "DIRECT_IO"?
Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
name for it.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 9:15 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 9:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
Em Tue, 28 Dec 2021 09:21:23 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -23,6 +23,17 @@ menuconfig PCI
> >
> > if PCI
> >
> > +config LEGACY_PCI
> > + bool "Enable support for legacy PCI devices"
> > + depends on HAVE_PCI
> > + help
> > + This option enables support for legacy PCI devices. This includes
> > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > + It also includes compatibility features on PCI Express devices which
> > + make use of legacy I/O spaces.
This Kconfig doesn't seem what it is needed there, as this should be an
arch-dependent feature, and not something that the poor user should be
aware if a given architecture supports it or not. Also, the above will keep
causing warnings or errors with randconfigs.
Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
HAVE_PCI:
menuconfig PCI
bool "PCI support"
depends on HAVE_PCI
help
This option enables support for the PCI local bus, including
support for PCI-X and the foundations for PCI Express support.
Say 'Y' here unless you know what you are doing.
So, instead, I would expect that a new HAVE_xxx option would be
added at arch/*/Kconfig, like:
config X86
...
select HAVE_PCI_DIRECT_IO
It would also make sense to document it at Documentation/features/.
>
> All you really care about is the "legacy" I/O spaces here, this isn't
> tied to PCI specifically at all, right?
>
> So why not just have a OLD_STYLE_IO config option or something like
> that, to show that it's the i/o functions we care about here, not PCI at
> all?
>
> And maybe not call it "old" or "legacy" as time constantly goes forward,
> just describe it as it is, "DIRECT_IO"?
Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
name for it.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 9:15 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 9:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel, dri-devel,
Jaroslav Kysela, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Niklas Schnelle, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
netdev, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
Em Tue, 28 Dec 2021 09:21:23 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -23,6 +23,17 @@ menuconfig PCI
> >
> > if PCI
> >
> > +config LEGACY_PCI
> > + bool "Enable support for legacy PCI devices"
> > + depends on HAVE_PCI
> > + help
> > + This option enables support for legacy PCI devices. This includes
> > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > + It also includes compatibility features on PCI Express devices which
> > + make use of legacy I/O spaces.
This Kconfig doesn't seem what it is needed there, as this should be an
arch-dependent feature, and not something that the poor user should be
aware if a given architecture supports it or not. Also, the above will keep
causing warnings or errors with randconfigs.
Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
HAVE_PCI:
menuconfig PCI
bool "PCI support"
depends on HAVE_PCI
help
This option enables support for the PCI local bus, including
support for PCI-X and the foundations for PCI Express support.
Say 'Y' here unless you know what you are doing.
So, instead, I would expect that a new HAVE_xxx option would be
added at arch/*/Kconfig, like:
config X86
...
select HAVE_PCI_DIRECT_IO
It would also make sense to document it at Documentation/features/.
>
> All you really care about is the "legacy" I/O spaces here, this isn't
> tied to PCI specifically at all, right?
>
> So why not just have a OLD_STYLE_IO config option or something like
> that, to show that it's the i/o functions we care about here, not PCI at
> all?
>
> And maybe not call it "old" or "legacy" as time constantly goes forward,
> just describe it as it is, "DIRECT_IO"?
Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
name for it.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 9:15 ` Mauro Carvalho Chehab
` (2 preceding siblings ...)
(?)
@ 2021-12-28 10:58 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 10:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Greg Kroah-Hartman
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 09:21:23 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -23,6 +23,17 @@ menuconfig PCI
> > >
> > > if PCI
> > >
> > > +config LEGACY_PCI
> > > + bool "Enable support for legacy PCI devices"
> > > + depends on HAVE_PCI
> > > + help
> > > + This option enables support for legacy PCI devices. This includes
> > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > + It also includes compatibility features on PCI Express devices which
> > > + make use of legacy I/O spaces.
>
> This Kconfig doesn't seem what it is needed there, as this should be an
> arch-dependent feature, and not something that the poor user should be
> aware if a given architecture supports it or not. Also, the above will keep
> causing warnings or errors with randconfigs.
>
> Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> HAVE_PCI:
Ah yes you're right.
>
> menuconfig PCI
> bool "PCI support"
> depends on HAVE_PCI
> help
> This option enables support for the PCI local bus, including
> support for PCI-X and the foundations for PCI Express support.
> Say 'Y' here unless you know what you are doing.
>
> So, instead, I would expect that a new HAVE_xxx option would be
> added at arch/*/Kconfig, like:
>
> config X86
> ...
> select HAVE_PCI_DIRECT_IO
>
> It would also make sense to document it at Documentation/features/.
I'll look into that, thanks.
>
> > All you really care about is the "legacy" I/O spaces here, this isn't
> > tied to PCI specifically at all, right?
> >
> > So why not just have a OLD_STYLE_IO config option or something like
> > that, to show that it's the i/o functions we care about here, not PCI at
> > all?
> >
> > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > just describe it as it is, "DIRECT_IO"?
>
> Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> name for it.
>
> Thanks,
> Mauro
Hmm, I might be missing something here but that sounds a lot like the
HAS_IOPORT option added in patch 02.
We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
while LEGACY_PCI is for PCI drivers that require port I/O. This
includes pre-PCIe devices as well as PCIe devices which require
features like I/O spaces. The "legacy" naming is comes from the PCIe
spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
compatibility with legacy devices which require their use. Future
revisions of this specification may deprecate the use of I/O Space."
These two separate config options allow us to compile without support
for these legacy PCI devices even on a system where inb()/outb() and
friends are required for some PC style devices and for example ACPI.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 10:58 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 10:58 UTC (permalink / raw)
To: intel-wired-lan
On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 09:21:23 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -23,6 +23,17 @@ menuconfig PCI
> > >
> > > if PCI
> > >
> > > +config LEGACY_PCI
> > > + bool "Enable support for legacy PCI devices"
> > > + depends on HAVE_PCI
> > > + help
> > > + This option enables support for legacy PCI devices. This includes
> > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > + It also includes compatibility features on PCI Express devices which
> > > + make use of legacy I/O spaces.
>
> This Kconfig doesn't seem what it is needed there, as this should be an
> arch-dependent feature, and not something that the poor user should be
> aware if a given architecture supports it or not. Also, the above will keep
> causing warnings or errors with randconfigs.
>
> Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> HAVE_PCI:
Ah yes you're right.
>
> menuconfig PCI
> bool "PCI support"
> depends on HAVE_PCI
> help
> This option enables support for the PCI local bus, including
> support for PCI-X and the foundations for PCI Express support.
> Say 'Y' here unless you know what you are doing.
>
> So, instead, I would expect that a new HAVE_xxx option would be
> added at arch/*/Kconfig, like:
>
> config X86
> ...
> select HAVE_PCI_DIRECT_IO
>
> It would also make sense to document it at Documentation/features/.
I'll look into that, thanks.
>
> > All you really care about is the "legacy" I/O spaces here, this isn't
> > tied to PCI specifically at all, right?
> >
> > So why not just have a OLD_STYLE_IO config option or something like
> > that, to show that it's the i/o functions we care about here, not PCI at
> > all?
> >
> > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > just describe it as it is, "DIRECT_IO"?
>
> Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> name for it.
>
> Thanks,
> Mauro
Hmm, I might be missing something here but that sounds a lot like the
HAS_IOPORT option added in patch 02.
We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
while LEGACY_PCI is for PCI drivers that require port I/O. This
includes pre-PCIe devices as well as PCIe devices which require
features like I/O spaces. The "legacy" naming is comes from the PCIe
spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
compatibility with legacy devices which require their use. Future
revisions of this specification may deprecate the use of I/O Space."
These two separate config options allow us to compile without support
for these legacy PCI devices even on a system where inb()/outb() and
friends are required for some PC style devices and for example ACPI.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 10:58 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 10:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel, dri-devel,
Jaroslav Kysela, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
netdev, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 09:21:23 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -23,6 +23,17 @@ menuconfig PCI
> > >
> > > if PCI
> > >
> > > +config LEGACY_PCI
> > > + bool "Enable support for legacy PCI devices"
> > > + depends on HAVE_PCI
> > > + help
> > > + This option enables support for legacy PCI devices. This includes
> > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > + It also includes compatibility features on PCI Express devices which
> > > + make use of legacy I/O spaces.
>
> This Kconfig doesn't seem what it is needed there, as this should be an
> arch-dependent feature, and not something that the poor user should be
> aware if a given architecture supports it or not. Also, the above will keep
> causing warnings or errors with randconfigs.
>
> Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> HAVE_PCI:
Ah yes you're right.
>
> menuconfig PCI
> bool "PCI support"
> depends on HAVE_PCI
> help
> This option enables support for the PCI local bus, including
> support for PCI-X and the foundations for PCI Express support.
> Say 'Y' here unless you know what you are doing.
>
> So, instead, I would expect that a new HAVE_xxx option would be
> added at arch/*/Kconfig, like:
>
> config X86
> ...
> select HAVE_PCI_DIRECT_IO
>
> It would also make sense to document it at Documentation/features/.
I'll look into that, thanks.
>
> > All you really care about is the "legacy" I/O spaces here, this isn't
> > tied to PCI specifically at all, right?
> >
> > So why not just have a OLD_STYLE_IO config option or something like
> > that, to show that it's the i/o functions we care about here, not PCI at
> > all?
> >
> > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > just describe it as it is, "DIRECT_IO"?
>
> Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> name for it.
>
> Thanks,
> Mauro
Hmm, I might be missing something here but that sounds a lot like the
HAS_IOPORT option added in patch 02.
We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
while LEGACY_PCI is for PCI drivers that require port I/O. This
includes pre-PCIe devices as well as PCIe devices which require
features like I/O spaces. The "legacy" naming is comes from the PCIe
spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
compatibility with legacy devices which require their use. Future
revisions of this specification may deprecate the use of I/O Space."
These two separate config options allow us to compile without support
for these legacy PCI devices even on a system where inb()/outb() and
friends are required for some PC style devices and for example ACPI.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 10:58 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 10:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
dri-devel, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
netdev, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 09:21:23 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -23,6 +23,17 @@ menuconfig PCI
> > >
> > > if PCI
> > >
> > > +config LEGACY_PCI
> > > + bool "Enable support for legacy PCI devices"
> > > + depends on HAVE_PCI
> > > + help
> > > + This option enables support for legacy PCI devices. This includes
> > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > + It also includes compatibility features on PCI Express devices which
> > > + make use of legacy I/O spaces.
>
> This Kconfig doesn't seem what it is needed there, as this should be an
> arch-dependent feature, and not something that the poor user should be
> aware if a given architecture supports it or not. Also, the above will keep
> causing warnings or errors with randconfigs.
>
> Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> HAVE_PCI:
Ah yes you're right.
>
> menuconfig PCI
> bool "PCI support"
> depends on HAVE_PCI
> help
> This option enables support for the PCI local bus, including
> support for PCI-X and the foundations for PCI Express support.
> Say 'Y' here unless you know what you are doing.
>
> So, instead, I would expect that a new HAVE_xxx option would be
> added at arch/*/Kconfig, like:
>
> config X86
> ...
> select HAVE_PCI_DIRECT_IO
>
> It would also make sense to document it at Documentation/features/.
I'll look into that, thanks.
>
> > All you really care about is the "legacy" I/O spaces here, this isn't
> > tied to PCI specifically at all, right?
> >
> > So why not just have a OLD_STYLE_IO config option or something like
> > that, to show that it's the i/o functions we care about here, not PCI at
> > all?
> >
> > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > just describe it as it is, "DIRECT_IO"?
>
> Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> name for it.
>
> Thanks,
> Mauro
Hmm, I might be missing something here but that sounds a lot like the
HAS_IOPORT option added in patch 02.
We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
while LEGACY_PCI is for PCI drivers that require port I/O. This
includes pre-PCIe devices as well as PCIe devices which require
features like I/O spaces. The "legacy" naming is comes from the PCIe
spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
compatibility with legacy devices which require their use. Future
revisions of this specification may deprecate the use of I/O Space."
These two separate config options allow us to compile without support
for these legacy PCI devices even on a system where inb()/outb() and
friends are required for some PC style devices and for example ACPI.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 10:58 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 10:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Greg Kroah-Hartman
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 09:21:23 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -23,6 +23,17 @@ menuconfig PCI
> > >
> > > if PCI
> > >
> > > +config LEGACY_PCI
> > > + bool "Enable support for legacy PCI devices"
> > > + depends on HAVE_PCI
> > > + help
> > > + This option enables support for legacy PCI devices. This includes
> > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > + It also includes compatibility features on PCI Express devices which
> > > + make use of legacy I/O spaces.
>
> This Kconfig doesn't seem what it is needed there, as this should be an
> arch-dependent feature, and not something that the poor user should be
> aware if a given architecture supports it or not. Also, the above will keep
> causing warnings or errors with randconfigs.
>
> Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> HAVE_PCI:
Ah yes you're right.
>
> menuconfig PCI
> bool "PCI support"
> depends on HAVE_PCI
> help
> This option enables support for the PCI local bus, including
> support for PCI-X and the foundations for PCI Express support.
> Say 'Y' here unless you know what you are doing.
>
> So, instead, I would expect that a new HAVE_xxx option would be
> added at arch/*/Kconfig, like:
>
> config X86
> ...
> select HAVE_PCI_DIRECT_IO
>
> It would also make sense to document it at Documentation/features/.
I'll look into that, thanks.
>
> > All you really care about is the "legacy" I/O spaces here, this isn't
> > tied to PCI specifically at all, right?
> >
> > So why not just have a OLD_STYLE_IO config option or something like
> > that, to show that it's the i/o functions we care about here, not PCI at
> > all?
> >
> > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > just describe it as it is, "DIRECT_IO"?
>
> Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> name for it.
>
> Thanks,
> Mauro
Hmm, I might be missing something here but that sounds a lot like the
HAS_IOPORT option added in patch 02.
We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
while LEGACY_PCI is for PCI drivers that require port I/O. This
includes pre-PCIe devices as well as PCIe devices which require
features like I/O spaces. The "legacy" naming is comes from the PCIe
spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
compatibility with legacy devices which require their use. Future
revisions of this specification may deprecate the use of I/O Space."
These two separate config options allow us to compile without support
for these legacy PCI devices even on a system where inb()/outb() and
friends are required for some PC style devices and for example ACPI.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 10:58 ` Niklas Schnelle
` (2 preceding siblings ...)
(?)
@ 2021-12-28 12:01 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 12:01 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Mauro Carvalho Chehab, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Tue, Dec 28, 2021 at 11:58:55AM +0100, Niklas Schnelle wrote:
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O. This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
Ah, then mention the reason why this is called LEGACY_PCI is that it is
because that is what the PCI spec calls it. It was not obvious here at
all that this is where the name came from.
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:01 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 12:01 UTC (permalink / raw)
To: intel-wired-lan
On Tue, Dec 28, 2021 at 11:58:55AM +0100, Niklas Schnelle wrote:
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O. This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
Ah, then mention the reason why this is called LEGACY_PCI is that it is
because that is what the PCI spec calls it. It was not obvious here at
all that this is where the name came from.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:01 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 12:01 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
Wim Van Sebroeck, linux-ide, Albert Ou, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Jean Delvare, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Mauro Carvalho Chehab, megaraidlinux.pdl,
Teddy Wang, linux-hwmon, Arnd Bergmann, Karsten Keil,
Sreekanth Reddy, Martin K. Petersen, Nick Hu, Sudip Mukherjee,
Shivasharan S, netdev, dri-devel, Dmitry Torokhov, linux-wireless,
Takashi Iwai, David S. Miller, H Hartley Sweeten, Palmer Dabbelt,
Forest Bond, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Tue, Dec 28, 2021 at 11:58:55AM +0100, Niklas Schnelle wrote:
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O. This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
Ah, then mention the reason why this is called LEGACY_PCI is that it is
because that is what the PCI spec calls it. It was not obvious here at
all that this is where the name came from.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:01 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 12:01 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Mauro Carvalho Chehab, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Tue, Dec 28, 2021 at 11:58:55AM +0100, Niklas Schnelle wrote:
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O. This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
Ah, then mention the reason why this is called LEGACY_PCI is that it is
because that is what the PCI spec calls it. It was not obvious here at
all that this is where the name came from.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:01 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 12:01 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel,
Wim Van Sebroeck, Jaroslav Kysela, linux-ide, Albert Ou, Guo Ren,
linux-i2c, linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel,
linux-arch, Hannes Reinecke, Michael Grzeschik, linux-scsi,
Sumit Saxena, Damien Le Moal, Sathya Prakash, Jesse Brandeburg,
linux-csky, Kashyap Desai, Nilesh Javali, intel-wired-lan,
linux-serial, GR-QLogic-Storage-Upstream, Jakub Kicinski,
MPT-FusionLinux.pdl, James E.J. Bottomley, Guenter Roeck,
linux-media, linux-input, Jean Delvare, linux-watchdog,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, John Garry,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Mauro Carvalho Chehab,
megaraidlinux.pdl, Teddy Wang, linux-hwmon, Arnd Bergmann,
Karsten Keil, Sreekanth Reddy, Martin K. Petersen, Nick Hu,
Sudip Mukherjee, Shivasharan S, netdev, dri-devel,
Dmitry Torokhov, linux-wireless, Takashi Iwai, David S. Miller,
H Hartley Sweeten, Palmer Dabbelt, Forest Bond, Hans Verkuil,
Tony Nguyen, Bartosz Golaszewski
On Tue, Dec 28, 2021 at 11:58:55AM +0100, Niklas Schnelle wrote:
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O. This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
Ah, then mention the reason why this is called LEGACY_PCI is that it is
because that is what the PCI spec calls it. It was not obvious here at
all that this is where the name came from.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 10:58 ` Niklas Schnelle
` (2 preceding siblings ...)
(?)
@ 2021-12-28 12:54 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 12:54 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
Em Tue, 28 Dec 2021 11:58:55 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 09:21:23 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> >
> > > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > > --- a/drivers/pci/Kconfig
> > > > +++ b/drivers/pci/Kconfig
> > > > @@ -23,6 +23,17 @@ menuconfig PCI
> > > >
> > > > if PCI
> > > >
> > > > +config LEGACY_PCI
> > > > + bool "Enable support for legacy PCI devices"
> > > > + depends on HAVE_PCI
> > > > + help
> > > > + This option enables support for legacy PCI devices. This includes
> > > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > > + It also includes compatibility features on PCI Express devices which
> > > > + make use of legacy I/O spaces.
> >
> > This Kconfig doesn't seem what it is needed there, as this should be an
> > arch-dependent feature, and not something that the poor user should be
> > aware if a given architecture supports it or not. Also, the above will keep
> > causing warnings or errors with randconfigs.
> >
> > Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> > HAVE_PCI:
>
> Ah yes you're right.
>
> >
> > menuconfig PCI
> > bool "PCI support"
> > depends on HAVE_PCI
> > help
> > This option enables support for the PCI local bus, including
> > support for PCI-X and the foundations for PCI Express support.
> > Say 'Y' here unless you know what you are doing.
> >
> > So, instead, I would expect that a new HAVE_xxx option would be
> > added at arch/*/Kconfig, like:
> >
> > config X86
> > ...
> > select HAVE_PCI_DIRECT_IO
> >
> > It would also make sense to document it at Documentation/features/.
>
> I'll look into that, thanks.
>
> >
> > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > tied to PCI specifically at all, right?
> > >
> > > So why not just have a OLD_STYLE_IO config option or something like
> > > that, to show that it's the i/o functions we care about here, not PCI at
> > > all?
> > >
> > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > just describe it as it is, "DIRECT_IO"?
> >
> > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > name for it.
> >
> > Thanks,
> > Mauro
>
> Hmm, I might be missing something here but that sounds a lot like the
> HAS_IOPORT option added in patch 02.
>
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O.
I didn't look at the other patches on this series, but why it is needed
to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
where LEGACY_PCI shall be "n"?
> This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
I would still avoid calling it LEGACY_PCI, as this sounds too generic.
I didn't read the PCI/PCIe specs, but I suspect that are a lot more
features that were/will be deprecated on PCI specs as time goes by.
So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
means.
> These two separate config options allow us to compile without support
> for these legacy PCI devices even on a system where inb()/outb() and
> friends are required for some PC style devices and for example ACPI.
Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
I couldn't find any usage of inb/outb & friends on it:
$ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
It uses, instead, readl/writel:
static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
{
return readl(chip->mmio + reg);
}
static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
{
writel(value, chip->mmio + reg);
}
I failed to see what makes it different from VIDEO_BT848 and
DVB_BT8XX drivers. They all support exactly the same chipset:
Brooktree/Conexant BT8xx. On those devices, depending on the exact
model, up to three separate interfaces are provided, each one with
its own Kconfig var:
- audio I/O (SND_BT87X);
- video I/O (VIDEO_BT848);
- MPEG-TS I/O (DVB_BT8XX).
Thanks,
Mauro
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 12:54 UTC (permalink / raw)
To: intel-wired-lan
Em Tue, 28 Dec 2021 11:58:55 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 09:21:23 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> >
> > > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > > --- a/drivers/pci/Kconfig
> > > > +++ b/drivers/pci/Kconfig
> > > > @@ -23,6 +23,17 @@ menuconfig PCI
> > > >
> > > > if PCI
> > > >
> > > > +config LEGACY_PCI
> > > > + bool "Enable support for legacy PCI devices"
> > > > + depends on HAVE_PCI
> > > > + help
> > > > + This option enables support for legacy PCI devices. This includes
> > > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > > + It also includes compatibility features on PCI Express devices which
> > > > + make use of legacy I/O spaces.
> >
> > This Kconfig doesn't seem what it is needed there, as this should be an
> > arch-dependent feature, and not something that the poor user should be
> > aware if a given architecture supports it or not. Also, the above will keep
> > causing warnings or errors with randconfigs.
> >
> > Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> > HAVE_PCI:
>
> Ah yes you're right.
>
> >
> > menuconfig PCI
> > bool "PCI support"
> > depends on HAVE_PCI
> > help
> > This option enables support for the PCI local bus, including
> > support for PCI-X and the foundations for PCI Express support.
> > Say 'Y' here unless you know what you are doing.
> >
> > So, instead, I would expect that a new HAVE_xxx option would be
> > added at arch/*/Kconfig, like:
> >
> > config X86
> > ...
> > select HAVE_PCI_DIRECT_IO
> >
> > It would also make sense to document it at Documentation/features/.
>
> I'll look into that, thanks.
>
> >
> > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > tied to PCI specifically at all, right?
> > >
> > > So why not just have a OLD_STYLE_IO config option or something like
> > > that, to show that it's the i/o functions we care about here, not PCI at
> > > all?
> > >
> > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > just describe it as it is, "DIRECT_IO"?
> >
> > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > name for it.
> >
> > Thanks,
> > Mauro
>
> Hmm, I might be missing something here but that sounds a lot like the
> HAS_IOPORT option added in patch 02.
>
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O.
I didn't look at the other patches on this series, but why it is needed
to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
where LEGACY_PCI shall be "n"?
> This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
I would still avoid calling it LEGACY_PCI, as this sounds too generic.
I didn't read the PCI/PCIe specs, but I suspect that are a lot more
features that were/will be deprecated on PCI specs as time goes by.
So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
means.
> These two separate config options allow us to compile without support
> for these legacy PCI devices even on a system where inb()/outb() and
> friends are required for some PC style devices and for example ACPI.
Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
I couldn't find any usage of inb/outb & friends on it:
$ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
It uses, instead, readl/writel:
static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
{
return readl(chip->mmio + reg);
}
static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
{
writel(value, chip->mmio + reg);
}
I failed to see what makes it different from VIDEO_BT848 and
DVB_BT8XX drivers. They all support exactly the same chipset:
Brooktree/Conexant BT8xx. On those devices, depending on the exact
model, up to three separate interfaces are provided, each one with
its own Kconfig var:
- audio I/O (SND_BT87X);
- video I/O (VIDEO_BT848);
- MPEG-TS I/O (DVB_BT8XX).
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 12:54 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
dri-devel, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
Em Tue, 28 Dec 2021 11:58:55 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 09:21:23 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> >
> > > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > > --- a/drivers/pci/Kconfig
> > > > +++ b/drivers/pci/Kconfig
> > > > @@ -23,6 +23,17 @@ menuconfig PCI
> > > >
> > > > if PCI
> > > >
> > > > +config LEGACY_PCI
> > > > + bool "Enable support for legacy PCI devices"
> > > > + depends on HAVE_PCI
> > > > + help
> > > > + This option enables support for legacy PCI devices. This includes
> > > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > > + It also includes compatibility features on PCI Express devices which
> > > > + make use of legacy I/O spaces.
> >
> > This Kconfig doesn't seem what it is needed there, as this should be an
> > arch-dependent feature, and not something that the poor user should be
> > aware if a given architecture supports it or not. Also, the above will keep
> > causing warnings or errors with randconfigs.
> >
> > Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> > HAVE_PCI:
>
> Ah yes you're right.
>
> >
> > menuconfig PCI
> > bool "PCI support"
> > depends on HAVE_PCI
> > help
> > This option enables support for the PCI local bus, including
> > support for PCI-X and the foundations for PCI Express support.
> > Say 'Y' here unless you know what you are doing.
> >
> > So, instead, I would expect that a new HAVE_xxx option would be
> > added at arch/*/Kconfig, like:
> >
> > config X86
> > ...
> > select HAVE_PCI_DIRECT_IO
> >
> > It would also make sense to document it at Documentation/features/.
>
> I'll look into that, thanks.
>
> >
> > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > tied to PCI specifically at all, right?
> > >
> > > So why not just have a OLD_STYLE_IO config option or something like
> > > that, to show that it's the i/o functions we care about here, not PCI at
> > > all?
> > >
> > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > just describe it as it is, "DIRECT_IO"?
> >
> > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > name for it.
> >
> > Thanks,
> > Mauro
>
> Hmm, I might be missing something here but that sounds a lot like the
> HAS_IOPORT option added in patch 02.
>
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O.
I didn't look at the other patches on this series, but why it is needed
to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
where LEGACY_PCI shall be "n"?
> This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
I would still avoid calling it LEGACY_PCI, as this sounds too generic.
I didn't read the PCI/PCIe specs, but I suspect that are a lot more
features that were/will be deprecated on PCI specs as time goes by.
So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
means.
> These two separate config options allow us to compile without support
> for these legacy PCI devices even on a system where inb()/outb() and
> friends are required for some PC style devices and for example ACPI.
Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
I couldn't find any usage of inb/outb & friends on it:
$ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
It uses, instead, readl/writel:
static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
{
return readl(chip->mmio + reg);
}
static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
{
writel(value, chip->mmio + reg);
}
I failed to see what makes it different from VIDEO_BT848 and
DVB_BT8XX drivers. They all support exactly the same chipset:
Brooktree/Conexant BT8xx. On those devices, depending on the exact
model, up to three separate interfaces are provided, each one with
its own Kconfig var:
- audio I/O (SND_BT87X);
- video I/O (VIDEO_BT848);
- MPEG-TS I/O (DVB_BT8XX).
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 12:54 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
Em Tue, 28 Dec 2021 11:58:55 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 09:21:23 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> >
> > > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > > --- a/drivers/pci/Kconfig
> > > > +++ b/drivers/pci/Kconfig
> > > > @@ -23,6 +23,17 @@ menuconfig PCI
> > > >
> > > > if PCI
> > > >
> > > > +config LEGACY_PCI
> > > > + bool "Enable support for legacy PCI devices"
> > > > + depends on HAVE_PCI
> > > > + help
> > > > + This option enables support for legacy PCI devices. This includes
> > > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > > + It also includes compatibility features on PCI Express devices which
> > > > + make use of legacy I/O spaces.
> >
> > This Kconfig doesn't seem what it is needed there, as this should be an
> > arch-dependent feature, and not something that the poor user should be
> > aware if a given architecture supports it or not. Also, the above will keep
> > causing warnings or errors with randconfigs.
> >
> > Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> > HAVE_PCI:
>
> Ah yes you're right.
>
> >
> > menuconfig PCI
> > bool "PCI support"
> > depends on HAVE_PCI
> > help
> > This option enables support for the PCI local bus, including
> > support for PCI-X and the foundations for PCI Express support.
> > Say 'Y' here unless you know what you are doing.
> >
> > So, instead, I would expect that a new HAVE_xxx option would be
> > added at arch/*/Kconfig, like:
> >
> > config X86
> > ...
> > select HAVE_PCI_DIRECT_IO
> >
> > It would also make sense to document it at Documentation/features/.
>
> I'll look into that, thanks.
>
> >
> > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > tied to PCI specifically at all, right?
> > >
> > > So why not just have a OLD_STYLE_IO config option or something like
> > > that, to show that it's the i/o functions we care about here, not PCI at
> > > all?
> > >
> > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > just describe it as it is, "DIRECT_IO"?
> >
> > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > name for it.
> >
> > Thanks,
> > Mauro
>
> Hmm, I might be missing something here but that sounds a lot like the
> HAS_IOPORT option added in patch 02.
>
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O.
I didn't look at the other patches on this series, but why it is needed
to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
where LEGACY_PCI shall be "n"?
> This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
I would still avoid calling it LEGACY_PCI, as this sounds too generic.
I didn't read the PCI/PCIe specs, but I suspect that are a lot more
features that were/will be deprecated on PCI specs as time goes by.
So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
means.
> These two separate config options allow us to compile without support
> for these legacy PCI devices even on a system where inb()/outb() and
> friends are required for some PC style devices and for example ACPI.
Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
I couldn't find any usage of inb/outb & friends on it:
$ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
It uses, instead, readl/writel:
static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
{
return readl(chip->mmio + reg);
}
static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
{
writel(value, chip->mmio + reg);
}
I failed to see what makes it different from VIDEO_BT848 and
DVB_BT8XX drivers. They all support exactly the same chipset:
Brooktree/Conexant BT8xx. On those devices, depending on the exact
model, up to three separate interfaces are provided, each one with
its own Kconfig var:
- audio I/O (SND_BT87X);
- video I/O (VIDEO_BT848);
- MPEG-TS I/O (DVB_BT8XX).
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 12:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 12:54 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel, dri-devel,
Jaroslav Kysela, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
Em Tue, 28 Dec 2021 11:58:55 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 10:15 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 09:21:23 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> >
> > > On Mon, Dec 27, 2021 at 05:42:46PM +0100, Niklas Schnelle wrote:
> > > > --- a/drivers/pci/Kconfig
> > > > +++ b/drivers/pci/Kconfig
> > > > @@ -23,6 +23,17 @@ menuconfig PCI
> > > >
> > > > if PCI
> > > >
> > > > +config LEGACY_PCI
> > > > + bool "Enable support for legacy PCI devices"
> > > > + depends on HAVE_PCI
> > > > + help
> > > > + This option enables support for legacy PCI devices. This includes
> > > > + PCI devices attached directly or via a bridge on a PCI Express bus.
> > > > + It also includes compatibility features on PCI Express devices which
> > > > + make use of legacy I/O spaces.
> >
> > This Kconfig doesn't seem what it is needed there, as this should be an
> > arch-dependent feature, and not something that the poor user should be
> > aware if a given architecture supports it or not. Also, the above will keep
> > causing warnings or errors with randconfigs.
> >
> > Also, the "depends on HAVE_CPI" is bogus, as PCI already depends on
> > HAVE_PCI:
>
> Ah yes you're right.
>
> >
> > menuconfig PCI
> > bool "PCI support"
> > depends on HAVE_PCI
> > help
> > This option enables support for the PCI local bus, including
> > support for PCI-X and the foundations for PCI Express support.
> > Say 'Y' here unless you know what you are doing.
> >
> > So, instead, I would expect that a new HAVE_xxx option would be
> > added at arch/*/Kconfig, like:
> >
> > config X86
> > ...
> > select HAVE_PCI_DIRECT_IO
> >
> > It would also make sense to document it at Documentation/features/.
>
> I'll look into that, thanks.
>
> >
> > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > tied to PCI specifically at all, right?
> > >
> > > So why not just have a OLD_STYLE_IO config option or something like
> > > that, to show that it's the i/o functions we care about here, not PCI at
> > > all?
> > >
> > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > just describe it as it is, "DIRECT_IO"?
> >
> > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > name for it.
> >
> > Thanks,
> > Mauro
>
> Hmm, I might be missing something here but that sounds a lot like the
> HAS_IOPORT option added in patch 02.
>
> We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> while LEGACY_PCI is for PCI drivers that require port I/O.
I didn't look at the other patches on this series, but why it is needed
to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
where LEGACY_PCI shall be "n"?
> This
> includes pre-PCIe devices as well as PCIe devices which require
> features like I/O spaces. The "legacy" naming is comes from the PCIe
> spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> compatibility with legacy devices which require their use. Future
> revisions of this specification may deprecate the use of I/O Space."
I would still avoid calling it LEGACY_PCI, as this sounds too generic.
I didn't read the PCI/PCIe specs, but I suspect that are a lot more
features that were/will be deprecated on PCI specs as time goes by.
So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
means.
> These two separate config options allow us to compile without support
> for these legacy PCI devices even on a system where inb()/outb() and
> friends are required for some PC style devices and for example ACPI.
Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
> @@ -172,6 +177,7 @@ config SND_AZT3328
>
> config SND_BT87X
> tristate "Bt87x Audio Capture"
> + depends on LEGACY_PCI
> select SND_PCM
> help
> If you want to record audio from TV cards based on
I couldn't find any usage of inb/outb & friends on it:
$ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
It uses, instead, readl/writel:
static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
{
return readl(chip->mmio + reg);
}
static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
{
writel(value, chip->mmio + reg);
}
I failed to see what makes it different from VIDEO_BT848 and
DVB_BT8XX drivers. They all support exactly the same chipset:
Brooktree/Conexant BT8xx. On those devices, depending on the exact
model, up to three separate interfaces are provided, each one with
its own Kconfig var:
- audio I/O (SND_BT87X);
- video I/O (VIDEO_BT848);
- MPEG-TS I/O (DVB_BT8XX).
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 12:54 ` Mauro Carvalho Chehab
` (2 preceding siblings ...)
(?)
@ 2021-12-28 15:06 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:06 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Bjorn Helgaas
Cc: Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
>
---8<---
>
> > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > tied to PCI specifically at all, right?
> > > >
> > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > all?
> > > >
> > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > just describe it as it is, "DIRECT_IO"?
> > >
> > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > name for it.
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, I might be missing something here but that sounds a lot like the
> > HAS_IOPORT option added in patch 02.
> >
> > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > while LEGACY_PCI is for PCI drivers that require port I/O.
>
> I didn't look at the other patches on this series, but why it is needed
> to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
>
> I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> where LEGACY_PCI shall be "n"?
In the current patch set LEGACY_PCI is not currently selected by
architectures, though of course it could be if we know that an
architecture requires it. We should probably also set it in any
defconfig that has devices depending on it so as not to break these.
Other than that it would be set during kernel configuration if one
wants/needs support for legacy PCI devices. For testing I ran with
HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
based workstation and Raspberry Pi 4 (DT). I guess at the moment it
would make most sense for special configs such as those tailored for
vitualization guets but in the end that would be something for
distributions to decide.
Arnd described the options here:
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> > This
> > includes pre-PCIe devices as well as PCIe devices which require
> > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > compatibility with legacy devices which require their use. Future
> > revisions of this specification may deprecate the use of I/O Space."
>
> I would still avoid calling it LEGACY_PCI, as this sounds too generic.
>
> I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> features that were/will be deprecated on PCI specs as time goes by.
>
> So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> means.
Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
LEGACY_PCI is pretty clear since most devices are either pre-PCIe
devices or a compatibility feature allowing drivers for a pre-PCIe
device to work with a PCIe device.
>
> > These two separate config options allow us to compile without support
> > for these legacy PCI devices even on a system where inb()/outb() and
> > friends are required for some PC style devices and for example ACPI.
>
> Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
>
> > @@ -172,6 +177,7 @@ config SND_AZT3328
> >
> > config SND_BT87X
> > tristate "Bt87x Audio Capture"
> > + depends on LEGACY_PCI
> > select SND_PCM
> > help
> > If you want to record audio from TV cards based on
>
> I couldn't find any usage of inb/outb & friends on it:
>
> $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
>
> It uses, instead, readl/writel:
>
> static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
> {
> return readl(chip->mmio + reg);
> }
>
> static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
> {
> writel(value, chip->mmio + reg);
> }
>
> I failed to see what makes it different from VIDEO_BT848 and
> DVB_BT8XX drivers. They all support exactly the same chipset:
> Brooktree/Conexant BT8xx. On those devices, depending on the exact
> model, up to three separate interfaces are provided, each one with
> its own Kconfig var:
>
> - audio I/O (SND_BT87X);
> - video I/O (VIDEO_BT848);
> - MPEG-TS I/O (DVB_BT8XX).
>
> Thanks,
> Mauro
You're right, that makes no sense this doesn't seem to require
LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on
PCI" which could have caused issues with HAVE_PCI=n rand configs.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 15:06 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:06 UTC (permalink / raw)
To: intel-wired-lan
On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
>
---8<---
>
> > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > tied to PCI specifically at all, right?
> > > >
> > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > all?
> > > >
> > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > just describe it as it is, "DIRECT_IO"?
> > >
> > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > name for it.
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, I might be missing something here but that sounds a lot like the
> > HAS_IOPORT option added in patch 02.
> >
> > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > while LEGACY_PCI is for PCI drivers that require port I/O.
>
> I didn't look at the other patches on this series, but why it is needed
> to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
>
> I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> where LEGACY_PCI shall be "n"?
In the current patch set LEGACY_PCI is not currently selected by
architectures, though of course it could be if we know that an
architecture requires it. We should probably also set it in any
defconfig that has devices depending on it so as not to break these.
Other than that it would be set during kernel configuration if one
wants/needs support for legacy PCI devices. For testing I ran with
HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
based workstation and Raspberry Pi 4 (DT). I guess at the moment it
would make most sense for special configs such as those tailored for
vitualization guets but in the end that would be something for
distributions to decide.
Arnd described the options here:
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q at mail.gmail.com/
>
> > This
> > includes pre-PCIe devices as well as PCIe devices which require
> > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > compatibility with legacy devices which require their use. Future
> > revisions of this specification may deprecate the use of I/O Space."
>
> I would still avoid calling it LEGACY_PCI, as this sounds too generic.
>
> I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> features that were/will be deprecated on PCI specs as time goes by.
>
> So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> means.
Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
LEGACY_PCI is pretty clear since most devices are either pre-PCIe
devices or a compatibility feature allowing drivers for a pre-PCIe
device to work with a PCIe device.
>
> > These two separate config options allow us to compile without support
> > for these legacy PCI devices even on a system where inb()/outb() and
> > friends are required for some PC style devices and for example ACPI.
>
> Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
>
> > @@ -172,6 +177,7 @@ config SND_AZT3328
> >
> > config SND_BT87X
> > tristate "Bt87x Audio Capture"
> > + depends on LEGACY_PCI
> > select SND_PCM
> > help
> > If you want to record audio from TV cards based on
>
> I couldn't find any usage of inb/outb & friends on it:
>
> $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
>
> It uses, instead, readl/writel:
>
> static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
> {
> return readl(chip->mmio + reg);
> }
>
> static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
> {
> writel(value, chip->mmio + reg);
> }
>
> I failed to see what makes it different from VIDEO_BT848 and
> DVB_BT8XX drivers. They all support exactly the same chipset:
> Brooktree/Conexant BT8xx. On those devices, depending on the exact
> model, up to three separate interfaces are provided, each one with
> its own Kconfig var:
>
> - audio I/O (SND_BT87X);
> - video I/O (VIDEO_BT848);
> - MPEG-TS I/O (DVB_BT8XX).
>
> Thanks,
> Mauro
You're right, that makes no sense this doesn't seem to require
LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on
PCI" which could have caused issues with HAVE_PCI=n rand configs.
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 15:06 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:06 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Bjorn Helgaas
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel, dri-devel,
Jaroslav Kysela, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
>
---8<---
>
> > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > tied to PCI specifically at all, right?
> > > >
> > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > all?
> > > >
> > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > just describe it as it is, "DIRECT_IO"?
> > >
> > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > name for it.
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, I might be missing something here but that sounds a lot like the
> > HAS_IOPORT option added in patch 02.
> >
> > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > while LEGACY_PCI is for PCI drivers that require port I/O.
>
> I didn't look at the other patches on this series, but why it is needed
> to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
>
> I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> where LEGACY_PCI shall be "n"?
In the current patch set LEGACY_PCI is not currently selected by
architectures, though of course it could be if we know that an
architecture requires it. We should probably also set it in any
defconfig that has devices depending on it so as not to break these.
Other than that it would be set during kernel configuration if one
wants/needs support for legacy PCI devices. For testing I ran with
HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
based workstation and Raspberry Pi 4 (DT). I guess at the moment it
would make most sense for special configs such as those tailored for
vitualization guets but in the end that would be something for
distributions to decide.
Arnd described the options here:
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> > This
> > includes pre-PCIe devices as well as PCIe devices which require
> > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > compatibility with legacy devices which require their use. Future
> > revisions of this specification may deprecate the use of I/O Space."
>
> I would still avoid calling it LEGACY_PCI, as this sounds too generic.
>
> I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> features that were/will be deprecated on PCI specs as time goes by.
>
> So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> means.
Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
LEGACY_PCI is pretty clear since most devices are either pre-PCIe
devices or a compatibility feature allowing drivers for a pre-PCIe
device to work with a PCIe device.
>
> > These two separate config options allow us to compile without support
> > for these legacy PCI devices even on a system where inb()/outb() and
> > friends are required for some PC style devices and for example ACPI.
>
> Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
>
> > @@ -172,6 +177,7 @@ config SND_AZT3328
> >
> > config SND_BT87X
> > tristate "Bt87x Audio Capture"
> > + depends on LEGACY_PCI
> > select SND_PCM
> > help
> > If you want to record audio from TV cards based on
>
> I couldn't find any usage of inb/outb & friends on it:
>
> $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
>
> It uses, instead, readl/writel:
>
> static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
> {
> return readl(chip->mmio + reg);
> }
>
> static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
> {
> writel(value, chip->mmio + reg);
> }
>
> I failed to see what makes it different from VIDEO_BT848 and
> DVB_BT8XX drivers. They all support exactly the same chipset:
> Brooktree/Conexant BT8xx. On those devices, depending on the exact
> model, up to three separate interfaces are provided, each one with
> its own Kconfig var:
>
> - audio I/O (SND_BT87X);
> - video I/O (VIDEO_BT848);
> - MPEG-TS I/O (DVB_BT8XX).
>
> Thanks,
> Mauro
You're right, that makes no sense this doesn't seem to require
LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on
PCI" which could have caused issues with HAVE_PCI=n rand configs.
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 15:06 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:06 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Bjorn Helgaas
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
dri-devel, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
>
---8<---
>
> > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > tied to PCI specifically at all, right?
> > > >
> > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > all?
> > > >
> > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > just describe it as it is, "DIRECT_IO"?
> > >
> > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > name for it.
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, I might be missing something here but that sounds a lot like the
> > HAS_IOPORT option added in patch 02.
> >
> > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > while LEGACY_PCI is for PCI drivers that require port I/O.
>
> I didn't look at the other patches on this series, but why it is needed
> to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
>
> I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> where LEGACY_PCI shall be "n"?
In the current patch set LEGACY_PCI is not currently selected by
architectures, though of course it could be if we know that an
architecture requires it. We should probably also set it in any
defconfig that has devices depending on it so as not to break these.
Other than that it would be set during kernel configuration if one
wants/needs support for legacy PCI devices. For testing I ran with
HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
based workstation and Raspberry Pi 4 (DT). I guess at the moment it
would make most sense for special configs such as those tailored for
vitualization guets but in the end that would be something for
distributions to decide.
Arnd described the options here:
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> > This
> > includes pre-PCIe devices as well as PCIe devices which require
> > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > compatibility with legacy devices which require their use. Future
> > revisions of this specification may deprecate the use of I/O Space."
>
> I would still avoid calling it LEGACY_PCI, as this sounds too generic.
>
> I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> features that were/will be deprecated on PCI specs as time goes by.
>
> So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> means.
Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
LEGACY_PCI is pretty clear since most devices are either pre-PCIe
devices or a compatibility feature allowing drivers for a pre-PCIe
device to work with a PCIe device.
>
> > These two separate config options allow us to compile without support
> > for these legacy PCI devices even on a system where inb()/outb() and
> > friends are required for some PC style devices and for example ACPI.
>
> Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
>
> > @@ -172,6 +177,7 @@ config SND_AZT3328
> >
> > config SND_BT87X
> > tristate "Bt87x Audio Capture"
> > + depends on LEGACY_PCI
> > select SND_PCM
> > help
> > If you want to record audio from TV cards based on
>
> I couldn't find any usage of inb/outb & friends on it:
>
> $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
>
> It uses, instead, readl/writel:
>
> static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
> {
> return readl(chip->mmio + reg);
> }
>
> static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
> {
> writel(value, chip->mmio + reg);
> }
>
> I failed to see what makes it different from VIDEO_BT848 and
> DVB_BT8XX drivers. They all support exactly the same chipset:
> Brooktree/Conexant BT8xx. On those devices, depending on the exact
> model, up to three separate interfaces are provided, each one with
> its own Kconfig var:
>
> - audio I/O (SND_BT87X);
> - video I/O (VIDEO_BT848);
> - MPEG-TS I/O (DVB_BT8XX).
>
> Thanks,
> Mauro
You're right, that makes no sense this doesn't seem to require
LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on
PCI" which could have caused issues with HAVE_PCI=n rand configs.
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 15:06 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:06 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Bjorn Helgaas
Cc: Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Hans Verkuil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-staging, linux-serial, dri-devel, linux-watchdog,
alsa-devel
On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
>
---8<---
>
> > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > tied to PCI specifically at all, right?
> > > >
> > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > all?
> > > >
> > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > just describe it as it is, "DIRECT_IO"?
> > >
> > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > name for it.
> > >
> > > Thanks,
> > > Mauro
> >
> > Hmm, I might be missing something here but that sounds a lot like the
> > HAS_IOPORT option added in patch 02.
> >
> > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > while LEGACY_PCI is for PCI drivers that require port I/O.
>
> I didn't look at the other patches on this series, but why it is needed
> to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
>
> I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> where LEGACY_PCI shall be "n"?
In the current patch set LEGACY_PCI is not currently selected by
architectures, though of course it could be if we know that an
architecture requires it. We should probably also set it in any
defconfig that has devices depending on it so as not to break these.
Other than that it would be set during kernel configuration if one
wants/needs support for legacy PCI devices. For testing I ran with
HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
based workstation and Raspberry Pi 4 (DT). I guess at the moment it
would make most sense for special configs such as those tailored for
vitualization guets but in the end that would be something for
distributions to decide.
Arnd described the options here:
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> > This
> > includes pre-PCIe devices as well as PCIe devices which require
> > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > compatibility with legacy devices which require their use. Future
> > revisions of this specification may deprecate the use of I/O Space."
>
> I would still avoid calling it LEGACY_PCI, as this sounds too generic.
>
> I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> features that were/will be deprecated on PCI specs as time goes by.
>
> So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> means.
Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
LEGACY_PCI is pretty clear since most devices are either pre-PCIe
devices or a compatibility feature allowing drivers for a pre-PCIe
device to work with a PCIe device.
>
> > These two separate config options allow us to compile without support
> > for these legacy PCI devices even on a system where inb()/outb() and
> > friends are required for some PC style devices and for example ACPI.
>
> Hmm... why this patch make SND_BT87X dependent on LEGACY_PCI?
>
> > @@ -172,6 +177,7 @@ config SND_AZT3328
> >
> > config SND_BT87X
> > tristate "Bt87x Audio Capture"
> > + depends on LEGACY_PCI
> > select SND_PCM
> > help
> > If you want to record audio from TV cards based on
>
> I couldn't find any usage of inb/outb & friends on it:
>
> $ grep -E '(inb|outb|inw|outw|inl|outl)\b' ./sound/pci/bt87x.c
>
> It uses, instead, readl/writel:
>
> static inline u32 snd_bt87x_readl(struct snd_bt87x *chip, u32 reg)
> {
> return readl(chip->mmio + reg);
> }
>
> static inline void snd_bt87x_writel(struct snd_bt87x *chip, u32 reg, u32 value)
> {
> writel(value, chip->mmio + reg);
> }
>
> I failed to see what makes it different from VIDEO_BT848 and
> DVB_BT8XX drivers. They all support exactly the same chipset:
> Brooktree/Conexant BT8xx. On those devices, depending on the exact
> model, up to three separate interfaces are provided, each one with
> its own Kconfig var:
>
> - audio I/O (SND_BT87X);
> - video I/O (VIDEO_BT848);
> - MPEG-TS I/O (DVB_BT8XX).
>
> Thanks,
> Mauro
You're right, that makes no sense this doesn't seem to require
LEGACY_PCI. Maybe this was added by Arnd because it lacks a "depends on
PCI" which could have caused issues with HAVE_PCI=n rand configs.
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 15:06 ` Niklas Schnelle
` (2 preceding siblings ...)
(?)
@ 2021-12-28 17:12 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 17:12 UTC (permalink / raw)
To: Niklas Schnelle, Hans Verkuil, Ettore Chimenti
Cc: Bjorn Helgaas, Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas,
John Garry, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-staging,
linux-serial, dri-devel, linux-watchdog, alsa-devel
Em Tue, 28 Dec 2021 16:06:44 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
(on a side note: the c/c list of this patch is too long. I would try to
avoid using a too long list, as otherwise this e-mail may end being rejected
by mail servers)
> On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> >
> ---8<---
> >
> > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > tied to PCI specifically at all, right?
> > > > >
> > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > all?
> > > > >
> > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > just describe it as it is, "DIRECT_IO"?
> > > >
> > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > name for it.
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, I might be missing something here but that sounds a lot like the
> > > HAS_IOPORT option added in patch 02.
> > >
> > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > while LEGACY_PCI is for PCI drivers that require port I/O.
> >
> > I didn't look at the other patches on this series, but why it is needed
> > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> >
> > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > where LEGACY_PCI shall be "n"?
>
> In the current patch set LEGACY_PCI is not currently selected by
> architectures, though of course it could be if we know that an
> architecture requires it. We should probably also set it in any
> defconfig that has devices depending on it so as not to break these.
>
> Other than that it would be set during kernel configuration if one
> wants/needs support for legacy PCI devices. For testing I ran with
> HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> would make most sense for special configs such as those tailored for
> vitualization guets but in the end that would be something for
> distributions to decide.
IMO, it makes sense to have a "default y" there, as on systems that
support I/O space, disabling it will just randomly disable some drivers
that could be required by some hardware. I won't doubt that some of
those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Arnd described the options here:
> https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
This is missing on patch 1. You should probably reorder your patch
series to first create HAS_IOPORT and then add LEGACY_PCI with
depends on, as otherwise it may cause randconfig build issues
at robots and/or git bisect.
I would also suggest to first introduce such change and then send
a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
maintainers to review.
>
> >
> > > This
> > > includes pre-PCIe devices as well as PCIe devices which require
> > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > compatibility with legacy devices which require their use. Future
> > > revisions of this specification may deprecate the use of I/O Space."
> >
> > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> >
> > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > features that were/will be deprecated on PCI specs as time goes by.
> >
> > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > means.
>
> Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> devices or a compatibility feature allowing drivers for a pre-PCIe
> device to work with a PCIe device.
That's the main point: it is *not* disabling pre-PCIe devices or
even legacy PCI drivers. It just disables a random set of drivers just
because they use inb/outb instead of readb/writeb. It keeps several pure
PCI drivers selected, and disables some PCIe for no real reason.
Just to give one example, this symbol:
> diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> index b672d3142eb7..5e92ece5b104 100644
> --- a/drivers/media/cec/platform/Kconfig
> +++ b/drivers/media/cec/platform/Kconfig
> @@ -100,7 +100,7 @@ config CEC_TEGRA
> config CEC_SECO
> tristate "SECO Boards HDMI CEC driver"
> depends on (X86 || IA64) || COMPILE_TEST
> - depends on PCI && DMI
> + depends on LEGACY_PCI && DMI
> select CEC_CORE
> select CEC_NOTIFIER
> help
Disables HDMI CEC support on some Intel motherboards.
Any distro meant to run on generic hardware should keep it selected.
I can see some value of a "PCI_LEGACY" option to disable all
non-PCIe drivers, but this is not the case here.
Thanks,
Mauro
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 17:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 17:12 UTC (permalink / raw)
To: intel-wired-lan
Em Tue, 28 Dec 2021 16:06:44 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
(on a side note: the c/c list of this patch is too long. I would try to
avoid using a too long list, as otherwise this e-mail may end being rejected
by mail servers)
> On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> >
> ---8<---
> >
> > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > tied to PCI specifically at all, right?
> > > > >
> > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > all?
> > > > >
> > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > just describe it as it is, "DIRECT_IO"?
> > > >
> > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > name for it.
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, I might be missing something here but that sounds a lot like the
> > > HAS_IOPORT option added in patch 02.
> > >
> > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > while LEGACY_PCI is for PCI drivers that require port I/O.
> >
> > I didn't look at the other patches on this series, but why it is needed
> > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> >
> > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > where LEGACY_PCI shall be "n"?
>
> In the current patch set LEGACY_PCI is not currently selected by
> architectures, though of course it could be if we know that an
> architecture requires it. We should probably also set it in any
> defconfig that has devices depending on it so as not to break these.
>
> Other than that it would be set during kernel configuration if one
> wants/needs support for legacy PCI devices. For testing I ran with
> HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> would make most sense for special configs such as those tailored for
> vitualization guets but in the end that would be something for
> distributions to decide.
IMO, it makes sense to have a "default y" there, as on systems that
support I/O space, disabling it will just randomly disable some drivers
that could be required by some hardware. I won't doubt that some of
those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Arnd described the options here:
> https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q at mail.gmail.com/
Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
This is missing on patch 1. You should probably reorder your patch
series to first create HAS_IOPORT and then add LEGACY_PCI with
depends on, as otherwise it may cause randconfig build issues
at robots and/or git bisect.
I would also suggest to first introduce such change and then send
a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
maintainers to review.
>
> >
> > > This
> > > includes pre-PCIe devices as well as PCIe devices which require
> > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > compatibility with legacy devices which require their use. Future
> > > revisions of this specification may deprecate the use of I/O Space."
> >
> > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> >
> > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > features that were/will be deprecated on PCI specs as time goes by.
> >
> > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > means.
>
> Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> devices or a compatibility feature allowing drivers for a pre-PCIe
> device to work with a PCIe device.
That's the main point: it is *not* disabling pre-PCIe devices or
even legacy PCI drivers. It just disables a random set of drivers just
because they use inb/outb instead of readb/writeb. It keeps several pure
PCI drivers selected, and disables some PCIe for no real reason.
Just to give one example, this symbol:
> diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> index b672d3142eb7..5e92ece5b104 100644
> --- a/drivers/media/cec/platform/Kconfig
> +++ b/drivers/media/cec/platform/Kconfig
> @@ -100,7 +100,7 @@ config CEC_TEGRA
> config CEC_SECO
> tristate "SECO Boards HDMI CEC driver"
> depends on (X86 || IA64) || COMPILE_TEST
> - depends on PCI && DMI
> + depends on LEGACY_PCI && DMI
> select CEC_CORE
> select CEC_NOTIFIER
> help
Disables HDMI CEC support on some Intel motherboards.
Any distro meant to run on generic hardware should keep it selected.
I can see some value of a "PCI_LEGACY" option to disable all
non-PCIe drivers, but this is not the case here.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 17:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 17:12 UTC (permalink / raw)
To: Niklas Schnelle, Hans Verkuil, Ettore Chimenti
Cc: linux-fbdev, linux-staging, linux-pci, Linus Walleij, alsa-devel,
dri-devel, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, intel-wired-lan, linux-scsi,
Sumit Saxena, Damien Le Moal, Sathya Prakash, Jesse Brandeburg,
linux-csky, Kashyap Desai, Nilesh Javali, Bjorn Helgaas,
linux-serial, GR-QLogic-Storage-Upstream, Jakub Kicinski,
MPT-FusionLinux.pdl, James E.J. Bottomley, Guenter Roeck,
linux-media, linux-input, Albert Ou, linux-watchdog,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, John Garry,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl,
Teddy Wang, linux-hwmon, Arnd Bergmann, Karsten Keil,
Sreekanth Reddy, Martin K. Petersen, Nick Hu, Sudip Mukherjee,
Shivasharan S, Greg Kroah-Hartman, Dmitry Torokhov,
linux-wireless, Takashi Iwai, David S. Miller, H Hartley Sweeten,
Palmer Dabbelt, Forest Bond, netdev, Tony Nguyen,
Bartosz Golaszewski
Em Tue, 28 Dec 2021 16:06:44 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
(on a side note: the c/c list of this patch is too long. I would try to
avoid using a too long list, as otherwise this e-mail may end being rejected
by mail servers)
> On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> >
> ---8<---
> >
> > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > tied to PCI specifically at all, right?
> > > > >
> > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > all?
> > > > >
> > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > just describe it as it is, "DIRECT_IO"?
> > > >
> > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > name for it.
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, I might be missing something here but that sounds a lot like the
> > > HAS_IOPORT option added in patch 02.
> > >
> > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > while LEGACY_PCI is for PCI drivers that require port I/O.
> >
> > I didn't look at the other patches on this series, but why it is needed
> > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> >
> > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > where LEGACY_PCI shall be "n"?
>
> In the current patch set LEGACY_PCI is not currently selected by
> architectures, though of course it could be if we know that an
> architecture requires it. We should probably also set it in any
> defconfig that has devices depending on it so as not to break these.
>
> Other than that it would be set during kernel configuration if one
> wants/needs support for legacy PCI devices. For testing I ran with
> HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> would make most sense for special configs such as those tailored for
> vitualization guets but in the end that would be something for
> distributions to decide.
IMO, it makes sense to have a "default y" there, as on systems that
support I/O space, disabling it will just randomly disable some drivers
that could be required by some hardware. I won't doubt that some of
those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Arnd described the options here:
> https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
This is missing on patch 1. You should probably reorder your patch
series to first create HAS_IOPORT and then add LEGACY_PCI with
depends on, as otherwise it may cause randconfig build issues
at robots and/or git bisect.
I would also suggest to first introduce such change and then send
a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
maintainers to review.
>
> >
> > > This
> > > includes pre-PCIe devices as well as PCIe devices which require
> > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > compatibility with legacy devices which require their use. Future
> > > revisions of this specification may deprecate the use of I/O Space."
> >
> > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> >
> > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > features that were/will be deprecated on PCI specs as time goes by.
> >
> > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > means.
>
> Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> devices or a compatibility feature allowing drivers for a pre-PCIe
> device to work with a PCIe device.
That's the main point: it is *not* disabling pre-PCIe devices or
even legacy PCI drivers. It just disables a random set of drivers just
because they use inb/outb instead of readb/writeb. It keeps several pure
PCI drivers selected, and disables some PCIe for no real reason.
Just to give one example, this symbol:
> diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> index b672d3142eb7..5e92ece5b104 100644
> --- a/drivers/media/cec/platform/Kconfig
> +++ b/drivers/media/cec/platform/Kconfig
> @@ -100,7 +100,7 @@ config CEC_TEGRA
> config CEC_SECO
> tristate "SECO Boards HDMI CEC driver"
> depends on (X86 || IA64) || COMPILE_TEST
> - depends on PCI && DMI
> + depends on LEGACY_PCI && DMI
> select CEC_CORE
> select CEC_NOTIFIER
> help
Disables HDMI CEC support on some Intel motherboards.
Any distro meant to run on generic hardware should keep it selected.
I can see some value of a "PCI_LEGACY" option to disable all
non-PCIe drivers, but this is not the case here.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 17:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 17:12 UTC (permalink / raw)
To: Niklas Schnelle, Hans Verkuil, Ettore Chimenti
Cc: Bjorn Helgaas, Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas,
John Garry, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-staging,
linux-serial, dri-devel, linux-watchdog, alsa-devel
Em Tue, 28 Dec 2021 16:06:44 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
(on a side note: the c/c list of this patch is too long. I would try to
avoid using a too long list, as otherwise this e-mail may end being rejected
by mail servers)
> On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> >
> ---8<---
> >
> > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > tied to PCI specifically at all, right?
> > > > >
> > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > all?
> > > > >
> > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > just describe it as it is, "DIRECT_IO"?
> > > >
> > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > name for it.
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, I might be missing something here but that sounds a lot like the
> > > HAS_IOPORT option added in patch 02.
> > >
> > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > while LEGACY_PCI is for PCI drivers that require port I/O.
> >
> > I didn't look at the other patches on this series, but why it is needed
> > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> >
> > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > where LEGACY_PCI shall be "n"?
>
> In the current patch set LEGACY_PCI is not currently selected by
> architectures, though of course it could be if we know that an
> architecture requires it. We should probably also set it in any
> defconfig that has devices depending on it so as not to break these.
>
> Other than that it would be set during kernel configuration if one
> wants/needs support for legacy PCI devices. For testing I ran with
> HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> would make most sense for special configs such as those tailored for
> vitualization guets but in the end that would be something for
> distributions to decide.
IMO, it makes sense to have a "default y" there, as on systems that
support I/O space, disabling it will just randomly disable some drivers
that could be required by some hardware. I won't doubt that some of
those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Arnd described the options here:
> https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
This is missing on patch 1. You should probably reorder your patch
series to first create HAS_IOPORT and then add LEGACY_PCI with
depends on, as otherwise it may cause randconfig build issues
at robots and/or git bisect.
I would also suggest to first introduce such change and then send
a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
maintainers to review.
>
> >
> > > This
> > > includes pre-PCIe devices as well as PCIe devices which require
> > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > compatibility with legacy devices which require their use. Future
> > > revisions of this specification may deprecate the use of I/O Space."
> >
> > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> >
> > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > features that were/will be deprecated on PCI specs as time goes by.
> >
> > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > means.
>
> Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> devices or a compatibility feature allowing drivers for a pre-PCIe
> device to work with a PCIe device.
That's the main point: it is *not* disabling pre-PCIe devices or
even legacy PCI drivers. It just disables a random set of drivers just
because they use inb/outb instead of readb/writeb. It keeps several pure
PCI drivers selected, and disables some PCIe for no real reason.
Just to give one example, this symbol:
> diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> index b672d3142eb7..5e92ece5b104 100644
> --- a/drivers/media/cec/platform/Kconfig
> +++ b/drivers/media/cec/platform/Kconfig
> @@ -100,7 +100,7 @@ config CEC_TEGRA
> config CEC_SECO
> tristate "SECO Boards HDMI CEC driver"
> depends on (X86 || IA64) || COMPILE_TEST
> - depends on PCI && DMI
> + depends on LEGACY_PCI && DMI
> select CEC_CORE
> select CEC_NOTIFIER
> help
Disables HDMI CEC support on some Intel motherboards.
Any distro meant to run on generic hardware should keep it selected.
I can see some value of a "PCI_LEGACY" option to disable all
non-PCIe drivers, but this is not the case here.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-28 17:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 17:12 UTC (permalink / raw)
To: Niklas Schnelle, Hans Verkuil, Ettore Chimenti
Cc: linux-fbdev, linux-staging, linux-pci, alsa-devel, dri-devel,
Jaroslav Kysela, linux-ide, Jean Delvare, Guo Ren, linux-i2c,
linux-riscv, Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, Bjorn Helgaas, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Tony Nguyen, intel-wired-lan, Bartosz Golaszewski
Em Tue, 28 Dec 2021 16:06:44 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
(on a side note: the c/c list of this patch is too long. I would try to
avoid using a too long list, as otherwise this e-mail may end being rejected
by mail servers)
> On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> >
> ---8<---
> >
> > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > tied to PCI specifically at all, right?
> > > > >
> > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > all?
> > > > >
> > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > just describe it as it is, "DIRECT_IO"?
> > > >
> > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > name for it.
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > Hmm, I might be missing something here but that sounds a lot like the
> > > HAS_IOPORT option added in patch 02.
> > >
> > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > while LEGACY_PCI is for PCI drivers that require port I/O.
> >
> > I didn't look at the other patches on this series, but why it is needed
> > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> >
> > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > where LEGACY_PCI shall be "n"?
>
> In the current patch set LEGACY_PCI is not currently selected by
> architectures, though of course it could be if we know that an
> architecture requires it. We should probably also set it in any
> defconfig that has devices depending on it so as not to break these.
>
> Other than that it would be set during kernel configuration if one
> wants/needs support for legacy PCI devices. For testing I ran with
> HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> would make most sense for special configs such as those tailored for
> vitualization guets but in the end that would be something for
> distributions to decide.
IMO, it makes sense to have a "default y" there, as on systems that
support I/O space, disabling it will just randomly disable some drivers
that could be required by some hardware. I won't doubt that some of
those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Arnd described the options here:
> https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
This is missing on patch 1. You should probably reorder your patch
series to first create HAS_IOPORT and then add LEGACY_PCI with
depends on, as otherwise it may cause randconfig build issues
at robots and/or git bisect.
I would also suggest to first introduce such change and then send
a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
maintainers to review.
>
> >
> > > This
> > > includes pre-PCIe devices as well as PCIe devices which require
> > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > compatibility with legacy devices which require their use. Future
> > > revisions of this specification may deprecate the use of I/O Space."
> >
> > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> >
> > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > features that were/will be deprecated on PCI specs as time goes by.
> >
> > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > means.
>
> Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> devices or a compatibility feature allowing drivers for a pre-PCIe
> device to work with a PCIe device.
That's the main point: it is *not* disabling pre-PCIe devices or
even legacy PCI drivers. It just disables a random set of drivers just
because they use inb/outb instead of readb/writeb. It keeps several pure
PCI drivers selected, and disables some PCIe for no real reason.
Just to give one example, this symbol:
> diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> index b672d3142eb7..5e92ece5b104 100644
> --- a/drivers/media/cec/platform/Kconfig
> +++ b/drivers/media/cec/platform/Kconfig
> @@ -100,7 +100,7 @@ config CEC_TEGRA
> config CEC_SECO
> tristate "SECO Boards HDMI CEC driver"
> depends on (X86 || IA64) || COMPILE_TEST
> - depends on PCI && DMI
> + depends on LEGACY_PCI && DMI
> select CEC_CORE
> select CEC_NOTIFIER
> help
Disables HDMI CEC support on some Intel motherboards.
Any distro meant to run on generic hardware should keep it selected.
I can see some value of a "PCI_LEGACY" option to disable all
non-PCIe drivers, but this is not the case here.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-28 17:12 ` Mauro Carvalho Chehab
(?)
(?)
@ 2021-12-29 11:45 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 11:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Ettore Chimenti
Cc: Bjorn Helgaas, Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas,
John Garry, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 16:06:44 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
>
> (on a side note: the c/c list of this patch is too long. I would try to
> avoid using a too long list, as otherwise this e-mail may end being rejected
> by mail servers)
>
> > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > >
> > ---8<---
> > >
> > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > tied to PCI specifically at all, right?
> > > > > >
> > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > all?
> > > > > >
> > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > just describe it as it is, "DIRECT_IO"?
> > > > >
> > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > name for it.
> > > > >
> > > > > Thanks,
> > > > > Mauro
> > > >
> > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > HAS_IOPORT option added in patch 02.
> > > >
> > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > >
> > > I didn't look at the other patches on this series, but why it is needed
> > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > >
> > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > where LEGACY_PCI shall be "n"?
> >
> > In the current patch set LEGACY_PCI is not currently selected by
> > architectures, though of course it could be if we know that an
> > architecture requires it. We should probably also set it in any
> > defconfig that has devices depending on it so as not to break these.
> >
> > Other than that it would be set during kernel configuration if one
> > wants/needs support for legacy PCI devices. For testing I ran with
> > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > would make most sense for special configs such as those tailored for
> > vitualization guets but in the end that would be something for
> > distributions to decide.
>
> IMO, it makes sense to have a "default y" there, as on systems that
> support I/O space, disabling it will just randomly disable some drivers
> that could be required by some hardware. I won't doubt that some of
> those could be ported from using inb/outb to use, instead, readb/writeb.
Makes sense, if these get more legacy over time we can always change
the default. This would also mean we don't need to change defconfigs
that include legacy PCI devices.
>
> > Arnd described the options here:
> > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> This is missing on patch 1. You should probably reorder your patch
> series to first create HAS_IOPORT and then add LEGACY_PCI with
> depends on, as otherwise it may cause randconfig build issues
> at robots and/or git bisect.
>
> I would also suggest to first introduce such change and then send
> a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> maintainers to review.
Playing around with the reordering I think it might make sense to
introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
add dependencies for both on a per subsystem basis. I think it would be
overkill to have two series of per subsystem patches.
>
> > >
> > > > This
> > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > compatibility with legacy devices which require their use. Future
> > > > revisions of this specification may deprecate the use of I/O Space."
> > >
> > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > >
> > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > features that were/will be deprecated on PCI specs as time goes by.
> > >
> > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > means.
> >
> > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > devices or a compatibility feature allowing drivers for a pre-PCIe
> > device to work with a PCIe device.
>
> That's the main point: it is *not* disabling pre-PCIe devices or
> even legacy PCI drivers. It just disables a random set of drivers just
> because they use inb/outb instead of readb/writeb. It keeps several pure
> PCI drivers selected, and disables some PCIe for no real reason.
That is not intentional. The dependencies are certainly not perfect yet
which is one of the reasons this is still an RFC. I hope getting these
right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
dependency selection on a per subsystem basis.
>
> Just to give one example, this symbol:
>
> > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > index b672d3142eb7..5e92ece5b104 100644
> > --- a/drivers/media/cec/platform/Kconfig
> > +++ b/drivers/media/cec/platform/Kconfig
> > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > config CEC_SECO
> > tristate "SECO Boards HDMI CEC driver"
> > depends on (X86 || IA64) || COMPILE_TEST
> > - depends on PCI && DMI
> > + depends on LEGACY_PCI && DMI
> > select CEC_CORE
> > select CEC_NOTIFIER
> > help
>
> Disables HDMI CEC support on some Intel motherboards.
> Any distro meant to run on generic hardware should keep it selected.
As far as I can see this one actually uses a hardcoded I/O port numbers
and googling it looks like it's an on-board device on the UDOO x86
board. I guess that should indeed just be
"depends on PCI && DMI && HAS_IOPORT".
>
> I can see some value of a "PCI_LEGACY" option to disable all
> non-PCIe drivers, but this is not the case here.
>
> Thanks,
> Mauro
Ok, I think we definitely need to work on getting the dependencies
right. I do think we agree that once done correctly there is value in
such an option independent of HAS_IOPORT only gating inb() etc uses.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 11:45 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 11:45 UTC (permalink / raw)
To: intel-wired-lan
On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 16:06:44 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
>
> (on a side note: the c/c list of this patch is too long. I would try to
> avoid using a too long list, as otherwise this e-mail may end being rejected
> by mail servers)
>
> > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > >
> > ---8<---
> > >
> > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > tied to PCI specifically at all, right?
> > > > > >
> > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > all?
> > > > > >
> > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > just describe it as it is, "DIRECT_IO"?
> > > > >
> > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > name for it.
> > > > >
> > > > > Thanks,
> > > > > Mauro
> > > >
> > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > HAS_IOPORT option added in patch 02.
> > > >
> > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > >
> > > I didn't look at the other patches on this series, but why it is needed
> > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > >
> > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > where LEGACY_PCI shall be "n"?
> >
> > In the current patch set LEGACY_PCI is not currently selected by
> > architectures, though of course it could be if we know that an
> > architecture requires it. We should probably also set it in any
> > defconfig that has devices depending on it so as not to break these.
> >
> > Other than that it would be set during kernel configuration if one
> > wants/needs support for legacy PCI devices. For testing I ran with
> > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > would make most sense for special configs such as those tailored for
> > vitualization guets but in the end that would be something for
> > distributions to decide.
>
> IMO, it makes sense to have a "default y" there, as on systems that
> support I/O space, disabling it will just randomly disable some drivers
> that could be required by some hardware. I won't doubt that some of
> those could be ported from using inb/outb to use, instead, readb/writeb.
Makes sense, if these get more legacy over time we can always change
the default. This would also mean we don't need to change defconfigs
that include legacy PCI devices.
>
> > Arnd described the options here:
> > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q at mail.gmail.com/
>
> Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> This is missing on patch 1. You should probably reorder your patch
> series to first create HAS_IOPORT and then add LEGACY_PCI with
> depends on, as otherwise it may cause randconfig build issues
> at robots and/or git bisect.
>
> I would also suggest to first introduce such change and then send
> a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> maintainers to review.
Playing around with the reordering I think it might make sense to
introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
add dependencies for both on a per subsystem basis. I think it would be
overkill to have two series of per subsystem patches.
>
> > >
> > > > This
> > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > compatibility with legacy devices which require their use. Future
> > > > revisions of this specification may deprecate the use of I/O Space."
> > >
> > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > >
> > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > features that were/will be deprecated on PCI specs as time goes by.
> > >
> > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > means.
> >
> > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > devices or a compatibility feature allowing drivers for a pre-PCIe
> > device to work with a PCIe device.
>
> That's the main point: it is *not* disabling pre-PCIe devices or
> even legacy PCI drivers. It just disables a random set of drivers just
> because they use inb/outb instead of readb/writeb. It keeps several pure
> PCI drivers selected, and disables some PCIe for no real reason.
That is not intentional. The dependencies are certainly not perfect yet
which is one of the reasons this is still an RFC. I hope getting these
right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
dependency selection on a per subsystem basis.
>
> Just to give one example, this symbol:
>
> > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > index b672d3142eb7..5e92ece5b104 100644
> > --- a/drivers/media/cec/platform/Kconfig
> > +++ b/drivers/media/cec/platform/Kconfig
> > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > config CEC_SECO
> > tristate "SECO Boards HDMI CEC driver"
> > depends on (X86 || IA64) || COMPILE_TEST
> > - depends on PCI && DMI
> > + depends on LEGACY_PCI && DMI
> > select CEC_CORE
> > select CEC_NOTIFIER
> > help
>
> Disables HDMI CEC support on some Intel motherboards.
> Any distro meant to run on generic hardware should keep it selected.
As far as I can see this one actually uses a hardcoded I/O port numbers
and googling it looks like it's an on-board device on the UDOO x86
board. I guess that should indeed just be
"depends on PCI && DMI && HAS_IOPORT".
>
> I can see some value of a "PCI_LEGACY" option to disable all
> non-PCIe drivers, but this is not the case here.
>
> Thanks,
> Mauro
Ok, I think we definitely need to work on getting the dependencies
right. I do think we agree that once done correctly there is value in
such an option independent of HAS_IOPORT only gating inb() etc uses.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 11:45 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 11:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Ettore Chimenti
Cc: linux-fbdev, linux-pci, dri-devel, Jaroslav Kysela, linux-ide,
Jean Delvare, Guo Ren, linux-i2c, linux-riscv, Vincent Chen,
Jiri Slaby, linux-kernel, linux-arch, Hannes Reinecke,
Michael Grzeschik, linux-scsi, Sumit Saxena, Damien Le Moal,
Sathya Prakash, Jesse Brandeburg, linux-csky, Kashyap Desai,
Nilesh Javali, Bjorn Helgaas, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Tony Nguyen, intel-wired-lan, Bartosz Golaszewski
On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 16:06:44 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
>
> (on a side note: the c/c list of this patch is too long. I would try to
> avoid using a too long list, as otherwise this e-mail may end being rejected
> by mail servers)
>
> > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > >
> > ---8<---
> > >
> > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > tied to PCI specifically at all, right?
> > > > > >
> > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > all?
> > > > > >
> > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > just describe it as it is, "DIRECT_IO"?
> > > > >
> > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > name for it.
> > > > >
> > > > > Thanks,
> > > > > Mauro
> > > >
> > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > HAS_IOPORT option added in patch 02.
> > > >
> > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > >
> > > I didn't look at the other patches on this series, but why it is needed
> > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > >
> > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > where LEGACY_PCI shall be "n"?
> >
> > In the current patch set LEGACY_PCI is not currently selected by
> > architectures, though of course it could be if we know that an
> > architecture requires it. We should probably also set it in any
> > defconfig that has devices depending on it so as not to break these.
> >
> > Other than that it would be set during kernel configuration if one
> > wants/needs support for legacy PCI devices. For testing I ran with
> > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > would make most sense for special configs such as those tailored for
> > vitualization guets but in the end that would be something for
> > distributions to decide.
>
> IMO, it makes sense to have a "default y" there, as on systems that
> support I/O space, disabling it will just randomly disable some drivers
> that could be required by some hardware. I won't doubt that some of
> those could be ported from using inb/outb to use, instead, readb/writeb.
Makes sense, if these get more legacy over time we can always change
the default. This would also mean we don't need to change defconfigs
that include legacy PCI devices.
>
> > Arnd described the options here:
> > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> This is missing on patch 1. You should probably reorder your patch
> series to first create HAS_IOPORT and then add LEGACY_PCI with
> depends on, as otherwise it may cause randconfig build issues
> at robots and/or git bisect.
>
> I would also suggest to first introduce such change and then send
> a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> maintainers to review.
Playing around with the reordering I think it might make sense to
introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
add dependencies for both on a per subsystem basis. I think it would be
overkill to have two series of per subsystem patches.
>
> > >
> > > > This
> > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > compatibility with legacy devices which require their use. Future
> > > > revisions of this specification may deprecate the use of I/O Space."
> > >
> > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > >
> > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > features that were/will be deprecated on PCI specs as time goes by.
> > >
> > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > means.
> >
> > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > devices or a compatibility feature allowing drivers for a pre-PCIe
> > device to work with a PCIe device.
>
> That's the main point: it is *not* disabling pre-PCIe devices or
> even legacy PCI drivers. It just disables a random set of drivers just
> because they use inb/outb instead of readb/writeb. It keeps several pure
> PCI drivers selected, and disables some PCIe for no real reason.
That is not intentional. The dependencies are certainly not perfect yet
which is one of the reasons this is still an RFC. I hope getting these
right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
dependency selection on a per subsystem basis.
>
> Just to give one example, this symbol:
>
> > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > index b672d3142eb7..5e92ece5b104 100644
> > --- a/drivers/media/cec/platform/Kconfig
> > +++ b/drivers/media/cec/platform/Kconfig
> > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > config CEC_SECO
> > tristate "SECO Boards HDMI CEC driver"
> > depends on (X86 || IA64) || COMPILE_TEST
> > - depends on PCI && DMI
> > + depends on LEGACY_PCI && DMI
> > select CEC_CORE
> > select CEC_NOTIFIER
> > help
>
> Disables HDMI CEC support on some Intel motherboards.
> Any distro meant to run on generic hardware should keep it selected.
As far as I can see this one actually uses a hardcoded I/O port numbers
and googling it looks like it's an on-board device on the UDOO x86
board. I guess that should indeed just be
"depends on PCI && DMI && HAS_IOPORT".
>
> I can see some value of a "PCI_LEGACY" option to disable all
> non-PCIe drivers, but this is not the case here.
>
> Thanks,
> Mauro
Ok, I think we definitely need to work on getting the dependencies
right. I do think we agree that once done correctly there is value in
such an option independent of HAS_IOPORT only gating inb() etc uses.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 11:45 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 11:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Ettore Chimenti
Cc: Bjorn Helgaas, Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas,
John Garry, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Dec 2021 16:06:44 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
>
> (on a side note: the c/c list of this patch is too long. I would try to
> avoid using a too long list, as otherwise this e-mail may end being rejected
> by mail servers)
>
> > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > >
> > ---8<---
> > >
> > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > tied to PCI specifically at all, right?
> > > > > >
> > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > all?
> > > > > >
> > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > just describe it as it is, "DIRECT_IO"?
> > > > >
> > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > name for it.
> > > > >
> > > > > Thanks,
> > > > > Mauro
> > > >
> > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > HAS_IOPORT option added in patch 02.
> > > >
> > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > >
> > > I didn't look at the other patches on this series, but why it is needed
> > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > >
> > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > where LEGACY_PCI shall be "n"?
> >
> > In the current patch set LEGACY_PCI is not currently selected by
> > architectures, though of course it could be if we know that an
> > architecture requires it. We should probably also set it in any
> > defconfig that has devices depending on it so as not to break these.
> >
> > Other than that it would be set during kernel configuration if one
> > wants/needs support for legacy PCI devices. For testing I ran with
> > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > would make most sense for special configs such as those tailored for
> > vitualization guets but in the end that would be something for
> > distributions to decide.
>
> IMO, it makes sense to have a "default y" there, as on systems that
> support I/O space, disabling it will just randomly disable some drivers
> that could be required by some hardware. I won't doubt that some of
> those could be ported from using inb/outb to use, instead, readb/writeb.
Makes sense, if these get more legacy over time we can always change
the default. This would also mean we don't need to change defconfigs
that include legacy PCI devices.
>
> > Arnd described the options here:
> > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
>
> Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> This is missing on patch 1. You should probably reorder your patch
> series to first create HAS_IOPORT and then add LEGACY_PCI with
> depends on, as otherwise it may cause randconfig build issues
> at robots and/or git bisect.
>
> I would also suggest to first introduce such change and then send
> a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> maintainers to review.
Playing around with the reordering I think it might make sense to
introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
add dependencies for both on a per subsystem basis. I think it would be
overkill to have two series of per subsystem patches.
>
> > >
> > > > This
> > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > compatibility with legacy devices which require their use. Future
> > > > revisions of this specification may deprecate the use of I/O Space."
> > >
> > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > >
> > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > features that were/will be deprecated on PCI specs as time goes by.
> > >
> > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > means.
> >
> > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > devices or a compatibility feature allowing drivers for a pre-PCIe
> > device to work with a PCIe device.
>
> That's the main point: it is *not* disabling pre-PCIe devices or
> even legacy PCI drivers. It just disables a random set of drivers just
> because they use inb/outb instead of readb/writeb. It keeps several pure
> PCI drivers selected, and disables some PCIe for no real reason.
That is not intentional. The dependencies are certainly not perfect yet
which is one of the reasons this is still an RFC. I hope getting these
right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
dependency selection on a per subsystem basis.
>
> Just to give one example, this symbol:
>
> > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > index b672d3142eb7..5e92ece5b104 100644
> > --- a/drivers/media/cec/platform/Kconfig
> > +++ b/drivers/media/cec/platform/Kconfig
> > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > config CEC_SECO
> > tristate "SECO Boards HDMI CEC driver"
> > depends on (X86 || IA64) || COMPILE_TEST
> > - depends on PCI && DMI
> > + depends on LEGACY_PCI && DMI
> > select CEC_CORE
> > select CEC_NOTIFIER
> > help
>
> Disables HDMI CEC support on some Intel motherboards.
> Any distro meant to run on generic hardware should keep it selected.
As far as I can see this one actually uses a hardcoded I/O port numbers
and googling it looks like it's an on-board device on the UDOO x86
board. I guess that should indeed just be
"depends on PCI && DMI && HAS_IOPORT".
>
> I can see some value of a "PCI_LEGACY" option to disable all
> non-PCIe drivers, but this is not the case here.
>
> Thanks,
> Mauro
Ok, I think we definitely need to work on getting the dependencies
right. I do think we agree that once done correctly there is value in
such an option independent of HAS_IOPORT only gating inb() etc uses.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-29 11:45 ` Niklas Schnelle
(?)
(?)
@ 2021-12-29 12:12 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-29 12:12 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Hans Verkuil, Ettore Chimenti, Bjorn Helgaas, Greg Kroah-Hartman,
Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-serial, dri-devel, linux-watchdog
Em Wed, 29 Dec 2021 12:45:38 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 16:06:44 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> >
> > (on a side note: the c/c list of this patch is too long. I would try to
> > avoid using a too long list, as otherwise this e-mail may end being rejected
> > by mail servers)
> >
> > > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > > >
> > > ---8<---
> > > >
> > > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > > tied to PCI specifically at all, right?
> > > > > > >
> > > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > > all?
> > > > > > >
> > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > > just describe it as it is, "DIRECT_IO"?
> > > > > >
> > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > > name for it.
> > > > > >
> > > > > > Thanks,
> > > > > > Mauro
> > > > >
> > > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > > HAS_IOPORT option added in patch 02.
> > > > >
> > > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > > >
> > > > I didn't look at the other patches on this series, but why it is needed
> > > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > > >
> > > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > > where LEGACY_PCI shall be "n"?
> > >
> > > In the current patch set LEGACY_PCI is not currently selected by
> > > architectures, though of course it could be if we know that an
> > > architecture requires it. We should probably also set it in any
> > > defconfig that has devices depending on it so as not to break these.
> > >
> > > Other than that it would be set during kernel configuration if one
> > > wants/needs support for legacy PCI devices. For testing I ran with
> > > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > > would make most sense for special configs such as those tailored for
> > > vitualization guets but in the end that would be something for
> > > distributions to decide.
> >
> > IMO, it makes sense to have a "default y" there, as on systems that
> > support I/O space, disabling it will just randomly disable some drivers
> > that could be required by some hardware. I won't doubt that some of
> > those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Makes sense, if these get more legacy over time we can always change
> the default. This would also mean we don't need to change defconfigs
> that include legacy PCI devices.
Yes.
> >
> > > Arnd described the options here:
> > > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
> >
> > Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> > This is missing on patch 1. You should probably reorder your patch
> > series to first create HAS_IOPORT and then add LEGACY_PCI with
> > depends on, as otherwise it may cause randconfig build issues
> > at robots and/or git bisect.
> >
> > I would also suggest to first introduce such change and then send
> > a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> > maintainers to review.
>
> Playing around with the reordering I think it might make sense to
> introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
> add dependencies for both on a per subsystem basis. I think it would be
> overkill to have two series of per subsystem patches.
Makes sense to me. Yeah, a single series should work.
> >
> > > >
> > > > > This
> > > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > > compatibility with legacy devices which require their use. Future
> > > > > revisions of this specification may deprecate the use of I/O Space."
> > > >
> > > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > > >
> > > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > > features that were/will be deprecated on PCI specs as time goes by.
> > > >
> > > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > > means.
> > >
> > > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > > devices or a compatibility feature allowing drivers for a pre-PCIe
> > > device to work with a PCIe device.
> >
> > That's the main point: it is *not* disabling pre-PCIe devices or
> > even legacy PCI drivers. It just disables a random set of drivers just
> > because they use inb/outb instead of readb/writeb. It keeps several pure
> > PCI drivers selected, and disables some PCIe for no real reason.
>
> That is not intentional. The dependencies are certainly not perfect yet
> which is one of the reasons this is still an RFC. I hope getting these
> right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
> dependency selection on a per subsystem basis.
Ok.
> >
> > Just to give one example, this symbol:
> >
> > > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > > index b672d3142eb7..5e92ece5b104 100644
> > > --- a/drivers/media/cec/platform/Kconfig
> > > +++ b/drivers/media/cec/platform/Kconfig
> > > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > > config CEC_SECO
> > > tristate "SECO Boards HDMI CEC driver"
> > > depends on (X86 || IA64) || COMPILE_TEST
> > > - depends on PCI && DMI
> > > + depends on LEGACY_PCI && DMI
> > > select CEC_CORE
> > > select CEC_NOTIFIER
> > > help
> >
> > Disables HDMI CEC support on some Intel motherboards.
> > Any distro meant to run on generic hardware should keep it selected.
>
> As far as I can see this one actually uses a hardcoded I/O port numbers
> and googling it looks like it's an on-board device on the UDOO x86
> board. I guess that should indeed just be
> "depends on PCI && DMI && HAS_IOPORT".
Agreed.
>
> >
> > I can see some value of a "PCI_LEGACY" option to disable all
> > non-PCIe drivers, but this is not the case here.
> >
> > Thanks,
> > Mauro
>
> Ok, I think we definitely need to work on getting the dependencies
> right.
Yes.
> I do think we agree that once done correctly there is value in
> such an option independent of HAS_IOPORT only gating inb() etc uses.
Personally, I don't see much value on a Kconfig var for legacy PCI I/O
space. From maintenance PoV, bots won't be triggered if someone use
HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
could end having a mix of both at the wrong places, in long term.
Also, assuming that PCIe hardware will some day abandon support for
"legacy" PCI I/O space, I guess some runtime logic would be needed,
in order to work with both kinds of PCIe controllers. So, having a
Kconfig option won't help much, IMO.
So, my personal preference would be to have just one Kconfig var, but
I'm ok if the PCI maintainers decide otherwise.
Thanks,
Mauro
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 12:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-29 12:12 UTC (permalink / raw)
To: intel-wired-lan
Em Wed, 29 Dec 2021 12:45:38 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 16:06:44 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> >
> > (on a side note: the c/c list of this patch is too long. I would try to
> > avoid using a too long list, as otherwise this e-mail may end being rejected
> > by mail servers)
> >
> > > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > > >
> > > ---8<---
> > > >
> > > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > > tied to PCI specifically at all, right?
> > > > > > >
> > > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > > all?
> > > > > > >
> > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > > just describe it as it is, "DIRECT_IO"?
> > > > > >
> > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > > name for it.
> > > > > >
> > > > > > Thanks,
> > > > > > Mauro
> > > > >
> > > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > > HAS_IOPORT option added in patch 02.
> > > > >
> > > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > > >
> > > > I didn't look at the other patches on this series, but why it is needed
> > > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > > >
> > > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > > where LEGACY_PCI shall be "n"?
> > >
> > > In the current patch set LEGACY_PCI is not currently selected by
> > > architectures, though of course it could be if we know that an
> > > architecture requires it. We should probably also set it in any
> > > defconfig that has devices depending on it so as not to break these.
> > >
> > > Other than that it would be set during kernel configuration if one
> > > wants/needs support for legacy PCI devices. For testing I ran with
> > > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > > would make most sense for special configs such as those tailored for
> > > vitualization guets but in the end that would be something for
> > > distributions to decide.
> >
> > IMO, it makes sense to have a "default y" there, as on systems that
> > support I/O space, disabling it will just randomly disable some drivers
> > that could be required by some hardware. I won't doubt that some of
> > those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Makes sense, if these get more legacy over time we can always change
> the default. This would also mean we don't need to change defconfigs
> that include legacy PCI devices.
Yes.
> >
> > > Arnd described the options here:
> > > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q at mail.gmail.com/
> >
> > Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> > This is missing on patch 1. You should probably reorder your patch
> > series to first create HAS_IOPORT and then add LEGACY_PCI with
> > depends on, as otherwise it may cause randconfig build issues
> > at robots and/or git bisect.
> >
> > I would also suggest to first introduce such change and then send
> > a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> > maintainers to review.
>
> Playing around with the reordering I think it might make sense to
> introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
> add dependencies for both on a per subsystem basis. I think it would be
> overkill to have two series of per subsystem patches.
Makes sense to me. Yeah, a single series should work.
> >
> > > >
> > > > > This
> > > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > > compatibility with legacy devices which require their use. Future
> > > > > revisions of this specification may deprecate the use of I/O Space."
> > > >
> > > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > > >
> > > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > > features that were/will be deprecated on PCI specs as time goes by.
> > > >
> > > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > > means.
> > >
> > > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > > devices or a compatibility feature allowing drivers for a pre-PCIe
> > > device to work with a PCIe device.
> >
> > That's the main point: it is *not* disabling pre-PCIe devices or
> > even legacy PCI drivers. It just disables a random set of drivers just
> > because they use inb/outb instead of readb/writeb. It keeps several pure
> > PCI drivers selected, and disables some PCIe for no real reason.
>
> That is not intentional. The dependencies are certainly not perfect yet
> which is one of the reasons this is still an RFC. I hope getting these
> right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
> dependency selection on a per subsystem basis.
Ok.
> >
> > Just to give one example, this symbol:
> >
> > > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > > index b672d3142eb7..5e92ece5b104 100644
> > > --- a/drivers/media/cec/platform/Kconfig
> > > +++ b/drivers/media/cec/platform/Kconfig
> > > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > > config CEC_SECO
> > > tristate "SECO Boards HDMI CEC driver"
> > > depends on (X86 || IA64) || COMPILE_TEST
> > > - depends on PCI && DMI
> > > + depends on LEGACY_PCI && DMI
> > > select CEC_CORE
> > > select CEC_NOTIFIER
> > > help
> >
> > Disables HDMI CEC support on some Intel motherboards.
> > Any distro meant to run on generic hardware should keep it selected.
>
> As far as I can see this one actually uses a hardcoded I/O port numbers
> and googling it looks like it's an on-board device on the UDOO x86
> board. I guess that should indeed just be
> "depends on PCI && DMI && HAS_IOPORT".
Agreed.
>
> >
> > I can see some value of a "PCI_LEGACY" option to disable all
> > non-PCIe drivers, but this is not the case here.
> >
> > Thanks,
> > Mauro
>
> Ok, I think we definitely need to work on getting the dependencies
> right.
Yes.
> I do think we agree that once done correctly there is value in
> such an option independent of HAS_IOPORT only gating inb() etc uses.
Personally, I don't see much value on a Kconfig var for legacy PCI I/O
space. From maintenance PoV, bots won't be triggered if someone use
HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
could end having a mix of both at the wrong places, in long term.
Also, assuming that PCIe hardware will some day abandon support for
"legacy" PCI I/O space, I guess some runtime logic would be needed,
in order to work with both kinds of PCIe controllers. So, having a
Kconfig option won't help much, IMO.
So, my personal preference would be to have just one Kconfig var, but
I'm ok if the PCI maintainers decide otherwise.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 12:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-29 12:12 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Hans Verkuil, Ettore Chimenti, Bjorn Helgaas, Greg Kroah-Hartman,
Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Damien Le Moal, Ian Abbott, H Hartley Sweeten, Linus Walleij,
Bartosz Golaszewski, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Karsten Keil, Sathya Prakash, Sreekanth Reddy,
Suganath Prabu Subramani, Michael Grzeschik, David S. Miller,
Jakub Kicinski, Jesse Brandeburg, Tony Nguyen, Kalle Valo,
Jouni Malinen, James E.J. Bottomley, Martin K. Petersen,
Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
Nilesh Javali, GR-QLogic-Storage-Upstream, Mark Brown,
Sudip Mukherjee, Teddy Wang, Forest Bond, Jiri Slaby,
Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-ide,
linux-gpio, linux-hwmon, linux-i2c, linux-input, netdev,
linux-media, MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan,
linux-wireless, megaraidlinux.pdl, linux-spi, linux-fbdev,
linux-serial, dri-devel, linux-watchdog
Em Wed, 29 Dec 2021 12:45:38 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 16:06:44 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> >
> > (on a side note: the c/c list of this patch is too long. I would try to
> > avoid using a too long list, as otherwise this e-mail may end being rejected
> > by mail servers)
> >
> > > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > > >
> > > ---8<---
> > > >
> > > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > > tied to PCI specifically at all, right?
> > > > > > >
> > > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > > all?
> > > > > > >
> > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > > just describe it as it is, "DIRECT_IO"?
> > > > > >
> > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > > name for it.
> > > > > >
> > > > > > Thanks,
> > > > > > Mauro
> > > > >
> > > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > > HAS_IOPORT option added in patch 02.
> > > > >
> > > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > > >
> > > > I didn't look at the other patches on this series, but why it is needed
> > > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > > >
> > > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > > where LEGACY_PCI shall be "n"?
> > >
> > > In the current patch set LEGACY_PCI is not currently selected by
> > > architectures, though of course it could be if we know that an
> > > architecture requires it. We should probably also set it in any
> > > defconfig that has devices depending on it so as not to break these.
> > >
> > > Other than that it would be set during kernel configuration if one
> > > wants/needs support for legacy PCI devices. For testing I ran with
> > > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > > would make most sense for special configs such as those tailored for
> > > vitualization guets but in the end that would be something for
> > > distributions to decide.
> >
> > IMO, it makes sense to have a "default y" there, as on systems that
> > support I/O space, disabling it will just randomly disable some drivers
> > that could be required by some hardware. I won't doubt that some of
> > those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Makes sense, if these get more legacy over time we can always change
> the default. This would also mean we don't need to change defconfigs
> that include legacy PCI devices.
Yes.
> >
> > > Arnd described the options here:
> > > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
> >
> > Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> > This is missing on patch 1. You should probably reorder your patch
> > series to first create HAS_IOPORT and then add LEGACY_PCI with
> > depends on, as otherwise it may cause randconfig build issues
> > at robots and/or git bisect.
> >
> > I would also suggest to first introduce such change and then send
> > a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> > maintainers to review.
>
> Playing around with the reordering I think it might make sense to
> introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
> add dependencies for both on a per subsystem basis. I think it would be
> overkill to have two series of per subsystem patches.
Makes sense to me. Yeah, a single series should work.
> >
> > > >
> > > > > This
> > > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > > compatibility with legacy devices which require their use. Future
> > > > > revisions of this specification may deprecate the use of I/O Space."
> > > >
> > > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > > >
> > > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > > features that were/will be deprecated on PCI specs as time goes by.
> > > >
> > > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > > means.
> > >
> > > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > > devices or a compatibility feature allowing drivers for a pre-PCIe
> > > device to work with a PCIe device.
> >
> > That's the main point: it is *not* disabling pre-PCIe devices or
> > even legacy PCI drivers. It just disables a random set of drivers just
> > because they use inb/outb instead of readb/writeb. It keeps several pure
> > PCI drivers selected, and disables some PCIe for no real reason.
>
> That is not intentional. The dependencies are certainly not perfect yet
> which is one of the reasons this is still an RFC. I hope getting these
> right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
> dependency selection on a per subsystem basis.
Ok.
> >
> > Just to give one example, this symbol:
> >
> > > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > > index b672d3142eb7..5e92ece5b104 100644
> > > --- a/drivers/media/cec/platform/Kconfig
> > > +++ b/drivers/media/cec/platform/Kconfig
> > > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > > config CEC_SECO
> > > tristate "SECO Boards HDMI CEC driver"
> > > depends on (X86 || IA64) || COMPILE_TEST
> > > - depends on PCI && DMI
> > > + depends on LEGACY_PCI && DMI
> > > select CEC_CORE
> > > select CEC_NOTIFIER
> > > help
> >
> > Disables HDMI CEC support on some Intel motherboards.
> > Any distro meant to run on generic hardware should keep it selected.
>
> As far as I can see this one actually uses a hardcoded I/O port numbers
> and googling it looks like it's an on-board device on the UDOO x86
> board. I guess that should indeed just be
> "depends on PCI && DMI && HAS_IOPORT".
Agreed.
>
> >
> > I can see some value of a "PCI_LEGACY" option to disable all
> > non-PCIe drivers, but this is not the case here.
> >
> > Thanks,
> > Mauro
>
> Ok, I think we definitely need to work on getting the dependencies
> right.
Yes.
> I do think we agree that once done correctly there is value in
> such an option independent of HAS_IOPORT only gating inb() etc uses.
Personally, I don't see much value on a Kconfig var for legacy PCI I/O
space. From maintenance PoV, bots won't be triggered if someone use
HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
could end having a mix of both at the wrong places, in long term.
Also, assuming that PCIe hardware will some day abandon support for
"legacy" PCI I/O space, I guess some runtime logic would be needed,
in order to work with both kinds of PCIe controllers. So, having a
Kconfig option won't help much, IMO.
So, my personal preference would be to have just one Kconfig var, but
I'm ok if the PCI maintainers decide otherwise.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 12:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-29 12:12 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-fbdev, linux-pci, dri-devel, Ettore Chimenti, linux-ide,
Jean Delvare, Guo Ren, linux-i2c, linux-riscv, Vincent Chen,
Jiri Slaby, linux-kernel, linux-arch, Hannes Reinecke,
Michael Grzeschik, linux-scsi, Sumit Saxena, Damien Le Moal,
Sathya Prakash, Jesse Brandeburg, linux-csky, Kashyap Desai,
Nilesh Javali, Bjorn Helgaas, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Jaroslav Kysela, Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, intel-wired-lan,
Bartosz Golaszewski
Em Wed, 29 Dec 2021 12:45:38 +0100
Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> On Tue, 2021-12-28 at 18:12 +0100, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Dec 2021 16:06:44 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> >
> > (on a side note: the c/c list of this patch is too long. I would try to
> > avoid using a too long list, as otherwise this e-mail may end being rejected
> > by mail servers)
> >
> > > On Tue, 2021-12-28 at 13:54 +0100, Mauro Carvalho Chehab wrote:
> > > >
> > > ---8<---
> > > >
> > > > > > > All you really care about is the "legacy" I/O spaces here, this isn't
> > > > > > > tied to PCI specifically at all, right?
> > > > > > >
> > > > > > > So why not just have a OLD_STYLE_IO config option or something like
> > > > > > > that, to show that it's the i/o functions we care about here, not PCI at
> > > > > > > all?
> > > > > > >
> > > > > > > And maybe not call it "old" or "legacy" as time constantly goes forward,
> > > > > > > just describe it as it is, "DIRECT_IO"?
> > > > > >
> > > > > > Agreed. HAVE_PCI_DIRECT_IO (or something similar) seems a more appropriate
> > > > > > name for it.
> > > > > >
> > > > > > Thanks,
> > > > > > Mauro
> > > > >
> > > > > Hmm, I might be missing something here but that sounds a lot like the
> > > > > HAS_IOPORT option added in patch 02.
> > > > >
> > > > > We add both LEGACY_PCI and HAS_IOPORT to differentiate between two
> > > > > cases. HAS_IOPORT is for PC-style devices that are not on a PCI card
> > > > > while LEGACY_PCI is for PCI drivers that require port I/O.
> > > >
> > > > I didn't look at the other patches on this series, but why it is needed
> > > > to deal with them on a separate way? Won't "PCI" and "HAS_IOPORT" be enough?
> > > >
> > > > I mean, are there any architecture where HAVE_PCI=y and HAS_IOPORT=y
> > > > where LEGACY_PCI shall be "n"?
> > >
> > > In the current patch set LEGACY_PCI is not currently selected by
> > > architectures, though of course it could be if we know that an
> > > architecture requires it. We should probably also set it in any
> > > defconfig that has devices depending on it so as not to break these.
> > >
> > > Other than that it would be set during kernel configuration if one
> > > wants/needs support for legacy PCI devices. For testing I ran with
> > > HAVE_PCI=y, HAS_IOPORT=y and LEGACY_PCI=n on both my local Ryzen 3990X
> > > based workstation and Raspberry Pi 4 (DT). I guess at the moment it
> > > would make most sense for special configs such as those tailored for
> > > vitualization guets but in the end that would be something for
> > > distributions to decide.
> >
> > IMO, it makes sense to have a "default y" there, as on systems that
> > support I/O space, disabling it will just randomly disable some drivers
> > that could be required by some hardware. I won't doubt that some of
> > those could be ported from using inb/outb to use, instead, readb/writeb.
>
> Makes sense, if these get more legacy over time we can always change
> the default. This would also mean we don't need to change defconfigs
> that include legacy PCI devices.
Yes.
> >
> > > Arnd described the options here:
> > > https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/
> >
> > Based on Arnd's description, LEGACY_PCI should depend on HAS_IOPORT.
> > This is missing on patch 1. You should probably reorder your patch
> > series to first create HAS_IOPORT and then add LEGACY_PCI with
> > depends on, as otherwise it may cause randconfig build issues
> > at robots and/or git bisect.
> >
> > I would also suggest to first introduce such change and then send
> > a per-subsystem LEGACY_PCI patch, as it would be a lot easier for
> > maintainers to review.
>
> Playing around with the reordering I think it might make sense to
> introduce HAS_IOPORT in patch 01, then LEGACY_PCI in patch 02 and then
> add dependencies for both on a per subsystem basis. I think it would be
> overkill to have two series of per subsystem patches.
Makes sense to me. Yeah, a single series should work.
> >
> > > >
> > > > > This
> > > > > includes pre-PCIe devices as well as PCIe devices which require
> > > > > features like I/O spaces. The "legacy" naming is comes from the PCIe
> > > > > spec which in section 2.1.1.2 says "PCI Express supports I/O Space for
> > > > > compatibility with legacy devices which require their use. Future
> > > > > revisions of this specification may deprecate the use of I/O Space."
> > > >
> > > > I would still avoid calling it LEGACY_PCI, as this sounds too generic.
> > > >
> > > > I didn't read the PCI/PCIe specs, but I suspect that are a lot more
> > > > features that were/will be deprecated on PCI specs as time goes by.
> > > >
> > > > So, I would, instead, use something like PCI_LEGACY_IO_SPACE or
> > > > HAVE_PCI_LEGACY_IO_SPACE, in order to let it clear what "legacy"
> > > > means.
> > >
> > > Hmm, I'd like to hear Bjorn's opinion on this. Personally I feel like
> > > LEGACY_PCI is pretty clear since most devices are either pre-PCIe
> > > devices or a compatibility feature allowing drivers for a pre-PCIe
> > > device to work with a PCIe device.
> >
> > That's the main point: it is *not* disabling pre-PCIe devices or
> > even legacy PCI drivers. It just disables a random set of drivers just
> > because they use inb/outb instead of readb/writeb. It keeps several pure
> > PCI drivers selected, and disables some PCIe for no real reason.
>
> That is not intentional. The dependencies are certainly not perfect yet
> which is one of the reasons this is still an RFC. I hope getting these
> right will be a lot easier if we do both LEGACY_PCI and HAS_IOPORT
> dependency selection on a per subsystem basis.
Ok.
> >
> > Just to give one example, this symbol:
> >
> > > diff --git a/drivers/media/cec/platform/Kconfig b/drivers/media/cec/platform/Kconfig
> > > index b672d3142eb7..5e92ece5b104 100644
> > > --- a/drivers/media/cec/platform/Kconfig
> > > +++ b/drivers/media/cec/platform/Kconfig
> > > @@ -100,7 +100,7 @@ config CEC_TEGRA
> > > config CEC_SECO
> > > tristate "SECO Boards HDMI CEC driver"
> > > depends on (X86 || IA64) || COMPILE_TEST
> > > - depends on PCI && DMI
> > > + depends on LEGACY_PCI && DMI
> > > select CEC_CORE
> > > select CEC_NOTIFIER
> > > help
> >
> > Disables HDMI CEC support on some Intel motherboards.
> > Any distro meant to run on generic hardware should keep it selected.
>
> As far as I can see this one actually uses a hardcoded I/O port numbers
> and googling it looks like it's an on-board device on the UDOO x86
> board. I guess that should indeed just be
> "depends on PCI && DMI && HAS_IOPORT".
Agreed.
>
> >
> > I can see some value of a "PCI_LEGACY" option to disable all
> > non-PCIe drivers, but this is not the case here.
> >
> > Thanks,
> > Mauro
>
> Ok, I think we definitely need to work on getting the dependencies
> right.
Yes.
> I do think we agree that once done correctly there is value in
> such an option independent of HAS_IOPORT only gating inb() etc uses.
Personally, I don't see much value on a Kconfig var for legacy PCI I/O
space. From maintenance PoV, bots won't be triggered if someone use
HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
could end having a mix of both at the wrong places, in long term.
Also, assuming that PCIe hardware will some day abandon support for
"legacy" PCI I/O space, I guess some runtime logic would be needed,
in order to work with both kinds of PCIe controllers. So, having a
Kconfig option won't help much, IMO.
So, my personal preference would be to have just one Kconfig var, but
I'm ok if the PCI maintainers decide otherwise.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-29 12:12 ` Mauro Carvalho Chehab
(?)
(?)
@ 2021-12-29 16:03 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-29 16:03 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Niklas Schnelle, Hans Verkuil, Ettore Chimenti,
Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Dec 2021 12:45:38 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > ...
> > I do think we agree that once done correctly there is value in
> > such an option independent of HAS_IOPORT only gating inb() etc uses.
I'm not sure I'm convinced about this. For s390, you could do this
patch series, where you don't define inb() at all, and you add new
dependencies to prevent compile errors. Or you could define inb() to
return ~0, which is what happens on other platforms when the device is
not present.
> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> space. From maintenance PoV, bots won't be triggered if someone use
> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> could end having a mix of both at the wrong places, in long term.
>
> Also, assuming that PCIe hardware will some day abandon support for
> "legacy" PCI I/O space, I guess some runtime logic would be needed,
> in order to work with both kinds of PCIe controllers. So, having a
> Kconfig option won't help much, IMO.
>
> So, my personal preference would be to have just one Kconfig var, but
> I'm ok if the PCI maintainers decide otherwise.
I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
means something old and out of favor; it doesn't say *what* that
something is.
I think you're specifically interested in I/O port space usage, and it
seems that you want all PCI drivers that *only* use I/O port space to
depend on LEGACY_PCI? Drivers that can use either I/O or memory
space or both would not depend on LEGACY_PCI? This seems a little
murky and error-prone.
What if you used the approach from [1] but just dropped the warning?
The inb() would return ~0 if the platform doesn't support I/O port
space. Drivers should be prepared to handle that because that's what
happens if the device doesn't exist.
HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
avoids building drivers that aren't useful on s390. I'm not sure the
benefit outweighs the complication.
Bjorn
[1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 16:03 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-29 16:03 UTC (permalink / raw)
To: intel-wired-lan
On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Dec 2021 12:45:38 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > ...
> > I do think we agree that once done correctly there is value in
> > such an option independent of HAS_IOPORT only gating inb() etc uses.
I'm not sure I'm convinced about this. For s390, you could do this
patch series, where you don't define inb() at all, and you add new
dependencies to prevent compile errors. Or you could define inb() to
return ~0, which is what happens on other platforms when the device is
not present.
> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> space. From maintenance PoV, bots won't be triggered if someone use
> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> could end having a mix of both at the wrong places, in long term.
>
> Also, assuming that PCIe hardware will some day abandon support for
> "legacy" PCI I/O space, I guess some runtime logic would be needed,
> in order to work with both kinds of PCIe controllers. So, having a
> Kconfig option won't help much, IMO.
>
> So, my personal preference would be to have just one Kconfig var, but
> I'm ok if the PCI maintainers decide otherwise.
I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
means something old and out of favor; it doesn't say *what* that
something is.
I think you're specifically interested in I/O port space usage, and it
seems that you want all PCI drivers that *only* use I/O port space to
depend on LEGACY_PCI? Drivers that can use either I/O or memory
space or both would not depend on LEGACY_PCI? This seems a little
murky and error-prone.
What if you used the approach from [1] but just dropped the warning?
The inb() would return ~0 if the platform doesn't support I/O port
space. Drivers should be prepared to handle that because that's what
happens if the device doesn't exist.
HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
avoids building drivers that aren't useful on s390. I'm not sure the
benefit outweighs the complication.
Bjorn
[1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g at mail.gmail.com/
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 16:03 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-29 16:03 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Niklas Schnelle, Hans Verkuil, Ettore Chimenti,
Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Dec 2021 12:45:38 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > ...
> > I do think we agree that once done correctly there is value in
> > such an option independent of HAS_IOPORT only gating inb() etc uses.
I'm not sure I'm convinced about this. For s390, you could do this
patch series, where you don't define inb() at all, and you add new
dependencies to prevent compile errors. Or you could define inb() to
return ~0, which is what happens on other platforms when the device is
not present.
> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> space. From maintenance PoV, bots won't be triggered if someone use
> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> could end having a mix of both at the wrong places, in long term.
>
> Also, assuming that PCIe hardware will some day abandon support for
> "legacy" PCI I/O space, I guess some runtime logic would be needed,
> in order to work with both kinds of PCIe controllers. So, having a
> Kconfig option won't help much, IMO.
>
> So, my personal preference would be to have just one Kconfig var, but
> I'm ok if the PCI maintainers decide otherwise.
I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
means something old and out of favor; it doesn't say *what* that
something is.
I think you're specifically interested in I/O port space usage, and it
seems that you want all PCI drivers that *only* use I/O port space to
depend on LEGACY_PCI? Drivers that can use either I/O or memory
space or both would not depend on LEGACY_PCI? This seems a little
murky and error-prone.
What if you used the approach from [1] but just dropped the warning?
The inb() would return ~0 if the platform doesn't support I/O port
space. Drivers should be prepared to handle that because that's what
happens if the device doesn't exist.
HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
avoids building drivers that aren't useful on s390. I'm not sure the
benefit outweighs the complication.
Bjorn
[1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 16:03 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-29 16:03 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: linux-fbdev, linux-pci, dri-devel, Ettore Chimenti, linux-ide,
Albert Ou, Guo Ren, linux-i2c, linux-riscv, Vincent Chen,
Jiri Slaby, linux-kernel, linux-arch, Hannes Reinecke,
Michael Grzeschik, linux-scsi, Sumit Saxena, Damien Le Moal,
Sathya Prakash, Jesse Brandeburg, linux-csky, Kashyap Desai,
Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Jaroslav Kysela, Jean Delvare, linux-watchdog, Niklas Schnelle,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, John Garry,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl,
Teddy Wang, linux-hwmon, Arnd Bergmann, Karsten Keil,
Sreekanth Reddy, Martin K. Petersen, Nick Hu, Sudip Mukherjee,
Shivasharan S, Greg Kroah-Hartman, Dmitry Torokhov,
linux-wireless, Takashi Iwai, David S. Miller, H Hartley Sweeten,
Palmer Dabbelt, Forest Bond, netdev, Hans Verkuil, Tony Nguyen,
Bartosz Golaszewski
On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Dec 2021 12:45:38 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > ...
> > I do think we agree that once done correctly there is value in
> > such an option independent of HAS_IOPORT only gating inb() etc uses.
I'm not sure I'm convinced about this. For s390, you could do this
patch series, where you don't define inb() at all, and you add new
dependencies to prevent compile errors. Or you could define inb() to
return ~0, which is what happens on other platforms when the device is
not present.
> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> space. From maintenance PoV, bots won't be triggered if someone use
> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> could end having a mix of both at the wrong places, in long term.
>
> Also, assuming that PCIe hardware will some day abandon support for
> "legacy" PCI I/O space, I guess some runtime logic would be needed,
> in order to work with both kinds of PCIe controllers. So, having a
> Kconfig option won't help much, IMO.
>
> So, my personal preference would be to have just one Kconfig var, but
> I'm ok if the PCI maintainers decide otherwise.
I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
means something old and out of favor; it doesn't say *what* that
something is.
I think you're specifically interested in I/O port space usage, and it
seems that you want all PCI drivers that *only* use I/O port space to
depend on LEGACY_PCI? Drivers that can use either I/O or memory
space or both would not depend on LEGACY_PCI? This seems a little
murky and error-prone.
What if you used the approach from [1] but just dropped the warning?
The inb() would return ~0 if the platform doesn't support I/O port
space. Drivers should be prepared to handle that because that's what
happens if the device doesn't exist.
HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
avoids building drivers that aren't useful on s390. I'm not sure the
benefit outweighs the complication.
Bjorn
[1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-29 16:03 ` Bjorn Helgaas
(?)
(?)
@ 2021-12-29 16:55 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 16:55 UTC (permalink / raw)
To: Bjorn Helgaas, Mauro Carvalho Chehab, Arnd Bergmann
Cc: Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu, Vincent Chen,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal,
Ian Abbott, H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 29 Dec 2021 12:45:38 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > > ...
> > > I do think we agree that once done correctly there is value in
> > > such an option independent of HAS_IOPORT only gating inb() etc uses.
>
> I'm not sure I'm convinced about this. For s390, you could do this
> patch series, where you don't define inb() at all, and you add new
> dependencies to prevent compile errors. Or you could define inb() to
> return ~0, which is what happens on other platforms when the device is
> not present.
>
> > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > space. From maintenance PoV, bots won't be triggered if someone use
> > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > could end having a mix of both at the wrong places, in long term.
> >
> > Also, assuming that PCIe hardware will some day abandon support for
> > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > in order to work with both kinds of PCIe controllers. So, having a
> > Kconfig option won't help much, IMO.
> >
> > So, my personal preference would be to have just one Kconfig var, but
> > I'm ok if the PCI maintainers decide otherwise.
>
> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> means something old and out of favor; it doesn't say *what* that
> something is.
>
> I think you're specifically interested in I/O port space usage, and it
> seems that you want all PCI drivers that *only* use I/O port space to
> depend on LEGACY_PCI? Drivers that can use either I/O or memory
> space or both would not depend on LEGACY_PCI? This seems a little
> murky and error-prone.
I'd like to hear Arnd's opinion on this but you're the PCI maintainer
so of course your buy-in would be quite important for such an option.
>
> What if you used the approach from [1] but just dropped the warning?
> The inb() would return ~0 if the platform doesn't support I/O port
> space. Drivers should be prepared to handle that because that's what
> happens if the device doesn't exist.
Hmm, in that mail Linus very clearly and specifically asked for this to
be a compile-time thing. So, if we do want to make it compile-time but
keep the potential errors to a minimum I guess just having HAS_IOPORT
might be valid compromise. It gets caught by bots through allyesconfig
or randconfig on HAS_IOPORT=n architectures. Also it has a nice
symmetry with the existing HAS_IOMEM.
>
>
> HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
> avoids building drivers that aren't useful on s390. I'm not sure the
> benefit outweighs the complication.
>
> Bjorn
>
> [1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
>
Despite s390 I believe it would also affect nds32, um, h8300, nios2,
openrisc, hexagon, csky, and xtensa. But yes none of these is any less
niche than us. I do wonder if we will see a new drivers using I/O
ports?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 16:55 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 16:55 UTC (permalink / raw)
To: intel-wired-lan
On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 29 Dec 2021 12:45:38 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > > ...
> > > I do think we agree that once done correctly there is value in
> > > such an option independent of HAS_IOPORT only gating inb() etc uses.
>
> I'm not sure I'm convinced about this. For s390, you could do this
> patch series, where you don't define inb() at all, and you add new
> dependencies to prevent compile errors. Or you could define inb() to
> return ~0, which is what happens on other platforms when the device is
> not present.
>
> > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > space. From maintenance PoV, bots won't be triggered if someone use
> > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > could end having a mix of both at the wrong places, in long term.
> >
> > Also, assuming that PCIe hardware will some day abandon support for
> > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > in order to work with both kinds of PCIe controllers. So, having a
> > Kconfig option won't help much, IMO.
> >
> > So, my personal preference would be to have just one Kconfig var, but
> > I'm ok if the PCI maintainers decide otherwise.
>
> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> means something old and out of favor; it doesn't say *what* that
> something is.
>
> I think you're specifically interested in I/O port space usage, and it
> seems that you want all PCI drivers that *only* use I/O port space to
> depend on LEGACY_PCI? Drivers that can use either I/O or memory
> space or both would not depend on LEGACY_PCI? This seems a little
> murky and error-prone.
I'd like to hear Arnd's opinion on this but you're the PCI maintainer
so of course your buy-in would be quite important for such an option.
>
> What if you used the approach from [1] but just dropped the warning?
> The inb() would return ~0 if the platform doesn't support I/O port
> space. Drivers should be prepared to handle that because that's what
> happens if the device doesn't exist.
Hmm, in that mail Linus very clearly and specifically asked for this to
be a compile-time thing. So, if we do want to make it compile-time but
keep the potential errors to a minimum I guess just having HAS_IOPORT
might be valid compromise. It gets caught by bots through allyesconfig
or randconfig on HAS_IOPORT=n architectures. Also it has a nice
symmetry with the existing HAS_IOMEM.
>
>
> HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
> avoids building drivers that aren't useful on s390. I'm not sure the
> benefit outweighs the complication.
>
> Bjorn
>
> [1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g at mail.gmail.com/
>
Despite s390 I believe it would also affect nds32, um, h8300, nios2,
openrisc, hexagon, csky, and xtensa. But yes none of these is any less
niche than us. I do wonder if we will see a new drivers using I/O
ports?
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 16:55 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 16:55 UTC (permalink / raw)
To: Bjorn Helgaas, Mauro Carvalho Chehab, Arnd Bergmann
Cc: linux-fbdev, linux-pci, dri-devel, Ettore Chimenti, linux-ide,
Jean Delvare, Guo Ren, linux-i2c, linux-riscv, Vincent Chen,
Jiri Slaby, linux-kernel, linux-arch, Hannes Reinecke,
Michael Grzeschik, linux-scsi, Sumit Saxena, Damien Le Moal,
Sathya Prakash, Jesse Brandeburg, linux-csky, Kashyap Desai,
Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, linux-input,
Jaroslav Kysela, Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, John Garry, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 29 Dec 2021 12:45:38 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > > ...
> > > I do think we agree that once done correctly there is value in
> > > such an option independent of HAS_IOPORT only gating inb() etc uses.
>
> I'm not sure I'm convinced about this. For s390, you could do this
> patch series, where you don't define inb() at all, and you add new
> dependencies to prevent compile errors. Or you could define inb() to
> return ~0, which is what happens on other platforms when the device is
> not present.
>
> > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > space. From maintenance PoV, bots won't be triggered if someone use
> > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > could end having a mix of both at the wrong places, in long term.
> >
> > Also, assuming that PCIe hardware will some day abandon support for
> > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > in order to work with both kinds of PCIe controllers. So, having a
> > Kconfig option won't help much, IMO.
> >
> > So, my personal preference would be to have just one Kconfig var, but
> > I'm ok if the PCI maintainers decide otherwise.
>
> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> means something old and out of favor; it doesn't say *what* that
> something is.
>
> I think you're specifically interested in I/O port space usage, and it
> seems that you want all PCI drivers that *only* use I/O port space to
> depend on LEGACY_PCI? Drivers that can use either I/O or memory
> space or both would not depend on LEGACY_PCI? This seems a little
> murky and error-prone.
I'd like to hear Arnd's opinion on this but you're the PCI maintainer
so of course your buy-in would be quite important for such an option.
>
> What if you used the approach from [1] but just dropped the warning?
> The inb() would return ~0 if the platform doesn't support I/O port
> space. Drivers should be prepared to handle that because that's what
> happens if the device doesn't exist.
Hmm, in that mail Linus very clearly and specifically asked for this to
be a compile-time thing. So, if we do want to make it compile-time but
keep the potential errors to a minimum I guess just having HAS_IOPORT
might be valid compromise. It gets caught by bots through allyesconfig
or randconfig on HAS_IOPORT=n architectures. Also it has a nice
symmetry with the existing HAS_IOMEM.
>
>
> HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
> avoids building drivers that aren't useful on s390. I'm not sure the
> benefit outweighs the complication.
>
> Bjorn
>
> [1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
>
Despite s390 I believe it would also affect nds32, um, h8300, nios2,
openrisc, hexagon, csky, and xtensa. But yes none of these is any less
niche than us. I do wonder if we will see a new drivers using I/O
ports?
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2021-12-29 16:55 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 16:55 UTC (permalink / raw)
To: Bjorn Helgaas, Mauro Carvalho Chehab, Arnd Bergmann
Cc: Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu, Vincent Chen,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal,
Ian Abbott, H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 29 Dec 2021 12:45:38 +0100
> > Niklas Schnelle <schnelle@linux.ibm.com> escreveu:
> > > ...
> > > I do think we agree that once done correctly there is value in
> > > such an option independent of HAS_IOPORT only gating inb() etc uses.
>
> I'm not sure I'm convinced about this. For s390, you could do this
> patch series, where you don't define inb() at all, and you add new
> dependencies to prevent compile errors. Or you could define inb() to
> return ~0, which is what happens on other platforms when the device is
> not present.
>
> > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > space. From maintenance PoV, bots won't be triggered if someone use
> > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > could end having a mix of both at the wrong places, in long term.
> >
> > Also, assuming that PCIe hardware will some day abandon support for
> > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > in order to work with both kinds of PCIe controllers. So, having a
> > Kconfig option won't help much, IMO.
> >
> > So, my personal preference would be to have just one Kconfig var, but
> > I'm ok if the PCI maintainers decide otherwise.
>
> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> means something old and out of favor; it doesn't say *what* that
> something is.
>
> I think you're specifically interested in I/O port space usage, and it
> seems that you want all PCI drivers that *only* use I/O port space to
> depend on LEGACY_PCI? Drivers that can use either I/O or memory
> space or both would not depend on LEGACY_PCI? This seems a little
> murky and error-prone.
I'd like to hear Arnd's opinion on this but you're the PCI maintainer
so of course your buy-in would be quite important for such an option.
>
> What if you used the approach from [1] but just dropped the warning?
> The inb() would return ~0 if the platform doesn't support I/O port
> space. Drivers should be prepared to handle that because that's what
> happens if the device doesn't exist.
Hmm, in that mail Linus very clearly and specifically asked for this to
be a compile-time thing. So, if we do want to make it compile-time but
keep the potential errors to a minimum I guess just having HAS_IOPORT
might be valid compromise. It gets caught by bots through allyesconfig
or randconfig on HAS_IOPORT=n architectures. Also it has a nice
symmetry with the existing HAS_IOMEM.
>
>
> HAS_IOPORT and LEGACY_PCI is a lot of Kconfiggery that basically just
> avoids building drivers that aren't useful on s390. I'm not sure the
> benefit outweighs the complication.
>
> Bjorn
>
> [1] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
>
Despite s390 I believe it would also affect nds32, um, h8300, nios2,
openrisc, hexagon, csky, and xtensa. But yes none of these is any less
niche than us. I do wonder if we will see a new drivers using I/O
ports?
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2021-12-29 16:55 ` Niklas Schnelle
(?)
(?)
@ 2022-01-05 17:42 ` John Garry
-1 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-05 17:42 UTC (permalink / raw)
To: Niklas Schnelle, Bjorn Helgaas, Mauro Carvalho Chehab,
Arnd Bergmann
Cc: Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On 29/12/2021 16:55, Niklas Schnelle wrote:
> On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
>> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
>>> Em Wed, 29 Dec 2021 12:45:38 +0100
>>> Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
>>>> ...
>>>> I do think we agree that once done correctly there is value in
>>>> such an option independent of HAS_IOPORT only gating inb() etc uses.
>> I'm not sure I'm convinced about this. For s390, you could do this
>> patch series, where you don't define inb() at all, and you add new
>> dependencies to prevent compile errors. Or you could define inb() to
>> return ~0, which is what happens on other platforms when the device is
>> not present.
>>
>>> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
>>> space. From maintenance PoV, bots won't be triggered if someone use
>>> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
>>> could end having a mix of both at the wrong places, in long term.
>>>
>>> Also, assuming that PCIe hardware will some day abandon support for
>>> "legacy" PCI I/O space, I guess some runtime logic would be needed,
>>> in order to work with both kinds of PCIe controllers. So, having a
>>> Kconfig option won't help much, IMO.
>>>
>>> So, my personal preference would be to have just one Kconfig var, but
>>> I'm ok if the PCI maintainers decide otherwise.
>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>> means something old and out of favor; it doesn't say*what* that
>> something is.
>>
>> I think you're specifically interested in I/O port space usage, and it
>> seems that you want all PCI drivers that*only* use I/O port space to
>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>> space or both would not depend on LEGACY_PCI? This seems a little
>> murky and error-prone.
> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> so of course your buy-in would be quite important for such an option.
>
Hi Niklas,
I can't see the value in the LEGACY_PCI config - however I don't really
understand Arnd's original intention.
It was written that it would allow us to control "whether we have any
pre-PCIe devices or those PCIe drivers that need PIO accessors other
than ioport_map()/pci_iomap()".
However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
always the gating factor here. Arnd?
Thanks,
John
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-05 17:42 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-05 17:42 UTC (permalink / raw)
To: intel-wired-lan
On 29/12/2021 16:55, Niklas Schnelle wrote:
> On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
>> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
>>> Em Wed, 29 Dec 2021 12:45:38 +0100
>>> Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
>>>> ...
>>>> I do think we agree that once done correctly there is value in
>>>> such an option independent of HAS_IOPORT only gating inb() etc uses.
>> I'm not sure I'm convinced about this. For s390, you could do this
>> patch series, where you don't define inb() at all, and you add new
>> dependencies to prevent compile errors. Or you could define inb() to
>> return ~0, which is what happens on other platforms when the device is
>> not present.
>>
>>> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
>>> space. From maintenance PoV, bots won't be triggered if someone use
>>> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
>>> could end having a mix of both at the wrong places, in long term.
>>>
>>> Also, assuming that PCIe hardware will some day abandon support for
>>> "legacy" PCI I/O space, I guess some runtime logic would be needed,
>>> in order to work with both kinds of PCIe controllers. So, having a
>>> Kconfig option won't help much, IMO.
>>>
>>> So, my personal preference would be to have just one Kconfig var, but
>>> I'm ok if the PCI maintainers decide otherwise.
>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>> means something old and out of favor; it doesn't say*what* that
>> something is.
>>
>> I think you're specifically interested in I/O port space usage, and it
>> seems that you want all PCI drivers that*only* use I/O port space to
>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>> space or both would not depend on LEGACY_PCI? This seems a little
>> murky and error-prone.
> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> so of course your buy-in would be quite important for such an option.
>
Hi Niklas,
I can't see the value in the LEGACY_PCI config - however I don't really
understand Arnd's original intention.
It was written that it would allow us to control "whether we have any
pre-PCIe devices or those PCIe drivers that need PIO accessors other
than ioport_map()/pci_iomap()".
However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
always the gating factor here. Arnd?
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-05 17:42 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-05 17:42 UTC (permalink / raw)
To: Niklas Schnelle, Bjorn Helgaas, Mauro Carvalho Chehab,
Arnd Bergmann
Cc: linux-fbdev, linux-pci, dri-devel, Ettore Chimenti, linux-ide,
Jean Delvare, Guo Ren, linux-i2c, linux-riscv, Vincent Chen,
Jiri Slaby, linux-kernel, linux-arch, Hannes Reinecke,
Michael Grzeschik, linux-scsi, Sumit Saxena, Damien Le Moal,
Sathya Prakash, Jesse Brandeburg, linux-csky, Kashyap Desai,
Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, Jaroslav Kysela,
Albert Ou, linux-watchdog, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, linux-input, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Wim Van Sebroeck, megaraidlinux.pdl, Teddy Wang,
linux-hwmon, Arnd Bergmann, Karsten Keil, Sreekanth Reddy,
Martin K. Petersen, Nick Hu, Sudip Mukherjee, Shivasharan S,
Greg Kroah-Hartman, Dmitry Torokhov, linux-wireless, Takashi Iwai,
David S. Miller, H Hartley Sweeten, Palmer Dabbelt, Forest Bond,
netdev, Hans Verkuil, Tony Nguyen, Bartosz Golaszewski
On 29/12/2021 16:55, Niklas Schnelle wrote:
> On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
>> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
>>> Em Wed, 29 Dec 2021 12:45:38 +0100
>>> Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
>>>> ...
>>>> I do think we agree that once done correctly there is value in
>>>> such an option independent of HAS_IOPORT only gating inb() etc uses.
>> I'm not sure I'm convinced about this. For s390, you could do this
>> patch series, where you don't define inb() at all, and you add new
>> dependencies to prevent compile errors. Or you could define inb() to
>> return ~0, which is what happens on other platforms when the device is
>> not present.
>>
>>> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
>>> space. From maintenance PoV, bots won't be triggered if someone use
>>> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
>>> could end having a mix of both at the wrong places, in long term.
>>>
>>> Also, assuming that PCIe hardware will some day abandon support for
>>> "legacy" PCI I/O space, I guess some runtime logic would be needed,
>>> in order to work with both kinds of PCIe controllers. So, having a
>>> Kconfig option won't help much, IMO.
>>>
>>> So, my personal preference would be to have just one Kconfig var, but
>>> I'm ok if the PCI maintainers decide otherwise.
>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>> means something old and out of favor; it doesn't say*what* that
>> something is.
>>
>> I think you're specifically interested in I/O port space usage, and it
>> seems that you want all PCI drivers that*only* use I/O port space to
>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>> space or both would not depend on LEGACY_PCI? This seems a little
>> murky and error-prone.
> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> so of course your buy-in would be quite important for such an option.
>
Hi Niklas,
I can't see the value in the LEGACY_PCI config - however I don't really
understand Arnd's original intention.
It was written that it would allow us to control "whether we have any
pre-PCIe devices or those PCIe drivers that need PIO accessors other
than ioport_map()/pci_iomap()".
However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
always the gating factor here. Arnd?
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-05 17:42 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-05 17:42 UTC (permalink / raw)
To: Niklas Schnelle, Bjorn Helgaas, Mauro Carvalho Chehab,
Arnd Bergmann
Cc: Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On 29/12/2021 16:55, Niklas Schnelle wrote:
> On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
>> On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
>>> Em Wed, 29 Dec 2021 12:45:38 +0100
>>> Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
>>>> ...
>>>> I do think we agree that once done correctly there is value in
>>>> such an option independent of HAS_IOPORT only gating inb() etc uses.
>> I'm not sure I'm convinced about this. For s390, you could do this
>> patch series, where you don't define inb() at all, and you add new
>> dependencies to prevent compile errors. Or you could define inb() to
>> return ~0, which is what happens on other platforms when the device is
>> not present.
>>
>>> Personally, I don't see much value on a Kconfig var for legacy PCI I/O
>>> space. From maintenance PoV, bots won't be triggered if someone use
>>> HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
>>> could end having a mix of both at the wrong places, in long term.
>>>
>>> Also, assuming that PCIe hardware will some day abandon support for
>>> "legacy" PCI I/O space, I guess some runtime logic would be needed,
>>> in order to work with both kinds of PCIe controllers. So, having a
>>> Kconfig option won't help much, IMO.
>>>
>>> So, my personal preference would be to have just one Kconfig var, but
>>> I'm ok if the PCI maintainers decide otherwise.
>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>> means something old and out of favor; it doesn't say*what* that
>> something is.
>>
>> I think you're specifically interested in I/O port space usage, and it
>> seems that you want all PCI drivers that*only* use I/O port space to
>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>> space or both would not depend on LEGACY_PCI? This seems a little
>> murky and error-prone.
> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> so of course your buy-in would be quite important for such an option.
>
Hi Niklas,
I can't see the value in the LEGACY_PCI config - however I don't really
understand Arnd's original intention.
It was written that it would allow us to control "whether we have any
pre-PCIe devices or those PCIe drivers that need PIO accessors other
than ioport_map()/pci_iomap()".
However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
always the gating factor here. Arnd?
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2022-01-05 17:42 ` John Garry
(?)
(?)
@ 2022-01-05 19:47 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: John Garry
Cc: linux-fbdev, linux-pci, Wim Van Sebroeck, Ettore Chimenti,
linux-ide, Albert Ou, Guo Ren, linux-i2c, linux-riscv,
Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Bartosz Golaszewski, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, Jaroslav Kysela,
Jean Delvare, linux-watchdog, Arnd Bergmann, Niklas Schnelle,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, linux-input,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Mauro Carvalho Chehab,
megaraidlinux.pdl, Teddy Wang, linux-hwmon, Arnd Bergmann,
Karsten Keil, Sreekanth Reddy, Martin K. Petersen, Nick Hu,
Sudip Mukherjee, Shivasharan S, Greg Kroah-Hartman, dri-devel,
Dmitry Torokhov, linux-wireless, Takashi Iwai, David S. Miller,
H Hartley Sweeten, Palmer Dabbelt, Forest Bond, netdev,
Hans Verkuil, Tony Nguyen, Damien Le Moal
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-05 19:47 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: intel-wired-lan
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-05 19:47 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: John Garry
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-05 19:47 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-05 19:47 UTC (permalink / raw)
To: John Garry
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Wed, Jan 05, 2022 at 05:42:16PM +0000, John Garry wrote:
> On 29/12/2021 16:55, Niklas Schnelle wrote:
> > On Wed, 2021-12-29 at 10:03 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 29, 2021 at 01:12:07PM +0100, Mauro Carvalho Chehab wrote:
> > > > Em Wed, 29 Dec 2021 12:45:38 +0100
> > > > Niklas Schnelle<schnelle@linux.ibm.com> escreveu:
> > > > > ...
> > > > > I do think we agree that once done correctly there is value in
> > > > > such an option independent of HAS_IOPORT only gating inb() etc uses.
> > > I'm not sure I'm convinced about this. For s390, you could do this
> > > patch series, where you don't define inb() at all, and you add new
> > > dependencies to prevent compile errors. Or you could define inb() to
> > > return ~0, which is what happens on other platforms when the device is
> > > not present.
> > >
> > > > Personally, I don't see much value on a Kconfig var for legacy PCI I/O
> > > > space. From maintenance PoV, bots won't be triggered if someone use
> > > > HAS_IOPORT instead of the PCI specific one - or vice-versa. So, we
> > > > could end having a mix of both at the wrong places, in long term.
> > > >
> > > > Also, assuming that PCIe hardware will some day abandon support for
> > > > "legacy" PCI I/O space, I guess some runtime logic would be needed,
> > > > in order to work with both kinds of PCIe controllers. So, having a
> > > > Kconfig option won't help much, IMO.
> > > >
> > > > So, my personal preference would be to have just one Kconfig var, but
> > > > I'm ok if the PCI maintainers decide otherwise.
> > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > means something old and out of favor; it doesn't say*what* that
> > > something is.
> > >
> > > I think you're specifically interested in I/O port space usage, and it
> > > seems that you want all PCI drivers that *only* use I/O port space to
> > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > space or both would not depend on LEGACY_PCI? This seems a little
> > > murky and error-prone.
> > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > so of course your buy-in would be quite important for such an option.
I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
think we need a clear guide for when to use it, e.g., "a PCI driver
that uses inb() must depend on LEGACY_PCI" or whatever it is.
I must be missing something because I don't see what we gain from
this. We have PCI drivers, e.g., megaraid [1], for devices that have
either MEM or I/O BARs. I think we want to build drivers like that on
any arch that supports PCI.
If the arch doesn't support I/O port space, devices that only have I/O
BARs won't work, of course, and hopefully the PCI core and driver can
figure that out and gracefully fail the probe.
But that same driver should still work with devices that have MEM
BARs. If inb() isn't always present, I guess we could litter these
drivers with #ifdefs, but that would be pretty ugly. IMO inb() should
be present but do something innocuous like return ~0, as it would if
I/O port space is supported but there's no device at that address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> I can't see the value in the LEGACY_PCI config - however I don't really
> understand Arnd's original intention.
>
> It was written that it would allow us to control "whether we have any
> pre-PCIe devices or those PCIe drivers that need PIO accessors other than
> ioport_map()/pci_iomap()".
>
> However I just don't see why CONFIG_PCI=y and CONFIG_HAS_IOPORT=y aren't
> always the gating factor here. Arnd?
>
> Thanks,
> John
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2022-01-05 19:47 ` Bjorn Helgaas
(?)
@ 2022-01-06 17:41 ` John Garry
-1 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-06 17:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On 05/01/2022 19:47, Bjorn Helgaas wrote:
>>>>> ok if the PCI maintainers decide otherwise.
>>>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>>>> means something old and out of favor; it doesn't say*what* that
>>>> something is.
>>>>
>>>> I think you're specifically interested in I/O port space usage, and it
>>>> seems that you want all PCI drivers that*only* use I/O port space to
>>>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>>>> space or both would not depend on LEGACY_PCI? This seems a little
>>>> murky and error-prone.
>>> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
>>> so of course your buy-in would be quite important for such an option.
> I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> think we need a clear guide for when to use it, e.g., "a PCI driver
> that uses inb() must depend on LEGACY_PCI" or whatever it is.
>
> I must be missing something because I don't see what we gain from
> this. We have PCI drivers, e.g., megaraid [1], for devices that have
> either MEM or I/O BARs. I think we want to build drivers like that on
> any arch that supports PCI.
>
> If the arch doesn't support I/O port space, devices that only have I/O
> BARs won't work, of course, and hopefully the PCI core and driver can
> figure that out and gracefully fail the probe.
>
> But that same driver should still work with devices that have MEM
> BARs. If inb() isn't always present, I guess we could litter these
> drivers with #ifdefs, but that would be pretty ugly.
There were some ifdefs added to the 8250 drivers in Arnd's original
patch [0], but it does not seem included here.
Niklas, what happened to the 8250 and the other driver changes?
[0]
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> IMO inb() should
> be present but do something innocuous like return ~0, as it would if
> I/O port space is supported but there's no device at that address.
>
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
>
That driver would prob not be used on systems which does not support
PIO, and so could have a HAS_IOPORT dependency. But it is not strictly
necessary.
Anyway, it would be good to have an idea of how much ifdeffery is
required in drivers.
Thanks,
John
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-06 17:41 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-06 17:41 UTC (permalink / raw)
To: intel-wired-lan
On 05/01/2022 19:47, Bjorn Helgaas wrote:
>>>>> ok if the PCI maintainers decide otherwise.
>>>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>>>> means something old and out of favor; it doesn't say*what* that
>>>> something is.
>>>>
>>>> I think you're specifically interested in I/O port space usage, and it
>>>> seems that you want all PCI drivers that*only* use I/O port space to
>>>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>>>> space or both would not depend on LEGACY_PCI? This seems a little
>>>> murky and error-prone.
>>> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
>>> so of course your buy-in would be quite important for such an option.
> I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> think we need a clear guide for when to use it, e.g., "a PCI driver
> that uses inb() must depend on LEGACY_PCI" or whatever it is.
>
> I must be missing something because I don't see what we gain from
> this. We have PCI drivers, e.g., megaraid [1], for devices that have
> either MEM or I/O BARs. I think we want to build drivers like that on
> any arch that supports PCI.
>
> If the arch doesn't support I/O port space, devices that only have I/O
> BARs won't work, of course, and hopefully the PCI core and driver can
> figure that out and gracefully fail the probe.
>
> But that same driver should still work with devices that have MEM
> BARs. If inb() isn't always present, I guess we could litter these
> drivers with #ifdefs, but that would be pretty ugly.
There were some ifdefs added to the 8250 drivers in Arnd's original
patch [0], but it does not seem included here.
Niklas, what happened to the 8250 and the other driver changes?
[0]
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA at mail.gmail.com/
> IMO inb() should
> be present but do something innocuous like return ~0, as it would if
> I/O port space is supported but there's no device at that address.
>
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
>
That driver would prob not be used on systems which does not support
PIO, and so could have a HAS_IOPORT dependency. But it is not strictly
necessary.
Anyway, it would be good to have an idea of how much ifdeffery is
required in drivers.
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-06 17:41 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-06 17:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On 05/01/2022 19:47, Bjorn Helgaas wrote:
>>>>> ok if the PCI maintainers decide otherwise.
>>>> I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
>>>> means something old and out of favor; it doesn't say*what* that
>>>> something is.
>>>>
>>>> I think you're specifically interested in I/O port space usage, and it
>>>> seems that you want all PCI drivers that*only* use I/O port space to
>>>> depend on LEGACY_PCI? Drivers that can use either I/O or memory
>>>> space or both would not depend on LEGACY_PCI? This seems a little
>>>> murky and error-prone.
>>> I'd like to hear Arnd's opinion on this but you're the PCI maintainer
>>> so of course your buy-in would be quite important for such an option.
> I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> think we need a clear guide for when to use it, e.g., "a PCI driver
> that uses inb() must depend on LEGACY_PCI" or whatever it is.
>
> I must be missing something because I don't see what we gain from
> this. We have PCI drivers, e.g., megaraid [1], for devices that have
> either MEM or I/O BARs. I think we want to build drivers like that on
> any arch that supports PCI.
>
> If the arch doesn't support I/O port space, devices that only have I/O
> BARs won't work, of course, and hopefully the PCI core and driver can
> figure that out and gracefully fail the probe.
>
> But that same driver should still work with devices that have MEM
> BARs. If inb() isn't always present, I guess we could litter these
> drivers with #ifdefs, but that would be pretty ugly.
There were some ifdefs added to the 8250 drivers in Arnd's original
patch [0], but it does not seem included here.
Niklas, what happened to the 8250 and the other driver changes?
[0]
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> IMO inb() should
> be present but do something innocuous like return ~0, as it would if
> I/O port space is supported but there's no device at that address.
>
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
>
That driver would prob not be used on systems which does not support
PIO, and so could have a HAS_IOPORT dependency. But it is not strictly
necessary.
Anyway, it would be good to have an idea of how much ifdeffery is
required in drivers.
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2022-01-06 17:41 ` John Garry
(?)
(?)
@ 2022-01-06 18:14 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-06 18:14 UTC (permalink / raw)
To: John Garry
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Thu, Jan 06, 2022 at 05:41:00PM +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > IMO inb() should
> > be present but do something innocuous like return ~0, as it would if
> > I/O port space is supported but there's no device at that address.
> >
> > [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> >
>
> That driver would prob not be used on systems which does not support PIO,
> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
I don't want the path of "this driver isn't needed because the device
is unlikely to be used on this arch."
Maybe it's not _always_ possible, but if the device can be plugged
into the platform, I think we should be able to build the driver for
it.
If the device requires I/O port space and the platform doesn't support
it, the PCI core or the driver should detect that and give a useful
diagnostic.
Bjorn
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-06 18:14 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-06 18:14 UTC (permalink / raw)
To: intel-wired-lan
On Thu, Jan 06, 2022 at 05:41:00PM +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > IMO inb() should
> > be present but do something innocuous like return ~0, as it would if
> > I/O port space is supported but there's no device at that address.
> >
> > [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> >
>
> That driver would prob not be used on systems which does not support PIO,
> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
I don't want the path of "this driver isn't needed because the device
is unlikely to be used on this arch."
Maybe it's not _always_ possible, but if the device can be plugged
into the platform, I think we should be able to build the driver for
it.
If the device requires I/O port space and the platform doesn't support
it, the PCI core or the driver should detect that and give a useful
diagnostic.
Bjorn
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-06 18:14 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-06 18:14 UTC (permalink / raw)
To: John Garry
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Thu, Jan 06, 2022 at 05:41:00PM +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > IMO inb() should
> > be present but do something innocuous like return ~0, as it would if
> > I/O port space is supported but there's no device at that address.
> >
> > [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> >
>
> That driver would prob not be used on systems which does not support PIO,
> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
I don't want the path of "this driver isn't needed because the device
is unlikely to be used on this arch."
Maybe it's not _always_ possible, but if the device can be plugged
into the platform, I think we should be able to build the driver for
it.
If the device requires I/O port space and the platform doesn't support
it, the PCI core or the driver should detect that and give a useful
diagnostic.
Bjorn
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-06 18:14 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2022-01-06 18:14 UTC (permalink / raw)
To: John Garry
Cc: linux-fbdev, linux-pci, Wim Van Sebroeck, Ettore Chimenti,
linux-ide, Albert Ou, Guo Ren, linux-i2c, linux-riscv,
Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Bartosz Golaszewski, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, Jaroslav Kysela,
Jean Delvare, linux-watchdog, Arnd Bergmann, Niklas Schnelle,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, linux-input,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Mauro Carvalho Chehab,
megaraidlinux.pdl, Teddy Wang, linux-hwmon, Arnd Bergmann,
Karsten Keil, Sreekanth Reddy, Martin K. Petersen, Nick Hu,
Sudip Mukherjee, Shivasharan S, Greg Kroah-Hartman, dri-devel,
Dmitry Torokhov, linux-wireless, Takashi Iwai, David S. Miller,
H Hartley Sweeten, Palmer Dabbelt, Forest Bond, netdev,
Hans Verkuil, Tony Nguyen, Damien Le Moal
On Thu, Jan 06, 2022 at 05:41:00PM +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > IMO inb() should
> > be present but do something innocuous like return ~0, as it would if
> > I/O port space is supported but there's no device at that address.
> >
> > [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.15#n4210
> >
>
> That driver would prob not be used on systems which does not support PIO,
> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
I don't want the path of "this driver isn't needed because the device
is unlikely to be used on this arch."
Maybe it's not _always_ possible, but if the device can be plugged
into the platform, I think we should be able to build the driver for
it.
If the device requires I/O port space and the platform doesn't support
it, the PCI core or the driver should detect that and give a useful
diagnostic.
Bjorn
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2022-01-06 18:14 ` Bjorn Helgaas
(?)
(?)
@ 2022-01-07 17:16 ` John Garry
-1 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-07 17:16 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On 06/01/2022 18:14, Bjorn Helgaas wrote:
>> That driver would prob not be used on systems which does not support PIO,
>> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
> I don't want the path of "this driver isn't needed because the device
> is unlikely to be used on this arch."
Sure, that was just a one off example. As I mentioned before, I think
that Arnd already did most of the ifdeffery work, but it was not
included in this series.
>
> Maybe it's not_always_ possible, but if the device can be plugged
> into the platform, I think we should be able to build the driver for
> it.
>
> If the device requires I/O port space and the platform doesn't support
> it, the PCI core or the driver should detect that and give a useful
> diagnostic.
>
I'm not sure what the driver can say apart from -ENODEV. Or IO port
management in resource.c could warn for requesting IO port region when
it's unsupported.
Anyway, this same conversion was had with Linus before I got involved.
If you think it is worth discussing again then I suppose the authors
here need to gain consensus.
Thanks,
John
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-07 17:16 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-07 17:16 UTC (permalink / raw)
To: intel-wired-lan
On 06/01/2022 18:14, Bjorn Helgaas wrote:
>> That driver would prob not be used on systems which does not support PIO,
>> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
> I don't want the path of "this driver isn't needed because the device
> is unlikely to be used on this arch."
Sure, that was just a one off example. As I mentioned before, I think
that Arnd already did most of the ifdeffery work, but it was not
included in this series.
>
> Maybe it's not_always_ possible, but if the device can be plugged
> into the platform, I think we should be able to build the driver for
> it.
>
> If the device requires I/O port space and the platform doesn't support
> it, the PCI core or the driver should detect that and give a useful
> diagnostic.
>
I'm not sure what the driver can say apart from -ENODEV. Or IO port
management in resource.c could warn for requesting IO port region when
it's unsupported.
Anyway, this same conversion was had with Linus before I got involved.
If you think it is worth discussing again then I suppose the authors
here need to gain consensus.
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-07 17:16 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-07 17:16 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-fbdev, linux-pci, Wim Van Sebroeck, Ettore Chimenti,
linux-ide, Albert Ou, Guo Ren, linux-i2c, linux-riscv,
Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Bartosz Golaszewski, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, Jaroslav Kysela,
Jean Delvare, linux-watchdog, Arnd Bergmann, Niklas Schnelle,
Jouni Malinen, Suganath Prabu Subramani, Kalle Valo, linux-input,
linux-spi, linux-gpio, Ian Abbott, Mark Brown, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Mauro Carvalho Chehab,
megaraidlinux.pdl, Teddy Wang, linux-hwmon, Arnd Bergmann,
Karsten Keil, Sreekanth Reddy, Martin K. Petersen, Nick Hu,
Sudip Mukherjee, Shivasharan S, Greg Kroah-Hartman, dri-devel,
Dmitry Torokhov, linux-wireless, Takashi Iwai, David S. Miller,
H Hartley Sweeten, Palmer Dabbelt, Forest Bond, netdev,
Hans Verkuil, Tony Nguyen, Damien Le Moal
On 06/01/2022 18:14, Bjorn Helgaas wrote:
>> That driver would prob not be used on systems which does not support PIO,
>> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
> I don't want the path of "this driver isn't needed because the device
> is unlikely to be used on this arch."
Sure, that was just a one off example. As I mentioned before, I think
that Arnd already did most of the ifdeffery work, but it was not
included in this series.
>
> Maybe it's not_always_ possible, but if the device can be plugged
> into the platform, I think we should be able to build the driver for
> it.
>
> If the device requires I/O port space and the platform doesn't support
> it, the PCI core or the driver should detect that and give a useful
> diagnostic.
>
I'm not sure what the driver can say apart from -ENODEV. Or IO port
management in resource.c could warn for requesting IO port region when
it's unsupported.
Anyway, this same conversion was had with Linus before I got involved.
If you think it is worth discussing again then I suppose the authors
here need to gain consensus.
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-07 17:16 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-07 17:16 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Niklas Schnelle, Mauro Carvalho Chehab, Arnd Bergmann,
Hans Verkuil, Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann,
Bjorn Helgaas, Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On 06/01/2022 18:14, Bjorn Helgaas wrote:
>> That driver would prob not be used on systems which does not support PIO,
>> and so could have a HAS_IOPORT dependency. But it is not strictly necessary.
> I don't want the path of "this driver isn't needed because the device
> is unlikely to be used on this arch."
Sure, that was just a one off example. As I mentioned before, I think
that Arnd already did most of the ifdeffery work, but it was not
included in this series.
>
> Maybe it's not_always_ possible, but if the device can be plugged
> into the platform, I think we should be able to build the driver for
> it.
>
> If the device requires I/O port space and the platform doesn't support
> it, the PCI core or the driver should detect that and give a useful
> diagnostic.
>
I'm not sure what the driver can say apart from -ENODEV. Or IO port
management in resource.c could warn for requesting IO port region when
it's unsupported.
Anyway, this same conversion was had with Linus before I got involved.
If you think it is worth discussing again then I suppose the authors
here need to gain consensus.
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
2022-01-06 17:41 ` John Garry
(?)
(?)
@ 2022-01-10 9:34 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-10 9:34 UTC (permalink / raw)
To: John Garry, Bjorn Helgaas
Cc: Mauro Carvalho Chehab, Arnd Bergmann, Hans Verkuil,
Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Thu, 2022-01-06 at 17:41 +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > > > > > ok if the PCI maintainers decide otherwise.
> > > > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > > > means something old and out of favor; it doesn't say*what* that
> > > > > something is.
> > > > >
> > > > > I think you're specifically interested in I/O port space usage, and it
> > > > > seems that you want all PCI drivers that*only* use I/O port space to
> > > > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > > > space or both would not depend on LEGACY_PCI? This seems a little
> > > > > murky and error-prone.
> > > > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > > > so of course your buy-in would be quite important for such an option.
> > I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> > think we need a clear guide for when to use it, e.g., "a PCI driver
> > that uses inb() must depend on LEGACY_PCI" or whatever it is.
> >
> > I must be missing something because I don't see what we gain from
> > this. We have PCI drivers, e.g., megaraid [1], for devices that have
> > either MEM or I/O BARs. I think we want to build drivers like that on
> > any arch that supports PCI.
> >
> > If the arch doesn't support I/O port space, devices that only have I/O
> > BARs won't work, of course, and hopefully the PCI core and driver can
> > figure that out and gracefully fail the probe.
> >
> > But that same driver should still work with devices that have MEM
> > BARs. If inb() isn't always present, I guess we could litter these
> > drivers with #ifdefs, but that would be pretty ugly.
I think this is the big question here. If we do go with a compile-time
solution as requested by Linus we will either get a lot of #ifdeffery,
coarse driver dependencies or as proposed by Alan Stern for the USB
#ifdefs might end up turning inb() into a compile-time nop.
The originally proposed change that returned ~0 from inb() and printed
a warning clearly is the simpler change and sure we could also drop the
warning. I'm honestly torn, I do agree with Linus that we shouldn't
have run-time things that we know at compile-time will not work but I
also dislike all the #ifdeffery a compile-time solution requires. Sadly
C really doesn't give us any better tools here.
Also I 100% agree with you Bjorn how likely it is to see a device on a
platform really shouldn't matter. Without going into details, on s390
we have already beneffited from PCI drivers working with 0 changes to
support devices we previously didn't have on the platform or
anticipated we would get in the future. Consequently drivers that could
work in principle should be built.
> >
>
> There were some ifdefs added to the 8250 drivers in Arnd's original
> patch [0], but it does not seem included here.
>
> Niklas, what happened to the 8250 and the other driver changes?
I missed it during the rebase, likely because the changed files compile
depend on !S390 via config SERIAL_8250 and thus didn't cause any errors
for my allyesconfig. That !S390 dependency is of course not really what
we want if the driver can use MEM BARs.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [Intel-wired-lan] [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-10 9:34 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-10 9:34 UTC (permalink / raw)
To: intel-wired-lan
On Thu, 2022-01-06 at 17:41 +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > > > > > ok if the PCI maintainers decide otherwise.
> > > > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > > > means something old and out of favor; it doesn't say*what* that
> > > > > something is.
> > > > >
> > > > > I think you're specifically interested in I/O port space usage, and it
> > > > > seems that you want all PCI drivers that*only* use I/O port space to
> > > > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > > > space or both would not depend on LEGACY_PCI? This seems a little
> > > > > murky and error-prone.
> > > > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > > > so of course your buy-in would be quite important for such an option.
> > I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> > think we need a clear guide for when to use it, e.g., "a PCI driver
> > that uses inb() must depend on LEGACY_PCI" or whatever it is.
> >
> > I must be missing something because I don't see what we gain from
> > this. We have PCI drivers, e.g., megaraid [1], for devices that have
> > either MEM or I/O BARs. I think we want to build drivers like that on
> > any arch that supports PCI.
> >
> > If the arch doesn't support I/O port space, devices that only have I/O
> > BARs won't work, of course, and hopefully the PCI core and driver can
> > figure that out and gracefully fail the probe.
> >
> > But that same driver should still work with devices that have MEM
> > BARs. If inb() isn't always present, I guess we could litter these
> > drivers with #ifdefs, but that would be pretty ugly.
I think this is the big question here. If we do go with a compile-time
solution as requested by Linus we will either get a lot of #ifdeffery,
coarse driver dependencies or as proposed by Alan Stern for the USB
#ifdefs might end up turning inb() into a compile-time nop.
The originally proposed change that returned ~0 from inb() and printed
a warning clearly is the simpler change and sure we could also drop the
warning. I'm honestly torn, I do agree with Linus that we shouldn't
have run-time things that we know at compile-time will not work but I
also dislike all the #ifdeffery a compile-time solution requires. Sadly
C really doesn't give us any better tools here.
Also I 100% agree with you Bjorn how likely it is to see a device on a
platform really shouldn't matter. Without going into details, on s390
we have already beneffited from PCI drivers working with 0 changes to
support devices we previously didn't have on the platform or
anticipated we would get in the future. Consequently drivers that could
work in principle should be built.
> >
>
> There were some ifdefs added to the 8250 drivers in Arnd's original
> patch [0], but it does not seem included here.
>
> Niklas, what happened to the 8250 and the other driver changes?
I missed it during the rebase, likely because the changed files compile
depend on !S390 via config SERIAL_8250 and thus didn't cause any errors
for my allyesconfig. That !S390 dependency is of course not really what
we want if the driver can use MEM BARs.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-10 9:34 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-10 9:34 UTC (permalink / raw)
To: John Garry, Bjorn Helgaas
Cc: linux-fbdev, linux-pci, Wim Van Sebroeck, Ettore Chimenti,
linux-ide, Albert Ou, Guo Ren, linux-i2c, linux-riscv,
Vincent Chen, Jiri Slaby, linux-kernel, linux-arch,
Hannes Reinecke, Michael Grzeschik, linux-scsi, Sumit Saxena,
Damien Le Moal, Sathya Prakash, Jesse Brandeburg, linux-csky,
Kashyap Desai, Nilesh Javali, intel-wired-lan, linux-serial,
GR-QLogic-Storage-Upstream, Jakub Kicinski, MPT-FusionLinux.pdl,
James E.J. Bottomley, Guenter Roeck, linux-media, Jaroslav Kysela,
Jean Delvare, linux-watchdog, Arnd Bergmann, Jouni Malinen,
Suganath Prabu Subramani, Kalle Valo, linux-input, linux-spi,
linux-gpio, Ian Abbott, Mark Brown, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Mauro Carvalho Chehab, megaraidlinux.pdl,
Teddy Wang, linux-hwmon, Arnd Bergmann, Karsten Keil,
Sreekanth Reddy, Martin K. Petersen, Nick Hu, Sudip Mukherjee,
Shivasharan S, Greg Kroah-Hartman, dri-devel, Dmitry Torokhov,
linux-wireless, Takashi Iwai, David S. Miller, H Hartley Sweeten,
Palmer Dabbelt, Forest Bond, netdev, Hans Verkuil, Tony Nguyen,
Bartosz Golaszewski
On Thu, 2022-01-06 at 17:41 +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > > > > > ok if the PCI maintainers decide otherwise.
> > > > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > > > means something old and out of favor; it doesn't say*what* that
> > > > > something is.
> > > > >
> > > > > I think you're specifically interested in I/O port space usage, and it
> > > > > seems that you want all PCI drivers that*only* use I/O port space to
> > > > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > > > space or both would not depend on LEGACY_PCI? This seems a little
> > > > > murky and error-prone.
> > > > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > > > so of course your buy-in would be quite important for such an option.
> > I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> > think we need a clear guide for when to use it, e.g., "a PCI driver
> > that uses inb() must depend on LEGACY_PCI" or whatever it is.
> >
> > I must be missing something because I don't see what we gain from
> > this. We have PCI drivers, e.g., megaraid [1], for devices that have
> > either MEM or I/O BARs. I think we want to build drivers like that on
> > any arch that supports PCI.
> >
> > If the arch doesn't support I/O port space, devices that only have I/O
> > BARs won't work, of course, and hopefully the PCI core and driver can
> > figure that out and gracefully fail the probe.
> >
> > But that same driver should still work with devices that have MEM
> > BARs. If inb() isn't always present, I guess we could litter these
> > drivers with #ifdefs, but that would be pretty ugly.
I think this is the big question here. If we do go with a compile-time
solution as requested by Linus we will either get a lot of #ifdeffery,
coarse driver dependencies or as proposed by Alan Stern for the USB
#ifdefs might end up turning inb() into a compile-time nop.
The originally proposed change that returned ~0 from inb() and printed
a warning clearly is the simpler change and sure we could also drop the
warning. I'm honestly torn, I do agree with Linus that we shouldn't
have run-time things that we know at compile-time will not work but I
also dislike all the #ifdeffery a compile-time solution requires. Sadly
C really doesn't give us any better tools here.
Also I 100% agree with you Bjorn how likely it is to see a device on a
platform really shouldn't matter. Without going into details, on s390
we have already beneffited from PCI drivers working with 0 changes to
support devices we previously didn't have on the platform or
anticipated we would get in the future. Consequently drivers that could
work in principle should be built.
> >
>
> There were some ifdefs added to the 8250 drivers in Arnd's original
> patch [0], but it does not seem included here.
>
> Niklas, what happened to the 8250 and the other driver changes?
I missed it during the rebase, likely because the changed files compile
depend on !S390 via config SERIAL_8250 and thus didn't cause any errors
for my allyesconfig. That !S390 dependency is of course not really what
we want if the driver can use MEM BARs.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
@ 2022-01-10 9:34 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-10 9:34 UTC (permalink / raw)
To: John Garry, Bjorn Helgaas
Cc: Mauro Carvalho Chehab, Arnd Bergmann, Hans Verkuil,
Ettore Chimenti, Greg Kroah-Hartman, Arnd Bergmann, Bjorn Helgaas,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Damien Le Moal, Ian Abbott,
H Hartley Sweeten, Linus Walleij, Bartosz Golaszewski,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Karsten Keil,
Sathya Prakash, Sreekanth Reddy, Suganath Prabu Subramani,
Michael Grzeschik, David S. Miller, Jakub Kicinski,
Jesse Brandeburg, Tony Nguyen, Kalle Valo, Jouni Malinen,
James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
GR-QLogic-Storage-Upstream, Mark Brown, Sudip Mukherjee,
Teddy Wang, Forest Bond, Jiri Slaby, Wim Van Sebroeck,
Jaroslav Kysela, Takashi Iwai, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-ide, linux-gpio,
linux-hwmon, linux-i2c, linux-input, netdev, linux-media,
MPT-FusionLinux.pdl, linux-scsi, intel-wired-lan, linux-wireless,
megaraidlinux.pdl, linux-spi, linux-fbdev, linux-serial,
dri-devel, linux-watchdog
On Thu, 2022-01-06 at 17:41 +0000, John Garry wrote:
> On 05/01/2022 19:47, Bjorn Helgaas wrote:
> > > > > > ok if the PCI maintainers decide otherwise.
> > > > > I don't really like the "LEGACY_PCI" Kconfig option. "Legacy" just
> > > > > means something old and out of favor; it doesn't say*what* that
> > > > > something is.
> > > > >
> > > > > I think you're specifically interested in I/O port space usage, and it
> > > > > seems that you want all PCI drivers that*only* use I/O port space to
> > > > > depend on LEGACY_PCI? Drivers that can use either I/O or memory
> > > > > space or both would not depend on LEGACY_PCI? This seems a little
> > > > > murky and error-prone.
> > > > I'd like to hear Arnd's opinion on this but you're the PCI maintainer
> > > > so of course your buy-in would be quite important for such an option.
> > I'd like to hear Arnd's opinion, too. If we do add LEGACY_PCI, I
> > think we need a clear guide for when to use it, e.g., "a PCI driver
> > that uses inb() must depend on LEGACY_PCI" or whatever it is.
> >
> > I must be missing something because I don't see what we gain from
> > this. We have PCI drivers, e.g., megaraid [1], for devices that have
> > either MEM or I/O BARs. I think we want to build drivers like that on
> > any arch that supports PCI.
> >
> > If the arch doesn't support I/O port space, devices that only have I/O
> > BARs won't work, of course, and hopefully the PCI core and driver can
> > figure that out and gracefully fail the probe.
> >
> > But that same driver should still work with devices that have MEM
> > BARs. If inb() isn't always present, I guess we could litter these
> > drivers with #ifdefs, but that would be pretty ugly.
I think this is the big question here. If we do go with a compile-time
solution as requested by Linus we will either get a lot of #ifdeffery,
coarse driver dependencies or as proposed by Alan Stern for the USB
#ifdefs might end up turning inb() into a compile-time nop.
The originally proposed change that returned ~0 from inb() and printed
a warning clearly is the simpler change and sure we could also drop the
warning. I'm honestly torn, I do agree with Linus that we shouldn't
have run-time things that we know at compile-time will not work but I
also dislike all the #ifdeffery a compile-time solution requires. Sadly
C really doesn't give us any better tools here.
Also I 100% agree with you Bjorn how likely it is to see a device on a
platform really shouldn't matter. Without going into details, on s390
we have already beneffited from PCI drivers working with 0 changes to
support devices we previously didn't have on the platform or
anticipated we would get in the future. Consequently drivers that could
work in principle should be built.
> >
>
> There were some ifdefs added to the 8250 drivers in Arnd's original
> patch [0], but it does not seem included here.
>
> Niklas, what happened to the 8250 and the other driver changes?
I missed it during the rebase, likely because the changed files compile
depend on !S390 via config SERIAL_8250 and thus didn't cause any errors
for my allyesconfig. That !S390 dependency is of course not really what
we want if the driver can use MEM BARs.
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-27 16:42 ` Niklas Schnelle
` (4 preceding siblings ...)
(?)
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-arch, linux-xtensa, linux-ia64, linux-parisc, linux-s390,
linux-pci, linux-sh, linux-kernel, linux-csky, linux-mips,
linux-m68k, openrisc, linux-alpha, sparclinux, linux-riscv,
linux-snps-arc, linuxppc-dev, linux-arm-kernel
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>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: openrisc
We introduce a new HAS_IOPORT Kconfig option to gate support for
I/O port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces. On these platforms
inb()/outb() etc are currently just stubs in asm-generic/io.h which when
called will cause a NULL pointer access which some compilers actually
detect and warn about.
The dependencies on HAS_IOPORT in drivers as well as ifdefs for
HAS_IOPORT specific sections will be added in subsequent patches on
a per subsystem basis. Then a final patch will ifdef the I/O access
functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
into a compile-time warning.
Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g at mail.gmail.com/
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/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 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
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
--
2.32.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-27 16:42 ` Niklas Schnelle
` (4 preceding siblings ...)
(?)
@ 2021-12-28 10:08 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Michael Schmitz, Greg Ungerer
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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 10:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 10:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Michael Schmitz, Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 10:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: openrisc
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 at mail.gmail.com/
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Thanks for your patch!
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -16,6 +16,7 @@ config M68K
> select GENERIC_CPU_DEVICES
> select GENERIC_IOMAP
> select GENERIC_IRQ_SHOW
> + select HAS_IOPORT
> select HAVE_AOUT if MMU
> select HAVE_ASM_MODVERSIONS
> select HAVE_DEBUG_BUGVERBOSE
This looks way too broad to me: most m68k platform do not have I/O
port access support.
My gut feeling says:
select HAS_IOPORT if PCI || ISA
but that might miss some intricate details...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 10:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, linux-parisc, Vineet Gupta, Matt Turner,
linux-snps-arc, Heiko Carstens, linux-xtensa, Albert Ou,
Chris Zankel, Jeff Dike, John Garry, linux-m68k, openrisc,
Ivan Kokshaysky, Greentime Hu, Paul Walmsley, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Richard Henderson,
Michael Schmitz, Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
Brian Cain, Nick Hu, linux-kernel, Dinh Nguyen, Palmer Dabbelt,
linux-alpha, Paul Mackerras, linuxppc-dev, David S. Miller
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 10:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Michael Schmitz, Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 10:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:08 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Michael Schmitz, Greg Ungerer
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-28 10:08 ` Geert Uytterhoeven
` (4 preceding siblings ...)
(?)
@ 2021-12-29 1:20 ` Michael Schmitz
-1 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Greg Ungerer
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
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 1:20 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 1:20 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 1:20 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: openrisc
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 at mail.gmail.com/
>> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
>> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
>> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
>
> Thanks for your patch!
>
>> --- a/arch/m68k/Kconfig
>> +++ b/arch/m68k/Kconfig
>> @@ -16,6 +16,7 @@ config M68K
>> select GENERIC_CPU_DEVICES
>> select GENERIC_IOMAP
>> select GENERIC_IRQ_SHOW
>> + select HAS_IOPORT
>> select HAVE_AOUT if MMU
>> select HAVE_ASM_MODVERSIONS
>> select HAVE_DEBUG_BUGVERBOSE
>
> This looks way too broad to me: most m68k platform do not have I/O
> port access support.
>
> My gut feeling says:
>
> select HAS_IOPORT if PCI || ISA
>
> but that might miss some intricate details...
In particular, this misses the Atari ROM port ISA adapter case -
select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
might do instead.
Cheers,
Michael
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
>
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 1:20 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Niklas Schnelle
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, linux-parisc, Vineet Gupta, Matt Turner,
linux-snps-arc, Heiko Carstens, linux-xtensa, Albert Ou,
Chris Zankel, Jeff Dike, John Garry, linux-m68k, openrisc,
Ivan Kokshaysky, Greentime Hu, Paul Walmsley, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Richard Henderson,
Arnd Bergmann, Michal Simek, Thomas Bogendoerfer, Brian Cain,
Nick Hu, linux-kernel, Dinh Nguyen, Palmer Dabbelt, linux-alpha,
Paul Mackerras, linuxppc-dev, David S. Miller
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 1:20 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 1:20 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 1:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Michal Simek, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-xtensa, openrisc,
linux-s390, linux-alpha, linux-snps-arc, linux-arm-kernel,
linux-ia64, linux-m68k, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, Greg Ungerer
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
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-29 1:20 ` Michael Schmitz
` (4 preceding siblings ...)
(?)
@ 2021-12-29 3:41 ` Arnd Bergmann
-1 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate support for
> >> I/O port access. In a future patch HAS_IOPORT=n will disable compilation
> >> of the I/O accessor functions inb()/outb() and friends on architectures
> >> which can not meaningfully support legacy I/O spaces. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >> select GENERIC_CPU_DEVICES
> >> select GENERIC_IOMAP
> >> select GENERIC_IRQ_SHOW
> >> + select HAS_IOPORT
> >> select HAVE_AOUT if MMU
> >> select HAVE_ASM_MODVERSIONS
> >> select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> > select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
> select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.
Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.
Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.
Arnd
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 3:41 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 3:41 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 3:41 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: openrisc
On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate support for
> >> I/O port access. In a future patch HAS_IOPORT=n will disable compilation
> >> of the I/O accessor functions inb()/outb() and friends on architectures
> >> which can not meaningfully support legacy I/O spaces. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g at mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >> select GENERIC_CPU_DEVICES
> >> select GENERIC_IOMAP
> >> select GENERIC_IRQ_SHOW
> >> + select HAS_IOPORT
> >> select HAVE_AOUT if MMU
> >> select HAVE_ASM_MODVERSIONS
> >> select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> > select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
> select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.
Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.
Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.
Arnd
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 3:41 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: Michael Schmitz
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, Geert Uytterhoeven, linux-parisc,
Vineet Gupta, Matt Turner, linux-snps-arc, Heiko Carstens,
linux-xtensa, Albert Ou, Niklas Schnelle, Jeff Dike, John Garry,
linux-m68k, openrisc, Ivan Kokshaysky, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Brian Cain, Nick Hu, linux-kernel,
Dinh Nguyen, Palmer Dabbelt, linux-alpha, Paul Mackerras,
linuxppc-dev, David S. Miller
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 3:41 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 3:41 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 3:41 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >> We introduce a new HAS_IOPORT Kconfig option to gate support for
> >> I/O port access. In a future patch HAS_IOPORT=n will disable compilation
> >> of the I/O accessor functions inb()/outb() and friends on architectures
> >> which can not meaningfully support legacy I/O spaces. On these platforms
> >> inb()/outb() etc are currently just stubs in asm-generic/io.h which when
> >> called will cause a NULL pointer access which some compilers actually
> >> detect and warn about.
> >>
> >> The dependencies on HAS_IOPORT in drivers as well as ifdefs for
> >> HAS_IOPORT specific sections will be added in subsequent patches on
> >> a per subsystem basis. Then a final patch will ifdef the I/O access
> >> functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
> >> into a compile-time warning.
> >>
> >> Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> >> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/m68k/Kconfig
> >> +++ b/arch/m68k/Kconfig
> >> @@ -16,6 +16,7 @@ config M68K
> >> select GENERIC_CPU_DEVICES
> >> select GENERIC_IOMAP
> >> select GENERIC_IRQ_SHOW
> >> + select HAS_IOPORT
> >> select HAVE_AOUT if MMU
> >> select HAVE_ASM_MODVERSIONS
> >> select HAVE_DEBUG_BUGVERBOSE
> >
> > This looks way too broad to me: most m68k platform do not have I/O
> > port access support.
> >
> > My gut feeling says:
> >
> > select HAS_IOPORT if PCI || ISA
> >
> > but that might miss some intricate details...
>
> In particular, this misses the Atari ROM port ISA adapter case -
>
> select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>
> might do instead.
Right, makes sense. I had suggested to go the easy way and assume that
each architecture would select HAS_IOPORT if any configuration supports
it, but it looks like for m68k there is a clearly defined set of platforms that
do.
Note that for the platforms that don't set any of the three symbols, the
fallback makes inb() an alias for readb() with a different argument type,
so there may be m68k specific drivers that rely on this, but those would
already be broken if ATARI_ROM_ISA is set.
Arnd
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-29 3:41 ` Arnd Bergmann
` (4 preceding siblings ...)
(?)
@ 2021-12-29 4:15 ` Michael Schmitz
-1 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 4:15 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 4:15 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 4:15 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: openrisc
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 at mail.gmail.com/
>>>> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
>>>> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
>>>> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/arch/m68k/Kconfig
>>>> +++ b/arch/m68k/Kconfig
>>>> @@ -16,6 +16,7 @@ config M68K
>>>> select GENERIC_CPU_DEVICES
>>>> select GENERIC_IOMAP
>>>> select GENERIC_IRQ_SHOW
>>>> + select HAS_IOPORT
>>>> select HAVE_AOUT if MMU
>>>> select HAVE_ASM_MODVERSIONS
>>>> select HAVE_DEBUG_BUGVERBOSE
>>>
>>> This looks way too broad to me: most m68k platform do not have I/O
>>> port access support.
>>>
>>> My gut feeling says:
>>>
>>> select HAS_IOPORT if PCI || ISA
>>>
>>> but that might miss some intricate details...
>>
>> In particular, this misses the Atari ROM port ISA adapter case -
>>
>> select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
>>
>> might do instead.
>
> Right, makes sense. I had suggested to go the easy way and assume that
> each architecture would select HAS_IOPORT if any configuration supports
> it, but it looks like for m68k there is a clearly defined set of platforms that
> do.
>
> Note that for the platforms that don't set any of the three symbols, the
> fallback makes inb() an alias for readb() with a different argument type,
> so there may be m68k specific drivers that rely on this, but those would
> already be broken if ATARI_ROM_ISA is set.
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 4:15 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, Geert Uytterhoeven, linux-parisc,
Vineet Gupta, Matt Turner, linux-snps-arc, Heiko Carstens,
linux-xtensa, Albert Ou, Niklas Schnelle, Jeff Dike, John Garry,
linux-m68k, openrisc, Ivan Kokshaysky, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Brian Cain, Nick Hu, linux-kernel,
Dinh Nguyen, Palmer Dabbelt, linux-alpha, Paul Mackerras,
linuxppc-dev, David S. Miller
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 4:15 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-29 4:15 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-29 4:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-29 4:15 ` Michael Schmitz
` (4 preceding siblings ...)
(?)
@ 2021-12-30 1:48 ` Arnd Bergmann
-1 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 1:48 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 1:48 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 1:48 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: openrisc
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 1:48 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, Geert Uytterhoeven, linux-parisc,
Vineet Gupta, Matt Turner, linux-snps-arc, Heiko Carstens,
linux-xtensa, Albert Ou, Niklas Schnelle, Jeff Dike, John Garry,
linux-m68k, openrisc, Ivan Kokshaysky, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Brian Cain, Nick Hu, linux-kernel,
Dinh Nguyen, Palmer Dabbelt, linux-alpha, Paul Mackerras,
linuxppc-dev, David S. Miller
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 1:48 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 1:48 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 1:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-30 1:48 ` Arnd Bergmann
` (4 preceding siblings ...)
(?)
@ 2021-12-30 3:44 ` Michael Schmitz
-1 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 3:44 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 3:44 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 3:44 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: openrisc
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 3:44 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, Geert Uytterhoeven, linux-parisc,
Vineet Gupta, Matt Turner, linux-snps-arc, Heiko Carstens,
linux-xtensa, Albert Ou, Niklas Schnelle, Jeff Dike, John Garry,
linux-m68k, openrisc, Ivan Kokshaysky, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Brian Cain, Nick Hu, linux-kernel,
Dinh Nguyen, Palmer Dabbelt, linux-alpha, Paul Mackerras,
linuxppc-dev, David S. Miller
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 3:44 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-30 3:44 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-30 3:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-xtensa, openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-30 3:44 ` Michael Schmitz
` (4 preceding siblings ...)
(?)
@ 2021-12-31 11:28 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: Michael Schmitz, Arnd Bergmann
Cc: Geert Uytterhoeven, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel, Karol Gugala,
Jeff Dike, Yoshinori Sato, Brian Cain, Heiko Carstens,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Russell King, Catalin Marinas, Will Deacon, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 11:28 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: Michael Schmitz, Arnd Bergmann
Cc: Geert Uytterhoeven, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel, Karol Gugala,
Jeff Dike, Yoshinori Sato, Brian Cain, Heiko Carstens,
Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta <v>
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.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 11:28 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: Michael Schmitz, Arnd Bergmann
Cc: Geert Uytterhoeven, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel, Karol Gugala,
Jeff Dike, Yoshinori Sato, Brian Cain, Heiko Carstens,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Russell King, Catalin Marinas, Will Deacon, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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.
^ permalink raw reply [flat|nested] 323+ messages in thread
* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 11:28 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: openrisc
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.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 11:28 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: Michael Schmitz, Arnd Bergmann
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Karol Gugala, linux-arch,
linux-s390, Yoshinori Sato, Helge Deller, x86, Russell King,
linux-csky, Ingo Molnar, Geert Uytterhoeven, linux-parisc,
Vineet Gupta, Matt Turner, linux-snps-arc, Heiko Carstens,
linux-xtensa, Albert Ou, Jeff Dike, John Garry, linux-m68k,
openrisc, Ivan Kokshaysky, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Brian Cain, Nick Hu, linux-kernel,
Dinh Nguyen, Palmer Dabbelt, linux-alpha, Paul Mackerras,
linuxppc-dev, David S. Miller
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.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 11:28 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: Michael Schmitz, Arnd Bergmann
Cc: Geert Uytterhoeven, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel, Karol Gugala,
Jeff Dike, Yoshinori Sato, Brian Cain, Heiko Carstens,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Russell King, Catalin Marinas, Will Deacon, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 11:28 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:28 UTC (permalink / raw)
To: Michael Schmitz, Arnd Bergmann
Cc: Geert Uytterhoeven, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel, Karol Gugala,
Jeff Dike, Yoshinori Sato, Brian Cain, Heiko Carstens,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Russell King, Catalin Marinas, Will Deacon, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, Greg Ungerer
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.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-30 3:44 ` Michael Schmitz
` (4 preceding siblings ...)
(?)
@ 2021-12-31 16:04 ` Arnd Bergmann
-1 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 16:04 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 16:04 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 16:04 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: openrisc
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 16:04 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: Michael Schmitz
Cc: Rich Felker, Linux-sh list, Catalin Marinas, Dave Hansen,
linux-pci, open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
sparclinux, Guo Ren, H. Peter Anvin, Borislav Petkov, linux-ia64,
linux-riscv, Vincent Chen, Will Deacon, Greg Ungerer,
Karol Gugala, linux-arch, linux-s390, Yoshinori Sato,
Helge Deller, the arch/x86 maintainers, Russell King, linux-csky,
Ingo Molnar, Geert Uytterhoeven, Parisc List, Vineet Gupta,
Matt Turner, open list:SYNOPSYS ARC ARCHITECTURE, Heiko Carstens,
open list:TENSILICA XTENSA PORT (xtensa), Albert Ou,
Niklas Schnelle, Jeff Dike, John Garry, linux-m68k, Openrisc,
Ivan Kokshaysky, Greentime Hu, Paul Walmsley, Bjorn Helgaas,
Thomas Gleixner, Linux ARM, Richard Henderson, Chris Zankel,
Michal Simek, Thomas Bogendoerfer, Brian Cain, Nick Hu,
Linux Kernel Mailing List, Dinh Nguyen, Palmer Dabbelt, alpha,
Paul Mackerras, linuxppc-dev, David S. Miller
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 16:04 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 16:04 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-31 16:04 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-31 16:04 ` Arnd Bergmann
` (4 preceding siblings ...)
(?)
@ 2021-12-31 21:55 ` Michael Schmitz
-1 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 21:55 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 21:55 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 21:55 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: openrisc
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 21:55 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rich Felker, Linux-sh list, Catalin Marinas, Dave Hansen,
linux-pci, open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
sparclinux, Guo Ren, H. Peter Anvin, Borislav Petkov, linux-ia64,
linux-riscv, Vincent Chen, Will Deacon, Greg Ungerer,
Karol Gugala, linux-arch, linux-s390, Yoshinori Sato,
Helge Deller, the arch/x86 maintainers, Russell King, linux-csky,
Ingo Molnar, Geert Uytterhoeven, Parisc List, Vineet Gupta,
Matt Turner, open list:SYNOPSYS ARC ARCHITECTURE, Heiko Carstens,
open list:TENSILICA XTENSA PORT (xtensa), Albert Ou,
Niklas Schnelle, Jeff Dike, John Garry, linux-m68k, Openrisc,
Ivan Kokshaysky, Greentime Hu, Paul Walmsley, Bjorn Helgaas,
Thomas Gleixner, Linux ARM, Richard Henderson, Chris Zankel,
Michal Simek, Thomas Bogendoerfer, Brian Cain, Nick Hu,
Linux Kernel Mailing List, Dinh Nguyen, Palmer Dabbelt, alpha,
Paul Mackerras, linuxppc-dev, David S. Miller
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 21:55 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-31 21:55 ` Michael Schmitz
0 siblings, 0 replies; 323+ messages in thread
From: Michael Schmitz @ 2021-12-31 21:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Niklas Schnelle, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Dinh Nguyen, Chris Zankel,
Karol Gugala, Jeff Dike, Yoshinori Sato, Brian Cain,
Heiko Carstens, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rich Felker, David S. Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen,
the arch/x86 maintainers, H. Peter Anvin,
Linux Kernel Mailing List, linux-arch, linux-pci, linux-riscv,
linux-csky, open list:TENSILICA XTENSA PORT (xtensa), Openrisc,
linux-s390, alpha, open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
linux-ia64, linux-m68k, open list:BROADCOM NVRAM DRIVER,
Parisc List, linuxppc-dev, Linux-sh list, sparclinux,
Greg Ungerer
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
2021-12-27 16:42 ` Niklas Schnelle
` (4 preceding siblings ...)
(?)
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* [OpenRISC] [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: openrisc
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 at mail.gmail.com/
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
...
> @@ -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
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Rich Felker, linux-sh, Catalin Marinas, Dave Hansen, linux-pci,
linux-mips, James E.J. Bottomley, sparclinux, Guo Ren,
H. Peter Anvin, Borislav Petkov, linux-ia64, linux-riscv,
Vincent Chen, Will Deacon, Karol Gugala, linux-arch, linux-s390,
Yoshinori Sato, Helge Deller, x86, Russell King, linux-csky,
Ingo Molnar, Geert Uytterhoeven, linux-parisc, Vineet Gupta,
Matt Turner, linux-snps-arc, Heiko Carstens, linux-xtensa,
Albert Ou, Chris Zankel, Jeff Dike, John Garry, linux-m68k,
openrisc, Ivan Kokshaysky, Greentime Hu, Paul Walmsley,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Arnd Bergmann, Michal Simek,
Thomas Bogendoerfer, Brian Cain, Nick Hu, linux-kernel,
Dinh Nguyen, Palmer Dabbelt, linux-alpha, Paul Mackerras,
linuxppc-dev, David S. Miller
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2021-12-28 16:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 323+ messages in thread
From: Mauro Carvalho Chehab @ 2021-12-28 16:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, linux-xtensa,
openrisc, linux-s390, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Rafael J. Wysocki, Len Brown
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-acpi
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As ACPI always uses I/O port access we depend on
HAS_IOPORT unconditionally.
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>
---
drivers/acpi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index cdbdf68bd98f..b57f15817ede 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on ARCH_SUPPORTS_ACPI
+ depends on HAS_IOPORT
select PNP
select NLS
default y if X86
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Rafael J. Wysocki, Len Brown
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-acpi
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As ACPI always uses I/O port access we depend on
HAS_IOPORT unconditionally.
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>
---
drivers/acpi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index cdbdf68bd98f..b57f15817ede 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on ARCH_SUPPORTS_ACPI
+ depends on HAS_IOPORT
select PNP
select NLS
default y if X86
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:47 ` Rafael J. Wysocki
-1 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-27 16:47 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Rafael J. Wysocki, Len Brown, Linux Kernel Mailing List,
linux-arch, Linux PCI, linux-riscv, linux-csky,
ACPI Devel Maling List
On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. As ACPI always uses I/O port access
The ARM64 people may not agree with this.
> we depend on HAS_IOPORT unconditionally.
>
> 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>
> ---
> drivers/acpi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index cdbdf68bd98f..b57f15817ede 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> menuconfig ACPI
> bool "ACPI (Advanced Configuration and Power Interface) Support"
> depends on ARCH_SUPPORTS_ACPI
> + depends on HAS_IOPORT
> select PNP
> select NLS
> default y if X86
> --
> 2.32.0
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:47 ` Rafael J. Wysocki
0 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-27 16:47 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Rafael J. Wysocki, Len Brown, Linux Kernel Mailing List,
linux-arch, Linux PCI, linux-riscv, linux-csky,
ACPI Devel Maling List
On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. As ACPI always uses I/O port access
The ARM64 people may not agree with this.
> we depend on HAS_IOPORT unconditionally.
>
> 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>
> ---
> drivers/acpi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index cdbdf68bd98f..b57f15817ede 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> menuconfig ACPI
> bool "ACPI (Advanced Configuration and Power Interface) Support"
> depends on ARCH_SUPPORTS_ACPI
> + depends on HAS_IOPORT
> select PNP
> select NLS
> default y if X86
> --
> 2.32.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:47 ` Rafael J. Wysocki
@ 2021-12-27 17:02 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 17:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As ACPI always uses I/O port access
>
> The ARM64 people may not agree with this.
Maybe my wording is bad. This is my rewording of what Arnd had in his
original mail: "The ACPI subsystem needs access to I/O ports, so that
also gets a dependency."(
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
).
>
> > we depend on HAS_IOPORT unconditionally.
> >
> > 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>
> > ---
> > drivers/acpi/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index cdbdf68bd98f..b57f15817ede 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > menuconfig ACPI
> > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > depends on ARCH_SUPPORTS_ACPI
> > + depends on HAS_IOPORT
> > select PNP
> > select NLS
> > default y if X86
> > --
> > 2.32.0
> >
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 17:02 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 17:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As ACPI always uses I/O port access
>
> The ARM64 people may not agree with this.
Maybe my wording is bad. This is my rewording of what Arnd had in his
original mail: "The ACPI subsystem needs access to I/O ports, so that
also gets a dependency."(
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
).
>
> > we depend on HAS_IOPORT unconditionally.
> >
> > 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>
> > ---
> > drivers/acpi/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index cdbdf68bd98f..b57f15817ede 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > menuconfig ACPI
> > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > depends on ARCH_SUPPORTS_ACPI
> > + depends on HAS_IOPORT
> > select PNP
> > select NLS
> > default y if X86
> > --
> > 2.32.0
> >
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 17:02 ` Niklas Schnelle
@ 2021-12-27 17:12 ` Rafael J. Wysocki
-1 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-27 17:12 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Rafael J. Wysocki, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Len Brown,
Linux Kernel Mailing List, linux-arch, Linux PCI, linux-riscv,
linux-csky, ACPI Devel Maling List
On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. As ACPI always uses I/O port access
> >
> > The ARM64 people may not agree with this.
>
> Maybe my wording is bad. This is my rewording of what Arnd had in his
> original mail: "The ACPI subsystem needs access to I/O ports, so that
> also gets a dependency."(
> https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> ).
And my point is that on ARM64 the ACPI subsystem does not need to
access IO ports.
It may not even need to access them on x86, but that depends on the
platform firmware in use.
If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
applies to ia64 too)?
> >
> > > we depend on HAS_IOPORT unconditionally.
> > >
> > > 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>
> > > ---
> > > drivers/acpi/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > index cdbdf68bd98f..b57f15817ede 100644
> > > --- a/drivers/acpi/Kconfig
> > > +++ b/drivers/acpi/Kconfig
> > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > menuconfig ACPI
> > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > depends on ARCH_SUPPORTS_ACPI
> > > + depends on HAS_IOPORT
> > > select PNP
> > > select NLS
> > > default y if X86
> > > --
> > > 2.32.0
> > >
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 17:12 ` Rafael J. Wysocki
0 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-27 17:12 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Rafael J. Wysocki, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Len Brown,
Linux Kernel Mailing List, linux-arch, Linux PCI, linux-riscv,
linux-csky, ACPI Devel Maling List
On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. As ACPI always uses I/O port access
> >
> > The ARM64 people may not agree with this.
>
> Maybe my wording is bad. This is my rewording of what Arnd had in his
> original mail: "The ACPI subsystem needs access to I/O ports, so that
> also gets a dependency."(
> https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> ).
And my point is that on ARM64 the ACPI subsystem does not need to
access IO ports.
It may not even need to access them on x86, but that depends on the
platform firmware in use.
If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
applies to ia64 too)?
> >
> > > we depend on HAS_IOPORT unconditionally.
> > >
> > > 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>
> > > ---
> > > drivers/acpi/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > index cdbdf68bd98f..b57f15817ede 100644
> > > --- a/drivers/acpi/Kconfig
> > > +++ b/drivers/acpi/Kconfig
> > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > menuconfig ACPI
> > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > depends on ARCH_SUPPORTS_ACPI
> > > + depends on HAS_IOPORT
> > > select PNP
> > > select NLS
> > > default y if X86
> > > --
> > > 2.32.0
> > >
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 17:12 ` Rafael J. Wysocki
@ 2021-12-27 17:15 ` Rafael J. Wysocki
-1 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-27 17:15 UTC (permalink / raw)
To: Rafael J. Wysocki, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >
> > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. As ACPI always uses I/O port access
> > >
> > > The ARM64 people may not agree with this.
> >
> > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > also gets a dependency."(
> > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > ).
>
> And my point is that on ARM64 the ACPI subsystem does not need to
> access IO ports.
>
> It may not even need to access them on x86, but that depends on the
> platform firmware in use.
>
> If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> applies to ia64 too)?
>
> > >
> > > > we depend on HAS_IOPORT unconditionally.
> > > >
> > > > 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>
> > > > ---
> > > > drivers/acpi/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > --- a/drivers/acpi/Kconfig
> > > > +++ b/drivers/acpi/Kconfig
> > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > menuconfig ACPI
> > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > depends on ARCH_SUPPORTS_ACPI
Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
> > > > + depends on HAS_IOPORT
> > > > select PNP
> > > > select NLS
> > > > default y if X86
> > > > --
> > > > 2.32.0
> > > >
> >
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 17:15 ` Rafael J. Wysocki
0 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-27 17:15 UTC (permalink / raw)
To: Rafael J. Wysocki, Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> >
> > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. As ACPI always uses I/O port access
> > >
> > > The ARM64 people may not agree with this.
> >
> > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > also gets a dependency."(
> > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > ).
>
> And my point is that on ARM64 the ACPI subsystem does not need to
> access IO ports.
>
> It may not even need to access them on x86, but that depends on the
> platform firmware in use.
>
> If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> applies to ia64 too)?
>
> > >
> > > > we depend on HAS_IOPORT unconditionally.
> > > >
> > > > 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>
> > > > ---
> > > > drivers/acpi/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > --- a/drivers/acpi/Kconfig
> > > > +++ b/drivers/acpi/Kconfig
> > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > menuconfig ACPI
> > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > depends on ARCH_SUPPORTS_ACPI
Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
> > > > + depends on HAS_IOPORT
> > > > select PNP
> > > > select NLS
> > > > default y if X86
> > > > --
> > > > 2.32.0
> > > >
> >
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 17:15 ` Rafael J. Wysocki
@ 2021-12-27 17:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 17:43 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > not being declared. As ACPI always uses I/O port access
> > > >
> > > > The ARM64 people may not agree with this.
> > >
> > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > also gets a dependency."(
> > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > ).
> >
> > And my point is that on ARM64 the ACPI subsystem does not need to
> > access IO ports.
> >
> > It may not even need to access them on x86, but that depends on the
> > platform firmware in use.
Well at least it does compile code calling outb() in
drivers/acpi/ec.c:acpi_ec_write_cmd(). Not sure if there is an
alternative path at runtime if there is then we might want to instead
use ifdefs to always use the non I/O port path if HAS_IOPORT is
undefined.
> >
> > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > applies to ia64 too)?
Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
all select HAS_IOPORT too. See patch 02 or the summary in the cover
letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
hexagon, csky, and xtensa do not select it.
> >
> > > > > we depend on HAS_IOPORT unconditionally.
> > > > >
> > > > > 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>
> > > > > ---
> > > > > drivers/acpi/Kconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > --- a/drivers/acpi/Kconfig
> > > > > +++ b/drivers/acpi/Kconfig
> > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > menuconfig ACPI
> > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > depends on ARCH_SUPPORTS_ACPI
>
> Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
If you prefer to have the dependency there that should work too yes.
>
> > > > > + depends on HAS_IOPORT
> > > > > select PNP
> > > > > select NLS
> > > > > default y if X86
> > > > > --
> > > > > 2.32.0
> > > > >
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 17:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 17:43 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > not being declared. As ACPI always uses I/O port access
> > > >
> > > > The ARM64 people may not agree with this.
> > >
> > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > also gets a dependency."(
> > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > ).
> >
> > And my point is that on ARM64 the ACPI subsystem does not need to
> > access IO ports.
> >
> > It may not even need to access them on x86, but that depends on the
> > platform firmware in use.
Well at least it does compile code calling outb() in
drivers/acpi/ec.c:acpi_ec_write_cmd(). Not sure if there is an
alternative path at runtime if there is then we might want to instead
use ifdefs to always use the non I/O port path if HAS_IOPORT is
undefined.
> >
> > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > applies to ia64 too)?
Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
all select HAS_IOPORT too. See patch 02 or the summary in the cover
letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
hexagon, csky, and xtensa do not select it.
> >
> > > > > we depend on HAS_IOPORT unconditionally.
> > > > >
> > > > > 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>
> > > > > ---
> > > > > drivers/acpi/Kconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > --- a/drivers/acpi/Kconfig
> > > > > +++ b/drivers/acpi/Kconfig
> > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > menuconfig ACPI
> > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > depends on ARCH_SUPPORTS_ACPI
>
> Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
If you prefer to have the dependency there that should work too yes.
>
> > > > > + depends on HAS_IOPORT
> > > > > select PNP
> > > > > select NLS
> > > > > default y if X86
> > > > > --
> > > > > 2.32.0
> > > > >
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-27 17:43 ` Niklas Schnelle
@ 2021-12-28 15:20 ` Rafael J. Wysocki
-1 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-28 15:20 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Rafael J. Wysocki, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Len Brown,
Linux Kernel Mailing List, linux-arch, Linux PCI, linux-riscv,
linux-csky, ACPI Devel Maling List
On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > > not being declared. As ACPI always uses I/O port access
> > > > >
> > > > > The ARM64 people may not agree with this.
> > > >
> > > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > > also gets a dependency."(
> > > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > > ).
> > >
> > > And my point is that on ARM64 the ACPI subsystem does not need to
> > > access IO ports.
> > >
> > > It may not even need to access them on x86, but that depends on the
> > > platform firmware in use.
>
> Well at least it does compile code calling outb() in
> drivers/acpi/ec.c:acpi_ec_write_cmd().
That's the EC driver which is not used on arm64 AFAICS and that driver
itself can be made depend on HAS_IOPORT.
> Not sure if there is an
> alternative path at runtime if there is then we might want to instead
> use ifdefs to always use the non I/O port path if HAS_IOPORT is
> undefined.
>
> > >
> > > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > > applies to ia64 too)?
>
> Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
> all select HAS_IOPORT too. See patch 02 or the summary in the cover
> letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
> hexagon, csky, and xtensa do not select it.
If that is the case, there should be no need to add the extra
dependency to CONFIG_ACPI.
> > >
> > > > > > we depend on HAS_IOPORT unconditionally.
> > > > > >
> > > > > > 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>
> > > > > > ---
> > > > > > drivers/acpi/Kconfig | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > > --- a/drivers/acpi/Kconfig
> > > > > > +++ b/drivers/acpi/Kconfig
> > > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > > menuconfig ACPI
> > > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > > depends on ARCH_SUPPORTS_ACPI
> >
> > Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
>
> If you prefer to have the dependency there that should work too yes.
I would prefer that.
IMO, if ARCH_SUPPORTS_ACPI is set, all of the requisite dependencies
should be met.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 15:20 ` Rafael J. Wysocki
0 siblings, 0 replies; 323+ messages in thread
From: Rafael J. Wysocki @ 2021-12-28 15:20 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Rafael J. Wysocki, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Len Brown,
Linux Kernel Mailing List, linux-arch, Linux PCI, linux-riscv,
linux-csky, ACPI Devel Maling List
On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > > not being declared. As ACPI always uses I/O port access
> > > > >
> > > > > The ARM64 people may not agree with this.
> > > >
> > > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > > also gets a dependency."(
> > > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > > ).
> > >
> > > And my point is that on ARM64 the ACPI subsystem does not need to
> > > access IO ports.
> > >
> > > It may not even need to access them on x86, but that depends on the
> > > platform firmware in use.
>
> Well at least it does compile code calling outb() in
> drivers/acpi/ec.c:acpi_ec_write_cmd().
That's the EC driver which is not used on arm64 AFAICS and that driver
itself can be made depend on HAS_IOPORT.
> Not sure if there is an
> alternative path at runtime if there is then we might want to instead
> use ifdefs to always use the non I/O port path if HAS_IOPORT is
> undefined.
>
> > >
> > > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > > applies to ia64 too)?
>
> Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
> all select HAS_IOPORT too. See patch 02 or the summary in the cover
> letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
> hexagon, csky, and xtensa do not select it.
If that is the case, there should be no need to add the extra
dependency to CONFIG_ACPI.
> > >
> > > > > > we depend on HAS_IOPORT unconditionally.
> > > > > >
> > > > > > 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>
> > > > > > ---
> > > > > > drivers/acpi/Kconfig | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > > --- a/drivers/acpi/Kconfig
> > > > > > +++ b/drivers/acpi/Kconfig
> > > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > > menuconfig ACPI
> > > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > > depends on ARCH_SUPPORTS_ACPI
> >
> > Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
>
> If you prefer to have the dependency there that should work too yes.
I would prefer that.
IMO, if ARCH_SUPPORTS_ACPI is set, all of the requisite dependencies
should be met.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
2021-12-28 15:20 ` Rafael J. Wysocki
@ 2021-12-28 16:31 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 16:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Tue, 2021-12-28 at 16:20 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > > > not being declared. As ACPI always uses I/O port access
> > > > > >
> > > > > > The ARM64 people may not agree with this.
> > > > >
> > > > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > > > also gets a dependency."(
> > > > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > > > ).
> > > >
> > > > And my point is that on ARM64 the ACPI subsystem does not need to
> > > > access IO ports.
> > > >
> > > > It may not even need to access them on x86, but that depends on the
> > > > platform firmware in use.
> >
> > Well at least it does compile code calling outb() in
> > drivers/acpi/ec.c:acpi_ec_write_cmd().
>
> That's the EC driver which is not used on arm64 AFAICS and that driver
> itself can be made depend on HAS_IOPORT.
Ah ok good to know.
Looking further there is also an inb_p() in
drivers/acpi/processor_idle.c:acpi_idle_bm_check(). That does look x86
specific though. There are a few more in the same file in
acpi_idle_do_entry() and acpi_idle_play_dead() they both look like
alternative mechanisms though interestingly one of the sites checks for
ACPI_CSTATE_SYSTEMIO while the other doesn't. Also it seems to me that
processor_idle.c is compiled when ACPI_PROCESSOR_IDLE is set which is
selected by ACPI_PROCESSOR which gets set for ARM64 as well.
Then there is a few more calls in drivers/acpi/osl.c which currently
gets compiled on all architectures as well.
I think we could ifdef all of these as it seems there are always
alternative paths. But I'm not sure if that makes sense if ACPI only
works on platforms with HAS_IOPORT anyway. From a cursory look it seems
even the not yet merged LoongArch would set HAS_IOPORT.
What do you think?
>
> > Not sure if there is an
> > alternative path at runtime if there is then we might want to instead
> > use ifdefs to always use the non I/O port path if HAS_IOPORT is
> > undefined.
> >
> > > > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > > > applies to ia64 too)?
> >
> > Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
> > all select HAS_IOPORT too. See patch 02 or the summary in the cover
> > letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
> > hexagon, csky, and xtensa do not select it.
>
> If that is the case, there should be no need to add the extra
> dependency to CONFIG_ACPI.
>
> > > > > > > we depend on HAS_IOPORT unconditionally.
> > > > > > >
> > > > > > > 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>
> > > > > > > ---
> > > > > > > drivers/acpi/Kconfig | 1 +
> > > > > > > 1 file changed, 1 insertion(+)
> > > > > > >
> > > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > > > --- a/drivers/acpi/Kconfig
> > > > > > > +++ b/drivers/acpi/Kconfig
> > > > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > > > menuconfig ACPI
> > > > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > > > depends on ARCH_SUPPORTS_ACPI
> > >
> > > Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
> >
> > If you prefer to have the dependency there that should work too yes.
>
> I would prefer that.
>
> IMO, if ARCH_SUPPORTS_ACPI is set, all of the requisite dependencies
> should be met.
I personally think it makes sense to have an explicit HAS_IOPORT
dependency even if it's already selected by all architectures setting
ARCH_SUPPORTS_ACPI adding it there as a dependency at the very least
documents its, currently unconditional, compile-time dependency.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 16:31 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 16:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Len Brown, Linux Kernel Mailing List, linux-arch, Linux PCI,
linux-riscv, linux-csky, ACPI Devel Maling List
On Tue, 2021-12-28 at 16:20 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > > > not being declared. As ACPI always uses I/O port access
> > > > > >
> > > > > > The ARM64 people may not agree with this.
> > > > >
> > > > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > > > also gets a dependency."(
> > > > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > > > ).
> > > >
> > > > And my point is that on ARM64 the ACPI subsystem does not need to
> > > > access IO ports.
> > > >
> > > > It may not even need to access them on x86, but that depends on the
> > > > platform firmware in use.
> >
> > Well at least it does compile code calling outb() in
> > drivers/acpi/ec.c:acpi_ec_write_cmd().
>
> That's the EC driver which is not used on arm64 AFAICS and that driver
> itself can be made depend on HAS_IOPORT.
Ah ok good to know.
Looking further there is also an inb_p() in
drivers/acpi/processor_idle.c:acpi_idle_bm_check(). That does look x86
specific though. There are a few more in the same file in
acpi_idle_do_entry() and acpi_idle_play_dead() they both look like
alternative mechanisms though interestingly one of the sites checks for
ACPI_CSTATE_SYSTEMIO while the other doesn't. Also it seems to me that
processor_idle.c is compiled when ACPI_PROCESSOR_IDLE is set which is
selected by ACPI_PROCESSOR which gets set for ARM64 as well.
Then there is a few more calls in drivers/acpi/osl.c which currently
gets compiled on all architectures as well.
I think we could ifdef all of these as it seems there are always
alternative paths. But I'm not sure if that makes sense if ACPI only
works on platforms with HAS_IOPORT anyway. From a cursory look it seems
even the not yet merged LoongArch would set HAS_IOPORT.
What do you think?
>
> > Not sure if there is an
> > alternative path at runtime if there is then we might want to instead
> > use ifdefs to always use the non I/O port path if HAS_IOPORT is
> > undefined.
> >
> > > > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > > > applies to ia64 too)?
> >
> > Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
> > all select HAS_IOPORT too. See patch 02 or the summary in the cover
> > letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
> > hexagon, csky, and xtensa do not select it.
>
> If that is the case, there should be no need to add the extra
> dependency to CONFIG_ACPI.
>
> > > > > > > we depend on HAS_IOPORT unconditionally.
> > > > > > >
> > > > > > > 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>
> > > > > > > ---
> > > > > > > drivers/acpi/Kconfig | 1 +
> > > > > > > 1 file changed, 1 insertion(+)
> > > > > > >
> > > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > > > --- a/drivers/acpi/Kconfig
> > > > > > > +++ b/drivers/acpi/Kconfig
> > > > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > > > menuconfig ACPI
> > > > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > > > depends on ARCH_SUPPORTS_ACPI
> > >
> > > Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
> >
> > If you prefer to have the dependency there that should work too yes.
>
> I would prefer that.
>
> IMO, if ARCH_SUPPORTS_ACPI is set, all of the requisite dependencies
> should be met.
I personally think it makes sense to have an explicit HAS_IOPORT
dependency even if it's already selected by all architectures setting
ARCH_SUPPORTS_ACPI adding it there as a dependency at the very least
documents its, currently unconditional, compile-time dependency.
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As PC style parport uses these functions we need to
handle this dependency for HAS_IOPORT.
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>
---
drivers/parport/Kconfig | 2 +-
include/linux/parport.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index e78a9f0302c7..d824f3069302 100644
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
menuconfig PARPORT
tristate "Parallel port support"
- depends on HAS_IOMEM
help
If you want to use devices connected to your machine's parallel port
(the connector at the computer with 25 holes), e.g. printer, ZIP
@@ -43,6 +42,7 @@ if PARPORT
config PARPORT_PC
tristate "PC-style hardware"
depends on ARCH_MIGHT_HAVE_PC_PARPORT
+ depends on HAS_IOPORT
help
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
diff --git a/include/linux/parport.h b/include/linux/parport.h
index 1c16ffb8b908..04ca5dc597a1 100644
--- a/include/linux/parport.h
+++ b/include/linux/parport.h
@@ -519,7 +519,7 @@ extern int parport_device_proc_register(struct pardevice *device);
extern int parport_device_proc_unregister(struct pardevice *device);
/* If PC hardware is the only type supported, we can optimise a bit. */
-#if !defined(CONFIG_PARPORT_NOT_PC)
+#if !defined(CONFIG_PARPORT_NOT_PC) && defined(CONFIG_PARPORT_PC)
#include <linux/parport_pc.h>
#define parport_write_data(p,x) parport_pc_write_data(p,x)
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As PC style parport uses these functions we need to
handle this dependency for HAS_IOPORT.
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>
---
drivers/parport/Kconfig | 2 +-
include/linux/parport.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index e78a9f0302c7..d824f3069302 100644
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
menuconfig PARPORT
tristate "Parallel port support"
- depends on HAS_IOMEM
help
If you want to use devices connected to your machine's parallel port
(the connector at the computer with 25 holes), e.g. printer, ZIP
@@ -43,6 +42,7 @@ if PARPORT
config PARPORT_PC
tristate "PC-style hardware"
depends on ARCH_MIGHT_HAVE_PC_PARPORT
+ depends on HAS_IOPORT
help
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
diff --git a/include/linux/parport.h b/include/linux/parport.h
index 1c16ffb8b908..04ca5dc597a1 100644
--- a/include/linux/parport.h
+++ b/include/linux/parport.h
@@ -519,7 +519,7 @@ extern int parport_device_proc_register(struct pardevice *device);
extern int parport_device_proc_unregister(struct pardevice *device);
/* If PC hardware is the only type supported, we can optimise a bit. */
-#if !defined(CONFIG_PARPORT_NOT_PC)
+#if !defined(CONFIG_PARPORT_NOT_PC) && defined(CONFIG_PARPORT_PC)
#include <linux/parport_pc.h>
#define parport_write_data(p,x) parport_pc_write_data(p,x)
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-28 10:14 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:14 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky
Hi Niklas,
On Mon, Dec 27, 2021 at 5:48 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. As PC style parport uses these functions we need to
> handle this dependency for HAS_IOPORT.
>
> 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/drivers/parport/Kconfig
> +++ b/drivers/parport/Kconfig
> @@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
>
> menuconfig PARPORT
> tristate "Parallel port support"
> - depends on HAS_IOMEM
Why drop this?
Don't all other parport drivers depend on it?
> help
> If you want to use devices connected to your machine's parallel port
> (the connector at the computer with 25 holes), e.g. printer, ZIP
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
@ 2021-12-28 10:14 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:14 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky
Hi Niklas,
On Mon, Dec 27, 2021 at 5:48 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. As PC style parport uses these functions we need to
> handle this dependency for HAS_IOPORT.
>
> 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/drivers/parport/Kconfig
> +++ b/drivers/parport/Kconfig
> @@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
>
> menuconfig PARPORT
> tristate "Parallel port support"
> - depends on HAS_IOMEM
Why drop this?
Don't all other parport drivers depend on it?
> help
> If you want to use devices connected to your machine's parallel port
> (the connector at the computer with 25 holes), e.g. printer, ZIP
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
2021-12-28 10:14 ` Geert Uytterhoeven
@ 2021-12-28 14:21 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 14:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky
On Tue, 2021-12-28 at 11:14 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:48 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As PC style parport uses these functions we need to
> > handle this dependency for HAS_IOPORT.
> >
> > 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/drivers/parport/Kconfig
> > +++ b/drivers/parport/Kconfig
> > @@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
> >
> > menuconfig PARPORT
> > tristate "Parallel port support"
> > - depends on HAS_IOMEM
>
> Why drop this?
> Don't all other parport drivers depend on it?
Seeing as the only platforms where HAS_IOMEM can even be unset are s390
and um you're probably right. Let's keep this.
>
> > help
> > If you want to use devices connected to your machine's parallel port
> > (the connector at the computer with 25 holes), e.g. printer, ZIP
>
> 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
@ 2021-12-28 14:21 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 14:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky
On Tue, 2021-12-28 at 11:14 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:48 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As PC style parport uses these functions we need to
> > handle this dependency for HAS_IOPORT.
> >
> > 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/drivers/parport/Kconfig
> > +++ b/drivers/parport/Kconfig
> > @@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
> >
> > menuconfig PARPORT
> > tristate "Parallel port support"
> > - depends on HAS_IOMEM
>
> Why drop this?
> Don't all other parport drivers depend on it?
Seeing as the only platforms where HAS_IOMEM can even be unset are s390
and um you're probably right. Let's keep this.
>
> > help
> > If you want to use devices connected to your machine's parallel port
> > (the connector at the computer with 25 holes), e.g. printer, ZIP
>
> 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
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
2021-12-28 10:14 ` Geert Uytterhoeven
@ 2021-12-29 2:58 ` Arnd Bergmann
-1 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 2:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Niklas Schnelle, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky
On Tue, Dec 28, 2021 at 5:14 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:48 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As PC style parport uses these functions we need to
> > handle this dependency for HAS_IOPORT.
> >
> > 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/drivers/parport/Kconfig
> > +++ b/drivers/parport/Kconfig
> > @@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
> >
> > menuconfig PARPORT
> > tristate "Parallel port support"
> > - depends on HAS_IOMEM
>
> Why drop this?
> Don't all other parport drivers depend on it?
The other drivers all have dependencies on specific platforms, so I
probably dropped it in the original draft because the remaining dependencies
are sufficient.
Technically, the partport_pc driver only needs HAS_IOPORT, not HAS_IOMEM,
but in the end this makes very little difference.
Arnd
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 04/32] parport: PC style parport depends on HAS_IOPORT
@ 2021-12-29 2:58 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-29 2:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Niklas Schnelle, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sudip Mukherjee, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky
On Tue, Dec 28, 2021 at 5:14 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:48 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As PC style parport uses these functions we need to
> > handle this dependency for HAS_IOPORT.
> >
> > 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/drivers/parport/Kconfig
> > +++ b/drivers/parport/Kconfig
> > @@ -14,7 +14,6 @@ config ARCH_MIGHT_HAVE_PC_PARPORT
> >
> > menuconfig PARPORT
> > tristate "Parallel port support"
> > - depends on HAS_IOMEM
>
> Why drop this?
> Don't all other parport drivers depend on it?
The other drivers all have dependencies on specific platforms, so I
probably dropped it in the original draft because the remaining dependencies
are sufficient.
Technically, the partport_pc driver only needs HAS_IOPORT, not HAS_IOMEM,
but in the end this makes very little difference.
Arnd
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 05/32] char: impi, tpm: depend on HAS_IOPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Jason Gunthorpe
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
openipmi-developer, linux-integrity
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add this dependency and ifdef
sections of code using inb()/outb() as alternative access methods.
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>
---
drivers/char/Kconfig | 3 ++-
drivers/char/ipmi/Makefile | 11 ++++-------
drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
drivers/char/ipmi/ipmi_si_pci.c | 3 +++
drivers/char/tpm/Kconfig | 1 +
drivers/char/tpm/tpm_infineon.c | 14 ++++++++++----
drivers/char/tpm/tpm_tis_core.c | 19 ++++++++-----------
7 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 740811893c57..3d046e364e53 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -33,6 +33,7 @@ config TTY_PRINTK_LEVEL
config PRINTER
tristate "Parallel printer support"
depends on PARPORT
+ depends on HAS_IOPORT
help
If you intend to attach a printer to the parallel port of your Linux
box (as opposed to using a serial printer; if the connector at the
@@ -346,7 +347,7 @@ config NVRAM
config DEVPORT
bool "/dev/port character device"
- depends on ISA || PCI
+ depends on HAS_IOPORT
default y
help
Say Y here if you want to support the /dev/port device. The /dev/port
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 7ce790efad92..439bed4feb3a 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -5,13 +5,10 @@
ipmi_si-y := ipmi_si_intf.o ipmi_kcs_sm.o ipmi_smic_sm.o ipmi_bt_sm.o \
ipmi_si_hotmod.o ipmi_si_hardcode.o ipmi_si_platform.o \
- ipmi_si_port_io.o ipmi_si_mem_io.o
-ifdef CONFIG_PCI
-ipmi_si-y += ipmi_si_pci.o
-endif
-ifdef CONFIG_PARISC
-ipmi_si-y += ipmi_si_parisc.o
-endif
+ ipmi_si_mem_io.o
+ipmi_si-$(CONFIG_HAS_IOPORT) += ipmi_si_port_io.o
+ipmi_si-$(CONFIG_PCI) += ipmi_si_pci.o
+ipmi_si-$(CONFIG_PARISC) += ipmi_si_parisc.o
obj-$(CONFIG_IPMI_HANDLER) += ipmi_msghandler.o
obj-$(CONFIG_IPMI_DEVICE_INTERFACE) += ipmi_devintf.o
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 64dedb3ef8ec..e8094b4007de 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1881,7 +1881,8 @@ int ipmi_si_add_smi(struct si_sm_io *io)
}
if (!io->io_setup) {
- if (io->addr_space == IPMI_IO_ADDR_SPACE) {
+ if (IS_ENABLED(CONFIG_HAS_IOPORT) &&
+ io->addr_space == IPMI_IO_ADDR_SPACE) {
io->io_setup = ipmi_si_port_setup;
} else if (io->addr_space == IPMI_MEM_ADDR_SPACE) {
io->io_setup = ipmi_si_mem_setup;
diff --git a/drivers/char/ipmi/ipmi_si_pci.c b/drivers/char/ipmi/ipmi_si_pci.c
index 74fa2055868b..b83d55685b22 100644
--- a/drivers/char/ipmi/ipmi_si_pci.c
+++ b/drivers/char/ipmi/ipmi_si_pci.c
@@ -97,6 +97,9 @@ static int ipmi_pci_probe(struct pci_dev *pdev,
}
if (pci_resource_flags(pdev, 0) & IORESOURCE_IO) {
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT))
+ return -ENXIO;
+
io.addr_space = IPMI_IO_ADDR_SPACE;
io.io_setup = ipmi_si_port_setup;
} else {
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 4a5516406c22..4bc52ed08015 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -137,6 +137,7 @@ config TCG_NSC
config TCG_ATMEL
tristate "Atmel TPM Interface"
depends on PPC64 || HAS_IOPORT_MAP
+ depends on HAS_IOPORT
help
If you have a TPM security chip from Atmel say Yes and it
will be accessible from within Linux. To compile this driver
diff --git a/drivers/char/tpm/tpm_infineon.c b/drivers/char/tpm/tpm_infineon.c
index 9c924a1440a9..2d2ae37153ba 100644
--- a/drivers/char/tpm/tpm_infineon.c
+++ b/drivers/char/tpm/tpm_infineon.c
@@ -51,34 +51,40 @@ static struct tpm_inf_dev tpm_dev;
static inline void tpm_data_out(unsigned char data, unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
outb(data, tpm_dev.data_regs + offset);
else
+#endif
writeb(data, tpm_dev.mem_base + tpm_dev.data_regs + offset);
}
static inline unsigned char tpm_data_in(unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
return inb(tpm_dev.data_regs + offset);
- else
- return readb(tpm_dev.mem_base + tpm_dev.data_regs + offset);
+#endif
+ return readb(tpm_dev.mem_base + tpm_dev.data_regs + offset);
}
static inline void tpm_config_out(unsigned char data, unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
outb(data, tpm_dev.config_port + offset);
else
+#endif
writeb(data, tpm_dev.mem_base + tpm_dev.index_off + offset);
}
static inline unsigned char tpm_config_in(unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
return inb(tpm_dev.config_port + offset);
- else
- return readb(tpm_dev.mem_base + tpm_dev.index_off + offset);
+#endif
+ return readb(tpm_dev.mem_base + tpm_dev.index_off + offset);
}
/* TPM header definitions */
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index b2659a4c4016..eb298e82861e 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -879,11 +879,6 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value)
clkrun_val &= ~LPC_CLKRUN_EN;
iowrite32(clkrun_val, data->ilb_base_addr + LPC_CNTRL_OFFSET);
- /*
- * Write any random value on port 0x80 which is on LPC, to make
- * sure LPC clock is running before sending any TPM command.
- */
- outb(0xCC, 0x80);
} else {
data->clkrun_enabled--;
if (data->clkrun_enabled)
@@ -894,13 +889,15 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value)
/* Enable LPC CLKRUN# */
clkrun_val |= LPC_CLKRUN_EN;
iowrite32(clkrun_val, data->ilb_base_addr + LPC_CNTRL_OFFSET);
-
- /*
- * Write any random value on port 0x80 which is on LPC, to make
- * sure LPC clock is running before sending any TPM command.
- */
- outb(0xCC, 0x80);
}
+
+#ifdef CONFIG_HAS_IOPORT
+ /*
+ * Write any random value on port 0x80 which is on LPC, to make
+ * sure LPC clock is running before sending any TPM command.
+ */
+ outb(0xCC, 0x80);
+#endif
}
static const struct tpm_class_ops tpm_tis = {
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 05/32] char: impi, tpm: depend on HAS_IOPORT
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Jason Gunthorpe
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
openipmi-developer, linux-integrity
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add this dependency and ifdef
sections of code using inb()/outb() as alternative access methods.
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>
---
drivers/char/Kconfig | 3 ++-
drivers/char/ipmi/Makefile | 11 ++++-------
drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
drivers/char/ipmi/ipmi_si_pci.c | 3 +++
drivers/char/tpm/Kconfig | 1 +
drivers/char/tpm/tpm_infineon.c | 14 ++++++++++----
drivers/char/tpm/tpm_tis_core.c | 19 ++++++++-----------
7 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 740811893c57..3d046e364e53 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -33,6 +33,7 @@ config TTY_PRINTK_LEVEL
config PRINTER
tristate "Parallel printer support"
depends on PARPORT
+ depends on HAS_IOPORT
help
If you intend to attach a printer to the parallel port of your Linux
box (as opposed to using a serial printer; if the connector at the
@@ -346,7 +347,7 @@ config NVRAM
config DEVPORT
bool "/dev/port character device"
- depends on ISA || PCI
+ depends on HAS_IOPORT
default y
help
Say Y here if you want to support the /dev/port device. The /dev/port
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 7ce790efad92..439bed4feb3a 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -5,13 +5,10 @@
ipmi_si-y := ipmi_si_intf.o ipmi_kcs_sm.o ipmi_smic_sm.o ipmi_bt_sm.o \
ipmi_si_hotmod.o ipmi_si_hardcode.o ipmi_si_platform.o \
- ipmi_si_port_io.o ipmi_si_mem_io.o
-ifdef CONFIG_PCI
-ipmi_si-y += ipmi_si_pci.o
-endif
-ifdef CONFIG_PARISC
-ipmi_si-y += ipmi_si_parisc.o
-endif
+ ipmi_si_mem_io.o
+ipmi_si-$(CONFIG_HAS_IOPORT) += ipmi_si_port_io.o
+ipmi_si-$(CONFIG_PCI) += ipmi_si_pci.o
+ipmi_si-$(CONFIG_PARISC) += ipmi_si_parisc.o
obj-$(CONFIG_IPMI_HANDLER) += ipmi_msghandler.o
obj-$(CONFIG_IPMI_DEVICE_INTERFACE) += ipmi_devintf.o
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 64dedb3ef8ec..e8094b4007de 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1881,7 +1881,8 @@ int ipmi_si_add_smi(struct si_sm_io *io)
}
if (!io->io_setup) {
- if (io->addr_space == IPMI_IO_ADDR_SPACE) {
+ if (IS_ENABLED(CONFIG_HAS_IOPORT) &&
+ io->addr_space == IPMI_IO_ADDR_SPACE) {
io->io_setup = ipmi_si_port_setup;
} else if (io->addr_space == IPMI_MEM_ADDR_SPACE) {
io->io_setup = ipmi_si_mem_setup;
diff --git a/drivers/char/ipmi/ipmi_si_pci.c b/drivers/char/ipmi/ipmi_si_pci.c
index 74fa2055868b..b83d55685b22 100644
--- a/drivers/char/ipmi/ipmi_si_pci.c
+++ b/drivers/char/ipmi/ipmi_si_pci.c
@@ -97,6 +97,9 @@ static int ipmi_pci_probe(struct pci_dev *pdev,
}
if (pci_resource_flags(pdev, 0) & IORESOURCE_IO) {
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT))
+ return -ENXIO;
+
io.addr_space = IPMI_IO_ADDR_SPACE;
io.io_setup = ipmi_si_port_setup;
} else {
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 4a5516406c22..4bc52ed08015 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -137,6 +137,7 @@ config TCG_NSC
config TCG_ATMEL
tristate "Atmel TPM Interface"
depends on PPC64 || HAS_IOPORT_MAP
+ depends on HAS_IOPORT
help
If you have a TPM security chip from Atmel say Yes and it
will be accessible from within Linux. To compile this driver
diff --git a/drivers/char/tpm/tpm_infineon.c b/drivers/char/tpm/tpm_infineon.c
index 9c924a1440a9..2d2ae37153ba 100644
--- a/drivers/char/tpm/tpm_infineon.c
+++ b/drivers/char/tpm/tpm_infineon.c
@@ -51,34 +51,40 @@ static struct tpm_inf_dev tpm_dev;
static inline void tpm_data_out(unsigned char data, unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
outb(data, tpm_dev.data_regs + offset);
else
+#endif
writeb(data, tpm_dev.mem_base + tpm_dev.data_regs + offset);
}
static inline unsigned char tpm_data_in(unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
return inb(tpm_dev.data_regs + offset);
- else
- return readb(tpm_dev.mem_base + tpm_dev.data_regs + offset);
+#endif
+ return readb(tpm_dev.mem_base + tpm_dev.data_regs + offset);
}
static inline void tpm_config_out(unsigned char data, unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
outb(data, tpm_dev.config_port + offset);
else
+#endif
writeb(data, tpm_dev.mem_base + tpm_dev.index_off + offset);
}
static inline unsigned char tpm_config_in(unsigned char offset)
{
+#ifdef CONFIG_HAS_IOPORT
if (tpm_dev.iotype == TPM_INF_IO_PORT)
return inb(tpm_dev.config_port + offset);
- else
- return readb(tpm_dev.mem_base + tpm_dev.index_off + offset);
+#endif
+ return readb(tpm_dev.mem_base + tpm_dev.index_off + offset);
}
/* TPM header definitions */
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index b2659a4c4016..eb298e82861e 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -879,11 +879,6 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value)
clkrun_val &= ~LPC_CLKRUN_EN;
iowrite32(clkrun_val, data->ilb_base_addr + LPC_CNTRL_OFFSET);
- /*
- * Write any random value on port 0x80 which is on LPC, to make
- * sure LPC clock is running before sending any TPM command.
- */
- outb(0xCC, 0x80);
} else {
data->clkrun_enabled--;
if (data->clkrun_enabled)
@@ -894,13 +889,15 @@ static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value)
/* Enable LPC CLKRUN# */
clkrun_val |= LPC_CLKRUN_EN;
iowrite32(clkrun_val, data->ilb_base_addr + LPC_CNTRL_OFFSET);
-
- /*
- * Write any random value on port 0x80 which is on LPC, to make
- * sure LPC clock is running before sending any TPM command.
- */
- outb(0xCC, 0x80);
}
+
+#ifdef CONFIG_HAS_IOPORT
+ /*
+ * Write any random value on port 0x80 which is on LPC, to make
+ * sure LPC clock is running before sending any TPM command.
+ */
+ outb(0xCC, 0x80);
+#endif
}
static const struct tpm_class_ops tpm_tis = {
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread* Re: [RFC 05/32] char: impi, tpm: depend on HAS_IOPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-28 10:17 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:17 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Jason Gunthorpe, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky,
openipmi-developer, linux-integrity
Hi Niklas,
Thanks for your patch!
On Mon, Dec 27, 2021 at 5:51 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add this dependency and ifdef
> sections of code using inb()/outb() as alternative access methods.
>
> 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>
> ---
> drivers/char/Kconfig | 3 ++-
Your oneline-summary doesn't cover this file.
> drivers/char/ipmi/Makefile | 11 ++++-------
> drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
> drivers/char/ipmi/ipmi_si_pci.c | 3 +++
> drivers/char/tpm/Kconfig | 1 +
> drivers/char/tpm/tpm_infineon.c | 14 ++++++++++----
> drivers/char/tpm/tpm_tis_core.c | 19 ++++++++-----------
> 7 files changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 740811893c57..3d046e364e53 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -33,6 +33,7 @@ config TTY_PRINTK_LEVEL
> config PRINTER
> tristate "Parallel printer support"
> depends on PARPORT
> + depends on HAS_IOPORT
Why? drivers/char/lp.c doesn't use I/O accessors, and should work with
all parport drivers.
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 05/32] char: impi, tpm: depend on HAS_IOPORT
@ 2021-12-28 10:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:17 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Jason Gunthorpe, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky,
openipmi-developer, linux-integrity
Hi Niklas,
Thanks for your patch!
On Mon, Dec 27, 2021 at 5:51 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add this dependency and ifdef
> sections of code using inb()/outb() as alternative access methods.
>
> 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>
> ---
> drivers/char/Kconfig | 3 ++-
Your oneline-summary doesn't cover this file.
> drivers/char/ipmi/Makefile | 11 ++++-------
> drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
> drivers/char/ipmi/ipmi_si_pci.c | 3 +++
> drivers/char/tpm/Kconfig | 1 +
> drivers/char/tpm/tpm_infineon.c | 14 ++++++++++----
> drivers/char/tpm/tpm_tis_core.c | 19 ++++++++-----------
> 7 files changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 740811893c57..3d046e364e53 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -33,6 +33,7 @@ config TTY_PRINTK_LEVEL
> config PRINTER
> tristate "Parallel printer support"
> depends on PARPORT
> + depends on HAS_IOPORT
Why? drivers/char/lp.c doesn't use I/O accessors, and should work with
all parport drivers.
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 05/32] char: impi, tpm: depend on HAS_IOPORT
2021-12-28 10:17 ` Geert Uytterhoeven
@ 2021-12-28 12:13 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 12:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Jason Gunthorpe, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky,
openipmi-developer, linux-integrity
On Tue, 2021-12-28 at 11:17 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> Thanks for your patch!
>
> On Mon, Dec 27, 2021 at 5:51 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add this dependency and ifdef
> > sections of code using inb()/outb() as alternative access methods.
> >
> > 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>
> > ---
> > drivers/char/Kconfig | 3 ++-
>
> Your oneline-summary doesn't cover this file.
Thanks, I guess then I should go with "char: depend on HAS_IOPORT"
>
> > drivers/char/ipmi/Makefile | 11 ++++-------
> > drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
> > drivers/char/ipmi/ipmi_si_pci.c | 3 +++
> > drivers/char/tpm/Kconfig | 1 +
> > drivers/char/tpm/tpm_infineon.c | 14 ++++++++++----
> > drivers/char/tpm/tpm_tis_core.c | 19 ++++++++-----------
> > 7 files changed, 30 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> > index 740811893c57..3d046e364e53 100644
> > --- a/drivers/char/Kconfig
> > +++ b/drivers/char/Kconfig
> > @@ -33,6 +33,7 @@ config TTY_PRINTK_LEVEL
> > config PRINTER
> > tristate "Parallel printer support"
> > depends on PARPORT
> > + depends on HAS_IOPORT
>
> Why? drivers/char/lp.c doesn't use I/O accessors, and should work with
> all parport drivers.
You're right that should work.
>
> 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 05/32] char: impi, tpm: depend on HAS_IOPORT
@ 2021-12-28 12:13 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 12:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Jason Gunthorpe, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky,
openipmi-developer, linux-integrity
On Tue, 2021-12-28 at 11:17 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> Thanks for your patch!
>
> On Mon, Dec 27, 2021 at 5:51 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add this dependency and ifdef
> > sections of code using inb()/outb() as alternative access methods.
> >
> > 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>
> > ---
> > drivers/char/Kconfig | 3 ++-
>
> Your oneline-summary doesn't cover this file.
Thanks, I guess then I should go with "char: depend on HAS_IOPORT"
>
> > drivers/char/ipmi/Makefile | 11 ++++-------
> > drivers/char/ipmi/ipmi_si_intf.c | 3 ++-
> > drivers/char/ipmi/ipmi_si_pci.c | 3 +++
> > drivers/char/tpm/Kconfig | 1 +
> > drivers/char/tpm/tpm_infineon.c | 14 ++++++++++----
> > drivers/char/tpm/tpm_tis_core.c | 19 ++++++++-----------
> > 7 files changed, 30 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> > index 740811893c57..3d046e364e53 100644
> > --- a/drivers/char/Kconfig
> > +++ b/drivers/char/Kconfig
> > @@ -33,6 +33,7 @@ config TTY_PRINTK_LEVEL
> > config PRINTER
> > tristate "Parallel printer support"
> > depends on PARPORT
> > + depends on HAS_IOPORT
>
> Why? drivers/char/lp.c doesn't use I/O accessors, and should work with
> all parport drivers.
You're right that should work.
>
> 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
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 06/32] speakup: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
William Hubbs, Chris Brannon, Kirk Reiser, Samuel Thibault
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
speakup
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. SPEAKUP_SERIALIO thus needs to depend on HAS_IOPORT.
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>
---
drivers/accessibility/speakup/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/accessibility/speakup/Kconfig b/drivers/accessibility/speakup/Kconfig
index 07ecbbde0384..e84fb617acc4 100644
--- a/drivers/accessibility/speakup/Kconfig
+++ b/drivers/accessibility/speakup/Kconfig
@@ -46,6 +46,7 @@ if SPEAKUP
config SPEAKUP_SERIALIO
def_bool y
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
config SPEAKUP_SYNTH_ACNTSA
tristate "Accent SA synthesizer support"
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 06/32] speakup: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
William Hubbs, Chris Brannon, Kirk Reiser, Samuel Thibault
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
speakup
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. SPEAKUP_SERIALIO thus needs to depend on HAS_IOPORT.
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>
---
drivers/accessibility/speakup/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/accessibility/speakup/Kconfig b/drivers/accessibility/speakup/Kconfig
index 07ecbbde0384..e84fb617acc4 100644
--- a/drivers/accessibility/speakup/Kconfig
+++ b/drivers/accessibility/speakup/Kconfig
@@ -46,6 +46,7 @@ if SPEAKUP
config SPEAKUP_SERIALIO
def_bool y
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
config SPEAKUP_SYNTH_ACNTSA
tristate "Accent SA synthesizer support"
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 06/32] speakup: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 17:52 ` Samuel Thibault
-1 siblings, 0 replies; 323+ messages in thread
From: Samuel Thibault @ 2021-12-27 17:52 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
William Hubbs, Chris Brannon, Kirk Reiser, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, speakup
Niklas Schnelle, le lun. 27 déc. 2021 17:42:51 +0100, a ecrit:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. SPEAKUP_SERIALIO thus needs to depend on HAS_IOPORT.
>
> 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>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ---
> drivers/accessibility/speakup/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/accessibility/speakup/Kconfig b/drivers/accessibility/speakup/Kconfig
> index 07ecbbde0384..e84fb617acc4 100644
> --- a/drivers/accessibility/speakup/Kconfig
> +++ b/drivers/accessibility/speakup/Kconfig
> @@ -46,6 +46,7 @@ if SPEAKUP
> config SPEAKUP_SERIALIO
> def_bool y
> depends on ISA || COMPILE_TEST
> + depends on HAS_IOPORT
>
> config SPEAKUP_SYNTH_ACNTSA
> tristate "Accent SA synthesizer support"
> --
> 2.32.0
>
--
Samuel
/* Amuse the user. */
printk(
" \\|/ ____ \\|/\n"
" \"@'/ ,. \\`@\"\n"
" /_| \\__/ |_\\\n"
" \\__U_/\n");
(From linux/arch/sparc/kernel/traps.c:die_if_kernel())
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 06/32] speakup: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 17:52 ` Samuel Thibault
0 siblings, 0 replies; 323+ messages in thread
From: Samuel Thibault @ 2021-12-27 17:52 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
William Hubbs, Chris Brannon, Kirk Reiser, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, speakup
Niklas Schnelle, le lun. 27 déc. 2021 17:42:51 +0100, a ecrit:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. SPEAKUP_SERIALIO thus needs to depend on HAS_IOPORT.
>
> 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>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ---
> drivers/accessibility/speakup/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/accessibility/speakup/Kconfig b/drivers/accessibility/speakup/Kconfig
> index 07ecbbde0384..e84fb617acc4 100644
> --- a/drivers/accessibility/speakup/Kconfig
> +++ b/drivers/accessibility/speakup/Kconfig
> @@ -46,6 +46,7 @@ if SPEAKUP
> config SPEAKUP_SERIALIO
> def_bool y
> depends on ISA || COMPILE_TEST
> + depends on HAS_IOPORT
>
> config SPEAKUP_SYNTH_ACNTSA
> tristate "Accent SA synthesizer support"
> --
> 2.32.0
>
--
Samuel
/* Amuse the user. */
printk(
" \\|/ ____ \\|/\n"
" \"@'/ ,. \\`@\"\n"
" /_| \\__/ |_\\\n"
" \\__U_/\n");
(From linux/arch/sparc/kernel/traps.c:die_if_kernel())
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 07/32] Input: gameport: add ISA and HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dmitry Torokhov
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-input
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As ISA already implies HAS_IOPORT we can simply add
this dependency and guard sections of code using inb()/outb() as
alternative access methods.
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>
---
drivers/input/gameport/Kconfig | 2 ++
include/linux/gameport.h | 9 +++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 082280f95333..366a2723e9a0 100644
--- a/drivers/input/gameport/Kconfig
+++ b/drivers/input/gameport/Kconfig
@@ -25,6 +25,7 @@ if GAMEPORT
config GAMEPORT_NS558
tristate "Classic ISA and PnP gameport support"
+ depends on ISA
help
Say Y here if you have an ISA or PnP gameport.
@@ -35,6 +36,7 @@ config GAMEPORT_NS558
config GAMEPORT_L4
tristate "PDPI Lightning 4 gamecard support"
+ depends on ISA
help
Say Y here if you have a PDPI Lightning 4 gamecard.
diff --git a/include/linux/gameport.h b/include/linux/gameport.h
index 69081d899492..9e55ac748a86 100644
--- a/include/linux/gameport.h
+++ b/include/linux/gameport.h
@@ -167,16 +167,21 @@ static inline void gameport_trigger(struct gameport *gameport)
{
if (gameport->trigger)
gameport->trigger(gameport);
+#ifdef CONFIG_HAS_IOPORT
else
outb(0xff, gameport->io);
+#endif
}
static inline unsigned char gameport_read(struct gameport *gameport)
{
if (gameport->read)
return gameport->read(gameport);
- else
- return inb(gameport->io);
+#ifdef CONFIG_HAS_IOPORT
+ return inb(gameport->io);
+#else
+ return 0xff;
+#endif
}
static inline int gameport_cooked_read(struct gameport *gameport, int *axes, int *buttons)
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 07/32] Input: gameport: add ISA and HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dmitry Torokhov
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-input
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As ISA already implies HAS_IOPORT we can simply add
this dependency and guard sections of code using inb()/outb() as
alternative access methods.
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>
---
drivers/input/gameport/Kconfig | 2 ++
include/linux/gameport.h | 9 +++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 082280f95333..366a2723e9a0 100644
--- a/drivers/input/gameport/Kconfig
+++ b/drivers/input/gameport/Kconfig
@@ -25,6 +25,7 @@ if GAMEPORT
config GAMEPORT_NS558
tristate "Classic ISA and PnP gameport support"
+ depends on ISA
help
Say Y here if you have an ISA or PnP gameport.
@@ -35,6 +36,7 @@ config GAMEPORT_NS558
config GAMEPORT_L4
tristate "PDPI Lightning 4 gamecard support"
+ depends on ISA
help
Say Y here if you have a PDPI Lightning 4 gamecard.
diff --git a/include/linux/gameport.h b/include/linux/gameport.h
index 69081d899492..9e55ac748a86 100644
--- a/include/linux/gameport.h
+++ b/include/linux/gameport.h
@@ -167,16 +167,21 @@ static inline void gameport_trigger(struct gameport *gameport)
{
if (gameport->trigger)
gameport->trigger(gameport);
+#ifdef CONFIG_HAS_IOPORT
else
outb(0xff, gameport->io);
+#endif
}
static inline unsigned char gameport_read(struct gameport *gameport)
{
if (gameport->read)
return gameport->read(gameport);
- else
- return inb(gameport->io);
+#ifdef CONFIG_HAS_IOPORT
+ return inb(gameport->io);
+#else
+ return 0xff;
+#endif
}
static inline int gameport_cooked_read(struct gameport *gameport, int *axes, int *buttons)
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 08/32] comedi: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Ian Abbott, H Hartley Sweeten
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/comedi/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 1b642716c5d3..f5b8869df781 100644
--- a/drivers/comedi/Kconfig
+++ b/drivers/comedi/Kconfig
@@ -67,6 +67,7 @@ config COMEDI_TEST
config COMEDI_PARPORT
tristate "Parallel port support"
+ depends on HAS_IOPORT
help
Enable support for the standard parallel port.
A cheap and easy way to get a few more digital I/O lines. Steal
@@ -79,6 +80,7 @@ config COMEDI_PARPORT
config COMEDI_SSV_DNP
tristate "SSV Embedded Systems DIL/Net-PC support"
depends on X86_32 || COMPILE_TEST
+ depends on HAS_IOPORT
help
Enable support for SSV Embedded Systems DIL/Net-PC
@@ -89,6 +91,7 @@ endif # COMEDI_MISC_DRIVERS
menuconfig COMEDI_ISA_DRIVERS
bool "Comedi ISA and PC/104 drivers"
+ depends on ISA
help
Enable comedi ISA and PC/104 drivers to be built
@@ -1095,6 +1098,7 @@ config COMEDI_NI_PCIMIO
tristate "NI PCI-MIO-E series and M series support"
depends on LEGACY_PCI
depends on HAS_DMA
+ depends on LEGACY_PCI
select COMEDI_NI_TIOCMD
select COMEDI_8255
help
@@ -1116,6 +1120,7 @@ config COMEDI_NI_PCIMIO
config COMEDI_RTD520
tristate "Real Time Devices PCI4520/DM7520 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Real Time Devices PCI4520/DM7520
@@ -1184,6 +1189,7 @@ config COMEDI_NI_DAQ_700_CS
config COMEDI_NI_DAQ_DIO24_CS
tristate "NI DAQ-Card DIO-24 PCMCIA support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for the National Instruments PCMCIA DAQ-Card DIO-24
@@ -1202,6 +1208,7 @@ config COMEDI_NI_LABPC_CS
config COMEDI_NI_MIO_CS
tristate "NI DAQCard E series PCMCIA support"
+ depends on LEGACY_PCI
select COMEDI_NI_TIO
select COMEDI_8255
help
@@ -1296,6 +1303,7 @@ config COMEDI_8255
config COMEDI_8255_SA
tristate "Standalone 8255 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for 8255 digital I/O as a standalone driver.
@@ -1332,10 +1340,12 @@ config COMEDI_AMPLC_DIO200
config COMEDI_AMPLC_PC236
tristate
+ depends on HAS_IOPORT
select COMEDI_8255
config COMEDI_DAS08
tristate
+ depends on HAS_IOPORT
select COMEDI_8254
select COMEDI_8255
@@ -1344,6 +1354,7 @@ config COMEDI_ISADMA
config COMEDI_NI_LABPC
tristate
+ depends on HAS_IOPORT
select COMEDI_8254
select COMEDI_8255
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 08/32] comedi: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Ian Abbott, H Hartley Sweeten
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/comedi/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 1b642716c5d3..f5b8869df781 100644
--- a/drivers/comedi/Kconfig
+++ b/drivers/comedi/Kconfig
@@ -67,6 +67,7 @@ config COMEDI_TEST
config COMEDI_PARPORT
tristate "Parallel port support"
+ depends on HAS_IOPORT
help
Enable support for the standard parallel port.
A cheap and easy way to get a few more digital I/O lines. Steal
@@ -79,6 +80,7 @@ config COMEDI_PARPORT
config COMEDI_SSV_DNP
tristate "SSV Embedded Systems DIL/Net-PC support"
depends on X86_32 || COMPILE_TEST
+ depends on HAS_IOPORT
help
Enable support for SSV Embedded Systems DIL/Net-PC
@@ -89,6 +91,7 @@ endif # COMEDI_MISC_DRIVERS
menuconfig COMEDI_ISA_DRIVERS
bool "Comedi ISA and PC/104 drivers"
+ depends on ISA
help
Enable comedi ISA and PC/104 drivers to be built
@@ -1095,6 +1098,7 @@ config COMEDI_NI_PCIMIO
tristate "NI PCI-MIO-E series and M series support"
depends on LEGACY_PCI
depends on HAS_DMA
+ depends on LEGACY_PCI
select COMEDI_NI_TIOCMD
select COMEDI_8255
help
@@ -1116,6 +1120,7 @@ config COMEDI_NI_PCIMIO
config COMEDI_RTD520
tristate "Real Time Devices PCI4520/DM7520 support"
+ depends on LEGACY_PCI
select COMEDI_8254
help
Enable support for Real Time Devices PCI4520/DM7520
@@ -1184,6 +1189,7 @@ config COMEDI_NI_DAQ_700_CS
config COMEDI_NI_DAQ_DIO24_CS
tristate "NI DAQ-Card DIO-24 PCMCIA support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for the National Instruments PCMCIA DAQ-Card DIO-24
@@ -1202,6 +1208,7 @@ config COMEDI_NI_LABPC_CS
config COMEDI_NI_MIO_CS
tristate "NI DAQCard E series PCMCIA support"
+ depends on LEGACY_PCI
select COMEDI_NI_TIO
select COMEDI_8255
help
@@ -1296,6 +1303,7 @@ config COMEDI_8255
config COMEDI_8255_SA
tristate "Standalone 8255 support"
+ depends on LEGACY_PCI
select COMEDI_8255
help
Enable support for 8255 digital I/O as a standalone driver.
@@ -1332,10 +1340,12 @@ config COMEDI_AMPLC_DIO200
config COMEDI_AMPLC_PC236
tristate
+ depends on HAS_IOPORT
select COMEDI_8255
config COMEDI_DAS08
tristate
+ depends on HAS_IOPORT
select COMEDI_8254
select COMEDI_8255
@@ -1344,6 +1354,7 @@ config COMEDI_ISADMA
config COMEDI_NI_LABPC
tristate
+ depends on HAS_IOPORT
select COMEDI_8254
select COMEDI_8255
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 09/32] sound: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
(?)
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jaroslav Kysela, Takashi Iwai
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
alsa-devel
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
sound/drivers/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4b5ba916d93e 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -128,6 +128,7 @@ config SND_VIRMIDI
config SND_MTPAV
tristate "MOTU MidiTimePiece AV multiport MIDI"
+ depends on HAS_IOPORT
select SND_RAWMIDI
help
To use a MOTU MidiTimePiece AV multiport MIDI adapter
@@ -152,6 +153,7 @@ config SND_MTS64
config SND_SERIAL_U16550
tristate "UART16550 serial MIDI driver"
+ depends on HAS_IOPORT
select SND_RAWMIDI
help
To include support for MIDI serial port interfaces, say Y here
@@ -167,6 +169,7 @@ config SND_SERIAL_U16550
config SND_MPU401
tristate "Generic MPU-401 UART driver"
+ depends on HAS_IOPORT
select SND_MPU401_UART
help
Say Y here to include support for MIDI ports compatible with
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 09/32] sound: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arch, alsa-devel, linux-pci, linux-kernel, linux-csky,
linux-riscv
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
sound/drivers/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4b5ba916d93e 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -128,6 +128,7 @@ config SND_VIRMIDI
config SND_MTPAV
tristate "MOTU MidiTimePiece AV multiport MIDI"
+ depends on HAS_IOPORT
select SND_RAWMIDI
help
To use a MOTU MidiTimePiece AV multiport MIDI adapter
@@ -152,6 +153,7 @@ config SND_MTS64
config SND_SERIAL_U16550
tristate "UART16550 serial MIDI driver"
+ depends on HAS_IOPORT
select SND_RAWMIDI
help
To include support for MIDI serial port interfaces, say Y here
@@ -167,6 +169,7 @@ config SND_SERIAL_U16550
config SND_MPU401
tristate "Generic MPU-401 UART driver"
+ depends on HAS_IOPORT
select SND_MPU401_UART
help
Say Y here to include support for MIDI ports compatible with
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 09/32] sound: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jaroslav Kysela, Takashi Iwai
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
alsa-devel
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
sound/drivers/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4b5ba916d93e 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -128,6 +128,7 @@ config SND_VIRMIDI
config SND_MTPAV
tristate "MOTU MidiTimePiece AV multiport MIDI"
+ depends on HAS_IOPORT
select SND_RAWMIDI
help
To use a MOTU MidiTimePiece AV multiport MIDI adapter
@@ -152,6 +153,7 @@ config SND_MTS64
config SND_SERIAL_U16550
tristate "UART16550 serial MIDI driver"
+ depends on HAS_IOPORT
select SND_RAWMIDI
help
To include support for MIDI serial port interfaces, say Y here
@@ -167,6 +169,7 @@ config SND_SERIAL_U16550
config SND_MPU401
tristate "Generic MPU-401 UART driver"
+ depends on HAS_IOPORT
select SND_MPU401_UART
help
Say Y here to include support for MIDI ports compatible with
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-i2c
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/i2c/busses/Kconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a8d6274dc965..55403018784a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -175,7 +175,7 @@ config I2C_ISMT
config I2C_PIIX4
tristate "Intel PIIX4 and compatible (ATI/AMD/Serverworks/Broadcom/SMSC)"
- depends on PCI
+ depends on PCI && HAS_IOPORT
help
If you say yes to this option, support will be included for the Intel
PIIX4 family of mainboard I2C interfaces. Specifically, the following
@@ -828,6 +828,7 @@ config I2C_NPCM7XX
config I2C_OCORES
tristate "OpenCores I2C Controller"
+ depends on HAS_IOPORT
help
If you say yes to this option, support will be included for the
OpenCores I2C controller. For details see
@@ -1227,6 +1228,7 @@ config I2C_CP2615
config I2C_PARPORT
tristate "Parallel port adapter"
depends on PARPORT
+ depends on HAS_IOPORT
select I2C_ALGOBIT
select I2C_SMBUS
help
@@ -1325,6 +1327,7 @@ config I2C_ICY
config I2C_MLXCPLD
tristate "Mellanox I2C driver"
depends on X86_64 || COMPILE_TEST
+ depends on HAS_IOPORT
help
This exposes the Mellanox platform I2C busses to the linux I2C layer
for X86 based systems.
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-i2c
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/i2c/busses/Kconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a8d6274dc965..55403018784a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -175,7 +175,7 @@ config I2C_ISMT
config I2C_PIIX4
tristate "Intel PIIX4 and compatible (ATI/AMD/Serverworks/Broadcom/SMSC)"
- depends on PCI
+ depends on PCI && HAS_IOPORT
help
If you say yes to this option, support will be included for the Intel
PIIX4 family of mainboard I2C interfaces. Specifically, the following
@@ -828,6 +828,7 @@ config I2C_NPCM7XX
config I2C_OCORES
tristate "OpenCores I2C Controller"
+ depends on HAS_IOPORT
help
If you say yes to this option, support will be included for the
OpenCores I2C controller. For details see
@@ -1227,6 +1228,7 @@ config I2C_CP2615
config I2C_PARPORT
tristate "Parallel port adapter"
depends on PARPORT
+ depends on HAS_IOPORT
select I2C_ALGOBIT
select I2C_SMBUS
help
@@ -1325,6 +1327,7 @@ config I2C_ICY
config I2C_MLXCPLD
tristate "Mellanox I2C driver"
depends on X86_64 || COMPILE_TEST
+ depends on HAS_IOPORT
help
This exposes the Mellanox platform I2C busses to the linux I2C layer
for X86 based systems.
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-28 10:21 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:21 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, Linux I2C
Hi Niklas,
On Mon, Dec 27, 2021 at 5:49 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -828,6 +828,7 @@ config I2C_NPCM7XX
>
> config I2C_OCORES
> tristate "OpenCores I2C Controller"
> + depends on HAS_IOPORT
While drivers/i2c/busses/i2c-ocores.c does use {in,out}(), I doubt this
is used to access legacy I/O space.
> help
> If you say yes to this option, support will be included for the
> OpenCores I2C controller. For details see
> @@ -1227,6 +1228,7 @@ config I2C_CP2615
> config I2C_PARPORT
> tristate "Parallel port adapter"
> depends on PARPORT
> + depends on HAS_IOPORT
Same as PRINTER: shouldn't this work with all parport drivers?
> select I2C_ALGOBIT
> select I2C_SMBUS
> help
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 10:21 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:21 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, Linux I2C
Hi Niklas,
On Mon, Dec 27, 2021 at 5:49 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -828,6 +828,7 @@ config I2C_NPCM7XX
>
> config I2C_OCORES
> tristate "OpenCores I2C Controller"
> + depends on HAS_IOPORT
While drivers/i2c/busses/i2c-ocores.c does use {in,out}(), I doubt this
is used to access legacy I/O space.
> help
> If you say yes to this option, support will be included for the
> OpenCores I2C controller. For details see
> @@ -1227,6 +1228,7 @@ config I2C_CP2615
> config I2C_PARPORT
> tristate "Parallel port adapter"
> depends on PARPORT
> + depends on HAS_IOPORT
Same as PRINTER: shouldn't this work with all parport drivers?
> select I2C_ALGOBIT
> select I2C_SMBUS
> help
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
2021-12-28 10:21 ` Geert Uytterhoeven
@ 2021-12-28 12:13 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 12:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, Linux I2C
On Tue, 2021-12-28 at 11:21 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:49 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
> > 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/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -828,6 +828,7 @@ config I2C_NPCM7XX
> >
> > config I2C_OCORES
> > tristate "OpenCores I2C Controller"
> > + depends on HAS_IOPORT
>
> While drivers/i2c/busses/i2c-ocores.c does use {in,out}(), I doubt this
> is used to access legacy I/O space.
Hmm, it does use i2c->iobase for inb()/outb() but i2c->base for
ioreadXY()/iowriteXY(). And as it gets i2c->iobase from
platform_get_resource(pdev, IORESOURCE_IO, 0) I'd think that is an I/O
resource/space. It does look like some kind of fallback path though,
the IORESOURCE_IO is only looked at if accessing an IORESOURCE_MEM
fails so maybe that should instead be ifdeffed.
>
> > help
> > If you say yes to this option, support will be included for the
> > OpenCores I2C controller. For details see
> > @@ -1227,6 +1228,7 @@ config I2C_CP2615
> > config I2C_PARPORT
> > tristate "Parallel port adapter"
> > depends on PARPORT
> > + depends on HAS_IOPORT
>
> Same as PRINTER: shouldn't this work with all parport drivers?
Agree, will drop.
>
> > select I2C_ALGOBIT
> > select I2C_SMBUS
> > help
>
> 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 12:13 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 12:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, Linux I2C
On Tue, 2021-12-28 at 11:21 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:49 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
> > 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/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -828,6 +828,7 @@ config I2C_NPCM7XX
> >
> > config I2C_OCORES
> > tristate "OpenCores I2C Controller"
> > + depends on HAS_IOPORT
>
> While drivers/i2c/busses/i2c-ocores.c does use {in,out}(), I doubt this
> is used to access legacy I/O space.
Hmm, it does use i2c->iobase for inb()/outb() but i2c->base for
ioreadXY()/iowriteXY(). And as it gets i2c->iobase from
platform_get_resource(pdev, IORESOURCE_IO, 0) I'd think that is an I/O
resource/space. It does look like some kind of fallback path though,
the IORESOURCE_IO is only looked at if accessing an IORESOURCE_MEM
fails so maybe that should instead be ifdeffed.
>
> > help
> > If you say yes to this option, support will be included for the
> > OpenCores I2C controller. For details see
> > @@ -1227,6 +1228,7 @@ config I2C_CP2615
> > config I2C_PARPORT
> > tristate "Parallel port adapter"
> > depends on PARPORT
> > + depends on HAS_IOPORT
>
> Same as PRINTER: shouldn't this work with all parport drivers?
Agree, will drop.
>
> > select I2C_ALGOBIT
> > select I2C_SMBUS
> > help
>
> 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
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dmitry Torokhov
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-input
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/input/serio/Kconfig | 2 ++
drivers/input/touchscreen/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index f39b7b3f7942..5d125627c595 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -75,6 +75,7 @@ config SERIO_Q40KBD
config SERIO_PARKBD
tristate "Parallel port keyboard adapter"
depends on PARPORT
+ depends on HAS_IOPORT
help
Say Y here if you built a simple parallel port adapter to attach
an additional AT keyboard, XT keyboard or PS/2 mouse.
@@ -148,6 +149,7 @@ config HIL_MLC
config SERIO_PCIPS2
tristate "PCI PS/2 keyboard and PS/2 mouse controller"
depends on PCI
+ depends on HAS_IOPORT
help
Say Y here if you have a Mobility Docking station with PS/2
keyboard and mice ports.
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 2f6adfb7b938..a77663b79aec 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -664,6 +664,7 @@ config TOUCHSCREEN_INEXIO
config TOUCHSCREEN_MK712
tristate "ICS MicroClock MK712 touchscreen"
+ depends on ISA
help
Say Y here if you have the ICS MicroClock MK712 touchscreen
controller chip in your system.
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dmitry Torokhov
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-input
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/input/serio/Kconfig | 2 ++
drivers/input/touchscreen/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index f39b7b3f7942..5d125627c595 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -75,6 +75,7 @@ config SERIO_Q40KBD
config SERIO_PARKBD
tristate "Parallel port keyboard adapter"
depends on PARPORT
+ depends on HAS_IOPORT
help
Say Y here if you built a simple parallel port adapter to attach
an additional AT keyboard, XT keyboard or PS/2 mouse.
@@ -148,6 +149,7 @@ config HIL_MLC
config SERIO_PCIPS2
tristate "PCI PS/2 keyboard and PS/2 mouse controller"
depends on PCI
+ depends on HAS_IOPORT
help
Say Y here if you have a Mobility Docking station with PS/2
keyboard and mice ports.
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 2f6adfb7b938..a77663b79aec 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -664,6 +664,7 @@ config TOUCHSCREEN_INEXIO
config TOUCHSCREEN_MK712
tristate "ICS MicroClock MK712 touchscreen"
+ depends on ISA
help
Say Y here if you have the ICS MicroClock MK712 touchscreen
controller chip in your system.
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-28 10:23 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:23 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dmitry Torokhov, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky, linux-input
Hi Niklas,
On Mon, Dec 27, 2021 at 5:50 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -75,6 +75,7 @@ config SERIO_Q40KBD
> config SERIO_PARKBD
> tristate "Parallel port keyboard adapter"
> depends on PARPORT
> + depends on HAS_IOPORT
Same as PRINTER: shouldn't this work with all parport drivers?
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 10:23 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:23 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dmitry Torokhov, Linux Kernel Mailing List, Linux-Arch, linux-pci,
linux-riscv, linux-csky, linux-input
Hi Niklas,
On Mon, Dec 27, 2021 at 5:50 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -75,6 +75,7 @@ config SERIO_Q40KBD
> config SERIO_PARKBD
> tristate "Parallel port keyboard adapter"
> depends on PARPORT
> + depends on HAS_IOPORT
Same as PRINTER: shouldn't this work with all parport drivers?
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jonathan Cameron, Lars-Peter Clausen
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-iio
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/iio/adc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 3363af15a43f..1338ce51c0c5 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -119,7 +119,7 @@ config AD7606
config AD7606_IFACE_PARALLEL
tristate "Analog Devices AD7606 ADC driver with parallel interface support"
- depends on HAS_IOMEM
+ depends on HAS_IOPORT
select AD7606
help
Say yes here to build parallel interface support for Analog Devices:
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jonathan Cameron, Lars-Peter Clausen
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-iio
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/iio/adc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 3363af15a43f..1338ce51c0c5 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -119,7 +119,7 @@ config AD7606
config AD7606_IFACE_PARALLEL
tristate "Analog Devices AD7606 ADC driver with parallel interface support"
- depends on HAS_IOMEM
+ depends on HAS_IOPORT
select AD7606
help
Say yes here to build parallel interface support for Analog Devices:
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-28 10:32 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky, linux-iio
Hi Niklas,
On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -119,7 +119,7 @@ config AD7606
>
> config AD7606_IFACE_PARALLEL
> tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> - depends on HAS_IOMEM
> + depends on HAS_IOPORT
While this driver uses ins[bw](), this seems unrelated to legacy
I/O space, as the driver maps a MMIO region. Probably different
accessors should be used instead.
Note that this driver has no in-tree users. Same for the SPI variant,
but at least that one has modern json-schema DT bindings ;-)
> select AD7606
> help
> Say yes here to build parallel interface support for Analog Devices:
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 10:32 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:32 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky, linux-iio
Hi Niklas,
On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -119,7 +119,7 @@ config AD7606
>
> config AD7606_IFACE_PARALLEL
> tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> - depends on HAS_IOMEM
> + depends on HAS_IOPORT
While this driver uses ins[bw](), this seems unrelated to legacy
I/O space, as the driver maps a MMIO region. Probably different
accessors should be used instead.
Note that this driver has no in-tree users. Same for the SPI variant,
but at least that one has modern json-schema DT bindings ;-)
> select AD7606
> help
> Say yes here to build parallel interface support for Analog Devices:
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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
2021-12-28 10:32 ` Geert Uytterhoeven
@ 2021-12-28 12:50 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 12:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky, linux-iio
On Tue, 2021-12-28 at 11:32 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
> > 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/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -119,7 +119,7 @@ config AD7606
> >
> > config AD7606_IFACE_PARALLEL
> > tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> > - depends on HAS_IOMEM
> > + depends on HAS_IOPORT
>
> While this driver uses ins[bw](), this seems unrelated to legacy
> I/O space, as the driver maps a MMIO region. Probably different
> accessors should be used instead.
You're right on first glance it looks like a misuse of the ins[bw]()
accessors. I do wonder how that even works, if PCI_IOBASE is 0 it would
result in readsw()/readsb() with presumably the correct address but no
idea how this interacts witth x86's special I/O instructions.
>
> Note that this driver has no in-tree users. Same for the SPI variant,
> but at least that one has modern json-schema DT bindings ;-)
Can't find any mention in the MAINTAINERS file either.
>
> > select AD7606
> > help
> > Say yes here to build parallel interface support for Analog Devices:
>
> 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 12:50 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 12:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux-Arch, linux-pci, linux-riscv, linux-csky, linux-iio
On Tue, 2021-12-28 at 11:32 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
> > 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/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -119,7 +119,7 @@ config AD7606
> >
> > config AD7606_IFACE_PARALLEL
> > tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> > - depends on HAS_IOMEM
> > + depends on HAS_IOPORT
>
> While this driver uses ins[bw](), this seems unrelated to legacy
> I/O space, as the driver maps a MMIO region. Probably different
> accessors should be used instead.
You're right on first glance it looks like a misuse of the ins[bw]()
accessors. I do wonder how that even works, if PCI_IOBASE is 0 it would
result in readsw()/readsb() with presumably the correct address but no
idea how this interacts witth x86's special I/O instructions.
>
> Note that this driver has no in-tree users. Same for the SPI variant,
> but at least that one has modern json-schema DT bindings ;-)
Can't find any mention in the MAINTAINERS file either.
>
> > select AD7606
> > help
> > Say yes here to build parallel interface support for Analog Devices:
>
> 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
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
2021-12-28 12:50 ` Niklas Schnelle
@ 2021-12-28 17:01 ` Jonathan Cameron
-1 siblings, 0 replies; 323+ messages in thread
From: Jonathan Cameron @ 2021-12-28 17:01 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Geert Uytterhoeven, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Lars-Peter Clausen,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, linux-iio, Michael Hennerich
On Tue, 28 Dec 2021 13:50:20 +0100
Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> On Tue, 2021-12-28 at 11:32 +0100, Geert Uytterhoeven wrote:
> > Hi Niklas,
> >
> > On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. We thus need to add HAS_IOPORT as dependency for
> > > those drivers using them.
> > >
> > > 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>
As a side note, whilst it doesn't always happen and I regularly forget
to fix it up whilst applying, it's really helpful to make sure the driver
name is somewhere in the patch title.
e.g. iio: adc: ad7606: add HAS_IOPORT dependencies.
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/iio/adc/Kconfig
> > > +++ b/drivers/iio/adc/Kconfig
> > > @@ -119,7 +119,7 @@ config AD7606
> > >
> > > config AD7606_IFACE_PARALLEL
> > > tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> > > - depends on HAS_IOMEM
> > > + depends on HAS_IOPORT
> >
> > While this driver uses ins[bw](), this seems unrelated to legacy
> > I/O space, as the driver maps a MMIO region. Probably different
> > accessors should be used instead.
>
> You're right on first glance it looks like a misuse of the ins[bw]()
> accessors. I do wonder how that even works, if PCI_IOBASE is 0 it would
> result in readsw()/readsb() with presumably the correct address but no
> idea how this interacts witth x86's special I/O instructions.
>
> >
> > Note that this driver has no in-tree users. Same for the SPI variant,
> > but at least that one has modern json-schema DT bindings ;-)
>
> Can't find any mention in the MAINTAINERS file either.
It falls under the Analog devices catch all.
We don't list them all individually because there are a lot of them and
it would just be noise in many case.
Added Michael to CC. You already have Lars.
ANALOG DEVICES INC IIO DRIVERS
M: Lars-Peter Clausen <lars@metafoo.de>
M: Michael Hennerich <Michael.Hennerich@analog.com>
S: Supported
W: http://wiki.analog.com/
W: http://ez.analog.com/community/linux-device-drivers
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
F: Documentation/devicetree/bindings/iio/*/adi,*
F: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
F: drivers/iio/*/ad*
F: drivers/iio/adc/ltc249*
F: drivers/iio/amplifiers/hmc425a.c
F: drivers/staging/iio/*/ad*
X: drivers/iio/*/adjd*
https://wiki.analog.com/resources/tools-software/linux-drivers/iio-adc/ad7606
includes some details.
I'll leave it to the Lars or Michael to confirm what is going on here.
Jonathan
>
> >
> > > select AD7606
> > > help
> > > Say yes here to build parallel interface support for Analog Devices:
> >
> > 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
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 17:01 ` Jonathan Cameron
0 siblings, 0 replies; 323+ messages in thread
From: Jonathan Cameron @ 2021-12-28 17:01 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Geert Uytterhoeven, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Lars-Peter Clausen,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, linux-iio, Michael Hennerich
On Tue, 28 Dec 2021 13:50:20 +0100
Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> On Tue, 2021-12-28 at 11:32 +0100, Geert Uytterhoeven wrote:
> > Hi Niklas,
> >
> > On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. We thus need to add HAS_IOPORT as dependency for
> > > those drivers using them.
> > >
> > > 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>
As a side note, whilst it doesn't always happen and I regularly forget
to fix it up whilst applying, it's really helpful to make sure the driver
name is somewhere in the patch title.
e.g. iio: adc: ad7606: add HAS_IOPORT dependencies.
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/iio/adc/Kconfig
> > > +++ b/drivers/iio/adc/Kconfig
> > > @@ -119,7 +119,7 @@ config AD7606
> > >
> > > config AD7606_IFACE_PARALLEL
> > > tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> > > - depends on HAS_IOMEM
> > > + depends on HAS_IOPORT
> >
> > While this driver uses ins[bw](), this seems unrelated to legacy
> > I/O space, as the driver maps a MMIO region. Probably different
> > accessors should be used instead.
>
> You're right on first glance it looks like a misuse of the ins[bw]()
> accessors. I do wonder how that even works, if PCI_IOBASE is 0 it would
> result in readsw()/readsb() with presumably the correct address but no
> idea how this interacts witth x86's special I/O instructions.
>
> >
> > Note that this driver has no in-tree users. Same for the SPI variant,
> > but at least that one has modern json-schema DT bindings ;-)
>
> Can't find any mention in the MAINTAINERS file either.
It falls under the Analog devices catch all.
We don't list them all individually because there are a lot of them and
it would just be noise in many case.
Added Michael to CC. You already have Lars.
ANALOG DEVICES INC IIO DRIVERS
M: Lars-Peter Clausen <lars@metafoo.de>
M: Michael Hennerich <Michael.Hennerich@analog.com>
S: Supported
W: http://wiki.analog.com/
W: http://ez.analog.com/community/linux-device-drivers
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
F: Documentation/devicetree/bindings/iio/*/adi,*
F: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
F: drivers/iio/*/ad*
F: drivers/iio/adc/ltc249*
F: drivers/iio/amplifiers/hmc425a.c
F: drivers/staging/iio/*/ad*
X: drivers/iio/*/adjd*
https://wiki.analog.com/resources/tools-software/linux-drivers/iio-adc/ad7606
includes some details.
I'll leave it to the Lars or Michael to confirm what is going on here.
Jonathan
>
> >
> > > select AD7606
> > > help
> > > Say yes here to build parallel interface support for Analog Devices:
> >
> > 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
>
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
2021-12-28 17:01 ` Jonathan Cameron
@ 2022-01-30 15:05 ` Jonathan Cameron
-1 siblings, 0 replies; 323+ messages in thread
From: Jonathan Cameron @ 2022-01-30 15:05 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Geert Uytterhoeven, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Lars-Peter Clausen,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, linux-iio, Michael Hennerich
On Tue, 28 Dec 2021 17:01:25 +0000
Jonathan Cameron <jic23@jic23.retrosnub.co.uk> wrote:
> On Tue, 28 Dec 2021 13:50:20 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> > On Tue, 2021-12-28 at 11:32 +0100, Geert Uytterhoeven wrote:
> > > Hi Niklas,
> > >
> > > On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. We thus need to add HAS_IOPORT as dependency for
> > > > those drivers using them.
> > > >
> > > > 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>
>
> As a side note, whilst it doesn't always happen and I regularly forget
> to fix it up whilst applying, it's really helpful to make sure the driver
> name is somewhere in the patch title.
>
> e.g. iio: adc: ad7606: add HAS_IOPORT dependencies.
>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/iio/adc/Kconfig
> > > > +++ b/drivers/iio/adc/Kconfig
> > > > @@ -119,7 +119,7 @@ config AD7606
> > > >
> > > > config AD7606_IFACE_PARALLEL
> > > > tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> > > > - depends on HAS_IOMEM
> > > > + depends on HAS_IOPORT
> > >
> > > While this driver uses ins[bw](), this seems unrelated to legacy
> > > I/O space, as the driver maps a MMIO region. Probably different
> > > accessors should be used instead.
> >
> > You're right on first glance it looks like a misuse of the ins[bw]()
> > accessors. I do wonder how that even works, if PCI_IOBASE is 0 it would
> > result in readsw()/readsb() with presumably the correct address but no
> > idea how this interacts witth x86's special I/O instructions.
> >
> > >
> > > Note that this driver has no in-tree users. Same for the SPI variant,
> > > but at least that one has modern json-schema DT bindings ;-)
> >
> > Can't find any mention in the MAINTAINERS file either.
>
> It falls under the Analog devices catch all.
> We don't list them all individually because there are a lot of them and
> it would just be noise in many case.
>
> Added Michael to CC. You already have Lars.
>
> ANALOG DEVICES INC IIO DRIVERS
> M: Lars-Peter Clausen <lars@metafoo.de>
> M: Michael Hennerich <Michael.Hennerich@analog.com>
> S: Supported
> W: http://wiki.analog.com/
> W: http://ez.analog.com/community/linux-device-drivers
> F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
> F: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
> F: Documentation/devicetree/bindings/iio/*/adi,*
> F: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
> F: drivers/iio/*/ad*
> F: drivers/iio/adc/ltc249*
> F: drivers/iio/amplifiers/hmc425a.c
> F: drivers/staging/iio/*/ad*
> X: drivers/iio/*/adjd*
>
> https://wiki.analog.com/resources/tools-software/linux-drivers/iio-adc/ad7606
> includes some details.
>
> I'll leave it to the Lars or Michael to confirm what is going on here.
Can someone (probably at Analog Devices) take a look at this?
Thanks,
Jonathan
>
> Jonathan
>
> >
> > >
> > > > select AD7606
> > > > help
> > > > Say yes here to build parallel interface support for Analog Devices:
> > >
> > > 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
> >
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
@ 2022-01-30 15:05 ` Jonathan Cameron
0 siblings, 0 replies; 323+ messages in thread
From: Jonathan Cameron @ 2022-01-30 15:05 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Geert Uytterhoeven, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Lars-Peter Clausen,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, linux-iio, Michael Hennerich
On Tue, 28 Dec 2021 17:01:25 +0000
Jonathan Cameron <jic23@jic23.retrosnub.co.uk> wrote:
> On Tue, 28 Dec 2021 13:50:20 +0100
> Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> > On Tue, 2021-12-28 at 11:32 +0100, Geert Uytterhoeven wrote:
> > > Hi Niklas,
> > >
> > > On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. We thus need to add HAS_IOPORT as dependency for
> > > > those drivers using them.
> > > >
> > > > 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>
>
> As a side note, whilst it doesn't always happen and I regularly forget
> to fix it up whilst applying, it's really helpful to make sure the driver
> name is somewhere in the patch title.
>
> e.g. iio: adc: ad7606: add HAS_IOPORT dependencies.
>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/iio/adc/Kconfig
> > > > +++ b/drivers/iio/adc/Kconfig
> > > > @@ -119,7 +119,7 @@ config AD7606
> > > >
> > > > config AD7606_IFACE_PARALLEL
> > > > tristate "Analog Devices AD7606 ADC driver with parallel interface support"
> > > > - depends on HAS_IOMEM
> > > > + depends on HAS_IOPORT
> > >
> > > While this driver uses ins[bw](), this seems unrelated to legacy
> > > I/O space, as the driver maps a MMIO region. Probably different
> > > accessors should be used instead.
> >
> > You're right on first glance it looks like a misuse of the ins[bw]()
> > accessors. I do wonder how that even works, if PCI_IOBASE is 0 it would
> > result in readsw()/readsb() with presumably the correct address but no
> > idea how this interacts witth x86's special I/O instructions.
> >
> > >
> > > Note that this driver has no in-tree users. Same for the SPI variant,
> > > but at least that one has modern json-schema DT bindings ;-)
> >
> > Can't find any mention in the MAINTAINERS file either.
>
> It falls under the Analog devices catch all.
> We don't list them all individually because there are a lot of them and
> it would just be noise in many case.
>
> Added Michael to CC. You already have Lars.
>
> ANALOG DEVICES INC IIO DRIVERS
> M: Lars-Peter Clausen <lars@metafoo.de>
> M: Michael Hennerich <Michael.Hennerich@analog.com>
> S: Supported
> W: http://wiki.analog.com/
> W: http://ez.analog.com/community/linux-device-drivers
> F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
> F: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
> F: Documentation/devicetree/bindings/iio/*/adi,*
> F: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
> F: drivers/iio/*/ad*
> F: drivers/iio/adc/ltc249*
> F: drivers/iio/amplifiers/hmc425a.c
> F: drivers/staging/iio/*/ad*
> X: drivers/iio/*/adjd*
>
> https://wiki.analog.com/resources/tools-software/linux-drivers/iio-adc/ad7606
> includes some details.
>
> I'll leave it to the Lars or Michael to confirm what is going on here.
Can someone (probably at Analog Devices) take a look at this?
Thanks,
Jonathan
>
> Jonathan
>
> >
> > >
> > > > select AD7606
> > > > help
> > > > Say yes here to build parallel interface support for Analog Devices:
> > >
> > > 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
> >
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jean Delvare, Guenter Roeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-hwmon
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/hwmon/Kconfig | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 09397562c396..c1a2d8ac96fd 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -547,6 +547,7 @@ config SENSORS_SPARX5
config SENSORS_F71805F
tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for hardware monitoring
@@ -558,6 +559,7 @@ config SENSORS_F71805F
config SENSORS_F71882FG
tristate "Fintek F71882FG and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for hardware monitoring
@@ -761,6 +763,7 @@ config SENSORS_CORETEMP
config SENSORS_IT87
tristate "ITE IT87xx and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -1387,6 +1390,7 @@ config SENSORS_LM95245
config SENSORS_PC87360
tristate "National Semiconductor PC87360 family"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -1401,6 +1405,7 @@ config SENSORS_PC87360
config SENSORS_PC87427
tristate "National Semiconductor PC87427"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get access to the hardware monitoring
@@ -1432,6 +1437,7 @@ config SENSORS_NTC_THERMISTOR
config SENSORS_NCT6683
tristate "Nuvoton NCT6683D"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for the hardware monitoring
@@ -1442,6 +1448,7 @@ config SENSORS_NCT6683
config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
depends on ACPI_WMI || ACPI_WMI=n
select HWMON_VID
@@ -1664,6 +1671,7 @@ config SENSORS_SIS5595
config SENSORS_DME1737
tristate "SMSC DME1737, SCH311x and compatibles"
+ depends on HAS_IOPORT
depends on I2C && !PPC
select HWMON_VID
help
@@ -1707,6 +1715,7 @@ config SENSORS_EMC6W201
config SENSORS_SMSC47M1
tristate "SMSC LPC47M10x and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for the integrated fan
@@ -1741,6 +1750,7 @@ config SENSORS_SMSC47M192
config SENSORS_SMSC47B397
tristate "SMSC LPC47B397-NC"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for the SMSC LPC47B397-NC
@@ -1754,6 +1764,7 @@ config SENSORS_SCH56XX_COMMON
config SENSORS_SCH5627
tristate "SMSC SCH5627"
+ depends on HAS_IOPORT
depends on !PPC && WATCHDOG
select SENSORS_SCH56XX_COMMON
select WATCHDOG_CORE
@@ -1767,6 +1778,7 @@ config SENSORS_SCH5627
config SENSORS_SCH5636
tristate "SMSC SCH5636"
+ depends on HAS_IOPORT
depends on !PPC && WATCHDOG
select SENSORS_SCH56XX_COMMON
select WATCHDOG_CORE
@@ -1995,6 +2007,7 @@ config SENSORS_VIA686A
config SENSORS_VT1211
tristate "VIA VT1211"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -2114,6 +2127,7 @@ config SENSORS_W83L786NG
config SENSORS_W83627HF
tristate "Winbond W83627HF, W83627THF, W83637HF, W83687THF, W83697HF"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -2126,6 +2140,7 @@ config SENSORS_W83627HF
config SENSORS_W83627EHF
tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jean Delvare, Guenter Roeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-hwmon
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/hwmon/Kconfig | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 09397562c396..c1a2d8ac96fd 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -547,6 +547,7 @@ config SENSORS_SPARX5
config SENSORS_F71805F
tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for hardware monitoring
@@ -558,6 +559,7 @@ config SENSORS_F71805F
config SENSORS_F71882FG
tristate "Fintek F71882FG and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for hardware monitoring
@@ -761,6 +763,7 @@ config SENSORS_CORETEMP
config SENSORS_IT87
tristate "ITE IT87xx and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -1387,6 +1390,7 @@ config SENSORS_LM95245
config SENSORS_PC87360
tristate "National Semiconductor PC87360 family"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -1401,6 +1405,7 @@ config SENSORS_PC87360
config SENSORS_PC87427
tristate "National Semiconductor PC87427"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get access to the hardware monitoring
@@ -1432,6 +1437,7 @@ config SENSORS_NTC_THERMISTOR
config SENSORS_NCT6683
tristate "Nuvoton NCT6683D"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for the hardware monitoring
@@ -1442,6 +1448,7 @@ config SENSORS_NCT6683
config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
depends on ACPI_WMI || ACPI_WMI=n
select HWMON_VID
@@ -1664,6 +1671,7 @@ config SENSORS_SIS5595
config SENSORS_DME1737
tristate "SMSC DME1737, SCH311x and compatibles"
+ depends on HAS_IOPORT
depends on I2C && !PPC
select HWMON_VID
help
@@ -1707,6 +1715,7 @@ config SENSORS_EMC6W201
config SENSORS_SMSC47M1
tristate "SMSC LPC47M10x and compatibles"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for the integrated fan
@@ -1741,6 +1750,7 @@ config SENSORS_SMSC47M192
config SENSORS_SMSC47B397
tristate "SMSC LPC47B397-NC"
+ depends on HAS_IOPORT
depends on !PPC
help
If you say yes here you get support for the SMSC LPC47B397-NC
@@ -1754,6 +1764,7 @@ config SENSORS_SCH56XX_COMMON
config SENSORS_SCH5627
tristate "SMSC SCH5627"
+ depends on HAS_IOPORT
depends on !PPC && WATCHDOG
select SENSORS_SCH56XX_COMMON
select WATCHDOG_CORE
@@ -1767,6 +1778,7 @@ config SENSORS_SCH5627
config SENSORS_SCH5636
tristate "SMSC SCH5636"
+ depends on HAS_IOPORT
depends on !PPC && WATCHDOG
select SENSORS_SCH56XX_COMMON
select WATCHDOG_CORE
@@ -1995,6 +2007,7 @@ config SENSORS_VIA686A
config SENSORS_VT1211
tristate "VIA VT1211"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -2114,6 +2127,7 @@ config SENSORS_W83L786NG
config SENSORS_W83627HF
tristate "Winbond W83627HF, W83627THF, W83637HF, W83687THF, W83697HF"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
@@ -2126,6 +2140,7 @@ config SENSORS_W83627HF
config SENSORS_W83627EHF
tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG"
+ depends on HAS_IOPORT
depends on !PPC
select HWMON_VID
help
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 18:07 ` Guenter Roeck
-1 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 18:07 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Jean Delvare
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-hwmon
On 12/27/21 8:42 AM, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
Similar to watchdog, I don't understand when HAS_IOPORT is needed and when not,
as there are more hwmon drivers using IO ports than the ones listed below.
Guenter
> 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>
> ---
> drivers/hwmon/Kconfig | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 09397562c396..c1a2d8ac96fd 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -547,6 +547,7 @@ config SENSORS_SPARX5
>
> config SENSORS_F71805F
> tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for hardware monitoring
> @@ -558,6 +559,7 @@ config SENSORS_F71805F
>
> config SENSORS_F71882FG
> tristate "Fintek F71882FG and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for hardware monitoring
> @@ -761,6 +763,7 @@ config SENSORS_CORETEMP
>
> config SENSORS_IT87
> tristate "ITE IT87xx and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -1387,6 +1390,7 @@ config SENSORS_LM95245
>
> config SENSORS_PC87360
> tristate "National Semiconductor PC87360 family"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -1401,6 +1405,7 @@ config SENSORS_PC87360
>
> config SENSORS_PC87427
> tristate "National Semiconductor PC87427"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get access to the hardware monitoring
> @@ -1432,6 +1437,7 @@ config SENSORS_NTC_THERMISTOR
>
> config SENSORS_NCT6683
> tristate "Nuvoton NCT6683D"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for the hardware monitoring
> @@ -1442,6 +1448,7 @@ config SENSORS_NCT6683
>
> config SENSORS_NCT6775
> tristate "Nuvoton NCT6775F and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> depends on ACPI_WMI || ACPI_WMI=n
> select HWMON_VID
> @@ -1664,6 +1671,7 @@ config SENSORS_SIS5595
>
> config SENSORS_DME1737
> tristate "SMSC DME1737, SCH311x and compatibles"
> + depends on HAS_IOPORT
> depends on I2C && !PPC
> select HWMON_VID
> help
> @@ -1707,6 +1715,7 @@ config SENSORS_EMC6W201
>
> config SENSORS_SMSC47M1
> tristate "SMSC LPC47M10x and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for the integrated fan
> @@ -1741,6 +1750,7 @@ config SENSORS_SMSC47M192
>
> config SENSORS_SMSC47B397
> tristate "SMSC LPC47B397-NC"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for the SMSC LPC47B397-NC
> @@ -1754,6 +1764,7 @@ config SENSORS_SCH56XX_COMMON
>
> config SENSORS_SCH5627
> tristate "SMSC SCH5627"
> + depends on HAS_IOPORT
> depends on !PPC && WATCHDOG
> select SENSORS_SCH56XX_COMMON
> select WATCHDOG_CORE
> @@ -1767,6 +1778,7 @@ config SENSORS_SCH5627
>
> config SENSORS_SCH5636
> tristate "SMSC SCH5636"
> + depends on HAS_IOPORT
> depends on !PPC && WATCHDOG
> select SENSORS_SCH56XX_COMMON
> select WATCHDOG_CORE
> @@ -1995,6 +2007,7 @@ config SENSORS_VIA686A
>
> config SENSORS_VT1211
> tristate "VIA VT1211"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -2114,6 +2127,7 @@ config SENSORS_W83L786NG
>
> config SENSORS_W83627HF
> tristate "Winbond W83627HF, W83627THF, W83637HF, W83687THF, W83697HF"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -2126,6 +2140,7 @@ config SENSORS_W83627HF
>
> config SENSORS_W83627EHF
> tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 18:07 ` Guenter Roeck
0 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 18:07 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Jean Delvare
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-hwmon
On 12/27/21 8:42 AM, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
Similar to watchdog, I don't understand when HAS_IOPORT is needed and when not,
as there are more hwmon drivers using IO ports than the ones listed below.
Guenter
> 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>
> ---
> drivers/hwmon/Kconfig | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 09397562c396..c1a2d8ac96fd 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -547,6 +547,7 @@ config SENSORS_SPARX5
>
> config SENSORS_F71805F
> tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for hardware monitoring
> @@ -558,6 +559,7 @@ config SENSORS_F71805F
>
> config SENSORS_F71882FG
> tristate "Fintek F71882FG and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for hardware monitoring
> @@ -761,6 +763,7 @@ config SENSORS_CORETEMP
>
> config SENSORS_IT87
> tristate "ITE IT87xx and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -1387,6 +1390,7 @@ config SENSORS_LM95245
>
> config SENSORS_PC87360
> tristate "National Semiconductor PC87360 family"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -1401,6 +1405,7 @@ config SENSORS_PC87360
>
> config SENSORS_PC87427
> tristate "National Semiconductor PC87427"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get access to the hardware monitoring
> @@ -1432,6 +1437,7 @@ config SENSORS_NTC_THERMISTOR
>
> config SENSORS_NCT6683
> tristate "Nuvoton NCT6683D"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for the hardware monitoring
> @@ -1442,6 +1448,7 @@ config SENSORS_NCT6683
>
> config SENSORS_NCT6775
> tristate "Nuvoton NCT6775F and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> depends on ACPI_WMI || ACPI_WMI=n
> select HWMON_VID
> @@ -1664,6 +1671,7 @@ config SENSORS_SIS5595
>
> config SENSORS_DME1737
> tristate "SMSC DME1737, SCH311x and compatibles"
> + depends on HAS_IOPORT
> depends on I2C && !PPC
> select HWMON_VID
> help
> @@ -1707,6 +1715,7 @@ config SENSORS_EMC6W201
>
> config SENSORS_SMSC47M1
> tristate "SMSC LPC47M10x and compatibles"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for the integrated fan
> @@ -1741,6 +1750,7 @@ config SENSORS_SMSC47M192
>
> config SENSORS_SMSC47B397
> tristate "SMSC LPC47B397-NC"
> + depends on HAS_IOPORT
> depends on !PPC
> help
> If you say yes here you get support for the SMSC LPC47B397-NC
> @@ -1754,6 +1764,7 @@ config SENSORS_SCH56XX_COMMON
>
> config SENSORS_SCH5627
> tristate "SMSC SCH5627"
> + depends on HAS_IOPORT
> depends on !PPC && WATCHDOG
> select SENSORS_SCH56XX_COMMON
> select WATCHDOG_CORE
> @@ -1767,6 +1778,7 @@ config SENSORS_SCH5627
>
> config SENSORS_SCH5636
> tristate "SMSC SCH5636"
> + depends on HAS_IOPORT
> depends on !PPC && WATCHDOG
> select SENSORS_SCH56XX_COMMON
> select WATCHDOG_CORE
> @@ -1995,6 +2007,7 @@ config SENSORS_VIA686A
>
> config SENSORS_VT1211
> tristate "VIA VT1211"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -2114,6 +2127,7 @@ config SENSORS_W83L786NG
>
> config SENSORS_W83627HF
> tristate "Winbond W83627HF, W83627THF, W83637HF, W83687THF, W83697HF"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
> @@ -2126,6 +2140,7 @@ config SENSORS_W83627HF
>
> config SENSORS_W83627EHF
> tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG"
> + depends on HAS_IOPORT
> depends on !PPC
> select HWMON_VID
> help
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:42 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Pavel Machek
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-leds
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/leds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ed800f5da7d8..7d670fc40865 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -688,7 +688,7 @@ config LEDS_LM355x
config LEDS_OT200
tristate "LED support for the Bachmann OT200"
- depends on LEDS_CLASS && HAS_IOMEM && (X86_32 || COMPILE_TEST)
+ depends on LEDS_CLASS && HAS_IOPORT && (X86_32 || COMPILE_TEST)
help
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:42 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Pavel Machek
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-leds
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/leds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ed800f5da7d8..7d670fc40865 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -688,7 +688,7 @@ config LEDS_LM355x
config LEDS_OT200
tristate "LED support for the Bachmann OT200"
- depends on LEDS_CLASS && HAS_IOMEM && (X86_32 || COMPILE_TEST)
+ depends on LEDS_CLASS && HAS_IOPORT && (X86_32 || COMPILE_TEST)
help
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Mauro Carvalho Chehab, Sean Young
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-media
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/media/radio/Kconfig | 13 +++++++++++++
drivers/media/rc/Kconfig | 6 ++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 32eb73993998..044590b58212 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -233,6 +233,7 @@ source "drivers/media/radio/wl128x/Kconfig"
menuconfig V4L_RADIO_ISA_DRIVERS
bool "ISA radio devices"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for these ISA drivers.
@@ -240,11 +241,13 @@ if V4L_RADIO_ISA_DRIVERS
config RADIO_ISA
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
tristate
config RADIO_CADET
tristate "ADS Cadet AM/FM Tuner"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
help
Choose Y here if you have one of these AM/FM radio cards, and then
@@ -256,6 +259,7 @@ config RADIO_CADET
config RADIO_RTRACK
tristate "AIMSlab RadioTrack (aka RadioReveal) support"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -288,6 +292,7 @@ config RADIO_RTRACK_PORT
config RADIO_RTRACK2
tristate "AIMSlab RadioTrack II support"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -312,6 +317,7 @@ config RADIO_RTRACK2_PORT
config RADIO_AZTECH
tristate "Aztech/Packard Bell Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -333,6 +339,7 @@ config RADIO_AZTECH_PORT
config RADIO_GEMTEK
tristate "GemTek Radio card (or compatible) support"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -389,6 +396,7 @@ config RADIO_MIROPCM20
config RADIO_SF16FMI
tristate "SF16-FMI/SF16-FMP/SF16-FMD Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
help
Choose Y here if you have one of these FM radio cards.
@@ -399,6 +407,7 @@ config RADIO_SF16FMI
config RADIO_SF16FMR2
tristate "SF16-FMR2/SF16-FMD2 Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_TEA575X
help
@@ -410,6 +419,7 @@ config RADIO_SF16FMR2
config RADIO_TERRATEC
tristate "TerraTec ActiveRadio ISA Standalone"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -425,6 +435,7 @@ config RADIO_TERRATEC
config RADIO_TRUST
tristate "Trust FM radio card"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -449,6 +460,7 @@ config RADIO_TRUST_PORT
config RADIO_TYPHOON
tristate "Typhoon Radio (a.k.a. EcoRadio)"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -484,6 +496,7 @@ config RADIO_TYPHOON_MUTEFREQ
config RADIO_ZOLTRIX
tristate "Zoltrix Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 9506baf3c4c1..d0947296f935 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -163,6 +163,7 @@ config RC_ATI_REMOTE
config IR_ENE
tristate "ENE eHome Receiver/Transceiver (pnp id: ENE0100/ENE02xxx)"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receiver
/transceiver made by ENE.
@@ -216,6 +217,7 @@ config IR_MCEUSB
config IR_ITE_CIR
tristate "ITE Tech Inc. IT8712/IT8512 Consumer Infrared Transceiver"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receivers
/transceivers made by ITE Tech Inc. These are found in
@@ -228,6 +230,7 @@ config IR_ITE_CIR
config IR_FINTEK
tristate "Fintek Consumer Infrared Transceiver"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receiver
/transceiver made by Fintek. This chip is found on assorted
@@ -269,6 +272,7 @@ config IR_MTK
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receiver
/transceiver made by Nuvoton (formerly Winbond). This chip is
@@ -312,6 +316,7 @@ config IR_STREAMZAP
config IR_WINBOND_CIR
tristate "Winbond IR remote control"
depends on (X86 && PNP) || COMPILE_TEST
+ depends on HAS_IOPORT
select NEW_LEDS
select LEDS_CLASS
select BITREVERSE
@@ -440,6 +445,7 @@ config IR_SUNXI
config IR_SERIAL
tristate "Homebrew Serial Port Receiver"
+ depends on HAS_IOPORT
help
Say Y if you want to use Homebrew Serial Port Receivers and
Transceivers.
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Mauro Carvalho Chehab, Sean Young
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-media
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/media/radio/Kconfig | 13 +++++++++++++
drivers/media/rc/Kconfig | 6 ++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 32eb73993998..044590b58212 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -233,6 +233,7 @@ source "drivers/media/radio/wl128x/Kconfig"
menuconfig V4L_RADIO_ISA_DRIVERS
bool "ISA radio devices"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for these ISA drivers.
@@ -240,11 +241,13 @@ if V4L_RADIO_ISA_DRIVERS
config RADIO_ISA
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
tristate
config RADIO_CADET
tristate "ADS Cadet AM/FM Tuner"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
help
Choose Y here if you have one of these AM/FM radio cards, and then
@@ -256,6 +259,7 @@ config RADIO_CADET
config RADIO_RTRACK
tristate "AIMSlab RadioTrack (aka RadioReveal) support"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -288,6 +292,7 @@ config RADIO_RTRACK_PORT
config RADIO_RTRACK2
tristate "AIMSlab RadioTrack II support"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -312,6 +317,7 @@ config RADIO_RTRACK2_PORT
config RADIO_AZTECH
tristate "Aztech/Packard Bell Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -333,6 +339,7 @@ config RADIO_AZTECH_PORT
config RADIO_GEMTEK
tristate "GemTek Radio card (or compatible) support"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -389,6 +396,7 @@ config RADIO_MIROPCM20
config RADIO_SF16FMI
tristate "SF16-FMI/SF16-FMP/SF16-FMD Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
help
Choose Y here if you have one of these FM radio cards.
@@ -399,6 +407,7 @@ config RADIO_SF16FMI
config RADIO_SF16FMR2
tristate "SF16-FMR2/SF16-FMD2 Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_TEA575X
help
@@ -410,6 +419,7 @@ config RADIO_SF16FMR2
config RADIO_TERRATEC
tristate "TerraTec ActiveRadio ISA Standalone"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -425,6 +435,7 @@ config RADIO_TERRATEC
config RADIO_TRUST
tristate "Trust FM radio card"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -449,6 +460,7 @@ config RADIO_TRUST_PORT
config RADIO_TYPHOON
tristate "Typhoon Radio (a.k.a. EcoRadio)"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
@@ -484,6 +496,7 @@ config RADIO_TYPHOON_MUTEFREQ
config RADIO_ZOLTRIX
tristate "Zoltrix Radio"
depends on ISA || COMPILE_TEST
+ depends on HAS_IOPORT
depends on VIDEO_V4L2
select RADIO_ISA
help
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 9506baf3c4c1..d0947296f935 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -163,6 +163,7 @@ config RC_ATI_REMOTE
config IR_ENE
tristate "ENE eHome Receiver/Transceiver (pnp id: ENE0100/ENE02xxx)"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receiver
/transceiver made by ENE.
@@ -216,6 +217,7 @@ config IR_MCEUSB
config IR_ITE_CIR
tristate "ITE Tech Inc. IT8712/IT8512 Consumer Infrared Transceiver"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receivers
/transceivers made by ITE Tech Inc. These are found in
@@ -228,6 +230,7 @@ config IR_ITE_CIR
config IR_FINTEK
tristate "Fintek Consumer Infrared Transceiver"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receiver
/transceiver made by Fintek. This chip is found on assorted
@@ -269,6 +272,7 @@ config IR_MTK
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP || COMPILE_TEST
+ depends on HAS_IOPORT
help
Say Y here to enable support for integrated infrared receiver
/transceiver made by Nuvoton (formerly Winbond). This chip is
@@ -312,6 +316,7 @@ config IR_STREAMZAP
config IR_WINBOND_CIR
tristate "Winbond IR remote control"
depends on (X86 && PNP) || COMPILE_TEST
+ depends on HAS_IOPORT
select NEW_LEDS
select LEDS_CLASS
select BITREVERSE
@@ -440,6 +445,7 @@ config IR_SUNXI
config IR_SERIAL
tristate "Homebrew Serial Port Receiver"
+ depends on HAS_IOPORT
help
Say Y if you want to use Homebrew Serial Port Receivers and
Transceivers.
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 16/32] misc: handle HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/misc/altera-stapl/Makefile | 3 ++-
drivers/misc/altera-stapl/altera.c | 6 +++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/altera-stapl/Makefile b/drivers/misc/altera-stapl/Makefile
index dd0f8189666b..90f18e7bf9b0 100644
--- a/drivers/misc/altera-stapl/Makefile
+++ b/drivers/misc/altera-stapl/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-altera-stapl-objs = altera-lpt.o altera-jtag.o altera-comp.o altera.o
+altera-stapl-y = altera-jtag.o altera-comp.o altera.o
+altera-stapl-$(CONFIG_HAS_IOPORT) += altera-lpt.o
obj-$(CONFIG_ALTERA_STAPL) += altera-stapl.o
diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c
index 92c0611034b0..c7ae64de8bb4 100644
--- a/drivers/misc/altera-stapl/altera.c
+++ b/drivers/misc/altera-stapl/altera.c
@@ -2431,6 +2431,10 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
astate->config = config;
if (!astate->config->jtag_io) {
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
+ retval = -ENODEV;
+ goto free_state;
+ }
dprintk("%s: using byteblaster!\n", __func__);
astate->config->jtag_io = netup_jtag_io_lpt;
}
@@ -2505,7 +2509,7 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
} else if (exec_result)
printk(KERN_ERR "%s: error %d\n", __func__, exec_result);
-
+free_state:
kfree(astate);
free_value:
kfree(value);
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 16/32] misc: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/misc/altera-stapl/Makefile | 3 ++-
drivers/misc/altera-stapl/altera.c | 6 +++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/altera-stapl/Makefile b/drivers/misc/altera-stapl/Makefile
index dd0f8189666b..90f18e7bf9b0 100644
--- a/drivers/misc/altera-stapl/Makefile
+++ b/drivers/misc/altera-stapl/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-altera-stapl-objs = altera-lpt.o altera-jtag.o altera-comp.o altera.o
+altera-stapl-y = altera-jtag.o altera-comp.o altera.o
+altera-stapl-$(CONFIG_HAS_IOPORT) += altera-lpt.o
obj-$(CONFIG_ALTERA_STAPL) += altera-stapl.o
diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c
index 92c0611034b0..c7ae64de8bb4 100644
--- a/drivers/misc/altera-stapl/altera.c
+++ b/drivers/misc/altera-stapl/altera.c
@@ -2431,6 +2431,10 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
astate->config = config;
if (!astate->config->jtag_io) {
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
+ retval = -ENODEV;
+ goto free_state;
+ }
dprintk("%s: using byteblaster!\n", __func__);
astate->config->jtag_io = netup_jtag_io_lpt;
}
@@ -2505,7 +2509,7 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
} else if (exec_result)
printk(KERN_ERR "%s: error %d\n", __func__, exec_result);
-
+free_state:
kfree(astate);
free_value:
kfree(value);
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread* Re: [RFC 16/32] misc: handle HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-28 8:15 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:15 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Mon, Dec 27, 2021 at 05:43:01PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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>
> ---
> drivers/misc/altera-stapl/Makefile | 3 ++-
> drivers/misc/altera-stapl/altera.c | 6 +++++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/altera-stapl/Makefile b/drivers/misc/altera-stapl/Makefile
> index dd0f8189666b..90f18e7bf9b0 100644
> --- a/drivers/misc/altera-stapl/Makefile
> +++ b/drivers/misc/altera-stapl/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -altera-stapl-objs = altera-lpt.o altera-jtag.o altera-comp.o altera.o
> +altera-stapl-y = altera-jtag.o altera-comp.o altera.o
> +altera-stapl-$(CONFIG_HAS_IOPORT) += altera-lpt.o
>
> obj-$(CONFIG_ALTERA_STAPL) += altera-stapl.o
> diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c
> index 92c0611034b0..c7ae64de8bb4 100644
> --- a/drivers/misc/altera-stapl/altera.c
> +++ b/drivers/misc/altera-stapl/altera.c
> @@ -2431,6 +2431,10 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
>
> astate->config = config;
> if (!astate->config->jtag_io) {
> + if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
> + retval = -ENODEV;
> + goto free_state;
> + }
A comment as to why you are doing this check here would be nice, as it
is not obvious at all what is going on.
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 16/32] misc: handle HAS_IOPORT dependencies
@ 2021-12-28 8:15 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:15 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Mon, Dec 27, 2021 at 05:43:01PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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>
> ---
> drivers/misc/altera-stapl/Makefile | 3 ++-
> drivers/misc/altera-stapl/altera.c | 6 +++++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/altera-stapl/Makefile b/drivers/misc/altera-stapl/Makefile
> index dd0f8189666b..90f18e7bf9b0 100644
> --- a/drivers/misc/altera-stapl/Makefile
> +++ b/drivers/misc/altera-stapl/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -altera-stapl-objs = altera-lpt.o altera-jtag.o altera-comp.o altera.o
> +altera-stapl-y = altera-jtag.o altera-comp.o altera.o
> +altera-stapl-$(CONFIG_HAS_IOPORT) += altera-lpt.o
>
> obj-$(CONFIG_ALTERA_STAPL) += altera-stapl.o
> diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c
> index 92c0611034b0..c7ae64de8bb4 100644
> --- a/drivers/misc/altera-stapl/altera.c
> +++ b/drivers/misc/altera-stapl/altera.c
> @@ -2431,6 +2431,10 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
>
> astate->config = config;
> if (!astate->config->jtag_io) {
> + if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
> + retval = -ENODEV;
> + goto free_state;
> + }
A comment as to why you are doing this check here would be nice, as it
is not obvious at all what is going on.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
David S. Miller, Jakub Kicinski, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
netdev, linux-can
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/net/Kconfig | 2 +-
drivers/net/can/cc770/Kconfig | 1 +
drivers/net/can/sja1000/Kconfig | 1 +
drivers/net/ethernet/via/Kconfig | 1 +
drivers/net/hamradio/Kconfig | 6 +++---
5 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6cccc3dc00bc..362d20c9a571 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -476,7 +476,7 @@ source "drivers/net/ipa/Kconfig"
config NET_SB1000
tristate "General Instruments Surfboard 1000"
- depends on PNP
+ depends on ISAPNP
help
This is a driver for the General Instrument (also known as
NextLevel) SURFboard 1000 internal
diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
index 9ef1359319f0..467ef19de1c1 100644
--- a/drivers/net/can/cc770/Kconfig
+++ b/drivers/net/can/cc770/Kconfig
@@ -7,6 +7,7 @@ if CAN_CC770
config CAN_CC770_ISA
tristate "ISA Bus based legacy CC770 driver"
+ depends on ISA
help
This driver adds legacy support for CC770 and AN82527 chips
connected to the ISA bus using I/O port, memory mapped or
diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
index 110071b26921..be1943a27ed0 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -87,6 +87,7 @@ config CAN_PLX_PCI
config CAN_SJA1000_ISA
tristate "ISA Bus based legacy SJA1000 driver"
+ depends on ISA
help
This driver adds legacy support for SJA1000 chips connected to
the ISA bus using I/O port, memory mapped or indirect access.
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 0ca7d8f7bfde..25add3d64859 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -20,6 +20,7 @@ config VIA_RHINE
tristate "VIA Rhine support"
depends on LEGACY_PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
depends on LEGACY_PCI || ARCH_VT8500 || COMPILE_TEST
+ depends on HAS_IOPORT
depends on HAS_DMA
select CRC32
select MII
diff --git a/drivers/net/hamradio/Kconfig b/drivers/net/hamradio/Kconfig
index 441da03c23ee..61c0bc156870 100644
--- a/drivers/net/hamradio/Kconfig
+++ b/drivers/net/hamradio/Kconfig
@@ -117,7 +117,7 @@ config SCC_TRXECHO
config BAYCOM_SER_FDX
tristate "BAYCOM ser12 fullduplex driver for AX.25"
- depends on AX25 && !S390
+ depends on AX25 && HAS_IOPORT
select CRC_CCITT
help
This is one of two drivers for Baycom style simple amateur radio
@@ -137,7 +137,7 @@ config BAYCOM_SER_FDX
config BAYCOM_SER_HDX
tristate "BAYCOM ser12 halfduplex driver for AX.25"
- depends on AX25 && !S390
+ depends on AX25 && HAS_IOPORT
select CRC_CCITT
help
This is one of two drivers for Baycom style simple amateur radio
@@ -185,7 +185,7 @@ config BAYCOM_EPP
config YAM
tristate "YAM driver for AX.25"
- depends on AX25 && !S390
+ depends on AX25 && HAS_IOPORT
help
The YAM is a modem for packet radio which connects to the serial
port and includes some of the functions of a Terminal Node
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
David S. Miller, Jakub Kicinski, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
netdev, linux-can
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/net/Kconfig | 2 +-
drivers/net/can/cc770/Kconfig | 1 +
drivers/net/can/sja1000/Kconfig | 1 +
drivers/net/ethernet/via/Kconfig | 1 +
drivers/net/hamradio/Kconfig | 6 +++---
5 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6cccc3dc00bc..362d20c9a571 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -476,7 +476,7 @@ source "drivers/net/ipa/Kconfig"
config NET_SB1000
tristate "General Instruments Surfboard 1000"
- depends on PNP
+ depends on ISAPNP
help
This is a driver for the General Instrument (also known as
NextLevel) SURFboard 1000 internal
diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
index 9ef1359319f0..467ef19de1c1 100644
--- a/drivers/net/can/cc770/Kconfig
+++ b/drivers/net/can/cc770/Kconfig
@@ -7,6 +7,7 @@ if CAN_CC770
config CAN_CC770_ISA
tristate "ISA Bus based legacy CC770 driver"
+ depends on ISA
help
This driver adds legacy support for CC770 and AN82527 chips
connected to the ISA bus using I/O port, memory mapped or
diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
index 110071b26921..be1943a27ed0 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -87,6 +87,7 @@ config CAN_PLX_PCI
config CAN_SJA1000_ISA
tristate "ISA Bus based legacy SJA1000 driver"
+ depends on ISA
help
This driver adds legacy support for SJA1000 chips connected to
the ISA bus using I/O port, memory mapped or indirect access.
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 0ca7d8f7bfde..25add3d64859 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -20,6 +20,7 @@ config VIA_RHINE
tristate "VIA Rhine support"
depends on LEGACY_PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
depends on LEGACY_PCI || ARCH_VT8500 || COMPILE_TEST
+ depends on HAS_IOPORT
depends on HAS_DMA
select CRC32
select MII
diff --git a/drivers/net/hamradio/Kconfig b/drivers/net/hamradio/Kconfig
index 441da03c23ee..61c0bc156870 100644
--- a/drivers/net/hamradio/Kconfig
+++ b/drivers/net/hamradio/Kconfig
@@ -117,7 +117,7 @@ config SCC_TRXECHO
config BAYCOM_SER_FDX
tristate "BAYCOM ser12 fullduplex driver for AX.25"
- depends on AX25 && !S390
+ depends on AX25 && HAS_IOPORT
select CRC_CCITT
help
This is one of two drivers for Baycom style simple amateur radio
@@ -137,7 +137,7 @@ config BAYCOM_SER_FDX
config BAYCOM_SER_HDX
tristate "BAYCOM ser12 halfduplex driver for AX.25"
- depends on AX25 && !S390
+ depends on AX25 && HAS_IOPORT
select CRC_CCITT
help
This is one of two drivers for Baycom style simple amateur radio
@@ -185,7 +185,7 @@ config BAYCOM_EPP
config YAM
tristate "YAM driver for AX.25"
- depends on AX25 && !S390
+ depends on AX25 && HAS_IOPORT
help
The YAM is a modem for packet radio which connects to the serial
port and includes some of the functions of a Terminal Node
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-27 17:28 ` Marc Kleine-Budde
-1 siblings, 0 replies; 323+ messages in thread
From: Marc Kleine-Budde @ 2021-12-27 17:28 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
David S. Miller, Jakub Kicinski, Wolfgang Grandegger,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
netdev, linux-can
[-- Attachment #1.1: Type: text/plain, Size: 846 bytes --]
On 27.12.2021 17:43:02, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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>
> ---
> drivers/net/can/cc770/Kconfig | 1 +
> drivers/net/can/sja1000/Kconfig | 1 +
For the CAN drivers:
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 17:28 ` Marc Kleine-Budde
0 siblings, 0 replies; 323+ messages in thread
From: Marc Kleine-Budde @ 2021-12-27 17:28 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
David S. Miller, Jakub Kicinski, Wolfgang Grandegger,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
netdev, linux-can
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On 27.12.2021 17:43:02, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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>
> ---
> drivers/net/can/cc770/Kconfig | 1 +
> drivers/net/can/sja1000/Kconfig | 1 +
For the CAN drivers:
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dominik Brodowski
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. PCMCIA devices are either LEGACY_PCI devices
which implies HAS_IOPORT or require HAS_IOPORT.
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>
---
drivers/pcmcia/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index d13b8d1a780a..3d05bdf1f9cb 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -5,7 +5,7 @@
menuconfig PCCARD
tristate "PCCard (PCMCIA/CardBus) support"
- depends on !UML
+ depends on LEGACY_PCI || HAS_IOPORT
help
Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
computer. These are credit-card size devices such as network cards,
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dominik Brodowski
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. PCMCIA devices are either LEGACY_PCI devices
which implies HAS_IOPORT or require HAS_IOPORT.
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>
---
drivers/pcmcia/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index d13b8d1a780a..3d05bdf1f9cb 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -5,7 +5,7 @@
menuconfig PCCARD
tristate "PCCard (PCMCIA/CardBus) support"
- depends on !UML
+ depends on LEGACY_PCI || HAS_IOPORT
help
Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
computer. These are credit-card size devices such as network cards,
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-27 18:41 ` Dominik Brodowski
-1 siblings, 0 replies; 323+ messages in thread
From: Dominik Brodowski @ 2021-12-27 18:41 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Am Mon, Dec 27, 2021 at 05:43:03PM +0100 schrieb Niklas Schnelle:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. PCMCIA devices are either LEGACY_PCI devices
> which implies HAS_IOPORT or require HAS_IOPORT.
>
> 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>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Thanks,
Dominik
> ---
> drivers/pcmcia/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> index d13b8d1a780a..3d05bdf1f9cb 100644
> --- a/drivers/pcmcia/Kconfig
> +++ b/drivers/pcmcia/Kconfig
> @@ -5,7 +5,7 @@
>
> menuconfig PCCARD
> tristate "PCCard (PCMCIA/CardBus) support"
> - depends on !UML
> + depends on LEGACY_PCI || HAS_IOPORT
> help
> Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
> computer. These are credit-card size devices such as network cards,
> --
> 2.32.0
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 18:41 ` Dominik Brodowski
0 siblings, 0 replies; 323+ messages in thread
From: Dominik Brodowski @ 2021-12-27 18:41 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Am Mon, Dec 27, 2021 at 05:43:03PM +0100 schrieb Niklas Schnelle:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. PCMCIA devices are either LEGACY_PCI devices
> which implies HAS_IOPORT or require HAS_IOPORT.
>
> 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>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Thanks,
Dominik
> ---
> drivers/pcmcia/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> index d13b8d1a780a..3d05bdf1f9cb 100644
> --- a/drivers/pcmcia/Kconfig
> +++ b/drivers/pcmcia/Kconfig
> @@ -5,7 +5,7 @@
>
> menuconfig PCCARD
> tristate "PCCard (PCMCIA/CardBus) support"
> - depends on !UML
> + depends on LEGACY_PCI || HAS_IOPORT
> help
> Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
> computer. These are credit-card size devices such as network cards,
> --
> 2.32.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Benson Leung
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/platform/chrome/Kconfig | 1 +
drivers/platform/chrome/wilco_ec/Kconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index ccc23d8686e8..b43ef78e75d4 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -111,6 +111,7 @@ config CROS_EC_SPI
config CROS_EC_LPC
tristate "ChromeOS Embedded Controller (LPC)"
depends on CROS_EC && ACPI && (X86 || COMPILE_TEST)
+ depends on HAS_IOPORT
help
If you say Y here, you get support for talking to the ChromeOS EC
over an LPC bus, including the LPC Microchip EC (MEC) variant.
diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig
index 49e8530ca0ac..d1648fb099ac 100644
--- a/drivers/platform/chrome/wilco_ec/Kconfig
+++ b/drivers/platform/chrome/wilco_ec/Kconfig
@@ -3,6 +3,7 @@ config WILCO_EC
tristate "ChromeOS Wilco Embedded Controller"
depends on X86 || COMPILE_TEST
depends on ACPI && CROS_EC_LPC && LEDS_CLASS
+ depends on HAS_IOPORT
help
If you say Y here, you get support for talking to the ChromeOS
Wilco EC over an eSPI bus. This uses a simple byte-level protocol
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Benson Leung
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/platform/chrome/Kconfig | 1 +
drivers/platform/chrome/wilco_ec/Kconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index ccc23d8686e8..b43ef78e75d4 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -111,6 +111,7 @@ config CROS_EC_SPI
config CROS_EC_LPC
tristate "ChromeOS Embedded Controller (LPC)"
depends on CROS_EC && ACPI && (X86 || COMPILE_TEST)
+ depends on HAS_IOPORT
help
If you say Y here, you get support for talking to the ChromeOS EC
over an LPC bus, including the LPC Microchip EC (MEC) variant.
diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig
index 49e8530ca0ac..d1648fb099ac 100644
--- a/drivers/platform/chrome/wilco_ec/Kconfig
+++ b/drivers/platform/chrome/wilco_ec/Kconfig
@@ -3,6 +3,7 @@ config WILCO_EC
tristate "ChromeOS Wilco Embedded Controller"
depends on X86 || COMPILE_TEST
depends on ACPI && CROS_EC_LPC && LEDS_CLASS
+ depends on HAS_IOPORT
help
If you say Y here, you get support for talking to the ChromeOS
Wilco EC over an eSPI bus. This uses a simple byte-level protocol
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jaroslav Kysela, Rafael J. Wysocki
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-acpi
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to depend on HAS_IOPORT even when
compile testing only.
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>
---
drivers/pnp/isapnp/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pnp/isapnp/Kconfig b/drivers/pnp/isapnp/Kconfig
index d0479a563123..79bd48f1dd94 100644
--- a/drivers/pnp/isapnp/Kconfig
+++ b/drivers/pnp/isapnp/Kconfig
@@ -4,7 +4,7 @@
#
config ISAPNP
bool "ISA Plug and Play support"
- depends on ISA || COMPILE_TEST
+ depends on ISA || (HAS_IOPORT && COMPILE_TEST)
help
Say Y here if you would like support for ISA Plug and Play devices.
Some information is in <file:Documentation/driver-api/isapnp.rst>.
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Jaroslav Kysela, Rafael J. Wysocki
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-acpi
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to depend on HAS_IOPORT even when
compile testing only.
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>
---
drivers/pnp/isapnp/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pnp/isapnp/Kconfig b/drivers/pnp/isapnp/Kconfig
index d0479a563123..79bd48f1dd94 100644
--- a/drivers/pnp/isapnp/Kconfig
+++ b/drivers/pnp/isapnp/Kconfig
@@ -4,7 +4,7 @@
#
config ISAPNP
bool "ISA Plug and Play support"
- depends on ISA || COMPILE_TEST
+ depends on ISA || (HAS_IOPORT && COMPILE_TEST)
help
Say Y here if you would like support for ISA Plug and Play devices.
Some information is in <file:Documentation/driver-api/isapnp.rst>.
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sebastian Reichel
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-pm
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/power/reset/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4b563db3ab3e..96b91eaca0cd 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -151,6 +151,7 @@ config POWER_RESET_OXNAS
config POWER_RESET_PIIX4_POWEROFF
tristate "Intel PIIX4 power-off driver"
depends on PCI
+ depends on HAS_IOPORT
depends on MIPS || COMPILE_TEST
help
This driver supports powering off a system using the Intel PIIX4
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Sebastian Reichel
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-pm
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/power/reset/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4b563db3ab3e..96b91eaca0cd 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -151,6 +151,7 @@ config POWER_RESET_OXNAS
config POWER_RESET_PIIX4_POWEROFF
tristate "Intel PIIX4 power-off driver"
depends on PCI
+ depends on HAS_IOPORT
depends on MIPS || COMPILE_TEST
help
This driver supports powering off a system using the Intel PIIX4
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 22/32] video: handle HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
(?)
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
dri-devel, linux-fbdev
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.
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>
---
drivers/video/fbdev/Kconfig | 1 +
include/video/vga.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index a3446d44c118..d95f638f4deb 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -436,6 +436,7 @@ config FB_FM2
config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
+ depends on HAS_IOPORT
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/include/video/vga.h b/include/video/vga.h
index d334e64c1c19..53cb52c0fddb 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -201,18 +201,26 @@ extern int restore_vga(struct vgastate *state);
static inline unsigned char vga_io_r (unsigned short port)
{
+#ifdef CONFIG_HAS_IOPORT
return inb_p(port);
+#else
+ return 0xff;
+#endif
}
static inline void vga_io_w (unsigned short port, unsigned char val)
{
+#ifdef CONFIG_HAS_IOPORT
outb_p(val, port);
+#endif
}
static inline void vga_io_w_fast (unsigned short port, unsigned char reg,
unsigned char val)
{
+#ifdef CONFIG_HAS_IOPORT
outw(VGA_OUT16VAL (val, reg), port);
+#endif
}
static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short port)
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 22/32] video: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-arch, linux-fbdev, linux-pci, linux-kernel, dri-devel,
linux-csky, linux-riscv
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.
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>
---
drivers/video/fbdev/Kconfig | 1 +
include/video/vga.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index a3446d44c118..d95f638f4deb 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -436,6 +436,7 @@ config FB_FM2
config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
+ depends on HAS_IOPORT
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/include/video/vga.h b/include/video/vga.h
index d334e64c1c19..53cb52c0fddb 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -201,18 +201,26 @@ extern int restore_vga(struct vgastate *state);
static inline unsigned char vga_io_r (unsigned short port)
{
+#ifdef CONFIG_HAS_IOPORT
return inb_p(port);
+#else
+ return 0xff;
+#endif
}
static inline void vga_io_w (unsigned short port, unsigned char val)
{
+#ifdef CONFIG_HAS_IOPORT
outb_p(val, port);
+#endif
}
static inline void vga_io_w_fast (unsigned short port, unsigned char reg,
unsigned char val)
{
+#ifdef CONFIG_HAS_IOPORT
outw(VGA_OUT16VAL (val, reg), port);
+#endif
}
static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short port)
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 22/32] video: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
dri-devel, linux-fbdev
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.
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>
---
drivers/video/fbdev/Kconfig | 1 +
include/video/vga.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index a3446d44c118..d95f638f4deb 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -436,6 +436,7 @@ config FB_FM2
config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
+ depends on HAS_IOPORT
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/include/video/vga.h b/include/video/vga.h
index d334e64c1c19..53cb52c0fddb 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -201,18 +201,26 @@ extern int restore_vga(struct vgastate *state);
static inline unsigned char vga_io_r (unsigned short port)
{
+#ifdef CONFIG_HAS_IOPORT
return inb_p(port);
+#else
+ return 0xff;
+#endif
}
static inline void vga_io_w (unsigned short port, unsigned char val)
{
+#ifdef CONFIG_HAS_IOPORT
outb_p(val, port);
+#endif
}
static inline void vga_io_w_fast (unsigned short port, unsigned char reg,
unsigned char val)
{
+#ifdef CONFIG_HAS_IOPORT
outw(VGA_OUT16VAL (val, reg), port);
+#endif
}
static inline unsigned char vga_mm_r (void __iomem *regbase, unsigned short port)
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Alessandro Zummo, Alexandre Belloni
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-rtc
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/rtc/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 058e56a10ab8..fde2bdb7090d 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -951,6 +951,7 @@ comment "Platform RTC drivers"
config RTC_DRV_CMOS
tristate "PC-style 'CMOS'"
depends on X86 || ARM || PPC || MIPS || SPARC64
+ depends on HAS_IOPORT
default y if X86
select RTC_MC146818_LIB
help
@@ -971,6 +972,7 @@ config RTC_DRV_CMOS
config RTC_DRV_ALPHA
bool "Alpha PC-style CMOS"
depends on ALPHA
+ depends on HAS_IOPORT
select RTC_MC146818_LIB
default y
help
@@ -1188,7 +1190,7 @@ config RTC_DRV_MSM6242
config RTC_DRV_BQ4802
tristate "TI BQ4802"
- depends on HAS_IOMEM
+ depends on HAS_IOMEM && HAS_IOPORT
help
If you say Y here you will get support for the TI
BQ4802 RTC chip.
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Alessandro Zummo, Alexandre Belloni
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-rtc
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/rtc/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 058e56a10ab8..fde2bdb7090d 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -951,6 +951,7 @@ comment "Platform RTC drivers"
config RTC_DRV_CMOS
tristate "PC-style 'CMOS'"
depends on X86 || ARM || PPC || MIPS || SPARC64
+ depends on HAS_IOPORT
default y if X86
select RTC_MC146818_LIB
help
@@ -971,6 +972,7 @@ config RTC_DRV_CMOS
config RTC_DRV_ALPHA
bool "Alpha PC-style CMOS"
depends on ALPHA
+ depends on HAS_IOPORT
select RTC_MC146818_LIB
default y
help
@@ -1188,7 +1190,7 @@ config RTC_DRV_MSM6242
config RTC_DRV_BQ4802
tristate "TI BQ4802"
- depends on HAS_IOMEM
+ depends on HAS_IOMEM && HAS_IOPORT
help
If you say Y here you will get support for the TI
BQ4802 RTC chip.
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
James E.J. Bottomley, Martin K. Petersen
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-scsi
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/scsi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5436b2be2c73..c90c97485fce 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -793,6 +793,7 @@ config SCSI_INIA100
config SCSI_PPA
tristate "IOMEGA parallel port (ppa - older drives)"
depends on SCSI && PARPORT_PC
+ depends on HAS_IOPORT
help
This driver supports older versions of IOMEGA's parallel port ZIP
drive (a 100 MB removable media device).
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
James E.J. Bottomley, Martin K. Petersen
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-scsi
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/scsi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5436b2be2c73..c90c97485fce 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -793,6 +793,7 @@ config SCSI_INIA100
config SCSI_PPA
tristate "IOMEGA parallel port (ppa - older drives)"
depends on SCSI && PARPORT_PC
+ depends on HAS_IOPORT
help
This driver supports older versions of IOMEGA's parallel port ZIP
drive (a 100 MB removable media device).
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-28 10:40 ` Geert Uytterhoeven
-1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:40 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
James E.J. Bottomley, Martin K. Petersen,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, scsi
Hi Niklas,
On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -793,6 +793,7 @@ config SCSI_INIA100
> config SCSI_PPA
> tristate "IOMEGA parallel port (ppa - older drives)"
> depends on SCSI && PARPORT_PC
> + depends on HAS_IOPORT
This is not needed, [04/32] already added that dependency to
PARPORT_PC.
> help
> This driver supports older versions of IOMEGA's parallel port ZIP
> drive (a 100 MB removable media device).
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 10:40 ` Geert Uytterhoeven
0 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2021-12-28 10:40 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
James E.J. Bottomley, Martin K. Petersen,
Linux Kernel Mailing List, Linux-Arch, linux-pci, linux-riscv,
linux-csky, scsi
Hi Niklas,
On Mon, Dec 27, 2021 at 5:53 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> 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/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -793,6 +793,7 @@ config SCSI_INIA100
> config SCSI_PPA
> tristate "IOMEGA parallel port (ppa - older drives)"
> depends on SCSI && PARPORT_PC
> + depends on HAS_IOPORT
This is not needed, [04/32] already added that dependency to
PARPORT_PC.
> help
> This driver supports older versions of IOMEGA's parallel port ZIP
> drive (a 100 MB removable media device).
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
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Wim Van Sebroeck, Guenter Roeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-watchdog
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/watchdog/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 05258109bcc2..2e87a65bdc8b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -452,6 +452,7 @@ config 21285_WATCHDOG
config 977_WATCHDOG
tristate "NetWinder WB83C977 watchdog"
depends on (FOOTBRIDGE && ARCH_NETWINDER) || (ARM && COMPILE_TEST)
+ depends on HAS_IOPORT
help
Say Y here to include support for the WB977 watchdog included in
NetWinder machines. Alternatively say M to compile the driver as
@@ -1200,6 +1201,7 @@ config ITCO_WDT
select WATCHDOG_CORE
depends on I2C || I2C=n
depends on MFD_INTEL_PMC_BXT || !MFD_INTEL_PMC_BXT
+ depends on HAS_IOPORT # for I2C_I801
select LPC_ICH if !EXPERT
select I2C_I801 if !EXPERT && I2C
help
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Wim Van Sebroeck, Guenter Roeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-watchdog
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
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>
---
drivers/watchdog/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 05258109bcc2..2e87a65bdc8b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -452,6 +452,7 @@ config 21285_WATCHDOG
config 977_WATCHDOG
tristate "NetWinder WB83C977 watchdog"
depends on (FOOTBRIDGE && ARCH_NETWINDER) || (ARM && COMPILE_TEST)
+ depends on HAS_IOPORT
help
Say Y here to include support for the WB977 watchdog included in
NetWinder machines. Alternatively say M to compile the driver as
@@ -1200,6 +1201,7 @@ config ITCO_WDT
select WATCHDOG_CORE
depends on I2C || I2C=n
depends on MFD_INTEL_PMC_BXT || !MFD_INTEL_PMC_BXT
+ depends on HAS_IOPORT # for I2C_I801
select LPC_ICH if !EXPERT
select I2C_I801 if !EXPERT && I2C
help
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-27 18:03 ` Guenter Roeck
-1 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 18:03 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Wim Van Sebroeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-watchdog
On 12/27/21 8:43 AM, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
How is the need for HAS_IOPORT determined, when exactly is it needed,
and when not ?
$ git grep -E "inb|inw" drivers/watchdog/ | cut -f1 -d: | sort -u
drivers/watchdog/acquirewdt.c
drivers/watchdog/advantechwdt.c
drivers/watchdog/cpu5wdt.c
drivers/watchdog/f71808e_wdt.c
drivers/watchdog/ibmasr.c
drivers/watchdog/ie6xx_wdt.c
drivers/watchdog/it8712f_wdt.c
drivers/watchdog/it87_wdt.c
drivers/watchdog/iTCO_vendor_support.c
drivers/watchdog/iTCO_wdt.c
drivers/watchdog/Kconfig
drivers/watchdog/machzwd.c
drivers/watchdog/mixcomwd.c
drivers/watchdog/ni903x_wdt.c
drivers/watchdog/nic7018_wdt.c
drivers/watchdog/nv_tco.c
drivers/watchdog/pc87413_wdt.c
drivers/watchdog/pcwd.c
drivers/watchdog/pcwd_pci.c
drivers/watchdog/sbc60xxwdt.c
drivers/watchdog/sbc7240_wdt.c
drivers/watchdog/sc1200wdt.c
drivers/watchdog/sch311x_wdt.c
drivers/watchdog/smsc37b787_wdt.c
drivers/watchdog/sp5100_tco.c
drivers/watchdog/w83627hf_wdt.c
drivers/watchdog/w83877f_wdt.c
drivers/watchdog/w83977f_wdt.c
drivers/watchdog/wafer5823wdt.c
drivers/watchdog/wdt977.c
drivers/watchdog/wdt.c
drivers/watchdog/wdt_pci.c
Guenter
> 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>
> ---
> drivers/watchdog/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 05258109bcc2..2e87a65bdc8b 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -452,6 +452,7 @@ config 21285_WATCHDOG
> config 977_WATCHDOG
> tristate "NetWinder WB83C977 watchdog"
> depends on (FOOTBRIDGE && ARCH_NETWINDER) || (ARM && COMPILE_TEST)
> + depends on HAS_IOPORT
> help
> Say Y here to include support for the WB977 watchdog included in
> NetWinder machines. Alternatively say M to compile the driver as
> @@ -1200,6 +1201,7 @@ config ITCO_WDT
> select WATCHDOG_CORE
> depends on I2C || I2C=n
> depends on MFD_INTEL_PMC_BXT || !MFD_INTEL_PMC_BXT
> + depends on HAS_IOPORT # for I2C_I801
> select LPC_ICH if !EXPERT
> select I2C_I801 if !EXPERT && I2C
> help
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-27 18:03 ` Guenter Roeck
0 siblings, 0 replies; 323+ messages in thread
From: Guenter Roeck @ 2021-12-27 18:03 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, John Garry,
Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Guo Ren, Wim Van Sebroeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-watchdog
On 12/27/21 8:43 AM, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
How is the need for HAS_IOPORT determined, when exactly is it needed,
and when not ?
$ git grep -E "inb|inw" drivers/watchdog/ | cut -f1 -d: | sort -u
drivers/watchdog/acquirewdt.c
drivers/watchdog/advantechwdt.c
drivers/watchdog/cpu5wdt.c
drivers/watchdog/f71808e_wdt.c
drivers/watchdog/ibmasr.c
drivers/watchdog/ie6xx_wdt.c
drivers/watchdog/it8712f_wdt.c
drivers/watchdog/it87_wdt.c
drivers/watchdog/iTCO_vendor_support.c
drivers/watchdog/iTCO_wdt.c
drivers/watchdog/Kconfig
drivers/watchdog/machzwd.c
drivers/watchdog/mixcomwd.c
drivers/watchdog/ni903x_wdt.c
drivers/watchdog/nic7018_wdt.c
drivers/watchdog/nv_tco.c
drivers/watchdog/pc87413_wdt.c
drivers/watchdog/pcwd.c
drivers/watchdog/pcwd_pci.c
drivers/watchdog/sbc60xxwdt.c
drivers/watchdog/sbc7240_wdt.c
drivers/watchdog/sc1200wdt.c
drivers/watchdog/sch311x_wdt.c
drivers/watchdog/smsc37b787_wdt.c
drivers/watchdog/sp5100_tco.c
drivers/watchdog/w83627hf_wdt.c
drivers/watchdog/w83877f_wdt.c
drivers/watchdog/w83977f_wdt.c
drivers/watchdog/wafer5823wdt.c
drivers/watchdog/wdt977.c
drivers/watchdog/wdt.c
drivers/watchdog/wdt_pci.c
Guenter
> 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>
> ---
> drivers/watchdog/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 05258109bcc2..2e87a65bdc8b 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -452,6 +452,7 @@ config 21285_WATCHDOG
> config 977_WATCHDOG
> tristate "NetWinder WB83C977 watchdog"
> depends on (FOOTBRIDGE && ARCH_NETWINDER) || (ARM && COMPILE_TEST)
> + depends on HAS_IOPORT
> help
> Say Y here to include support for the WB977 watchdog included in
> NetWinder machines. Alternatively say M to compile the driver as
> @@ -1200,6 +1201,7 @@ config ITCO_WDT
> select WATCHDOG_CORE
> depends on I2C || I2C=n
> depends on MFD_INTEL_PMC_BXT || !MFD_INTEL_PMC_BXT
> + depends on HAS_IOPORT # for I2C_I801
> select LPC_ICH if !EXPERT
> select I2C_I801 if !EXPERT && I2C
> help
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
2021-12-27 18:03 ` Guenter Roeck
@ 2021-12-28 9:58 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 9:58 UTC (permalink / raw)
To: Guenter Roeck, Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Wim Van Sebroeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-watchdog
On Mon, 2021-12-27 at 10:03 -0800, Guenter Roeck wrote:
> On 12/27/21 8:43 AM, Niklas Schnelle wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
>
> How is the need for HAS_IOPORT determined, when exactly is it needed,
> and when not ?
I mostly used "make allyesconfig" on s390 with the accessors ifdeffed
out (i.e. patch 32) to find where the I/O port accesses were compiled
in. This means that it doesn't find drivers which pull in a HAS_IOPORT
dependency transitively e.g. by depending on x86 or ACPI. It should get
those that use e.g. "|| COMPILE_TEST" though. This might not be ideal
but on the other hand it should catch all those drivers that currently
built with known broken code.
>
> $ git grep -E "inb|inw" drivers/watchdog/ | cut -f1 -d: | sort -u
> drivers/watchdog/acquirewdt.c
> drivers/watchdog/advantechwdt.c
>
---8<---
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
@ 2021-12-28 9:58 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 9:58 UTC (permalink / raw)
To: Guenter Roeck, Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, Wim Van Sebroeck
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-watchdog
On Mon, 2021-12-27 at 10:03 -0800, Guenter Roeck wrote:
> On 12/27/21 8:43 AM, Niklas Schnelle wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
>
> How is the need for HAS_IOPORT determined, when exactly is it needed,
> and when not ?
I mostly used "make allyesconfig" on s390 with the accessors ifdeffed
out (i.e. patch 32) to find where the I/O port accesses were compiled
in. This means that it doesn't find drivers which pull in a HAS_IOPORT
dependency transitively e.g. by depending on x86 or ACPI. It should get
those that use e.g. "|| COMPILE_TEST" though. This might not be ideal
but on the other hand it should catch all those drivers that currently
built with known broken code.
>
> $ git grep -E "inb|inw" drivers/watchdog/ | cut -f1 -d: | sort -u
> drivers/watchdog/acquirewdt.c
> drivers/watchdog/advantechwdt.c
>
---8<---
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 26/32] drm: handle HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
(?)
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dave Airlie, Gerd Hoffmann, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
virtualization, spice-devel, dri-devel
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. There is also a direct and hard coded use in
cirrus.c which according to the comment is only necessary during resume.
Let's just skip this as for example s390 which doesn't have I/O port
support also doesen't support suspend/resume.
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>
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/cirrus.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index ca3f51c2a8fe..d0e0d440c8d9 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 1ceb93fbdc50..81749943af13 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -13,6 +13,7 @@ config DRM_ARCPGU
config DRM_BOCHS
tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
select DRM_TTM
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 4611ec408506..c9b6e9779d18 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -306,8 +306,10 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
cirrus_set_start_address(cirrus, 0);
+#ifdef CONFIG_HAS_IOPORT
/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(0x20, 0x3c0);
+#endif
drm_dev_exit(idx);
return 0;
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 26/32] drm: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dave Airlie, Gerd Hoffmann, David Airlie, Daniel Vetter
Cc: linux-arch, linux-pci, linux-kernel, linux-csky, virtualization,
dri-devel, spice-devel, linux-riscv
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. There is also a direct and hard coded use in
cirrus.c which according to the comment is only necessary during resume.
Let's just skip this as for example s390 which doesn't have I/O port
support also doesen't support suspend/resume.
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>
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/cirrus.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index ca3f51c2a8fe..d0e0d440c8d9 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 1ceb93fbdc50..81749943af13 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -13,6 +13,7 @@ config DRM_ARCPGU
config DRM_BOCHS
tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
select DRM_TTM
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 4611ec408506..c9b6e9779d18 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -306,8 +306,10 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
cirrus_set_start_address(cirrus, 0);
+#ifdef CONFIG_HAS_IOPORT
/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(0x20, 0x3c0);
+#endif
drm_dev_exit(idx);
return 0;
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 26/32] drm: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dave Airlie, Gerd Hoffmann, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
virtualization, spice-devel, dri-devel
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. There is also a direct and hard coded use in
cirrus.c which according to the comment is only necessary during resume.
Let's just skip this as for example s390 which doesn't have I/O port
support also doesen't support suspend/resume.
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>
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/cirrus.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index ca3f51c2a8fe..d0e0d440c8d9 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 1ceb93fbdc50..81749943af13 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -13,6 +13,7 @@ config DRM_ARCPGU
config DRM_BOCHS
tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
select DRM_TTM
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 4611ec408506..c9b6e9779d18 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -306,8 +306,10 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
cirrus_set_start_address(cirrus, 0);
+#ifdef CONFIG_HAS_IOPORT
/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(0x20, 0x3c0);
+#endif
drm_dev_exit(idx);
return 0;
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 26/32] drm: handle HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
(?)
(?)
@ 2022-01-03 6:11 ` Gerd Hoffmann
-1 siblings, 0 replies; 323+ messages in thread
From: Gerd Hoffmann @ 2022-01-03 6:11 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-arch, Arnd Bergmann, Albert Ou, Dave Airlie, Nick Hu,
David Airlie, linux-pci, dri-devel, John Garry, linux-kernel,
linux-csky, virtualization, Palmer Dabbelt, Greentime Hu,
Daniel Vetter, Paul Walmsley, Bjorn Helgaas, Guo Ren, linux-riscv,
Vincent Chen, spice-devel
On Mon, Dec 27, 2021 at 05:43:11PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which according to the comment is only necessary during resume.
> Let's just skip this as for example s390 which doesn't have I/O port
> support also doesen't support suspend/resume.
> config DRM_BOCHS
> tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
> depends on DRM && PCI && MMU
> + depends on HAS_IOPORT
> select DRM_KMS_HELPER
> select DRM_VRAM_HELPER
> select DRM_TTM
On devices with an mmio bar the driver works just fine without inb/outb,
see bochs->mmio checks in bochs.c
take care,
Gerd
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 26/32] drm: handle HAS_IOPORT dependencies
@ 2022-01-03 6:11 ` Gerd Hoffmann
0 siblings, 0 replies; 323+ messages in thread
From: Gerd Hoffmann @ 2022-01-03 6:11 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dave Airlie, David Airlie, Daniel Vetter, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, virtualization,
spice-devel, dri-devel
On Mon, Dec 27, 2021 at 05:43:11PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which according to the comment is only necessary during resume.
> Let's just skip this as for example s390 which doesn't have I/O port
> support also doesen't support suspend/resume.
> config DRM_BOCHS
> tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
> depends on DRM && PCI && MMU
> + depends on HAS_IOPORT
> select DRM_KMS_HELPER
> select DRM_VRAM_HELPER
> select DRM_TTM
On devices with an mmio bar the driver works just fine without inb/outb,
see bochs->mmio checks in bochs.c
take care,
Gerd
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 26/32] drm: handle HAS_IOPORT dependencies
@ 2022-01-03 6:11 ` Gerd Hoffmann
0 siblings, 0 replies; 323+ messages in thread
From: Gerd Hoffmann @ 2022-01-03 6:11 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-arch, Arnd Bergmann, Albert Ou, Dave Airlie, Nick Hu,
David Airlie, linux-pci, dri-devel, John Garry, linux-kernel,
linux-csky, virtualization, Palmer Dabbelt, Greentime Hu,
Paul Walmsley, Bjorn Helgaas, Guo Ren, linux-riscv, Vincent Chen,
spice-devel
On Mon, Dec 27, 2021 at 05:43:11PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which according to the comment is only necessary during resume.
> Let's just skip this as for example s390 which doesn't have I/O port
> support also doesen't support suspend/resume.
> config DRM_BOCHS
> tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
> depends on DRM && PCI && MMU
> + depends on HAS_IOPORT
> select DRM_KMS_HELPER
> select DRM_VRAM_HELPER
> select DRM_TTM
On devices with an mmio bar the driver works just fine without inb/outb,
see bochs->mmio checks in bochs.c
take care,
Gerd
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 26/32] drm: handle HAS_IOPORT dependencies
@ 2022-01-03 6:11 ` Gerd Hoffmann
0 siblings, 0 replies; 323+ messages in thread
From: Gerd Hoffmann @ 2022-01-03 6:11 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dave Airlie, David Airlie, Daniel Vetter, linux-kernel,
linux-arch, linux-pci, linux-riscv, linux-csky, virtualization,
spice-devel, dri-devel
On Mon, Dec 27, 2021 at 05:43:11PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which according to the comment is only necessary during resume.
> Let's just skip this as for example s390 which doesn't have I/O port
> support also doesen't support suspend/resume.
> config DRM_BOCHS
> tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
> depends on DRM && PCI && MMU
> + depends on HAS_IOPORT
> select DRM_KMS_HELPER
> select DRM_VRAM_HELPER
> select DRM_TTM
On devices with an mmio bar the driver works just fine without inb/outb,
see bochs->mmio checks in bochs.c
take care,
Gerd
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Exporting I/O resources only makes sense if legacy I/O spaces are
supported so conditionally add them only if HAS_IOPORT is set.
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>
---
drivers/pci/pci-sysfs.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index cfe2f85af09e..a59a85593972 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1099,6 +1099,7 @@ static int pci_mmap_resource_wc(struct file *filp, struct kobject *kobj,
return pci_mmap_resource(kobj, attr, vma, 1);
}
+#ifdef CONFIG_HAS_IOPORT
static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count, bool write)
@@ -1157,6 +1158,21 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
}
+#else
+static ssize_t pci_read_resource_io(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t off, size_t count)
+{
+ return -ENXIO;
+}
+
+static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t off, size_t count)
+{
+ return -ENXIO;
+}
+#endif
/**
* pci_remove_resource_files - cleanup resource files
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Exporting I/O resources only makes sense if legacy I/O spaces are
supported so conditionally add them only if HAS_IOPORT is set.
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>
---
drivers/pci/pci-sysfs.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index cfe2f85af09e..a59a85593972 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1099,6 +1099,7 @@ static int pci_mmap_resource_wc(struct file *filp, struct kobject *kobj,
return pci_mmap_resource(kobj, attr, vma, 1);
}
+#ifdef CONFIG_HAS_IOPORT
static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count, bool write)
@@ -1157,6 +1158,21 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
}
+#else
+static ssize_t pci_read_resource_io(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t off, size_t count)
+{
+ return -ENXIO;
+}
+
+static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t off, size_t count)
+{
+ return -ENXIO;
+}
+#endif
/**
* pci_remove_resource_files - cleanup resource files
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread* Re: [RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-27 22:04 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-27 22:04 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Make the subject match historical convention (capitalize "Make").
On Mon, Dec 27, 2021 at 05:43:12PM +0100, Niklas Schnelle wrote:
> Exporting I/O resources only makes sense if legacy I/O spaces are
> supported so conditionally add them only if HAS_IOPORT is set.
IIUC, the effect of this is that the "resource%d" file for an I/O BAR
still appears in /sys, but reads or writes will fail with ENXIO.
Worth mentioning that in the commit log, since one could interpret the
above as meaning that the "resource%d" file exists only if HAS_IOPORT
is set. I think I will *exist* but not be very useful.
I also wonder what this looks like in the sysfs "resource" file and
via lspci. I suppose it's useful if lspci shows the fact that the BAR
exists and is an I/O BAR, even if the arch doesn't set HAS_IOPORT.
> 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>
> ---
> drivers/pci/pci-sysfs.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index cfe2f85af09e..a59a85593972 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1099,6 +1099,7 @@ static int pci_mmap_resource_wc(struct file *filp, struct kobject *kobj,
> return pci_mmap_resource(kobj, attr, vma, 1);
> }
>
> +#ifdef CONFIG_HAS_IOPORT
> static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
> struct bin_attribute *attr, char *buf,
> loff_t off, size_t count, bool write)
> @@ -1157,6 +1158,21 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
>
> return pci_resource_io(filp, kobj, attr, buf, off, count, true);
> }
> +#else
> +static ssize_t pci_read_resource_io(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr, char *buf,
> + loff_t off, size_t count)
> +{
> + return -ENXIO;
> +}
I assume the sysfs infrastructure prevents or fails reads/write if
res_attr->read and res_attr->write are not set at all, so maybe we
wouldn't need the stubs if we did something like this?
if (pci_resource_flags(pdev, num) & IORESOURCE_IO) {
#ifdef CONFIG_HAS_IOPORT
res_attr->read = pci_read_resource_io;
res_attr->write = pci_write_resource_io;
...
#endif
} else {
> +static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr, char *buf,
> + loff_t off, size_t count)
> +{
> + return -ENXIO;
> +}
> +#endif
>
> /**
> * pci_remove_resource_files - cleanup resource files
> --
> 2.32.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
@ 2021-12-27 22:04 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-27 22:04 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Make the subject match historical convention (capitalize "Make").
On Mon, Dec 27, 2021 at 05:43:12PM +0100, Niklas Schnelle wrote:
> Exporting I/O resources only makes sense if legacy I/O spaces are
> supported so conditionally add them only if HAS_IOPORT is set.
IIUC, the effect of this is that the "resource%d" file for an I/O BAR
still appears in /sys, but reads or writes will fail with ENXIO.
Worth mentioning that in the commit log, since one could interpret the
above as meaning that the "resource%d" file exists only if HAS_IOPORT
is set. I think I will *exist* but not be very useful.
I also wonder what this looks like in the sysfs "resource" file and
via lspci. I suppose it's useful if lspci shows the fact that the BAR
exists and is an I/O BAR, even if the arch doesn't set HAS_IOPORT.
> 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>
> ---
> drivers/pci/pci-sysfs.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index cfe2f85af09e..a59a85593972 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1099,6 +1099,7 @@ static int pci_mmap_resource_wc(struct file *filp, struct kobject *kobj,
> return pci_mmap_resource(kobj, attr, vma, 1);
> }
>
> +#ifdef CONFIG_HAS_IOPORT
> static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,
> struct bin_attribute *attr, char *buf,
> loff_t off, size_t count, bool write)
> @@ -1157,6 +1158,21 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
>
> return pci_resource_io(filp, kobj, attr, buf, off, count, true);
> }
> +#else
> +static ssize_t pci_read_resource_io(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr, char *buf,
> + loff_t off, size_t count)
> +{
> + return -ENXIO;
> +}
I assume the sysfs infrastructure prevents or fails reads/write if
res_attr->read and res_attr->write are not set at all, so maybe we
wouldn't need the stubs if we did something like this?
if (pci_resource_flags(pdev, num) & IORESOURCE_IO) {
#ifdef CONFIG_HAS_IOPORT
res_attr->read = pci_read_resource_io;
res_attr->write = pci_write_resource_io;
...
#endif
} else {
> +static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr, char *buf,
> + loff_t off, size_t count)
> +{
> + return -ENXIO;
> +}
> +#endif
>
> /**
> * pci_remove_resource_files - cleanup resource files
> --
> 2.32.0
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In the future inw()/outw() and friends will not be compiled on
architectures without I/O port support.
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>
---
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 003950c738d2..8624c98c57b2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -265,6 +265,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_1, quirk_isa_d
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_2, quirk_isa_dma_hangs);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_3, quirk_isa_dma_hangs);
+#ifdef CONFIG_HAS_IOPORT
/*
* Intel NM10 "TigerPoint" LPC PM1a_STS.BM_STS must be clear
* for some HT machines to use C4 w/o hanging.
@@ -284,6 +285,7 @@ static void quirk_tigerpoint_bm_sts(struct pci_dev *dev)
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TGP_LPC, quirk_tigerpoint_bm_sts);
+#endif
/* Chipsets where PCI->PCI transfers vanish or hang */
static void quirk_nopcipci(struct pci_dev *dev)
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In the future inw()/outw() and friends will not be compiled on
architectures without I/O port support.
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>
---
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 003950c738d2..8624c98c57b2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -265,6 +265,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_1, quirk_isa_d
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_2, quirk_isa_dma_hangs);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_3, quirk_isa_dma_hangs);
+#ifdef CONFIG_HAS_IOPORT
/*
* Intel NM10 "TigerPoint" LPC PM1a_STS.BM_STS must be clear
* for some HT machines to use C4 w/o hanging.
@@ -284,6 +285,7 @@ static void quirk_tigerpoint_bm_sts(struct pci_dev *dev)
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TGP_LPC, quirk_tigerpoint_bm_sts);
+#endif
/* Chipsets where PCI->PCI transfers vanish or hang */
static void quirk_nopcipci(struct pci_dev *dev)
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-27 22:33 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-27 22:33 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> In the future inw()/outw() and friends will not be compiled on
> architectures without I/O port support.
This commit log actually doesn't say what the patch does.
I'm pretty sure this particular quirk is x86 specific and could
probably be moved to arch/x86/pci/fixup.c, where the #ifdef probably
wouldn't be needed.
If we keep it in drivers/pci, please update the subject line to make
it more specific and match the convention, e.g.,
PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
BTW, git complains about some whitespace errors in other patches:
Applying: char: impi, tpm: depend on HAS_IOPORT
.git/rebase-apply/patch:92: trailing whitespace.
If you have a TPM security chip from Atmel say Yes and it
.git/rebase-apply/patch:93: trailing whitespace.
will be accessible from within Linux. To compile this driver
warning: 2 lines add whitespace errors.
Applying: video: handle HAS_IOPORT dependencies
.git/rebase-apply/patch:23: trailing whitespace.
warning: 1 line adds whitespace errors.
> 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>
> ---
> drivers/pci/quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 003950c738d2..8624c98c57b2 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -265,6 +265,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_1, quirk_isa_d
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_2, quirk_isa_dma_hangs);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_3, quirk_isa_dma_hangs);
>
> +#ifdef CONFIG_HAS_IOPORT
> /*
> * Intel NM10 "TigerPoint" LPC PM1a_STS.BM_STS must be clear
> * for some HT machines to use C4 w/o hanging.
> @@ -284,6 +285,7 @@ static void quirk_tigerpoint_bm_sts(struct pci_dev *dev)
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TGP_LPC, quirk_tigerpoint_bm_sts);
> +#endif
>
> /* Chipsets where PCI->PCI transfers vanish or hang */
> static void quirk_nopcipci(struct pci_dev *dev)
> --
> 2.32.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
@ 2021-12-27 22:33 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-27 22:33 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> In the future inw()/outw() and friends will not be compiled on
> architectures without I/O port support.
This commit log actually doesn't say what the patch does.
I'm pretty sure this particular quirk is x86 specific and could
probably be moved to arch/x86/pci/fixup.c, where the #ifdef probably
wouldn't be needed.
If we keep it in drivers/pci, please update the subject line to make
it more specific and match the convention, e.g.,
PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
BTW, git complains about some whitespace errors in other patches:
Applying: char: impi, tpm: depend on HAS_IOPORT
.git/rebase-apply/patch:92: trailing whitespace.
If you have a TPM security chip from Atmel say Yes and it
.git/rebase-apply/patch:93: trailing whitespace.
will be accessible from within Linux. To compile this driver
warning: 2 lines add whitespace errors.
Applying: video: handle HAS_IOPORT dependencies
.git/rebase-apply/patch:23: trailing whitespace.
warning: 1 line adds whitespace errors.
> 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>
> ---
> drivers/pci/quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 003950c738d2..8624c98c57b2 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -265,6 +265,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_1, quirk_isa_d
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_2, quirk_isa_dma_hangs);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_CBUS_3, quirk_isa_dma_hangs);
>
> +#ifdef CONFIG_HAS_IOPORT
> /*
> * Intel NM10 "TigerPoint" LPC PM1a_STS.BM_STS must be clear
> * for some HT machines to use C4 w/o hanging.
> @@ -284,6 +285,7 @@ static void quirk_tigerpoint_bm_sts(struct pci_dev *dev)
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TGP_LPC, quirk_tigerpoint_bm_sts);
> +#endif
>
> /* Chipsets where PCI->PCI transfers vanish or hang */
> static void quirk_nopcipci(struct pci_dev *dev)
> --
> 2.32.0
>
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
2021-12-27 22:33 ` Bjorn Helgaas
@ 2021-12-28 15:25 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:25 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > In the future inw()/outw() and friends will not be compiled on
> > architectures without I/O port support.
>
> This commit log actually doesn't say what the patch does.
>
> I'm pretty sure this particular quirk is x86 specific and could
> probably be moved to arch/x86/pci/fixup.c, where the #ifdef probably
> wouldn't be needed.
Will look into it, that does sound like a nicer solution. Thanks!
>
> If we keep it in drivers/pci, please update the subject line to make
> it more specific and match the convention, e.g.,
>
> PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
Ah yeah I was going back and forth between matching this within the
series vs matching the subsystem. I guess going with the subsystem is
mote important long term.
>
> BTW, git complains about some whitespace errors in other patches:
>
> Applying: char: impi, tpm: depend on HAS_IOPORT
> .git/rebase-apply/patch:92: trailing whitespace.
> If you have a TPM security chip from Atmel say Yes and it
> .git/rebase-apply/patch:93: trailing whitespace.
> will be accessible from within Linux. To compile this driver
> warning: 2 lines add whitespace errors.
> Applying: video: handle HAS_IOPORT dependencies
> .git/rebase-apply/patch:23: trailing whitespace.
>
> warning: 1 line adds whitespace errors.
That is very strange. I did run checkpatch before. There are a few
warnings not to touch obsolete code unnecessarily and a check about
using udelay() (pre-existing) plus two missing blank lines in pci-
quirks.h that I ignored because it matches the sorounding style.
I did notice that lore fails to render the subject lines for some of
the patches. But I just tried fetching the patches with b4 on top of
v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
use to check?
>
> > 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>
> > ---
---8<---
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
@ 2021-12-28 15:25 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 15:25 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > In the future inw()/outw() and friends will not be compiled on
> > architectures without I/O port support.
>
> This commit log actually doesn't say what the patch does.
>
> I'm pretty sure this particular quirk is x86 specific and could
> probably be moved to arch/x86/pci/fixup.c, where the #ifdef probably
> wouldn't be needed.
Will look into it, that does sound like a nicer solution. Thanks!
>
> If we keep it in drivers/pci, please update the subject line to make
> it more specific and match the convention, e.g.,
>
> PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
Ah yeah I was going back and forth between matching this within the
series vs matching the subsystem. I guess going with the subsystem is
mote important long term.
>
> BTW, git complains about some whitespace errors in other patches:
>
> Applying: char: impi, tpm: depend on HAS_IOPORT
> .git/rebase-apply/patch:92: trailing whitespace.
> If you have a TPM security chip from Atmel say Yes and it
> .git/rebase-apply/patch:93: trailing whitespace.
> will be accessible from within Linux. To compile this driver
> warning: 2 lines add whitespace errors.
> Applying: video: handle HAS_IOPORT dependencies
> .git/rebase-apply/patch:23: trailing whitespace.
>
> warning: 1 line adds whitespace errors.
That is very strange. I did run checkpatch before. There are a few
warnings not to touch obsolete code unnecessarily and a check about
using udelay() (pre-existing) plus two missing blank lines in pci-
quirks.h that I ignored because it matches the sorounding style.
I did notice that lore fails to render the subject lines for some of
the patches. But I just tried fetching the patches with b4 on top of
v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
use to check?
>
> > 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>
> > ---
---8<---
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
2021-12-28 15:25 ` Niklas Schnelle
@ 2021-12-28 16:35 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-28 16:35 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > If we keep it in drivers/pci, please update the subject line to make
> > it more specific and match the convention, e.g.,
> >
> > PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
>
> Ah yeah I was going back and forth between matching this within the
> series vs matching the subsystem. I guess going with the subsystem is
> mote important long term.
Haha, yes, a little ambiguity there. I do think the subsystem is more
important because the identity of the series is mostly lost after it's
applied. Thanks for thinking about it!
> > BTW, git complains about some whitespace errors in other patches:
> >
> > Applying: char: impi, tpm: depend on HAS_IOPORT
> > .git/rebase-apply/patch:92: trailing whitespace.
> > If you have a TPM security chip from Atmel say Yes and it
> > .git/rebase-apply/patch:93: trailing whitespace.
> > will be accessible from within Linux. To compile this driver
> > warning: 2 lines add whitespace errors.
> > Applying: video: handle HAS_IOPORT dependencies
> > .git/rebase-apply/patch:23: trailing whitespace.
> >
> > warning: 1 line adds whitespace errors.
>
> That is very strange. I did run checkpatch before. There are a few
> warnings not to touch obsolete code unnecessarily and a check about
> using udelay() (pre-existing) plus two missing blank lines in pci-
> quirks.h that I ignored because it matches the sorounding style.
>
> I did notice that lore fails to render the subject lines for some of
> the patches. But I just tried fetching the patches with b4 on top of
> v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
> v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
> use to check?
"git am" is what complained. Here's what I did:
$ git checkout -b wip/niklas v5.16-rc1
Switched to a new branch 'wip/niklas'
10:30:06 ~/linux (wip/niklas)$ b4 am -om/ 20211227164317.4146918-1-schnelle@linux.ibm.com
Looking up https://lore.kernel.org/r/20211227164317.4146918-1-schnelle%40linux.ibm.com
Grabbing thread from lore.kernel.org/all/20211227164317.4146918-1-schnelle%40linux.ibm.com/t.mbox.gz
Analyzing 70 messages in the thread
Checking attestation on all messages, may take a moment...
---
✓ [PATCH RFC 1/32] Kconfig: introduce and depend on LEGACY_PCI
✓ [PATCH RFC 2/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
✓ [PATCH RFC 3/32] ACPI: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 4/32] parport: PC style parport depends on HAS_IOPORT
✓ [PATCH RFC 5/32] char: impi, tpm: depend on HAS_IOPORT
✓ [PATCH RFC 6/32] speakup: Kconfig: add HAS_IOPORT dependencies
+ Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
✓ [PATCH RFC 7/32] Input: gameport: add ISA and HAS_IOPORT dependencies
✓ [PATCH RFC 8/32] comedi: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 9/32] sound: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 16/32] misc: handle HAS_IOPORT dependencies
✓ [PATCH RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
+ Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
✓ [PATCH RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
+ Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
✓ [PATCH RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 22/32] video: handle HAS_IOPORT dependencies
✓ [PATCH RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 26/32] drm: handle HAS_IOPORT dependencies
✓ [PATCH RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
✓ [PATCH RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
✓ [PATCH RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
✓ [PATCH RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
✓ [PATCH RFC 31/32] usb: handle HAS_IOPORT dependencies
✓ [PATCH RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
---
✓ Signed: DKIM/ibm.com (From: schnelle@linux.ibm.com)
---
Total patches: 32
---
Cover: m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.cover
Link: https://lore.kernel.org/r/20211227164317.4146918-1-schnelle@linux.ibm.com
Base: not specified
git am m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.mbx
10:30:32 ~/linux (wip/niklas)$ git am m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.mbx
Applying: Kconfig: introduce and depend on LEGACY_PCI
Applying: Kconfig: introduce HAS_IOPORT option and select it as necessary
Applying: ACPI: Kconfig: add HAS_IOPORT dependencies
Applying: parport: PC style parport depends on HAS_IOPORT
Applying: char: impi, tpm: depend on HAS_IOPORT
.git/rebase-apply/patch:92: trailing whitespace.
If you have a TPM security chip from Atmel say Yes and it
.git/rebase-apply/patch:93: trailing whitespace.
will be accessible from within Linux. To compile this driver
warning: 2 lines add whitespace errors.
Applying: speakup: Kconfig: add HAS_IOPORT dependencies
Applying: Input: gameport: add ISA and HAS_IOPORT dependencies
Applying: comedi: Kconfig: add HAS_IOPORT dependencies
Applying: sound: Kconfig: add HAS_IOPORT dependencies
Applying: i2c: Kconfig: add HAS_IOPORT dependencies
Applying: Input: Kconfig: add HAS_IOPORT dependencies
Applying: iio: adc: Kconfig: add HAS_IOPORT dependencies
Applying: hwmon: Kconfig: add HAS_IOPORT dependencies
Applying: leds: Kconfig: add HAS_IOPORT dependencies
Applying: media: Kconfig: add HAS_IOPORT dependencies
Applying: misc: handle HAS_IOPORT dependencies
Applying: net: Kconfig: add HAS_IOPORT dependencies
Applying: pcmcia: Kconfig: add HAS_IOPORT dependencies
Applying: platform: Kconfig: add HAS_IOPORT dependencies
Applying: pnp: Kconfig: add HAS_IOPORT dependencies
Applying: power: Kconfig: add HAS_IOPORT dependencies
Applying: video: handle HAS_IOPORT dependencies
.git/rebase-apply/patch:23: trailing whitespace.
warning: 1 line adds whitespace errors.
Applying: rtc: Kconfig: add HAS_IOPORT dependencies
Applying: scsi: Kconfig: add HAS_IOPORT dependencies
Applying: watchdog: Kconfig: add HAS_IOPORT dependencies
Applying: drm: handle HAS_IOPORT dependencies
Applying: PCI/sysfs: make I/O resource depend on HAS_IOPORT
Applying: PCI: make quirk using inw() depend on HAS_IOPORT
Applying: firmware: dmi-sysfs: handle HAS_IOPORT dependencies
Applying: /dev/port: don't compile file operations without CONFIG_DEVPORT
Applying: usb: handle HAS_IOPORT dependencies
Applying: asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
10:30:55 ~/linux (wip/niklas)$
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
@ 2021-12-28 16:35 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-28 16:35 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > If we keep it in drivers/pci, please update the subject line to make
> > it more specific and match the convention, e.g.,
> >
> > PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
>
> Ah yeah I was going back and forth between matching this within the
> series vs matching the subsystem. I guess going with the subsystem is
> mote important long term.
Haha, yes, a little ambiguity there. I do think the subsystem is more
important because the identity of the series is mostly lost after it's
applied. Thanks for thinking about it!
> > BTW, git complains about some whitespace errors in other patches:
> >
> > Applying: char: impi, tpm: depend on HAS_IOPORT
> > .git/rebase-apply/patch:92: trailing whitespace.
> > If you have a TPM security chip from Atmel say Yes and it
> > .git/rebase-apply/patch:93: trailing whitespace.
> > will be accessible from within Linux. To compile this driver
> > warning: 2 lines add whitespace errors.
> > Applying: video: handle HAS_IOPORT dependencies
> > .git/rebase-apply/patch:23: trailing whitespace.
> >
> > warning: 1 line adds whitespace errors.
>
> That is very strange. I did run checkpatch before. There are a few
> warnings not to touch obsolete code unnecessarily and a check about
> using udelay() (pre-existing) plus two missing blank lines in pci-
> quirks.h that I ignored because it matches the sorounding style.
>
> I did notice that lore fails to render the subject lines for some of
> the patches. But I just tried fetching the patches with b4 on top of
> v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
> v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
> use to check?
"git am" is what complained. Here's what I did:
$ git checkout -b wip/niklas v5.16-rc1
Switched to a new branch 'wip/niklas'
10:30:06 ~/linux (wip/niklas)$ b4 am -om/ 20211227164317.4146918-1-schnelle@linux.ibm.com
Looking up https://lore.kernel.org/r/20211227164317.4146918-1-schnelle%40linux.ibm.com
Grabbing thread from lore.kernel.org/all/20211227164317.4146918-1-schnelle%40linux.ibm.com/t.mbox.gz
Analyzing 70 messages in the thread
Checking attestation on all messages, may take a moment...
---
✓ [PATCH RFC 1/32] Kconfig: introduce and depend on LEGACY_PCI
✓ [PATCH RFC 2/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
✓ [PATCH RFC 3/32] ACPI: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 4/32] parport: PC style parport depends on HAS_IOPORT
✓ [PATCH RFC 5/32] char: impi, tpm: depend on HAS_IOPORT
✓ [PATCH RFC 6/32] speakup: Kconfig: add HAS_IOPORT dependencies
+ Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
✓ [PATCH RFC 7/32] Input: gameport: add ISA and HAS_IOPORT dependencies
✓ [PATCH RFC 8/32] comedi: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 9/32] sound: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 16/32] misc: handle HAS_IOPORT dependencies
✓ [PATCH RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
+ Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
✓ [PATCH RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
+ Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
✓ [PATCH RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 22/32] video: handle HAS_IOPORT dependencies
✓ [PATCH RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
✓ [PATCH RFC 26/32] drm: handle HAS_IOPORT dependencies
✓ [PATCH RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
✓ [PATCH RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
✓ [PATCH RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
✓ [PATCH RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
✓ [PATCH RFC 31/32] usb: handle HAS_IOPORT dependencies
✓ [PATCH RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
---
✓ Signed: DKIM/ibm.com (From: schnelle@linux.ibm.com)
---
Total patches: 32
---
Cover: m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.cover
Link: https://lore.kernel.org/r/20211227164317.4146918-1-schnelle@linux.ibm.com
Base: not specified
git am m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.mbx
10:30:32 ~/linux (wip/niklas)$ git am m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.mbx
Applying: Kconfig: introduce and depend on LEGACY_PCI
Applying: Kconfig: introduce HAS_IOPORT option and select it as necessary
Applying: ACPI: Kconfig: add HAS_IOPORT dependencies
Applying: parport: PC style parport depends on HAS_IOPORT
Applying: char: impi, tpm: depend on HAS_IOPORT
.git/rebase-apply/patch:92: trailing whitespace.
If you have a TPM security chip from Atmel say Yes and it
.git/rebase-apply/patch:93: trailing whitespace.
will be accessible from within Linux. To compile this driver
warning: 2 lines add whitespace errors.
Applying: speakup: Kconfig: add HAS_IOPORT dependencies
Applying: Input: gameport: add ISA and HAS_IOPORT dependencies
Applying: comedi: Kconfig: add HAS_IOPORT dependencies
Applying: sound: Kconfig: add HAS_IOPORT dependencies
Applying: i2c: Kconfig: add HAS_IOPORT dependencies
Applying: Input: Kconfig: add HAS_IOPORT dependencies
Applying: iio: adc: Kconfig: add HAS_IOPORT dependencies
Applying: hwmon: Kconfig: add HAS_IOPORT dependencies
Applying: leds: Kconfig: add HAS_IOPORT dependencies
Applying: media: Kconfig: add HAS_IOPORT dependencies
Applying: misc: handle HAS_IOPORT dependencies
Applying: net: Kconfig: add HAS_IOPORT dependencies
Applying: pcmcia: Kconfig: add HAS_IOPORT dependencies
Applying: platform: Kconfig: add HAS_IOPORT dependencies
Applying: pnp: Kconfig: add HAS_IOPORT dependencies
Applying: power: Kconfig: add HAS_IOPORT dependencies
Applying: video: handle HAS_IOPORT dependencies
.git/rebase-apply/patch:23: trailing whitespace.
warning: 1 line adds whitespace errors.
Applying: rtc: Kconfig: add HAS_IOPORT dependencies
Applying: scsi: Kconfig: add HAS_IOPORT dependencies
Applying: watchdog: Kconfig: add HAS_IOPORT dependencies
Applying: drm: handle HAS_IOPORT dependencies
Applying: PCI/sysfs: make I/O resource depend on HAS_IOPORT
Applying: PCI: make quirk using inw() depend on HAS_IOPORT
Applying: firmware: dmi-sysfs: handle HAS_IOPORT dependencies
Applying: /dev/port: don't compile file operations without CONFIG_DEVPORT
Applying: usb: handle HAS_IOPORT dependencies
Applying: asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
10:30:55 ~/linux (wip/niklas)$
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
2021-12-28 16:35 ` Bjorn Helgaas
@ 2021-12-28 16:52 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 16:52 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Tue, 2021-12-28 at 10:35 -0600, Bjorn Helgaas wrote:
> On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> > On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > > On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > > If we keep it in drivers/pci, please update the subject line to make
> > > it more specific and match the convention, e.g.,
> > >
> > > PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
> >
> > Ah yeah I was going back and forth between matching this within the
> > series vs matching the subsystem. I guess going with the subsystem is
> > mote important long term.
>
> Haha, yes, a little ambiguity there. I do think the subsystem is more
> important because the identity of the series is mostly lost after it's
> applied. Thanks for thinking about it!
>
> > > BTW, git complains about some whitespace errors in other patches:
> > >
> > > Applying: char: impi, tpm: depend on HAS_IOPORT
> > > .git/rebase-apply/patch:92: trailing whitespace.
> > > If you have a TPM security chip from Atmel say Yes and it
> > > .git/rebase-apply/patch:93: trailing whitespace.
> > > will be accessible from within Linux. To compile this driver
> > > warning: 2 lines add whitespace errors.
> > > Applying: video: handle HAS_IOPORT dependencies
> > > .git/rebase-apply/patch:23: trailing whitespace.
> > >
> > > warning: 1 line adds whitespace errors.
> >
> > That is very strange. I did run checkpatch before. There are a few
> > warnings not to touch obsolete code unnecessarily and a check about
> > using udelay() (pre-existing) plus two missing blank lines in pci-
> > quirks.h that I ignored because it matches the sorounding style.
> >
> > I did notice that lore fails to render the subject lines for some of
> > the patches. But I just tried fetching the patches with b4 on top of
> > v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
> > v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
> > use to check?
>
> "git am" is what complained. Here's what I did:
>
> $ git checkout -b wip/niklas v5.16-rc1
Ah this seems to be because my patches are against v5.16-rc7. I noted
that in the cover letter but I guess that is easy to miss and might not
match expectations.
> Switched to a new branch 'wip/niklas'
> 10:30:06 ~/linux (wip/niklas)$ b4 am -om/ 20211227164317.4146918-1-schnelle@linux.ibm.com
> Looking up https://lore.kernel.org/r/20211227164317.4146918-1-schnelle%40linux.ibm.com
> Grabbing thread from lore.kernel.org/all/20211227164317.4146918-1-schnelle%40linux.ibm.com/t.mbox.gz
> Analyzing 70 messages in the thread
> Checking attestation on all messages, may take a moment...
> ---
> ✓ [PATCH RFC 1/32] Kconfig: introduce and depend on LEGACY_PCI
> ✓ [PATCH RFC 2/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
> ✓ [PATCH RFC 3/32] ACPI: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 4/32] parport: PC style parport depends on HAS_IOPORT
> ✓ [PATCH RFC 5/32] char: impi, tpm: depend on HAS_IOPORT
> ✓ [PATCH RFC 6/32] speakup: Kconfig: add HAS_IOPORT dependencies
> + Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ✓ [PATCH RFC 7/32] Input: gameport: add ISA and HAS_IOPORT dependencies
> ✓ [PATCH RFC 8/32] comedi: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 9/32] sound: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 16/32] misc: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
> + Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ✓ [PATCH RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
> + Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> ✓ [PATCH RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 22/32] video: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 26/32] drm: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
> ✓ [PATCH RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
> ✓ [PATCH RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
> ✓ [PATCH RFC 31/32] usb: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
> ---
> ✓ Signed: DKIM/ibm.com (From: schnelle@linux.ibm.com)
>
Interesting now I have to figure out why I do get bad DKIM signature
checks with b4 and my mails. Maybe b4 has an endianess bug as I'm
usually working on mainframe.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
@ 2021-12-28 16:52 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-28 16:52 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Tue, 2021-12-28 at 10:35 -0600, Bjorn Helgaas wrote:
> On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> > On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > > On Mon, Dec 27, 2021 at 05:43:13PM +0100, Niklas Schnelle wrote:
> > > If we keep it in drivers/pci, please update the subject line to make
> > > it more specific and match the convention, e.g.,
> > >
> > > PCI: Compile quirk_tigerpoint_bm_sts() only when HAS_IOPORT set
> >
> > Ah yeah I was going back and forth between matching this within the
> > series vs matching the subsystem. I guess going with the subsystem is
> > mote important long term.
>
> Haha, yes, a little ambiguity there. I do think the subsystem is more
> important because the identity of the series is mostly lost after it's
> applied. Thanks for thinking about it!
>
> > > BTW, git complains about some whitespace errors in other patches:
> > >
> > > Applying: char: impi, tpm: depend on HAS_IOPORT
> > > .git/rebase-apply/patch:92: trailing whitespace.
> > > If you have a TPM security chip from Atmel say Yes and it
> > > .git/rebase-apply/patch:93: trailing whitespace.
> > > will be accessible from within Linux. To compile this driver
> > > warning: 2 lines add whitespace errors.
> > > Applying: video: handle HAS_IOPORT dependencies
> > > .git/rebase-apply/patch:23: trailing whitespace.
> > >
> > > warning: 1 line adds whitespace errors.
> >
> > That is very strange. I did run checkpatch before. There are a few
> > warnings not to touch obsolete code unnecessarily and a check about
> > using udelay() (pre-existing) plus two missing blank lines in pci-
> > quirks.h that I ignored because it matches the sorounding style.
> >
> > I did notice that lore fails to render the subject lines for some of
> > the patches. But I just tried fetching the patches with b4 on top of
> > v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl --git
> > v5.16-rc7..HEAD" and has an empty diff to my branch. What tool did you
> > use to check?
>
> "git am" is what complained. Here's what I did:
>
> $ git checkout -b wip/niklas v5.16-rc1
Ah this seems to be because my patches are against v5.16-rc7. I noted
that in the cover letter but I guess that is easy to miss and might not
match expectations.
> Switched to a new branch 'wip/niklas'
> 10:30:06 ~/linux (wip/niklas)$ b4 am -om/ 20211227164317.4146918-1-schnelle@linux.ibm.com
> Looking up https://lore.kernel.org/r/20211227164317.4146918-1-schnelle%40linux.ibm.com
> Grabbing thread from lore.kernel.org/all/20211227164317.4146918-1-schnelle%40linux.ibm.com/t.mbox.gz
> Analyzing 70 messages in the thread
> Checking attestation on all messages, may take a moment...
> ---
> ✓ [PATCH RFC 1/32] Kconfig: introduce and depend on LEGACY_PCI
> ✓ [PATCH RFC 2/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
> ✓ [PATCH RFC 3/32] ACPI: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 4/32] parport: PC style parport depends on HAS_IOPORT
> ✓ [PATCH RFC 5/32] char: impi, tpm: depend on HAS_IOPORT
> ✓ [PATCH RFC 6/32] speakup: Kconfig: add HAS_IOPORT dependencies
> + Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ✓ [PATCH RFC 7/32] Input: gameport: add ISA and HAS_IOPORT dependencies
> ✓ [PATCH RFC 8/32] comedi: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 9/32] sound: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 10/32] i2c: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 11/32] Input: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 12/32] iio: adc: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 13/32] hwmon: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 14/32] leds: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 15/32] media: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 16/32] misc: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 17/32] net: Kconfig: add HAS_IOPORT dependencies
> + Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ✓ [PATCH RFC 18/32] pcmcia: Kconfig: add HAS_IOPORT dependencies
> + Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> ✓ [PATCH RFC 19/32] platform: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 20/32] pnp: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 21/32] power: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 22/32] video: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 23/32] rtc: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 24/32] scsi: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 25/32] watchdog: Kconfig: add HAS_IOPORT dependencies
> ✓ [PATCH RFC 26/32] drm: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 27/32] PCI/sysfs: make I/O resource depend on HAS_IOPORT
> ✓ [PATCH RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
> ✓ [PATCH RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
> ✓ [PATCH RFC 31/32] usb: handle HAS_IOPORT dependencies
> ✓ [PATCH RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
> ---
> ✓ Signed: DKIM/ibm.com (From: schnelle@linux.ibm.com)
>
Interesting now I have to figure out why I do get bad DKIM signature
checks with b4 and my mails. Maybe b4 has an endianess bug as I'm
usually working on mainframe.
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
2021-12-28 16:52 ` Niklas Schnelle
@ 2021-12-28 17:28 ` Bjorn Helgaas
-1 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-28 17:28 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Tue, Dec 28, 2021 at 05:52:05PM +0100, Niklas Schnelle wrote:
> On Tue, 2021-12-28 at 10:35 -0600, Bjorn Helgaas wrote:
> > On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> > > On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > > > BTW, git complains about some whitespace errors in other patches:
> > > >
> > > > Applying: char: impi, tpm: depend on HAS_IOPORT
> > > > .git/rebase-apply/patch:92: trailing whitespace.
> > > > If you have a TPM security chip from Atmel say Yes and it
> > > > .git/rebase-apply/patch:93: trailing whitespace.
> > > > will be accessible from within Linux. To compile this driver
> > > > warning: 2 lines add whitespace errors.
> > > > Applying: video: handle HAS_IOPORT dependencies
> > > > .git/rebase-apply/patch:23: trailing whitespace.
> > > >
> > > > warning: 1 line adds whitespace errors.
> > >
> > > ... But I just tried fetching the patches with b4 on top of
> > > v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl
> > > --git v5.16-rc7..HEAD" and has an empty diff to my branch. What
> > > tool did you use to check?
> >
> > "git am" is what complained. Here's what I did:
> >
> > $ git checkout -b wip/niklas v5.16-rc1
>
> Ah this seems to be because my patches are against v5.16-rc7. I
> noted that in the cover letter but I guess that is easy to miss and
> might not match expectations.
I get the same complaints when applying to v5.16-rc7:
$ git checkout -b wip/niklas3 v5.16-rc7
$ b4 am -om/ 20211227164317.4146918-1-schnelle@linux.ibm.com
$ git am m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.mbx
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 28/32] PCI: make quirk using inw() depend on HAS_IOPORT
@ 2021-12-28 17:28 ` Bjorn Helgaas
0 siblings, 0 replies; 323+ messages in thread
From: Bjorn Helgaas @ 2021-12-28 17:28 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Tue, Dec 28, 2021 at 05:52:05PM +0100, Niklas Schnelle wrote:
> On Tue, 2021-12-28 at 10:35 -0600, Bjorn Helgaas wrote:
> > On Tue, Dec 28, 2021 at 04:25:25PM +0100, Niklas Schnelle wrote:
> > > On Mon, 2021-12-27 at 16:33 -0600, Bjorn Helgaas wrote:
> > > > BTW, git complains about some whitespace errors in other patches:
> > > >
> > > > Applying: char: impi, tpm: depend on HAS_IOPORT
> > > > .git/rebase-apply/patch:92: trailing whitespace.
> > > > If you have a TPM security chip from Atmel say Yes and it
> > > > .git/rebase-apply/patch:93: trailing whitespace.
> > > > will be accessible from within Linux. To compile this driver
> > > > warning: 2 lines add whitespace errors.
> > > > Applying: video: handle HAS_IOPORT dependencies
> > > > .git/rebase-apply/patch:23: trailing whitespace.
> > > >
> > > > warning: 1 line adds whitespace errors.
> > >
> > > ... But I just tried fetching the patches with b4 on top of
> > > v5.16-rc7 and the resulting tree passes "./scripts/checkpatch.pl
> > > --git v5.16-rc7..HEAD" and has an empty diff to my branch. What
> > > tool did you use to check?
> >
> > "git am" is what complained. Here's what I did:
> >
> > $ git checkout -b wip/niklas v5.16-rc1
>
> Ah this seems to be because my patches are against v5.16-rc7. I
> noted that in the cover letter but I guess that is easy to miss and
> might not match expectations.
I get the same complaints when applying to v5.16-rc7:
$ git checkout -b wip/niklas3 v5.16-rc7
$ b4 am -om/ 20211227164317.4146918-1-schnelle@linux.ibm.com
$ git am m/20211227_schnelle_kconfig_introduce_has_ioport_and_legacy_pci_options.mbx
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to guard sections of code calling them
as alternative access methods.
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>
---
drivers/firmware/dmi-sysfs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index 8b8127fa8955..cc7380b3c670 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -310,6 +310,7 @@ static struct kobj_type dmi_system_event_log_ktype = {
.default_attrs = dmi_sysfs_sel_attrs,
};
+#ifdef CONFIG_HAS_IOPORT
typedef u8 (*sel_io_reader)(const struct dmi_system_event_log *sel,
loff_t offset);
@@ -374,6 +375,7 @@ static ssize_t dmi_sel_raw_read_io(struct dmi_sysfs_entry *entry,
return wrote;
}
+#endif
static ssize_t dmi_sel_raw_read_phys32(struct dmi_sysfs_entry *entry,
const struct dmi_system_event_log *sel,
@@ -409,11 +411,13 @@ static ssize_t dmi_sel_raw_read_helper(struct dmi_sysfs_entry *entry,
memcpy(&sel, dh, sizeof(sel));
switch (sel.access_method) {
+#ifdef CONFIG_HAS_IOPORT
case DMI_SEL_ACCESS_METHOD_IO8:
case DMI_SEL_ACCESS_METHOD_IO2x8:
case DMI_SEL_ACCESS_METHOD_IO16:
return dmi_sel_raw_read_io(entry, &sel, state->buf,
state->pos, state->count);
+#endif
case DMI_SEL_ACCESS_METHOD_PHYS32:
return dmi_sel_raw_read_phys32(entry, &sel, state->buf,
state->pos, state->count);
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 29/32] firmware: dmi-sysfs: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to guard sections of code calling them
as alternative access methods.
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>
---
drivers/firmware/dmi-sysfs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index 8b8127fa8955..cc7380b3c670 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -310,6 +310,7 @@ static struct kobj_type dmi_system_event_log_ktype = {
.default_attrs = dmi_sysfs_sel_attrs,
};
+#ifdef CONFIG_HAS_IOPORT
typedef u8 (*sel_io_reader)(const struct dmi_system_event_log *sel,
loff_t offset);
@@ -374,6 +375,7 @@ static ssize_t dmi_sel_raw_read_io(struct dmi_sysfs_entry *entry,
return wrote;
}
+#endif
static ssize_t dmi_sel_raw_read_phys32(struct dmi_sysfs_entry *entry,
const struct dmi_system_event_log *sel,
@@ -409,11 +411,13 @@ static ssize_t dmi_sel_raw_read_helper(struct dmi_sysfs_entry *entry,
memcpy(&sel, dh, sizeof(sel));
switch (sel.access_method) {
+#ifdef CONFIG_HAS_IOPORT
case DMI_SEL_ACCESS_METHOD_IO8:
case DMI_SEL_ACCESS_METHOD_IO2x8:
case DMI_SEL_ACCESS_METHOD_IO16:
return dmi_sel_raw_read_io(entry, &sel, state->buf,
state->pos, state->count);
+#endif
case DMI_SEL_ACCESS_METHOD_PHYS32:
return dmi_sel_raw_read_phys32(entry, &sel, state->buf,
state->pos, state->count);
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In the future inb() and friends will not be available when compiling
with CONFIG_HAS_IOPORT=n so we must only try to access them here if
CONFIG_DEVPORT is set which depends on HAS_IOPORT.
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>
---
drivers/char/mem.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index cc296f0823bd..c1373617153f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
return 0;
}
+#ifdef CONFIG_DEVPORT
static ssize_t read_port(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
@@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
*ppos = i;
return tmp-buf;
}
+#endif
static ssize_t read_null(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
@@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
.splice_write = splice_write_null,
};
-static const struct file_operations __maybe_unused port_fops = {
+#ifdef CONFIG_DEVPORT
+static const struct file_operations port_fops = {
.llseek = memory_lseek,
.read = read_port,
.write = write_port,
.open = open_port,
};
+#endif
static const struct file_operations zero_fops = {
.llseek = zero_lseek,
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Greg Kroah-Hartman
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
In the future inb() and friends will not be available when compiling
with CONFIG_HAS_IOPORT=n so we must only try to access them here if
CONFIG_DEVPORT is set which depends on HAS_IOPORT.
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>
---
drivers/char/mem.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index cc296f0823bd..c1373617153f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
return 0;
}
+#ifdef CONFIG_DEVPORT
static ssize_t read_port(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
@@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
*ppos = i;
return tmp-buf;
}
+#endif
static ssize_t read_null(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
@@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
.splice_write = splice_write_null,
};
-static const struct file_operations __maybe_unused port_fops = {
+#ifdef CONFIG_DEVPORT
+static const struct file_operations port_fops = {
.llseek = memory_lseek,
.read = read_port,
.write = write_port,
.open = open_port,
};
+#endif
static const struct file_operations zero_fops = {
.llseek = zero_lseek,
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-28 8:17 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:17 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Mon, Dec 27, 2021 at 05:43:15PM +0100, Niklas Schnelle wrote:
> In the future inb() and friends will not be available when compiling
> with CONFIG_HAS_IOPORT=n so we must only try to access them here if
> CONFIG_DEVPORT is set which depends on HAS_IOPORT.
>
> 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>
> ---
> drivers/char/mem.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index cc296f0823bd..c1373617153f 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
> return 0;
> }
>
> +#ifdef CONFIG_DEVPORT
> static ssize_t read_port(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> {
> @@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
> *ppos = i;
> return tmp-buf;
> }
> +#endif
>
> static ssize_t read_null(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> @@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
> .splice_write = splice_write_null,
> };
>
> -static const struct file_operations __maybe_unused port_fops = {
> +#ifdef CONFIG_DEVPORT
> +static const struct file_operations port_fops = {
> .llseek = memory_lseek,
> .read = read_port,
> .write = write_port,
> .open = open_port,
> };
> +#endif
Why is this #ifdef needed if it is already __maybe_unused?
In looking closer, this change could be taken now as the use of this
variable already is behind this same #ifdef statement, right?
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
@ 2021-12-28 8:17 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-28 8:17 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Mon, Dec 27, 2021 at 05:43:15PM +0100, Niklas Schnelle wrote:
> In the future inb() and friends will not be available when compiling
> with CONFIG_HAS_IOPORT=n so we must only try to access them here if
> CONFIG_DEVPORT is set which depends on HAS_IOPORT.
>
> 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>
> ---
> drivers/char/mem.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index cc296f0823bd..c1373617153f 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
> return 0;
> }
>
> +#ifdef CONFIG_DEVPORT
> static ssize_t read_port(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> {
> @@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
> *ppos = i;
> return tmp-buf;
> }
> +#endif
>
> static ssize_t read_null(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> @@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
> .splice_write = splice_write_null,
> };
>
> -static const struct file_operations __maybe_unused port_fops = {
> +#ifdef CONFIG_DEVPORT
> +static const struct file_operations port_fops = {
> .llseek = memory_lseek,
> .read = read_port,
> .write = write_port,
> .open = open_port,
> };
> +#endif
Why is this #ifdef needed if it is already __maybe_unused?
In looking closer, this change could be taken now as the use of this
variable already is behind this same #ifdef statement, right?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
2021-12-28 8:17 ` Greg Kroah-Hartman
@ 2021-12-29 10:25 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 10:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Tue, 2021-12-28 at 09:17 +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 27, 2021 at 05:43:15PM +0100, Niklas Schnelle wrote:
> > In the future inb() and friends will not be available when compiling
> > with CONFIG_HAS_IOPORT=n so we must only try to access them here if
> > CONFIG_DEVPORT is set which depends on HAS_IOPORT.
> >
> > 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>
> > ---
> > drivers/char/mem.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > index cc296f0823bd..c1373617153f 100644
> > --- a/drivers/char/mem.c
> > +++ b/drivers/char/mem.c
> > @@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_DEVPORT
> > static ssize_t read_port(struct file *file, char __user *buf,
> > size_t count, loff_t *ppos)
> > {
> > @@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
> > *ppos = i;
> > return tmp-buf;
> > }
> > +#endif
> >
> > static ssize_t read_null(struct file *file, char __user *buf,
> > size_t count, loff_t *ppos)
> > @@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
> > .splice_write = splice_write_null,
> > };
> >
> > -static const struct file_operations __maybe_unused port_fops = {
> > +#ifdef CONFIG_DEVPORT
> > +static const struct file_operations port_fops = {
> > .llseek = memory_lseek,
> > .read = read_port,
> > .write = write_port,
> > .open = open_port,
> > };
> > +#endif
>
> Why is this #ifdef needed if it is already __maybe_unused?
Because read_port() calls inb() and write_port() calls outb() they
wouldn't compile once these are no longer defined. Then however the
read_port/write_port symbols in the struct initialization above
couldn't be resolved.
>
> In looking closer, this change could be taken now as the use of this
> variable already is behind this same #ifdef statement, right?
Yes
>
> thanks,
>
> greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
@ 2021-12-29 10:25 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-29 10:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Tue, 2021-12-28 at 09:17 +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 27, 2021 at 05:43:15PM +0100, Niklas Schnelle wrote:
> > In the future inb() and friends will not be available when compiling
> > with CONFIG_HAS_IOPORT=n so we must only try to access them here if
> > CONFIG_DEVPORT is set which depends on HAS_IOPORT.
> >
> > 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>
> > ---
> > drivers/char/mem.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > index cc296f0823bd..c1373617153f 100644
> > --- a/drivers/char/mem.c
> > +++ b/drivers/char/mem.c
> > @@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_DEVPORT
> > static ssize_t read_port(struct file *file, char __user *buf,
> > size_t count, loff_t *ppos)
> > {
> > @@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
> > *ppos = i;
> > return tmp-buf;
> > }
> > +#endif
> >
> > static ssize_t read_null(struct file *file, char __user *buf,
> > size_t count, loff_t *ppos)
> > @@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
> > .splice_write = splice_write_null,
> > };
> >
> > -static const struct file_operations __maybe_unused port_fops = {
> > +#ifdef CONFIG_DEVPORT
> > +static const struct file_operations port_fops = {
> > .llseek = memory_lseek,
> > .read = read_port,
> > .write = write_port,
> > .open = open_port,
> > };
> > +#endif
>
> Why is this #ifdef needed if it is already __maybe_unused?
Because read_port() calls inb() and write_port() calls outb() they
wouldn't compile once these are no longer defined. Then however the
read_port/write_port symbols in the struct initialization above
couldn't be resolved.
>
> In looking closer, this change could be taken now as the use of this
> variable already is behind this same #ifdef statement, right?
Yes
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
2021-12-29 10:25 ` Niklas Schnelle
@ 2021-12-29 10:38 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-29 10:38 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Wed, Dec 29, 2021 at 11:25:12AM +0100, Niklas Schnelle wrote:
> On Tue, 2021-12-28 at 09:17 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Dec 27, 2021 at 05:43:15PM +0100, Niklas Schnelle wrote:
> > > In the future inb() and friends will not be available when compiling
> > > with CONFIG_HAS_IOPORT=n so we must only try to access them here if
> > > CONFIG_DEVPORT is set which depends on HAS_IOPORT.
> > >
> > > 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>
> > > ---
> > > drivers/char/mem.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > > index cc296f0823bd..c1373617153f 100644
> > > --- a/drivers/char/mem.c
> > > +++ b/drivers/char/mem.c
> > > @@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
> > > return 0;
> > > }
> > >
> > > +#ifdef CONFIG_DEVPORT
> > > static ssize_t read_port(struct file *file, char __user *buf,
> > > size_t count, loff_t *ppos)
> > > {
> > > @@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
> > > *ppos = i;
> > > return tmp-buf;
> > > }
> > > +#endif
> > >
> > > static ssize_t read_null(struct file *file, char __user *buf,
> > > size_t count, loff_t *ppos)
> > > @@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
> > > .splice_write = splice_write_null,
> > > };
> > >
> > > -static const struct file_operations __maybe_unused port_fops = {
> > > +#ifdef CONFIG_DEVPORT
> > > +static const struct file_operations port_fops = {
> > > .llseek = memory_lseek,
> > > .read = read_port,
> > > .write = write_port,
> > > .open = open_port,
> > > };
> > > +#endif
> >
> > Why is this #ifdef needed if it is already __maybe_unused?
>
> Because read_port() calls inb() and write_port() calls outb() they
> wouldn't compile once these are no longer defined. Then however the
> read_port/write_port symbols in the struct initialization above
> couldn't be resolved.
>
> >
> > In looking closer, this change could be taken now as the use of this
> > variable already is behind this same #ifdef statement, right?
>
> Yes
Great, feel free to send this individually, not as a RFC patch, and I
will be glad to queue it up.
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
@ 2021-12-29 10:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 323+ messages in thread
From: Greg Kroah-Hartman @ 2021-12-29 10:38 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, linux-kernel, linux-arch, linux-pci, linux-riscv,
linux-csky
On Wed, Dec 29, 2021 at 11:25:12AM +0100, Niklas Schnelle wrote:
> On Tue, 2021-12-28 at 09:17 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Dec 27, 2021 at 05:43:15PM +0100, Niklas Schnelle wrote:
> > > In the future inb() and friends will not be available when compiling
> > > with CONFIG_HAS_IOPORT=n so we must only try to access them here if
> > > CONFIG_DEVPORT is set which depends on HAS_IOPORT.
> > >
> > > 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>
> > > ---
> > > drivers/char/mem.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > > index cc296f0823bd..c1373617153f 100644
> > > --- a/drivers/char/mem.c
> > > +++ b/drivers/char/mem.c
> > > @@ -402,6 +402,7 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
> > > return 0;
> > > }
> > >
> > > +#ifdef CONFIG_DEVPORT
> > > static ssize_t read_port(struct file *file, char __user *buf,
> > > size_t count, loff_t *ppos)
> > > {
> > > @@ -443,6 +444,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
> > > *ppos = i;
> > > return tmp-buf;
> > > }
> > > +#endif
> > >
> > > static ssize_t read_null(struct file *file, char __user *buf,
> > > size_t count, loff_t *ppos)
> > > @@ -665,12 +667,14 @@ static const struct file_operations null_fops = {
> > > .splice_write = splice_write_null,
> > > };
> > >
> > > -static const struct file_operations __maybe_unused port_fops = {
> > > +#ifdef CONFIG_DEVPORT
> > > +static const struct file_operations port_fops = {
> > > .llseek = memory_lseek,
> > > .read = read_port,
> > > .write = write_port,
> > > .open = open_port,
> > > };
> > > +#endif
> >
> > Why is this #ifdef needed if it is already __maybe_unused?
>
> Because read_port() calls inb() and write_port() calls outb() they
> wouldn't compile once these are no longer defined. Then however the
> read_port/write_port symbols in the struct initialization above
> couldn't be resolved.
>
> >
> > In looking closer, this change could be taken now as the use of this
> > variable already is behind this same #ifdef statement, right?
>
> Yes
Great, feel free to send this individually, not as a RFC patch, and I
will be glad to queue it up.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
2021-12-29 10:38 ` Greg Kroah-Hartman
@ 2021-12-30 16:19 ` Arnd Bergmann
-1 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 16:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Niklas Schnelle, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Linux Kernel Mailing List, linux-arch, linux-pci,
linux-riscv, linux-csky
On Wed, Dec 29, 2021 at 5:38 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> > > > -static const struct file_operations __maybe_unused port_fops = {
> > > > +#ifdef CONFIG_DEVPORT
> > > > +static const struct file_operations port_fops = {
> > > > .llseek = memory_lseek,
> > > > .read = read_port,
> > > > .write = write_port,
> > > > .open = open_port,
> > > > };
> > > > +#endif
> > >
> > > Why is this #ifdef needed if it is already __maybe_unused?
> >
> > Because read_port() calls inb() and write_port() calls outb() they
> > wouldn't compile once these are no longer defined. Then however the
> > read_port/write_port symbols in the struct initialization above
> > couldn't be resolved.
> >
> > >
> > > In looking closer, this change could be taken now as the use of this
> > > variable already is behind this same #ifdef statement, right?
> >
> > Yes
>
> Great, feel free to send this individually, not as a RFC patch, and I
> will be glad to queue it up.
I think this patch should contain the 'depends on HAS_IOPORT' that
is currently added in a different patch (char: impi, tpm: depend on
HAS_IOPORT).
However, we can't merge that version until HAS_IOPORT is actually
added to the kernel.
Arnd
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 30/32] /dev/port: don't compile file operations without CONFIG_DEVPORT
@ 2021-12-30 16:19 ` Arnd Bergmann
0 siblings, 0 replies; 323+ messages in thread
From: Arnd Bergmann @ 2021-12-30 16:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Niklas Schnelle, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann, Linux Kernel Mailing List, linux-arch, linux-pci,
linux-riscv, linux-csky
On Wed, Dec 29, 2021 at 5:38 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> > > > -static const struct file_operations __maybe_unused port_fops = {
> > > > +#ifdef CONFIG_DEVPORT
> > > > +static const struct file_operations port_fops = {
> > > > .llseek = memory_lseek,
> > > > .read = read_port,
> > > > .write = write_port,
> > > > .open = open_port,
> > > > };
> > > > +#endif
> > >
> > > Why is this #ifdef needed if it is already __maybe_unused?
> >
> > Because read_port() calls inb() and write_port() calls outb() they
> > wouldn't compile once these are no longer defined. Then however the
> > read_port/write_port symbols in the struct initialization above
> > couldn't be resolved.
> >
> > >
> > > In looking closer, this change could be taken now as the use of this
> > > variable already is behind this same #ifdef statement, right?
> >
> > Yes
>
> Great, feel free to send this individually, not as a RFC patch, and I
> will be glad to queue it up.
I think this patch should contain the 'depends on HAS_IOPORT' that
is currently added in a different patch (char: impi, tpm: depend on
HAS_IOPORT).
However, we can't merge that version until HAS_IOPORT is actually
added to the kernel.
Arnd
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 31/32] usb: handle HAS_IOPORT dependencies
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, Alan Stern
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-usb
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to guard sections of code calling them
as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
drivers requiring these functions need to depend on HAS_IOPORT.
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>
---
drivers/usb/core/hcd-pci.c | 3 +-
drivers/usb/host/Kconfig | 4 +-
drivers/usb/host/pci-quirks.c | 127 ++++++++++++++++++----------------
drivers/usb/host/pci-quirks.h | 33 ++++++---
drivers/usb/host/uhci-hcd.c | 2 +-
drivers/usb/host/uhci-hcd.h | 77 ++++++++++++++-------
6 files changed, 148 insertions(+), 98 deletions(-)
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index d630cccd2e6e..1ade46cec91a 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -212,7 +212,8 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id,
goto free_irq_vectors;
}
- hcd->amd_resume_bug = (usb_hcd_amd_remote_wakeup_quirk(dev) &&
+ hcd->amd_resume_bug = (IS_ENABLED(CONFIG_USB_PCI_AMD) &&
+ usb_hcd_amd_remote_wakeup_quirk(dev) &&
driver->flags & (HCD_USB11 | HCD_USB3)) ? 1 : 0;
if (driver->flags & HCD_MEMORY) {
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d1d926f8f9c2..5fb207e2d5e8 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -369,7 +369,7 @@ config USB_ISP116X_HCD
config USB_ISP1362_HCD
tristate "ISP1362 HCD support"
- depends on HAS_IOMEM
+ depends on HAS_IOPORT
depends on COMPILE_TEST # nothing uses this
help
Supports the Philips ISP1362 chip as a host controller
@@ -605,7 +605,7 @@ endif # USB_OHCI_HCD
config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
- depends on USB_PCI || USB_UHCI_SUPPORT_NON_PCI_HC
+ depends on (USB_PCI && HAS_IOPORT) || USB_UHCI_SUPPORT_NON_PCI_HC
help
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index ef08d68b9714..bba320194027 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -60,6 +60,23 @@
#define EHCI_USBLEGCTLSTS 4 /* legacy control/status */
#define EHCI_USBLEGCTLSTS_SOOE (1 << 13) /* SMI on ownership change */
+/* ASMEDIA quirk use */
+#define ASMT_DATA_WRITE0_REG 0xF8
+#define ASMT_DATA_WRITE1_REG 0xFC
+#define ASMT_CONTROL_REG 0xE0
+#define ASMT_CONTROL_WRITE_BIT 0x02
+#define ASMT_WRITEREG_CMD 0x10423
+#define ASMT_FLOWCTL_ADDR 0xFA30
+#define ASMT_FLOWCTL_DATA 0xBA
+#define ASMT_PSEUDO_DATA 0
+
+/* Intel quirk use */
+#define USB_INTEL_XUSB2PR 0xD0
+#define USB_INTEL_USB2PRM 0xD4
+#define USB_INTEL_USB3_PSSEN 0xD8
+#define USB_INTEL_USB3PRM 0xDC
+
+#ifdef CONFIG_USB_PCI_AMD
/* AMD quirk use */
#define AB_REG_BAR_LOW 0xe0
#define AB_REG_BAR_HIGH 0xe1
@@ -93,21 +110,6 @@
#define NB_PIF0_PWRDOWN_0 0x01100012
#define NB_PIF0_PWRDOWN_1 0x01100013
-#define USB_INTEL_XUSB2PR 0xD0
-#define USB_INTEL_USB2PRM 0xD4
-#define USB_INTEL_USB3_PSSEN 0xD8
-#define USB_INTEL_USB3PRM 0xDC
-
-/* ASMEDIA quirk use */
-#define ASMT_DATA_WRITE0_REG 0xF8
-#define ASMT_DATA_WRITE1_REG 0xFC
-#define ASMT_CONTROL_REG 0xE0
-#define ASMT_CONTROL_WRITE_BIT 0x02
-#define ASMT_WRITEREG_CMD 0x10423
-#define ASMT_FLOWCTL_ADDR 0xFA30
-#define ASMT_FLOWCTL_DATA 0xBA
-#define ASMT_PSEUDO_DATA 0
-
/*
* amd_chipset_gen values represent AMD different chipset generations
*/
@@ -460,50 +462,6 @@ void usb_amd_quirk_pll_disable(void)
}
EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
-static int usb_asmedia_wait_write(struct pci_dev *pdev)
-{
- unsigned long retry_count;
- unsigned char value;
-
- for (retry_count = 1000; retry_count > 0; --retry_count) {
-
- pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
-
- if (value == 0xff) {
- dev_err(&pdev->dev, "%s: check_ready ERROR", __func__);
- return -EIO;
- }
-
- if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
- return 0;
-
- udelay(50);
- }
-
- dev_warn(&pdev->dev, "%s: check_write_ready timeout", __func__);
- return -ETIMEDOUT;
-}
-
-void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
-{
- if (usb_asmedia_wait_write(pdev) != 0)
- return;
-
- /* send command and address to device */
- pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_WRITEREG_CMD);
- pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_FLOWCTL_ADDR);
- pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
-
- if (usb_asmedia_wait_write(pdev) != 0)
- return;
-
- /* send data to device */
- pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_FLOWCTL_DATA);
- pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_PSEUDO_DATA);
- pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
-}
-EXPORT_SYMBOL_GPL(usb_asmedia_modifyflowcontrol);
-
void usb_amd_quirk_pll_enable(void)
{
usb_amd_quirk_pll(0);
@@ -632,7 +590,52 @@ bool usb_amd_pt_check_port(struct device *device, int port)
return !(value & BIT(port_shift));
}
EXPORT_SYMBOL_GPL(usb_amd_pt_check_port);
+#endif
+static int usb_asmedia_wait_write(struct pci_dev *pdev)
+{
+ unsigned long retry_count;
+ unsigned char value;
+
+ for (retry_count = 1000; retry_count > 0; --retry_count) {
+ pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+
+ if (value == 0xff) {
+ dev_err(&pdev->dev, "%s: check_ready ERROR", __func__);
+ return -EIO;
+ }
+
+ if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
+ return 0;
+
+ udelay(50);
+ }
+
+ dev_warn(&pdev->dev, "%s: check_write_ready timeout", __func__);
+ return -ETIMEDOUT;
+}
+
+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
+{
+ if (usb_asmedia_wait_write(pdev) != 0)
+ return;
+
+ /* send command and address to device */
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_WRITEREG_CMD);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_FLOWCTL_ADDR);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+
+ if (usb_asmedia_wait_write(pdev) != 0)
+ return;
+
+ /* send data to device */
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_FLOWCTL_DATA);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_PSEUDO_DATA);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+}
+EXPORT_SYMBOL_GPL(usb_asmedia_modifyflowcontrol);
+
+#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
/*
* Make sure the controller is completely inactive, unable to
* generate interrupts or do DMA.
@@ -713,6 +716,7 @@ int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base)
return 1;
}
EXPORT_SYMBOL_GPL(uhci_check_and_reset_hc);
+#endif
static inline int io_type_enabled(struct pci_dev *pdev, unsigned int mask)
{
@@ -728,7 +732,7 @@ static void quirk_usb_handoff_uhci(struct pci_dev *pdev)
unsigned long base = 0;
int i;
- if (!pio_enabled(pdev))
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT) || !pio_enabled(pdev))
return;
for (i = 0; i < PCI_STD_NUM_BARS; i++)
@@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
"Can't enable PCI device, BIOS handoff failed.\n");
return;
}
- if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
+ if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
+ pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
quirk_usb_handoff_uhci(pdev);
else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
quirk_usb_handoff_ohci(pdev);
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index e729de21fad7..42eb18be37af 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -2,33 +2,50 @@
#ifndef __LINUX_USB_PCI_QUIRKS_H
#define __LINUX_USB_PCI_QUIRKS_H
-#ifdef CONFIG_USB_PCI
void uhci_reset_hc(struct pci_dev *pdev, unsigned long base);
int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base);
-int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev);
+
+struct pci_dev;
+
+#ifdef CONFIG_USB_PCI_AMD
bool usb_amd_hang_symptom_quirk(void);
bool usb_amd_prefetch_quirk(void);
void usb_amd_dev_put(void);
bool usb_amd_quirk_pll_check(void);
void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
-void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev);
-void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
-void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
void sb800_prefetch(struct device *dev, int on);
bool usb_amd_pt_check_port(struct device *device, int port);
#else
-struct pci_dev;
+static inline bool usb_amd_hang_symptom_quirk(void)
+{
+ return false;
+};
+static inline bool usb_amd_prefetch_quirk(void)
+{
+ return false;
+}
+static inline bool usb_amd_quirk_pll_check(void)
+{
+ return false;
+}
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
-static inline void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev) {}
static inline void usb_amd_dev_put(void) {}
-static inline void usb_disable_xhci_ports(struct pci_dev *xhci_pdev) {}
static inline void sb800_prefetch(struct device *dev, int on) {}
static inline bool usb_amd_pt_check_port(struct device *device, int port)
{
return false;
}
+#endif /* CONFIG_USB_PCI_AMD */
+
+#ifdef CONFIG_USB_PCI
+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev);
+void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
+#else
+static inline void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev) {}
+static inline void usb_disable_xhci_ports(struct pci_dev *xhci_pdev) {}
#endif /* CONFIG_USB_PCI */
#endif /* __LINUX_USB_PCI_QUIRKS_H */
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index d90b869f5f40..a3b0d3d3b395 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -841,7 +841,7 @@ static int uhci_count_ports(struct usb_hcd *hcd)
static const char hcd_name[] = "uhci_hcd";
-#ifdef CONFIG_USB_PCI
+#if defined(CONFIG_USB_PCI) && defined(CONFIG_HAS_IOPORT)
#include "uhci-pci.c"
#define PCI_DRIVER uhci_pci_driver
#endif
diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
index 8ae5ccd26753..8e30116b6fd2 100644
--- a/drivers/usb/host/uhci-hcd.h
+++ b/drivers/usb/host/uhci-hcd.h
@@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
{
+#ifdef CONFIG_HAS_IOPORT
if (uhci_has_pci_registers(uhci))
return inl(uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+#endif
+ if (uhci_is_aspeed(uhci))
return readl(uhci->regs + uhci_aspeed_reg(reg));
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci))
return readl_be(uhci->regs + reg);
#endif
else
@@ -600,72 +602,97 @@ static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
static inline void uhci_writel(const struct uhci_hcd *uhci, u32 val, int reg)
{
- if (uhci_has_pci_registers(uhci))
+#ifdef CONFIG_HAS_IOPORT
+ if (uhci_has_pci_registers(uhci)) {
outl(val, uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+ return;
+ }
+#endif
+ if (uhci_is_aspeed(uhci)) {
writel(val, uhci->regs + uhci_aspeed_reg(reg));
+ return;
+ }
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci)) {
writel_be(val, uhci->regs + reg);
+ return;
+ }
#endif
- else
- writel(val, uhci->regs + reg);
+ writel(val, uhci->regs + reg);
}
static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
{
+#ifdef CONFIG_HAS_IOPORT
if (uhci_has_pci_registers(uhci))
return inw(uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+#endif
+ if (uhci_is_aspeed(uhci))
return readl(uhci->regs + uhci_aspeed_reg(reg));
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci))
return readw_be(uhci->regs + reg);
#endif
- else
- return readw(uhci->regs + reg);
+ return readw(uhci->regs + reg);
}
static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
{
- if (uhci_has_pci_registers(uhci))
+#ifdef CONFIG_HAS_IOPORT
+ if (uhci_has_pci_registers(uhci)) {
outw(val, uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+ return;
+ }
+#endif
+ if (uhci_is_aspeed(uhci)) {
writel(val, uhci->regs + uhci_aspeed_reg(reg));
+ return;
+ }
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci)) {
writew_be(val, uhci->regs + reg);
+ return;
+ }
#endif
- else
- writew(val, uhci->regs + reg);
+
+ writew(val, uhci->regs + reg);
}
static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
{
+#ifdef CONFIG_HAS_IOPORT
if (uhci_has_pci_registers(uhci))
return inb(uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+#endif
+ if (uhci_is_aspeed(uhci))
return readl(uhci->regs + uhci_aspeed_reg(reg));
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci))
return readb_be(uhci->regs + reg);
#endif
- else
- return readb(uhci->regs + reg);
+
+ return readb(uhci->regs + reg);
}
static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
{
- if (uhci_has_pci_registers(uhci))
+#ifdef CONFIG_HAS_IOPORT
+ if (uhci_has_pci_registers(uhci)) {
outb(val, uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+ return;
+ }
+#endif
+ if (uhci_is_aspeed(uhci)) {
writel(val, uhci->regs + uhci_aspeed_reg(reg));
+ return;
+ }
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci)) {
writeb_be(val, uhci->regs + reg);
+ return;
+ }
#endif
- else
- writeb(val, uhci->regs + reg);
+ writeb(val, uhci->regs + reg);
}
#endif /* CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC */
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 31/32] usb: handle HAS_IOPORT dependencies
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, Alan Stern
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky,
linux-usb
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to guard sections of code calling them
as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
drivers requiring these functions need to depend on HAS_IOPORT.
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>
---
drivers/usb/core/hcd-pci.c | 3 +-
drivers/usb/host/Kconfig | 4 +-
drivers/usb/host/pci-quirks.c | 127 ++++++++++++++++++----------------
drivers/usb/host/pci-quirks.h | 33 ++++++---
drivers/usb/host/uhci-hcd.c | 2 +-
drivers/usb/host/uhci-hcd.h | 77 ++++++++++++++-------
6 files changed, 148 insertions(+), 98 deletions(-)
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index d630cccd2e6e..1ade46cec91a 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -212,7 +212,8 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id,
goto free_irq_vectors;
}
- hcd->amd_resume_bug = (usb_hcd_amd_remote_wakeup_quirk(dev) &&
+ hcd->amd_resume_bug = (IS_ENABLED(CONFIG_USB_PCI_AMD) &&
+ usb_hcd_amd_remote_wakeup_quirk(dev) &&
driver->flags & (HCD_USB11 | HCD_USB3)) ? 1 : 0;
if (driver->flags & HCD_MEMORY) {
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d1d926f8f9c2..5fb207e2d5e8 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -369,7 +369,7 @@ config USB_ISP116X_HCD
config USB_ISP1362_HCD
tristate "ISP1362 HCD support"
- depends on HAS_IOMEM
+ depends on HAS_IOPORT
depends on COMPILE_TEST # nothing uses this
help
Supports the Philips ISP1362 chip as a host controller
@@ -605,7 +605,7 @@ endif # USB_OHCI_HCD
config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
- depends on USB_PCI || USB_UHCI_SUPPORT_NON_PCI_HC
+ depends on (USB_PCI && HAS_IOPORT) || USB_UHCI_SUPPORT_NON_PCI_HC
help
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index ef08d68b9714..bba320194027 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -60,6 +60,23 @@
#define EHCI_USBLEGCTLSTS 4 /* legacy control/status */
#define EHCI_USBLEGCTLSTS_SOOE (1 << 13) /* SMI on ownership change */
+/* ASMEDIA quirk use */
+#define ASMT_DATA_WRITE0_REG 0xF8
+#define ASMT_DATA_WRITE1_REG 0xFC
+#define ASMT_CONTROL_REG 0xE0
+#define ASMT_CONTROL_WRITE_BIT 0x02
+#define ASMT_WRITEREG_CMD 0x10423
+#define ASMT_FLOWCTL_ADDR 0xFA30
+#define ASMT_FLOWCTL_DATA 0xBA
+#define ASMT_PSEUDO_DATA 0
+
+/* Intel quirk use */
+#define USB_INTEL_XUSB2PR 0xD0
+#define USB_INTEL_USB2PRM 0xD4
+#define USB_INTEL_USB3_PSSEN 0xD8
+#define USB_INTEL_USB3PRM 0xDC
+
+#ifdef CONFIG_USB_PCI_AMD
/* AMD quirk use */
#define AB_REG_BAR_LOW 0xe0
#define AB_REG_BAR_HIGH 0xe1
@@ -93,21 +110,6 @@
#define NB_PIF0_PWRDOWN_0 0x01100012
#define NB_PIF0_PWRDOWN_1 0x01100013
-#define USB_INTEL_XUSB2PR 0xD0
-#define USB_INTEL_USB2PRM 0xD4
-#define USB_INTEL_USB3_PSSEN 0xD8
-#define USB_INTEL_USB3PRM 0xDC
-
-/* ASMEDIA quirk use */
-#define ASMT_DATA_WRITE0_REG 0xF8
-#define ASMT_DATA_WRITE1_REG 0xFC
-#define ASMT_CONTROL_REG 0xE0
-#define ASMT_CONTROL_WRITE_BIT 0x02
-#define ASMT_WRITEREG_CMD 0x10423
-#define ASMT_FLOWCTL_ADDR 0xFA30
-#define ASMT_FLOWCTL_DATA 0xBA
-#define ASMT_PSEUDO_DATA 0
-
/*
* amd_chipset_gen values represent AMD different chipset generations
*/
@@ -460,50 +462,6 @@ void usb_amd_quirk_pll_disable(void)
}
EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
-static int usb_asmedia_wait_write(struct pci_dev *pdev)
-{
- unsigned long retry_count;
- unsigned char value;
-
- for (retry_count = 1000; retry_count > 0; --retry_count) {
-
- pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
-
- if (value == 0xff) {
- dev_err(&pdev->dev, "%s: check_ready ERROR", __func__);
- return -EIO;
- }
-
- if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
- return 0;
-
- udelay(50);
- }
-
- dev_warn(&pdev->dev, "%s: check_write_ready timeout", __func__);
- return -ETIMEDOUT;
-}
-
-void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
-{
- if (usb_asmedia_wait_write(pdev) != 0)
- return;
-
- /* send command and address to device */
- pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_WRITEREG_CMD);
- pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_FLOWCTL_ADDR);
- pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
-
- if (usb_asmedia_wait_write(pdev) != 0)
- return;
-
- /* send data to device */
- pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_FLOWCTL_DATA);
- pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_PSEUDO_DATA);
- pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
-}
-EXPORT_SYMBOL_GPL(usb_asmedia_modifyflowcontrol);
-
void usb_amd_quirk_pll_enable(void)
{
usb_amd_quirk_pll(0);
@@ -632,7 +590,52 @@ bool usb_amd_pt_check_port(struct device *device, int port)
return !(value & BIT(port_shift));
}
EXPORT_SYMBOL_GPL(usb_amd_pt_check_port);
+#endif
+static int usb_asmedia_wait_write(struct pci_dev *pdev)
+{
+ unsigned long retry_count;
+ unsigned char value;
+
+ for (retry_count = 1000; retry_count > 0; --retry_count) {
+ pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+
+ if (value == 0xff) {
+ dev_err(&pdev->dev, "%s: check_ready ERROR", __func__);
+ return -EIO;
+ }
+
+ if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
+ return 0;
+
+ udelay(50);
+ }
+
+ dev_warn(&pdev->dev, "%s: check_write_ready timeout", __func__);
+ return -ETIMEDOUT;
+}
+
+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev)
+{
+ if (usb_asmedia_wait_write(pdev) != 0)
+ return;
+
+ /* send command and address to device */
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_WRITEREG_CMD);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_FLOWCTL_ADDR);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+
+ if (usb_asmedia_wait_write(pdev) != 0)
+ return;
+
+ /* send data to device */
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, ASMT_FLOWCTL_DATA);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, ASMT_PSEUDO_DATA);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+}
+EXPORT_SYMBOL_GPL(usb_asmedia_modifyflowcontrol);
+
+#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
/*
* Make sure the controller is completely inactive, unable to
* generate interrupts or do DMA.
@@ -713,6 +716,7 @@ int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base)
return 1;
}
EXPORT_SYMBOL_GPL(uhci_check_and_reset_hc);
+#endif
static inline int io_type_enabled(struct pci_dev *pdev, unsigned int mask)
{
@@ -728,7 +732,7 @@ static void quirk_usb_handoff_uhci(struct pci_dev *pdev)
unsigned long base = 0;
int i;
- if (!pio_enabled(pdev))
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT) || !pio_enabled(pdev))
return;
for (i = 0; i < PCI_STD_NUM_BARS; i++)
@@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
"Can't enable PCI device, BIOS handoff failed.\n");
return;
}
- if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
+ if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
+ pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
quirk_usb_handoff_uhci(pdev);
else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
quirk_usb_handoff_ohci(pdev);
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index e729de21fad7..42eb18be37af 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -2,33 +2,50 @@
#ifndef __LINUX_USB_PCI_QUIRKS_H
#define __LINUX_USB_PCI_QUIRKS_H
-#ifdef CONFIG_USB_PCI
void uhci_reset_hc(struct pci_dev *pdev, unsigned long base);
int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base);
-int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev);
+
+struct pci_dev;
+
+#ifdef CONFIG_USB_PCI_AMD
bool usb_amd_hang_symptom_quirk(void);
bool usb_amd_prefetch_quirk(void);
void usb_amd_dev_put(void);
bool usb_amd_quirk_pll_check(void);
void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
-void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev);
-void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
-void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
void sb800_prefetch(struct device *dev, int on);
bool usb_amd_pt_check_port(struct device *device, int port);
#else
-struct pci_dev;
+static inline bool usb_amd_hang_symptom_quirk(void)
+{
+ return false;
+};
+static inline bool usb_amd_prefetch_quirk(void)
+{
+ return false;
+}
+static inline bool usb_amd_quirk_pll_check(void)
+{
+ return false;
+}
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
-static inline void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev) {}
static inline void usb_amd_dev_put(void) {}
-static inline void usb_disable_xhci_ports(struct pci_dev *xhci_pdev) {}
static inline void sb800_prefetch(struct device *dev, int on) {}
static inline bool usb_amd_pt_check_port(struct device *device, int port)
{
return false;
}
+#endif /* CONFIG_USB_PCI_AMD */
+
+#ifdef CONFIG_USB_PCI
+void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev);
+void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
+#else
+static inline void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev) {}
+static inline void usb_disable_xhci_ports(struct pci_dev *xhci_pdev) {}
#endif /* CONFIG_USB_PCI */
#endif /* __LINUX_USB_PCI_QUIRKS_H */
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index d90b869f5f40..a3b0d3d3b395 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -841,7 +841,7 @@ static int uhci_count_ports(struct usb_hcd *hcd)
static const char hcd_name[] = "uhci_hcd";
-#ifdef CONFIG_USB_PCI
+#if defined(CONFIG_USB_PCI) && defined(CONFIG_HAS_IOPORT)
#include "uhci-pci.c"
#define PCI_DRIVER uhci_pci_driver
#endif
diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
index 8ae5ccd26753..8e30116b6fd2 100644
--- a/drivers/usb/host/uhci-hcd.h
+++ b/drivers/usb/host/uhci-hcd.h
@@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
{
+#ifdef CONFIG_HAS_IOPORT
if (uhci_has_pci_registers(uhci))
return inl(uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+#endif
+ if (uhci_is_aspeed(uhci))
return readl(uhci->regs + uhci_aspeed_reg(reg));
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci))
return readl_be(uhci->regs + reg);
#endif
else
@@ -600,72 +602,97 @@ static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
static inline void uhci_writel(const struct uhci_hcd *uhci, u32 val, int reg)
{
- if (uhci_has_pci_registers(uhci))
+#ifdef CONFIG_HAS_IOPORT
+ if (uhci_has_pci_registers(uhci)) {
outl(val, uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+ return;
+ }
+#endif
+ if (uhci_is_aspeed(uhci)) {
writel(val, uhci->regs + uhci_aspeed_reg(reg));
+ return;
+ }
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci)) {
writel_be(val, uhci->regs + reg);
+ return;
+ }
#endif
- else
- writel(val, uhci->regs + reg);
+ writel(val, uhci->regs + reg);
}
static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
{
+#ifdef CONFIG_HAS_IOPORT
if (uhci_has_pci_registers(uhci))
return inw(uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+#endif
+ if (uhci_is_aspeed(uhci))
return readl(uhci->regs + uhci_aspeed_reg(reg));
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci))
return readw_be(uhci->regs + reg);
#endif
- else
- return readw(uhci->regs + reg);
+ return readw(uhci->regs + reg);
}
static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
{
- if (uhci_has_pci_registers(uhci))
+#ifdef CONFIG_HAS_IOPORT
+ if (uhci_has_pci_registers(uhci)) {
outw(val, uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+ return;
+ }
+#endif
+ if (uhci_is_aspeed(uhci)) {
writel(val, uhci->regs + uhci_aspeed_reg(reg));
+ return;
+ }
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci)) {
writew_be(val, uhci->regs + reg);
+ return;
+ }
#endif
- else
- writew(val, uhci->regs + reg);
+
+ writew(val, uhci->regs + reg);
}
static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
{
+#ifdef CONFIG_HAS_IOPORT
if (uhci_has_pci_registers(uhci))
return inb(uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+#endif
+ if (uhci_is_aspeed(uhci))
return readl(uhci->regs + uhci_aspeed_reg(reg));
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci))
return readb_be(uhci->regs + reg);
#endif
- else
- return readb(uhci->regs + reg);
+
+ return readb(uhci->regs + reg);
}
static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
{
- if (uhci_has_pci_registers(uhci))
+#ifdef CONFIG_HAS_IOPORT
+ if (uhci_has_pci_registers(uhci)) {
outb(val, uhci->io_addr + reg);
- else if (uhci_is_aspeed(uhci))
+ return;
+ }
+#endif
+ if (uhci_is_aspeed(uhci)) {
writel(val, uhci->regs + uhci_aspeed_reg(reg));
+ return;
+ }
#ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
- else if (uhci_big_endian_mmio(uhci))
+ if (uhci_big_endian_mmio(uhci)) {
writeb_be(val, uhci->regs + reg);
+ return;
+ }
#endif
- else
- writeb(val, uhci->regs + reg);
+ writeb(val, uhci->regs + reg);
}
#endif /* CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC */
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
2021-12-27 16:43 ` Niklas Schnelle
@ 2021-12-27 20:36 ` Alan Stern
-1 siblings, 0 replies; 323+ messages in thread
From: Alan Stern @ 2021-12-27 20:36 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to guard sections of code calling them
> as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> drivers requiring these functions need to depend on HAS_IOPORT.
A few things in here can be improved.
>
> 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>
> ---
> drivers/usb/core/hcd-pci.c | 3 +-
> drivers/usb/host/Kconfig | 4 +-
> drivers/usb/host/pci-quirks.c | 127 ++++++++++++++++++----------------
> drivers/usb/host/pci-quirks.h | 33 ++++++---
> drivers/usb/host/uhci-hcd.c | 2 +-
> drivers/usb/host/uhci-hcd.h | 77 ++++++++++++++-------
> 6 files changed, 148 insertions(+), 98 deletions(-)
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index ef08d68b9714..bba320194027 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> +#ifdef CONFIG_USB_PCI_AMD
> +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
In the original, the following code will be compiled even if
CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
> /*
> * Make sure the controller is completely inactive, unable to
> * generate interrupts or do DMA.
> @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> "Can't enable PCI device, BIOS handoff failed.\n");
> return;
> }
> - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> quirk_usb_handoff_uhci(pdev);
Same idea here.
> else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
> quirk_usb_handoff_ohci(pdev);
> diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
> index e729de21fad7..42eb18be37af 100644
> --- a/drivers/usb/host/pci-quirks.h
> +++ b/drivers/usb/host/pci-quirks.h
> @@ -2,33 +2,50 @@
> #ifndef __LINUX_USB_PCI_QUIRKS_H
> #define __LINUX_USB_PCI_QUIRKS_H
>
> -#ifdef CONFIG_USB_PCI
> void uhci_reset_hc(struct pci_dev *pdev, unsigned long base);
> int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base);
> -int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev);
> +
> +struct pci_dev;
This can't be right; struct pci_dev is referred to three lines earlier.
You could move this up, but it may not be needed at all.
> diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> index 8ae5ccd26753..8e30116b6fd2 100644
> --- a/drivers/usb/host/uhci-hcd.h
> +++ b/drivers/usb/host/uhci-hcd.h
> @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
>
> static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> {
> +#ifdef CONFIG_HAS_IOPORT
> if (uhci_has_pci_registers(uhci))
> return inl(uhci->io_addr + reg);
> - else if (uhci_is_aspeed(uhci))
> +#endif
Instead of making all these changes (here and in the hunks below), you
can simply modify the definition of uhci_has_pci_registers() so that it
always gives 0 when CONFIG_HAS_IOPORT is N.
Alan Stern
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
@ 2021-12-27 20:36 ` Alan Stern
0 siblings, 0 replies; 323+ messages in thread
From: Alan Stern @ 2021-12-27 20:36 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to guard sections of code calling them
> as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> drivers requiring these functions need to depend on HAS_IOPORT.
A few things in here can be improved.
>
> 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>
> ---
> drivers/usb/core/hcd-pci.c | 3 +-
> drivers/usb/host/Kconfig | 4 +-
> drivers/usb/host/pci-quirks.c | 127 ++++++++++++++++++----------------
> drivers/usb/host/pci-quirks.h | 33 ++++++---
> drivers/usb/host/uhci-hcd.c | 2 +-
> drivers/usb/host/uhci-hcd.h | 77 ++++++++++++++-------
> 6 files changed, 148 insertions(+), 98 deletions(-)
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index ef08d68b9714..bba320194027 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> +#ifdef CONFIG_USB_PCI_AMD
> +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
In the original, the following code will be compiled even if
CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
> /*
> * Make sure the controller is completely inactive, unable to
> * generate interrupts or do DMA.
> @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> "Can't enable PCI device, BIOS handoff failed.\n");
> return;
> }
> - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> quirk_usb_handoff_uhci(pdev);
Same idea here.
> else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
> quirk_usb_handoff_ohci(pdev);
> diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
> index e729de21fad7..42eb18be37af 100644
> --- a/drivers/usb/host/pci-quirks.h
> +++ b/drivers/usb/host/pci-quirks.h
> @@ -2,33 +2,50 @@
> #ifndef __LINUX_USB_PCI_QUIRKS_H
> #define __LINUX_USB_PCI_QUIRKS_H
>
> -#ifdef CONFIG_USB_PCI
> void uhci_reset_hc(struct pci_dev *pdev, unsigned long base);
> int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base);
> -int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev);
> +
> +struct pci_dev;
This can't be right; struct pci_dev is referred to three lines earlier.
You could move this up, but it may not be needed at all.
> diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> index 8ae5ccd26753..8e30116b6fd2 100644
> --- a/drivers/usb/host/uhci-hcd.h
> +++ b/drivers/usb/host/uhci-hcd.h
> @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
>
> static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> {
> +#ifdef CONFIG_HAS_IOPORT
> if (uhci_has_pci_registers(uhci))
> return inl(uhci->io_addr + reg);
> - else if (uhci_is_aspeed(uhci))
> +#endif
Instead of making all these changes (here and in the hunks below), you
can simply modify the definition of uhci_has_pci_registers() so that it
always gives 0 when CONFIG_HAS_IOPORT is N.
Alan Stern
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
2021-12-27 20:36 ` Alan Stern
@ 2021-12-31 11:06 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:06 UTC (permalink / raw)
To: Alan Stern
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to guard sections of code calling them
> > as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> > drivers requiring these functions need to depend on HAS_IOPORT.
>
> A few things in here can be improved.
>
> > 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>
> > ---
> > drivers/usb/core/hcd-pci.c | 3 +-
> > drivers/usb/host/Kconfig | 4 +-
> > drivers/usb/host/pci-quirks.c | 127 ++++++++++++++++++----------------
> > drivers/usb/host/pci-quirks.h | 33 ++++++---
> > drivers/usb/host/uhci-hcd.c | 2 +-
> > drivers/usb/host/uhci-hcd.h | 77 ++++++++++++++-------
> > 6 files changed, 148 insertions(+), 98 deletions(-)
> > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > index ef08d68b9714..bba320194027 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > +#ifdef CONFIG_USB_PCI_AMD
> > +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
>
> In the original, the following code will be compiled even if
> CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
If this was only '#ifdef CONFIG_HAS_IOPORT' we would leave
uhci_reset_hc() undeclared in the case where CONFIG_HAS_IOPORT is
unset. This function however is also called from uhci-pci.c. That on
the other hand is built only if CONFIG_USB_UHCI_HCD is set so if we
depend on both config options we can get rid of all calls and have the
functions undeclared.
>
> > /*
> > * Make sure the controller is completely inactive, unable to
> > * generate interrupts or do DMA.
> > @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> > "Can't enable PCI device, BIOS handoff failed.\n");
> > return;
> > }
> > - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> > + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > quirk_usb_handoff_uhci(pdev);
>
> Same idea here.
Hmm, I'm not 100% sure if the IS_ENABLED(CONFIG_USB_UHCI_HCD) depends
on some compiler optimizations for it to be ok that
uhci_check_and_reset_hc() is not declared in the case where both
CONFIG_HAS_IOPORT and CONFIG_USB_UHCI_HCD are unset. Maybe that should
be a plain ifdef.
>
> > else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
> > quirk_usb_handoff_ohci(pdev);
> > diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
> > index e729de21fad7..42eb18be37af 100644
> > --- a/drivers/usb/host/pci-quirks.h
> > +++ b/drivers/usb/host/pci-quirks.h
> > @@ -2,33 +2,50 @@
> > #ifndef __LINUX_USB_PCI_QUIRKS_H
> > #define __LINUX_USB_PCI_QUIRKS_H
> >
> > -#ifdef CONFIG_USB_PCI
> > void uhci_reset_hc(struct pci_dev *pdev, unsigned long base);
> > int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base);
> > -int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev);
> > +
> > +struct pci_dev;
>
> This can't be right; struct pci_dev is referred to three lines earlier.
> You could move this up, but it may not be needed at all.
I agree.
>
> > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > index 8ae5ccd26753..8e30116b6fd2 100644
> > --- a/drivers/usb/host/uhci-hcd.h
> > +++ b/drivers/usb/host/uhci-hcd.h
> > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> >
> > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > {
> > +#ifdef CONFIG_HAS_IOPORT
> > if (uhci_has_pci_registers(uhci))
> > return inl(uhci->io_addr + reg);
> > - else if (uhci_is_aspeed(uhci))
> > +#endif
>
> Instead of making all these changes (here and in the hunks below), you
> can simply modify the definition of uhci_has_pci_registers() so that it
> always gives 0 when CONFIG_HAS_IOPORT is N.
>
> Alan Stern
I don't think that works, for example in the hunk you quoted returning
0 from uhci_has_pci_registers() only skips over the inl() at run-time.
We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
@ 2021-12-31 11:06 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-31 11:06 UTC (permalink / raw)
To: Alan Stern
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to guard sections of code calling them
> > as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> > drivers requiring these functions need to depend on HAS_IOPORT.
>
> A few things in here can be improved.
>
> > 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>
> > ---
> > drivers/usb/core/hcd-pci.c | 3 +-
> > drivers/usb/host/Kconfig | 4 +-
> > drivers/usb/host/pci-quirks.c | 127 ++++++++++++++++++----------------
> > drivers/usb/host/pci-quirks.h | 33 ++++++---
> > drivers/usb/host/uhci-hcd.c | 2 +-
> > drivers/usb/host/uhci-hcd.h | 77 ++++++++++++++-------
> > 6 files changed, 148 insertions(+), 98 deletions(-)
> > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > index ef08d68b9714..bba320194027 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > +#ifdef CONFIG_USB_PCI_AMD
> > +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
>
> In the original, the following code will be compiled even if
> CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
If this was only '#ifdef CONFIG_HAS_IOPORT' we would leave
uhci_reset_hc() undeclared in the case where CONFIG_HAS_IOPORT is
unset. This function however is also called from uhci-pci.c. That on
the other hand is built only if CONFIG_USB_UHCI_HCD is set so if we
depend on both config options we can get rid of all calls and have the
functions undeclared.
>
> > /*
> > * Make sure the controller is completely inactive, unable to
> > * generate interrupts or do DMA.
> > @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> > "Can't enable PCI device, BIOS handoff failed.\n");
> > return;
> > }
> > - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> > + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > quirk_usb_handoff_uhci(pdev);
>
> Same idea here.
Hmm, I'm not 100% sure if the IS_ENABLED(CONFIG_USB_UHCI_HCD) depends
on some compiler optimizations for it to be ok that
uhci_check_and_reset_hc() is not declared in the case where both
CONFIG_HAS_IOPORT and CONFIG_USB_UHCI_HCD are unset. Maybe that should
be a plain ifdef.
>
> > else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
> > quirk_usb_handoff_ohci(pdev);
> > diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
> > index e729de21fad7..42eb18be37af 100644
> > --- a/drivers/usb/host/pci-quirks.h
> > +++ b/drivers/usb/host/pci-quirks.h
> > @@ -2,33 +2,50 @@
> > #ifndef __LINUX_USB_PCI_QUIRKS_H
> > #define __LINUX_USB_PCI_QUIRKS_H
> >
> > -#ifdef CONFIG_USB_PCI
> > void uhci_reset_hc(struct pci_dev *pdev, unsigned long base);
> > int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base);
> > -int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev);
> > +
> > +struct pci_dev;
>
> This can't be right; struct pci_dev is referred to three lines earlier.
> You could move this up, but it may not be needed at all.
I agree.
>
> > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > index 8ae5ccd26753..8e30116b6fd2 100644
> > --- a/drivers/usb/host/uhci-hcd.h
> > +++ b/drivers/usb/host/uhci-hcd.h
> > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> >
> > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > {
> > +#ifdef CONFIG_HAS_IOPORT
> > if (uhci_has_pci_registers(uhci))
> > return inl(uhci->io_addr + reg);
> > - else if (uhci_is_aspeed(uhci))
> > +#endif
>
> Instead of making all these changes (here and in the hunks below), you
> can simply modify the definition of uhci_has_pci_registers() so that it
> always gives 0 when CONFIG_HAS_IOPORT is N.
>
> Alan Stern
I don't think that works, for example in the hunk you quoted returning
0 from uhci_has_pci_registers() only skips over the inl() at run-time.
We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
2021-12-31 11:06 ` Niklas Schnelle
@ 2021-12-31 17:15 ` Alan Stern
-1 siblings, 0 replies; 323+ messages in thread
From: Alan Stern @ 2021-12-31 17:15 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Fri, Dec 31, 2021 at 12:06:24PM +0100, Niklas Schnelle wrote:
> On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> > On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. We thus need to guard sections of code calling them
> > > as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> > > drivers requiring these functions need to depend on HAS_IOPORT.
> >
> > A few things in here can be improved.
> >
> > > 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>
> > > ---
> > > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > > index ef08d68b9714..bba320194027 100644
> > > --- a/drivers/usb/host/pci-quirks.c
> > > +++ b/drivers/usb/host/pci-quirks.c
> > > +#ifdef CONFIG_USB_PCI_AMD
> > > +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
> >
> > In the original, the following code will be compiled even if
> > CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
>
> If this was only '#ifdef CONFIG_HAS_IOPORT' we would leave
> uhci_reset_hc() undeclared in the case where CONFIG_HAS_IOPORT is
> unset. This function however is also called from uhci-pci.c. That on
> the other hand is built only if CONFIG_USB_UHCI_HCD is set so if we
> depend on both config options we can get rid of all calls and have the
> functions undeclared.
But you changed the guard around the '#include "uhci-pci.c"' line in
uhci-hcd.c, so uhci-pci.c won't be built if CONFIG_HAS_IOPORT is unset.
Thus there won't be an undefined function call regardless.
You see, even if the kernel isn't configured to include a UHCI driver,
it's still important to hand off and disable any PCI UHCI hardware when
the system starts up. Otherwise you can get all sorts of crazy
interrupts and DMA from the BIOS.
> > > /*
> > > * Make sure the controller is completely inactive, unable to
> > > * generate interrupts or do DMA.
> > > @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> > > "Can't enable PCI device, BIOS handoff failed.\n");
> > > return;
> > > }
> > > - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> > > + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > quirk_usb_handoff_uhci(pdev);
> >
> > Same idea here.
>
> Hmm, I'm not 100% sure if the IS_ENABLED(CONFIG_USB_UHCI_HCD) depends
> on some compiler optimizations for it to be ok that
> uhci_check_and_reset_hc() is not declared in the case where both
> CONFIG_HAS_IOPORT and CONFIG_USB_UHCI_HCD are unset. Maybe that should
> be a plain ifdef.
The reasoning should be exactly the same as in the previous case.
> > > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > > index 8ae5ccd26753..8e30116b6fd2 100644
> > > --- a/drivers/usb/host/uhci-hcd.h
> > > +++ b/drivers/usb/host/uhci-hcd.h
> > > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> > >
> > > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > > {
> > > +#ifdef CONFIG_HAS_IOPORT
> > > if (uhci_has_pci_registers(uhci))
> > > return inl(uhci->io_addr + reg);
> > > - else if (uhci_is_aspeed(uhci))
> > > +#endif
> >
> > Instead of making all these changes (here and in the hunks below), you
> > can simply modify the definition of uhci_has_pci_registers() so that it
> > always gives 0 when CONFIG_HAS_IOPORT is N.
> >
> > Alan Stern
>
> I don't think that works, for example in the hunk you quoted returning
> 0 from uhci_has_pci_registers() only skips over the inl() at run-time.
> We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
I see. Do you think the following would be acceptable? Add:
#ifdef CONFIG_HAS_IOPORT
#define UHCI_IN(x) x
#define UHCI_OUT(x) x
#else
#define UHCI_IN(x) 0
#define UHCI_OUT(x)
#endif
and then replace for example inl(uhci->io_addr + reg) with
UHCI_IN(inl(uhci->io_addr + reg)).
The definition of uhci_has_pci_registers() should be updated in any
case; there's no reason for it to do a runtime check of uhci->io_addr
when HAS_IOPORT is disabled.
Alan Stern
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
@ 2021-12-31 17:15 ` Alan Stern
0 siblings, 0 replies; 323+ messages in thread
From: Alan Stern @ 2021-12-31 17:15 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Fri, Dec 31, 2021 at 12:06:24PM +0100, Niklas Schnelle wrote:
> On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> > On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. We thus need to guard sections of code calling them
> > > as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> > > drivers requiring these functions need to depend on HAS_IOPORT.
> >
> > A few things in here can be improved.
> >
> > > 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>
> > > ---
> > > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > > index ef08d68b9714..bba320194027 100644
> > > --- a/drivers/usb/host/pci-quirks.c
> > > +++ b/drivers/usb/host/pci-quirks.c
> > > +#ifdef CONFIG_USB_PCI_AMD
> > > +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
> >
> > In the original, the following code will be compiled even if
> > CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
>
> If this was only '#ifdef CONFIG_HAS_IOPORT' we would leave
> uhci_reset_hc() undeclared in the case where CONFIG_HAS_IOPORT is
> unset. This function however is also called from uhci-pci.c. That on
> the other hand is built only if CONFIG_USB_UHCI_HCD is set so if we
> depend on both config options we can get rid of all calls and have the
> functions undeclared.
But you changed the guard around the '#include "uhci-pci.c"' line in
uhci-hcd.c, so uhci-pci.c won't be built if CONFIG_HAS_IOPORT is unset.
Thus there won't be an undefined function call regardless.
You see, even if the kernel isn't configured to include a UHCI driver,
it's still important to hand off and disable any PCI UHCI hardware when
the system starts up. Otherwise you can get all sorts of crazy
interrupts and DMA from the BIOS.
> > > /*
> > > * Make sure the controller is completely inactive, unable to
> > > * generate interrupts or do DMA.
> > > @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> > > "Can't enable PCI device, BIOS handoff failed.\n");
> > > return;
> > > }
> > > - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> > > + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > quirk_usb_handoff_uhci(pdev);
> >
> > Same idea here.
>
> Hmm, I'm not 100% sure if the IS_ENABLED(CONFIG_USB_UHCI_HCD) depends
> on some compiler optimizations for it to be ok that
> uhci_check_and_reset_hc() is not declared in the case where both
> CONFIG_HAS_IOPORT and CONFIG_USB_UHCI_HCD are unset. Maybe that should
> be a plain ifdef.
The reasoning should be exactly the same as in the previous case.
> > > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > > index 8ae5ccd26753..8e30116b6fd2 100644
> > > --- a/drivers/usb/host/uhci-hcd.h
> > > +++ b/drivers/usb/host/uhci-hcd.h
> > > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> > >
> > > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > > {
> > > +#ifdef CONFIG_HAS_IOPORT
> > > if (uhci_has_pci_registers(uhci))
> > > return inl(uhci->io_addr + reg);
> > > - else if (uhci_is_aspeed(uhci))
> > > +#endif
> >
> > Instead of making all these changes (here and in the hunks below), you
> > can simply modify the definition of uhci_has_pci_registers() so that it
> > always gives 0 when CONFIG_HAS_IOPORT is N.
> >
> > Alan Stern
>
> I don't think that works, for example in the hunk you quoted returning
> 0 from uhci_has_pci_registers() only skips over the inl() at run-time.
> We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
I see. Do you think the following would be acceptable? Add:
#ifdef CONFIG_HAS_IOPORT
#define UHCI_IN(x) x
#define UHCI_OUT(x) x
#else
#define UHCI_IN(x) 0
#define UHCI_OUT(x)
#endif
and then replace for example inl(uhci->io_addr + reg) with
UHCI_IN(inl(uhci->io_addr + reg)).
The definition of uhci_has_pci_registers() should be updated in any
case; there's no reason for it to do a runtime check of uhci->io_addr
when HAS_IOPORT is disabled.
Alan Stern
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
2021-12-31 17:15 ` Alan Stern
@ 2022-01-03 11:35 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-03 11:35 UTC (permalink / raw)
To: Alan Stern
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Fri, 2021-12-31 at 12:15 -0500, Alan Stern wrote:
> On Fri, Dec 31, 2021 at 12:06:24PM +0100, Niklas Schnelle wrote:
> > On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> > > On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. We thus need to guard sections of code calling them
> > > > as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> > > > drivers requiring these functions need to depend on HAS_IOPORT.
> > >
> > > A few things in here can be improved.
> > >
> > > > 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>
> > > > ---
> > > > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > > > index ef08d68b9714..bba320194027 100644
> > > > --- a/drivers/usb/host/pci-quirks.c
> > > > +++ b/drivers/usb/host/pci-quirks.c
> > > > +#ifdef CONFIG_USB_PCI_AMD
> > > > +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
> > >
> > > In the original, the following code will be compiled even if
> > > CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
> >
> > If this was only '#ifdef CONFIG_HAS_IOPORT' we would leave
> > uhci_reset_hc() undeclared in the case where CONFIG_HAS_IOPORT is
> > unset. This function however is also called from uhci-pci.c. That on
> > the other hand is built only if CONFIG_USB_UHCI_HCD is set so if we
> > depend on both config options we can get rid of all calls and have the
> > functions undeclared.
>
> But you changed the guard around the '#include "uhci-pci.c"' line in
> uhci-hcd.c, so uhci-pci.c won't be built if CONFIG_HAS_IOPORT is unset.
> Thus there won't be an undefined function call regardless.
Ah thanks yes that makes sense. I seem to have gotten confused by the
uhci-hcd.c vs uhci-pci.c dependency.
>
> You see, even if the kernel isn't configured to include a UHCI driver,
> it's still important to hand off and disable any PCI UHCI hardware when
> the system starts up. Otherwise you can get all sorts of crazy
> interrupts and DMA from the BIOS.
Thanks for the explanation, this is very helpful to understand the
context.
>
> > > > /*
> > > > * Make sure the controller is completely inactive, unable to
> > > > * generate interrupts or do DMA.
> > > > @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> > > > "Can't enable PCI device, BIOS handoff failed.\n");
> > > > return;
> > > > }
> > > > - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > > + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> > > > + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > > quirk_usb_handoff_uhci(pdev);
> > >
> > > Same idea here.
> >
> > Hmm, I'm not 100% sure if the IS_ENABLED(CONFIG_USB_UHCI_HCD) depends
> > on some compiler optimizations for it to be ok that
> > uhci_check_and_reset_hc() is not declared in the case where both
> > CONFIG_HAS_IOPORT and CONFIG_USB_UHCI_HCD are unset. Maybe that should
> > be a plain ifdef.
>
> The reasoning should be exactly the same as in the previous case.
Yeah with your above explanation it makes sense that we need to keep
the calls even if CONFIG_USB_UHCI_HCD is not enabled. We're also
handling the CONFIG_HAS_IOPORT=n case in quirk_usb_handoff_uhci()
anyway.
>
> > > > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > > > index 8ae5ccd26753..8e30116b6fd2 100644
> > > > --- a/drivers/usb/host/uhci-hcd.h
> > > > +++ b/drivers/usb/host/uhci-hcd.h
> > > > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> > > >
> > > > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > > > {
> > > > +#ifdef CONFIG_HAS_IOPORT
> > > > if (uhci_has_pci_registers(uhci))
> > > > return inl(uhci->io_addr + reg);
> > > > - else if (uhci_is_aspeed(uhci))
> > > > +#endif
> > >
> > > Instead of making all these changes (here and in the hunks below), you
> > > can simply modify the definition of uhci_has_pci_registers() so that it
> > > always gives 0 when CONFIG_HAS_IOPORT is N.
> > >
> > > Alan Stern
> >
> > I don't think that works, for example in the hunk you quoted returning
> > 0 from uhci_has_pci_registers() only skips over the inl() at run-time.
> > We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
>
> I see. Do you think the following would be acceptable? Add:
>
> #ifdef CONFIG_HAS_IOPORT
> #define UHCI_IN(x) x
> #define UHCI_OUT(x) x
> #else
> #define UHCI_IN(x) 0
> #define UHCI_OUT(x)
> #endif
>
> and then replace for example inl(uhci->io_addr + reg) with
> UHCI_IN(inl(uhci->io_addr + reg)).
In principle that looks like a valid approach. Not sure this is better
than explicit ifdefs though. With this approach one could add
UHCI_IN()/UHCI_OUT() calls which end up as nops without realizing it as
it would disable any compile time warning for using them without
guarding against CONFIG_HAS_IOPORT being undefined.
>
> The definition of uhci_has_pci_registers() should be updated in any
> case; there's no reason for it to do a runtime check of uhci->io_addr
> when HAS_IOPORT is disabled.
Agree. Interestingly same as with the "if
(IS_ENABLED(CONFIG_HAS_IOPORT))" it seems having
uhci_has_pci_registers() compile-time defined to 0 (I added a
defined(CONFIG_HAS_IOPORT) to it) makes the compiler ignore the missing
inl() decleration already. But I'm not sure if we should rely on that.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
@ 2022-01-03 11:35 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-03 11:35 UTC (permalink / raw)
To: Alan Stern
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Fri, 2021-12-31 at 12:15 -0500, Alan Stern wrote:
> On Fri, Dec 31, 2021 at 12:06:24PM +0100, Niklas Schnelle wrote:
> > On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> > > On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. We thus need to guard sections of code calling them
> > > > as alternative access methods with CONFIG_HAS_IOPORT checks. Similarly
> > > > drivers requiring these functions need to depend on HAS_IOPORT.
> > >
> > > A few things in here can be improved.
> > >
> > > > 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>
> > > > ---
> > > > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > > > index ef08d68b9714..bba320194027 100644
> > > > --- a/drivers/usb/host/pci-quirks.c
> > > > +++ b/drivers/usb/host/pci-quirks.c
> > > > +#ifdef CONFIG_USB_PCI_AMD
> > > > +#if IS_ENABLED(CONFIG_USB_UHCI_HCD) && defined(CONFIG_HAS_IOPORT)
> > >
> > > In the original, the following code will be compiled even if
> > > CONFIG_USB_UHCI_HCD is not enabled. You shouldn't change that.
> >
> > If this was only '#ifdef CONFIG_HAS_IOPORT' we would leave
> > uhci_reset_hc() undeclared in the case where CONFIG_HAS_IOPORT is
> > unset. This function however is also called from uhci-pci.c. That on
> > the other hand is built only if CONFIG_USB_UHCI_HCD is set so if we
> > depend on both config options we can get rid of all calls and have the
> > functions undeclared.
>
> But you changed the guard around the '#include "uhci-pci.c"' line in
> uhci-hcd.c, so uhci-pci.c won't be built if CONFIG_HAS_IOPORT is unset.
> Thus there won't be an undefined function call regardless.
Ah thanks yes that makes sense. I seem to have gotten confused by the
uhci-hcd.c vs uhci-pci.c dependency.
>
> You see, even if the kernel isn't configured to include a UHCI driver,
> it's still important to hand off and disable any PCI UHCI hardware when
> the system starts up. Otherwise you can get all sorts of crazy
> interrupts and DMA from the BIOS.
Thanks for the explanation, this is very helpful to understand the
context.
>
> > > > /*
> > > > * Make sure the controller is completely inactive, unable to
> > > > * generate interrupts or do DMA.
> > > > @@ -1273,7 +1277,8 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
> > > > "Can't enable PCI device, BIOS handoff failed.\n");
> > > > return;
> > > > }
> > > > - if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > > + if (IS_ENABLED(CONFIG_USB_UHCI_HCD) &&
> > > > + pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
> > > > quirk_usb_handoff_uhci(pdev);
> > >
> > > Same idea here.
> >
> > Hmm, I'm not 100% sure if the IS_ENABLED(CONFIG_USB_UHCI_HCD) depends
> > on some compiler optimizations for it to be ok that
> > uhci_check_and_reset_hc() is not declared in the case where both
> > CONFIG_HAS_IOPORT and CONFIG_USB_UHCI_HCD are unset. Maybe that should
> > be a plain ifdef.
>
> The reasoning should be exactly the same as in the previous case.
Yeah with your above explanation it makes sense that we need to keep
the calls even if CONFIG_USB_UHCI_HCD is not enabled. We're also
handling the CONFIG_HAS_IOPORT=n case in quirk_usb_handoff_uhci()
anyway.
>
> > > > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > > > index 8ae5ccd26753..8e30116b6fd2 100644
> > > > --- a/drivers/usb/host/uhci-hcd.h
> > > > +++ b/drivers/usb/host/uhci-hcd.h
> > > > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> > > >
> > > > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > > > {
> > > > +#ifdef CONFIG_HAS_IOPORT
> > > > if (uhci_has_pci_registers(uhci))
> > > > return inl(uhci->io_addr + reg);
> > > > - else if (uhci_is_aspeed(uhci))
> > > > +#endif
> > >
> > > Instead of making all these changes (here and in the hunks below), you
> > > can simply modify the definition of uhci_has_pci_registers() so that it
> > > always gives 0 when CONFIG_HAS_IOPORT is N.
> > >
> > > Alan Stern
> >
> > I don't think that works, for example in the hunk you quoted returning
> > 0 from uhci_has_pci_registers() only skips over the inl() at run-time.
> > We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
>
> I see. Do you think the following would be acceptable? Add:
>
> #ifdef CONFIG_HAS_IOPORT
> #define UHCI_IN(x) x
> #define UHCI_OUT(x) x
> #else
> #define UHCI_IN(x) 0
> #define UHCI_OUT(x)
> #endif
>
> and then replace for example inl(uhci->io_addr + reg) with
> UHCI_IN(inl(uhci->io_addr + reg)).
In principle that looks like a valid approach. Not sure this is better
than explicit ifdefs though. With this approach one could add
UHCI_IN()/UHCI_OUT() calls which end up as nops without realizing it as
it would disable any compile time warning for using them without
guarding against CONFIG_HAS_IOPORT being undefined.
>
> The definition of uhci_has_pci_registers() should be updated in any
> case; there's no reason for it to do a runtime check of uhci->io_addr
> when HAS_IOPORT is disabled.
Agree. Interestingly same as with the "if
(IS_ENABLED(CONFIG_HAS_IOPORT))" it seems having
uhci_has_pci_registers() compile-time defined to 0 (I added a
defined(CONFIG_HAS_IOPORT) to it) makes the compiler ignore the missing
inl() decleration already. But I'm not sure if we should rely on that.
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
2022-01-03 11:35 ` Niklas Schnelle
@ 2022-01-03 16:15 ` Alan Stern
-1 siblings, 0 replies; 323+ messages in thread
From: Alan Stern @ 2022-01-03 16:15 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Mon, Jan 03, 2022 at 12:35:45PM +0100, Niklas Schnelle wrote:
> On Fri, 2021-12-31 at 12:15 -0500, Alan Stern wrote:
> > On Fri, Dec 31, 2021 at 12:06:24PM +0100, Niklas Schnelle wrote:
> > > On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> > > > On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > > > > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > > > > index 8ae5ccd26753..8e30116b6fd2 100644
> > > > > --- a/drivers/usb/host/uhci-hcd.h
> > > > > +++ b/drivers/usb/host/uhci-hcd.h
> > > > > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> > > > >
> > > > > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > > > > {
> > > > > +#ifdef CONFIG_HAS_IOPORT
> > > > > if (uhci_has_pci_registers(uhci))
> > > > > return inl(uhci->io_addr + reg);
> > > > > - else if (uhci_is_aspeed(uhci))
> > > > > +#endif
> > > >
> > > > Instead of making all these changes (here and in the hunks below), you
> > > > can simply modify the definition of uhci_has_pci_registers() so that it
> > > > always gives 0 when CONFIG_HAS_IOPORT is N.
> > > >
> > > > Alan Stern
> > >
> > > I don't think that works, for example in the hunk you quoted returning
> > > 0 from uhci_has_pci_registers() only skips over the inl() at run-time.
> > > We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
> >
> > I see. Do you think the following would be acceptable? Add:
> >
> > #ifdef CONFIG_HAS_IOPORT
> > #define UHCI_IN(x) x
> > #define UHCI_OUT(x) x
> > #else
> > #define UHCI_IN(x) 0
> > #define UHCI_OUT(x)
> > #endif
> >
> > and then replace for example inl(uhci->io_addr + reg) with
> > UHCI_IN(inl(uhci->io_addr + reg)).
>
> In principle that looks like a valid approach. Not sure this is better
> than explicit ifdefs though.
The general preference in the kernel is to avoid sprinkling #ifdef's
throughout function definitions, and instead encapsulate their effects
with macros or inline functions -- like this.
> With this approach one could add
> UHCI_IN()/UHCI_OUT() calls which end up as nops without realizing it as
> it would disable any compile time warning for using them without
> guarding against CONFIG_HAS_IOPORT being undefined.
To help prevent that, we can add
#undef UHCI_IN
#undef UHCI_OUT
at the end of this section.
> > The definition of uhci_has_pci_registers() should be updated in any
> > case; there's no reason for it to do a runtime check of uhci->io_addr
> > when HAS_IOPORT is disabled.
>
> Agree. Interestingly same as with the "if
> (IS_ENABLED(CONFIG_HAS_IOPORT))" it seems having
> uhci_has_pci_registers() compile-time defined to 0 (I added a
> defined(CONFIG_HAS_IOPORT) to it) makes the compiler ignore the missing
> inl() decleration already. But I'm not sure if we should rely on that.
I definitely would not rely on it.
Alan Stern
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 31/32] usb: handle HAS_IOPORT dependencies
@ 2022-01-03 16:15 ` Alan Stern
0 siblings, 0 replies; 323+ messages in thread
From: Alan Stern @ 2022-01-03 16:15 UTC (permalink / raw)
To: Niklas Schnelle
Cc: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Greg Kroah-Hartman, Mathias Nyman, linux-kernel, linux-arch,
linux-pci, linux-riscv, linux-csky, linux-usb
On Mon, Jan 03, 2022 at 12:35:45PM +0100, Niklas Schnelle wrote:
> On Fri, 2021-12-31 at 12:15 -0500, Alan Stern wrote:
> > On Fri, Dec 31, 2021 at 12:06:24PM +0100, Niklas Schnelle wrote:
> > > On Mon, 2021-12-27 at 15:36 -0500, Alan Stern wrote:
> > > > On Mon, Dec 27, 2021 at 05:43:16PM +0100, Niklas Schnelle wrote:
> > > > > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > > > > index 8ae5ccd26753..8e30116b6fd2 100644
> > > > > --- a/drivers/usb/host/uhci-hcd.h
> > > > > +++ b/drivers/usb/host/uhci-hcd.h
> > > > > @@ -586,12 +586,14 @@ static inline int uhci_aspeed_reg(unsigned int reg)
> > > > >
> > > > > static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> > > > > {
> > > > > +#ifdef CONFIG_HAS_IOPORT
> > > > > if (uhci_has_pci_registers(uhci))
> > > > > return inl(uhci->io_addr + reg);
> > > > > - else if (uhci_is_aspeed(uhci))
> > > > > +#endif
> > > >
> > > > Instead of making all these changes (here and in the hunks below), you
> > > > can simply modify the definition of uhci_has_pci_registers() so that it
> > > > always gives 0 when CONFIG_HAS_IOPORT is N.
> > > >
> > > > Alan Stern
> > >
> > > I don't think that works, for example in the hunk you quoted returning
> > > 0 from uhci_has_pci_registers() only skips over the inl() at run-time.
> > > We're aiming to have inl() undeclared if HAS_IOPORT is unset though.
> >
> > I see. Do you think the following would be acceptable? Add:
> >
> > #ifdef CONFIG_HAS_IOPORT
> > #define UHCI_IN(x) x
> > #define UHCI_OUT(x) x
> > #else
> > #define UHCI_IN(x) 0
> > #define UHCI_OUT(x)
> > #endif
> >
> > and then replace for example inl(uhci->io_addr + reg) with
> > UHCI_IN(inl(uhci->io_addr + reg)).
>
> In principle that looks like a valid approach. Not sure this is better
> than explicit ifdefs though.
The general preference in the kernel is to avoid sprinkling #ifdef's
throughout function definitions, and instead encapsulate their effects
with macros or inline functions -- like this.
> With this approach one could add
> UHCI_IN()/UHCI_OUT() calls which end up as nops without realizing it as
> it would disable any compile time warning for using them without
> guarding against CONFIG_HAS_IOPORT being undefined.
To help prevent that, we can add
#undef UHCI_IN
#undef UHCI_OUT
at the end of this section.
> > The definition of uhci_has_pci_registers() should be updated in any
> > case; there's no reason for it to do a runtime check of uhci->io_addr
> > when HAS_IOPORT is disabled.
>
> Agree. Interestingly same as with the "if
> (IS_ENABLED(CONFIG_HAS_IOPORT))" it seems having
> uhci_has_pci_registers() compile-time defined to 0 (I added a
> defined(CONFIG_HAS_IOPORT) to it) makes the compiler ignore the missing
> inl() decleration already. But I'm not sure if we should rely on that.
I definitely would not rely on it.
Alan Stern
^ permalink raw reply [flat|nested] 323+ messages in thread
* [RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
2021-12-27 16:42 ` Niklas Schnelle
@ 2021-12-27 16:43 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
With all subsystems and drivers either declaring their dependence on
HAS_IOPORT or ifdeffing I/O port specific code sections we can finally
make inb()/outb() and friends compile-time dependent on HAS_IOPORT as
suggested by Linus in the linked mail. The main benefit of this is that
on platforms such as s390 which have no meaningful way of implementing
inb()/outb() their use without the proper HAS_IOPORT dependency will
result in easy to catch and fix compile-time errors instead of compiling
code that can never work.
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>
---
include/asm-generic/io.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ce93aaf69f8..b2572b2eab07 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -448,6 +448,7 @@ static inline void writesq(volatile void __iomem *addr, const void *buffer,
#define IO_SPACE_LIMIT 0xffff
#endif
+#ifdef CONFIG_HAS_IOPORT
/*
* {in,out}{b,w,l}() access little endian I/O. {in,out}{b,w,l}_p() can be
* implemented on hardware that needs an additional delay for I/O accesses to
@@ -522,9 +523,12 @@ static inline void _outl(u32 value, unsigned long addr)
__io_paw();
}
#endif
+#endif /* CONFIG_HAS_IOPORT */
#include <linux/logic_pio.h>
+#ifdef CONFIG_HAS_IOPORT
+
#ifndef inb
#define inb _inb
#endif
@@ -703,6 +707,7 @@ static inline void outsl_p(unsigned long addr, const void *buffer,
outsl(addr, buffer, count);
}
#endif
+#endif /* CONFIG_HAS_IOPORT */
#ifndef CONFIG_GENERIC_IOMAP
#ifndef ioread8
--
2.32.0
^ permalink raw reply related [flat|nested] 323+ messages in thread* [RFC 32/32] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
@ 2021-12-27 16:43 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2021-12-27 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Arnd Bergmann
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
With all subsystems and drivers either declaring their dependence on
HAS_IOPORT or ifdeffing I/O port specific code sections we can finally
make inb()/outb() and friends compile-time dependent on HAS_IOPORT as
suggested by Linus in the linked mail. The main benefit of this is that
on platforms such as s390 which have no meaningful way of implementing
inb()/outb() their use without the proper HAS_IOPORT dependency will
result in easy to catch and fix compile-time errors instead of compiling
code that can never work.
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>
---
include/asm-generic/io.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ce93aaf69f8..b2572b2eab07 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -448,6 +448,7 @@ static inline void writesq(volatile void __iomem *addr, const void *buffer,
#define IO_SPACE_LIMIT 0xffff
#endif
+#ifdef CONFIG_HAS_IOPORT
/*
* {in,out}{b,w,l}() access little endian I/O. {in,out}{b,w,l}_p() can be
* implemented on hardware that needs an additional delay for I/O accesses to
@@ -522,9 +523,12 @@ static inline void _outl(u32 value, unsigned long addr)
__io_paw();
}
#endif
+#endif /* CONFIG_HAS_IOPORT */
#include <linux/logic_pio.h>
+#ifdef CONFIG_HAS_IOPORT
+
#ifndef inb
#define inb _inb
#endif
@@ -703,6 +707,7 @@ static inline void outsl_p(unsigned long addr, const void *buffer,
outsl(addr, buffer, count);
}
#endif
+#endif /* CONFIG_HAS_IOPORT */
#ifndef CONFIG_GENERIC_IOMAP
#ifndef ioread8
--
2.32.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 323+ messages in thread
* Re: [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
2021-12-27 16:42 ` Niklas Schnelle
@ 2022-01-06 17:45 ` John Garry
-1 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-06 17:45 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Hi Niklas,
On 27/12/2021 16:42, Niklas Schnelle wrote:
> I performed the following testing:
>
> - On s390 this series on top of v5.16-rc7 builds with allyesconfig i.e. the
> HAS_IOPORT=n case.
Are you sure that allyesconfig gives HAS_IOPORT=n? Indeed I see no
mechanism is always disallow HAS_IOPORT for s390 (which I think we would
want).
> It also builds with defconfig and the resulting kernel
> appears fully functional including tests with PCI devices.
Thanks,
Johnw
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
@ 2022-01-06 17:45 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-06 17:45 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
Hi Niklas,
On 27/12/2021 16:42, Niklas Schnelle wrote:
> I performed the following testing:
>
> - On s390 this series on top of v5.16-rc7 builds with allyesconfig i.e. the
> HAS_IOPORT=n case.
Are you sure that allyesconfig gives HAS_IOPORT=n? Indeed I see no
mechanism is always disallow HAS_IOPORT for s390 (which I think we would
want).
> It also builds with defconfig and the resulting kernel
> appears fully functional including tests with PCI devices.
Thanks,
Johnw
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
2022-01-06 17:45 ` John Garry
@ 2022-01-07 7:21 ` Niklas Schnelle
-1 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-07 7:21 UTC (permalink / raw)
To: John Garry, Arnd Bergmann, Bjorn Helgaas, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Thu, 2022-01-06 at 17:45 +0000, John Garry wrote:
> Hi Niklas,
>
> On 27/12/2021 16:42, Niklas Schnelle wrote:
> > I performed the following testing:
> >
> > - On s390 this series on top of v5.16-rc7 builds with allyesconfig i.e. the
> > HAS_IOPORT=n case.
>
> Are you sure that allyesconfig gives HAS_IOPORT=n? Indeed I see no
> mechanism is always disallow HAS_IOPORT for s390 (which I think we would
> want).
>
> > It also builds with defconfig and the resulting kernel
> > appears fully functional including tests with PCI devices.
>
> Thanks,
> Johnw
>
I checked again by adding
config HAS_IOPORT
def_bool n
in arch/s390/Kconfig and that doesn't seem to make a difference,
allyesconfig builds all the same. Also checked for CONFIG_HAS_IOPORT in
my .config and that isn't listed with or without the above addition.
I think this is because without a help text there is no "config
question" and thus nothing that allyesconfig would set to yes. I do
agree though that it's better to be explicit and add the above to those
Kconfigs that don't support HAS_IOPORT.
Thanks,
Niklas
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
@ 2022-01-07 7:21 ` Niklas Schnelle
0 siblings, 0 replies; 323+ messages in thread
From: Niklas Schnelle @ 2022-01-07 7:21 UTC (permalink / raw)
To: John Garry, Arnd Bergmann, Bjorn Helgaas, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On Thu, 2022-01-06 at 17:45 +0000, John Garry wrote:
> Hi Niklas,
>
> On 27/12/2021 16:42, Niklas Schnelle wrote:
> > I performed the following testing:
> >
> > - On s390 this series on top of v5.16-rc7 builds with allyesconfig i.e. the
> > HAS_IOPORT=n case.
>
> Are you sure that allyesconfig gives HAS_IOPORT=n? Indeed I see no
> mechanism is always disallow HAS_IOPORT for s390 (which I think we would
> want).
>
> > It also builds with defconfig and the resulting kernel
> > appears fully functional including tests with PCI devices.
>
> Thanks,
> Johnw
>
I checked again by adding
config HAS_IOPORT
def_bool n
in arch/s390/Kconfig and that doesn't seem to make a difference,
allyesconfig builds all the same. Also checked for CONFIG_HAS_IOPORT in
my .config and that isn't listed with or without the above addition.
I think this is because without a help text there is no "config
question" and thus nothing that allyesconfig would set to yes. I do
agree though that it's better to be explicit and add the above to those
Kconfigs that don't support HAS_IOPORT.
Thanks,
Niklas
^ permalink raw reply [flat|nested] 323+ messages in thread* Re: [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
2022-01-07 7:21 ` Niklas Schnelle
@ 2022-01-07 16:57 ` John Garry
-1 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-07 16:57 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On 07/01/2022 07:21, Niklas Schnelle wrote:
> I checked again by adding
>
> config HAS_IOPORT
> def_bool n
>
> in arch/s390/Kconfig and that doesn't seem to make a difference,
> allyesconfig builds all the same. Also checked for CONFIG_HAS_IOPORT in
> my .config and that isn't listed with or without the above addition.
Strange, as I build your branch and I see it:
HEAD is now at 9f421b6580ed asm-generic/io.h: drop inb() etc for
HAS_IOPORT=n
john@localhost:~/kernel-dev5> export ARCH=s390
john@localhost:~/kernel-dev5> export
CROSS_COMPILE=/usr/bin/s390x-suse-linux-
john@localhost:~/kernel-dev5> make allyesconfig
#
# configuration written to .config
#
john@localhost:~/kernel-dev5> more .config | grep HAS_IOPORT
CONFIG_HAS_IOPORT=y
>
> I think this is because without a help text there is no "config
> question" and thus nothing that allyesconfig would set to yes. I do
> agree though that it's better to be explicit and add the above to those
> Kconfigs that don't support HAS_IOPORT.
So maybe something like:
config HAS_IOPORT
def_bool ISA || LEGACY_PCI
depends on !S390
Otherwise you can build inb et al from asm-generic/io.h and get the
original compile error about arithmetic on NULL pointer, right?
But I assume that there is a more elegant way of doing this...
Thanks,
John
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 323+ messages in thread
* Re: [RFC 00/32] Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options
@ 2022-01-07 16:57 ` John Garry
0 siblings, 0 replies; 323+ messages in thread
From: John Garry @ 2022-01-07 16:57 UTC (permalink / raw)
To: Niklas Schnelle, Arnd Bergmann, Bjorn Helgaas, Nick Hu,
Greentime Hu, Vincent Chen, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: linux-kernel, linux-arch, linux-pci, linux-riscv, linux-csky
On 07/01/2022 07:21, Niklas Schnelle wrote:
> I checked again by adding
>
> config HAS_IOPORT
> def_bool n
>
> in arch/s390/Kconfig and that doesn't seem to make a difference,
> allyesconfig builds all the same. Also checked for CONFIG_HAS_IOPORT in
> my .config and that isn't listed with or without the above addition.
Strange, as I build your branch and I see it:
HEAD is now at 9f421b6580ed asm-generic/io.h: drop inb() etc for
HAS_IOPORT=n
john@localhost:~/kernel-dev5> export ARCH=s390
john@localhost:~/kernel-dev5> export
CROSS_COMPILE=/usr/bin/s390x-suse-linux-
john@localhost:~/kernel-dev5> make allyesconfig
#
# configuration written to .config
#
john@localhost:~/kernel-dev5> more .config | grep HAS_IOPORT
CONFIG_HAS_IOPORT=y
>
> I think this is because without a help text there is no "config
> question" and thus nothing that allyesconfig would set to yes. I do
> agree though that it's better to be explicit and add the above to those
> Kconfigs that don't support HAS_IOPORT.
So maybe something like:
config HAS_IOPORT
def_bool ISA || LEGACY_PCI
depends on !S390
Otherwise you can build inb et al from asm-generic/io.h and get the
original compile error about arithmetic on NULL pointer, right?
But I assume that there is a more elegant way of doing this...
Thanks,
John
^ permalink raw reply [flat|nested] 323+ messages in thread