All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC v2 00/39] Kconfig: Introduce HAS_IOPORT config option
@ 2022-04-29 13:49 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Bjorn Helgaas, Mauro Carvalho Chehab, Alan Stern,
	Rafael J. Wysocki, Geert Uytterhoeven, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, open list:RISC-V ARCHITECTURE

Hello Kernel Hackers,

Some platforms such as s390 do not support PCI I/O spaces. On such platforms
I/O space accessors like inb()/outb() are 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 cause a NULL pointer access. In a previous patch
we tried handling this with a run-time warning on access. This approach however
was rejected by Linus[0] 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.

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.

This series builts heavily on an original patch for demonstating the concept by
Arnd Bergmann[1] and is a stripped down version of a previous RFC[2]. The most
important change being that we dropped the LEGACY_PCI config option in favor of
using HAS_IOPORT regardless of whether the device is a legacy PCI device.
As this is a significant change to the overall series I did not carry over
previous R-bs.

This version is based on v5.18-rc4 and is also available on my kernel.org tree
in the has_ioport branch with the PGP signed tag has_ioport_rfc_v2:

https://git.kernel.org/pub/scm/linux/kernel/git/niks/linux.git

Thanks,
Niklas Schnelle

Changes from RFC v1:
- Completely dropped the LEGACY_PCI option and replaced its dependencies with
  HAS_IOPORT as appropriate
- In the usb subsystem patch I incorporated the feedback from v1 by Alan Stern:
  - Used a local macro to nop in*()/out*() in the helpers
  - Removed an unnecessary further restriction on CONFIG_USB_UHCI_HCD
- Added a few more subsystems including wireless, ptp, and, mISDN that I had
  previously missed due to a blanket !S390.
- Removed blanket !S390 dependencies where they are added due to the I/O port
  problem
- In the sound system SND_OPL3_LIB needed to use "depends on" instead of
  "select" because of its added HAS_IOPORT dependency
- In the drm subsystem the bochs driver gets #ifdefs instead of a blanket
  dependency because its MMIO capable device variant should work without
  HAS_IOPORT.

[0] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
[1] https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
[2] https://yhbt.net/lore/all/20211227164317.4146918-1-schnelle@linux.ibm.com/

Niklas Schnelle (39):
  Kconfig: introduce HAS_IOPORT option and select it as necessary
  ACPI: add dependency on HAS_IOPORT
  ata: add HAS_IOPORT dependencies
  char: impi, tpm: depend on HAS_IOPORT
  comedi: add HAS_IOPORT dependencies
  counter: add HAS_IOPORT dependencies
  /dev/port: don't compile file operations without CONFIG_DEVPORT
  drm: handle HAS_IOPORT dependencies
  firmware: dmi-sysfs: handle HAS_IOPORT=n
  gpio: add HAS_IOPORT dependencies
  hwmon: add HAS_IOPORT dependencies
  i2c: add HAS_IOPORT dependencies
  iio: adc: Kconfig: add HAS_IOPORT dependencies
  Input: add HAS_IOPORT dependencies
  Input: gameport: add ISA and HAS_IOPORT dependencies
  leds: add HAS_IOPORT dependencies
  media: add HAS_IOPORT dependencies
  misc: add HAS_IOPORT dependencies
  mISDN: add HAS_IOPORT dependencies
  mpt fusion: add HAS_IOPORT dependencies
  net: add HAS_IOPORT dependencies
  parport: PC style parport depends on HAS_IOPORT
  PCI: make quirk using inw() depend on HAS_IOPORT
  PCI/sysfs: make I/O resource depend on HAS_IOPORT
  pcmcia: add HAS_IOPORT dependencies
  platform: add HAS_IOPORT dependencies
  pnp: add HAS_IOPORT dependencies
  power: add HAS_IOPORT dependencies
  rtc: add HAS_IOPORT dependencies
  scsi: add HAS_IOPORT dependencies
  sound: add HAS_IOPORT dependencies
  speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  staging: add HAS_IOPORT dependencies
  tty: serial: add HAS_IOPORT dependencies
  usb: handle HAS_IOPORT dependencies
  video: handle HAS_IOPORT dependencies
  watchdog: add HAS_IOPORT dependencies
  wireless: add HAS_IOPORT dependencies
  asm-generic/io.h: drop inb() etc for HAS_IOPORT=n

 arch/alpha/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                          |   1 +
 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                       |  33 ++++-
 drivers/counter/Kconfig                      |   1 +
 drivers/firmware/dmi-sysfs.c                 |   4 +
 drivers/gpio/Kconfig                         |   2 +-
 drivers/gpu/drm/qxl/Kconfig                  |   1 +
 drivers/gpu/drm/tiny/bochs.c                 |  19 +++
 drivers/gpu/drm/tiny/cirrus.c                |   2 +
 drivers/hwmon/Kconfig                        |  21 ++-
 drivers/i2c/busses/Kconfig                   |  31 +++--
 drivers/iio/adc/Kconfig                      |   2 +-
 drivers/input/gameport/Kconfig               |   4 +-
 drivers/input/serio/Kconfig                  |   2 +
 drivers/input/touchscreen/Kconfig            |   1 +
 drivers/isdn/Kconfig                         |   1 -
 drivers/isdn/hardware/mISDN/Kconfig          |  12 +-
 drivers/leds/Kconfig                         |   2 +-
 drivers/media/pci/dm1105/Kconfig             |   2 +-
 drivers/media/radio/Kconfig                  |  14 +-
 drivers/media/rc/Kconfig                     |   6 +
 drivers/message/fusion/Kconfig               |   2 +-
 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           |   2 +-
 drivers/net/ethernet/sis/Kconfig             |   4 +-
 drivers/net/ethernet/ti/Kconfig              |   2 +-
 drivers/net/ethernet/via/Kconfig             |   1 +
 drivers/net/fddi/Kconfig                     |   2 +-
 drivers/net/hamradio/Kconfig                 |   6 +-
 drivers/net/wan/Kconfig                      |   2 +-
 drivers/net/wireless/atmel/Kconfig           |   2 +-
 drivers/net/wireless/intersil/hostap/Kconfig |   2 +-
 drivers/parport/Kconfig                      |   4 +-
 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                         |  19 +--
 drivers/scsi/aic7xxx/Kconfig.aic79xx         |   2 +-
 drivers/scsi/aic7xxx/Kconfig.aic7xxx         |   2 +-
 drivers/scsi/aic94xx/Kconfig                 |   2 +-
 drivers/scsi/megaraid/Kconfig.megaraid       |   6 +-
 drivers/scsi/mvsas/Kconfig                   |   2 +-
 drivers/scsi/qla2xxx/Kconfig                 |   2 +-
 drivers/staging/sm750fb/Kconfig              |   2 +-
 drivers/staging/vt6655/Kconfig               |   2 +-
 drivers/tty/Kconfig                          |   2 +-
 drivers/tty/serial/8250/Kconfig              |   2 +-
 drivers/tty/serial/Kconfig                   |   2 +-
 drivers/usb/core/hcd-pci.c                   |   2 +
 drivers/usb/host/Kconfig                     |   4 +-
 drivers/usb/host/pci-quirks.c                | 128 ++++++++++---------
 drivers/usb/host/pci-quirks.h                |  31 +++--
 drivers/usb/host/uhci-hcd.c                  |   2 +-
 drivers/usb/host/uhci-hcd.h                  |  33 +++--
 drivers/video/fbdev/Kconfig                  |  25 ++--
 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 +
 net/ax25/Kconfig                             |   2 +-
 sound/drivers/Kconfig                        |   5 +
 sound/isa/Kconfig                            |  44 +++----
 sound/pci/Kconfig                            |  64 +++++++---
 101 files changed, 489 insertions(+), 246 deletions(-)

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
-- 
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] 392+ messages in thread

* [RFC v2 00/39] Kconfig: Introduce HAS_IOPORT config option
@ 2022-04-29 13:49 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Bjorn Helgaas, Mauro Carvalho Chehab, Alan Stern,
	Rafael J. Wysocki, Geert Uytterhoeven, Paul Walmsley,
	Palmer Dabbelt, Albert Ou, open list:RISC-V ARCHITECTURE

Hello Kernel Hackers,

Some platforms such as s390 do not support PCI I/O spaces. On such platforms
I/O space accessors like inb()/outb() are 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 cause a NULL pointer access. In a previous patch
we tried handling this with a run-time warning on access. This approach however
was rejected by Linus[0] 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.

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.

This series builts heavily on an original patch for demonstating the concept by
Arnd Bergmann[1] and is a stripped down version of a previous RFC[2]. The most
important change being that we dropped the LEGACY_PCI config option in favor of
using HAS_IOPORT regardless of whether the device is a legacy PCI device.
As this is a significant change to the overall series I did not carry over
previous R-bs.

This version is based on v5.18-rc4 and is also available on my kernel.org tree
in the has_ioport branch with the PGP signed tag has_ioport_rfc_v2:

https://git.kernel.org/pub/scm/linux/kernel/git/niks/linux.git

Thanks,
Niklas Schnelle

Changes from RFC v1:
- Completely dropped the LEGACY_PCI option and replaced its dependencies with
  HAS_IOPORT as appropriate
- In the usb subsystem patch I incorporated the feedback from v1 by Alan Stern:
  - Used a local macro to nop in*()/out*() in the helpers
  - Removed an unnecessary further restriction on CONFIG_USB_UHCI_HCD
- Added a few more subsystems including wireless, ptp, and, mISDN that I had
  previously missed due to a blanket !S390.
- Removed blanket !S390 dependencies where they are added due to the I/O port
  problem
- In the sound system SND_OPL3_LIB needed to use "depends on" instead of
  "select" because of its added HAS_IOPORT dependency
- In the drm subsystem the bochs driver gets #ifdefs instead of a blanket
  dependency because its MMIO capable device variant should work without
  HAS_IOPORT.

[0] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
[1] https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
[2] https://yhbt.net/lore/all/20211227164317.4146918-1-schnelle@linux.ibm.com/

Niklas Schnelle (39):
  Kconfig: introduce HAS_IOPORT option and select it as necessary
  ACPI: add dependency on HAS_IOPORT
  ata: add HAS_IOPORT dependencies
  char: impi, tpm: depend on HAS_IOPORT
  comedi: add HAS_IOPORT dependencies
  counter: add HAS_IOPORT dependencies
  /dev/port: don't compile file operations without CONFIG_DEVPORT
  drm: handle HAS_IOPORT dependencies
  firmware: dmi-sysfs: handle HAS_IOPORT=n
  gpio: add HAS_IOPORT dependencies
  hwmon: add HAS_IOPORT dependencies
  i2c: add HAS_IOPORT dependencies
  iio: adc: Kconfig: add HAS_IOPORT dependencies
  Input: add HAS_IOPORT dependencies
  Input: gameport: add ISA and HAS_IOPORT dependencies
  leds: add HAS_IOPORT dependencies
  media: add HAS_IOPORT dependencies
  misc: add HAS_IOPORT dependencies
  mISDN: add HAS_IOPORT dependencies
  mpt fusion: add HAS_IOPORT dependencies
  net: add HAS_IOPORT dependencies
  parport: PC style parport depends on HAS_IOPORT
  PCI: make quirk using inw() depend on HAS_IOPORT
  PCI/sysfs: make I/O resource depend on HAS_IOPORT
  pcmcia: add HAS_IOPORT dependencies
  platform: add HAS_IOPORT dependencies
  pnp: add HAS_IOPORT dependencies
  power: add HAS_IOPORT dependencies
  rtc: add HAS_IOPORT dependencies
  scsi: add HAS_IOPORT dependencies
  sound: add HAS_IOPORT dependencies
  speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  staging: add HAS_IOPORT dependencies
  tty: serial: add HAS_IOPORT dependencies
  usb: handle HAS_IOPORT dependencies
  video: handle HAS_IOPORT dependencies
  watchdog: add HAS_IOPORT dependencies
  wireless: add HAS_IOPORT dependencies
  asm-generic/io.h: drop inb() etc for HAS_IOPORT=n

 arch/alpha/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                          |   1 +
 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                       |  33 ++++-
 drivers/counter/Kconfig                      |   1 +
 drivers/firmware/dmi-sysfs.c                 |   4 +
 drivers/gpio/Kconfig                         |   2 +-
 drivers/gpu/drm/qxl/Kconfig                  |   1 +
 drivers/gpu/drm/tiny/bochs.c                 |  19 +++
 drivers/gpu/drm/tiny/cirrus.c                |   2 +
 drivers/hwmon/Kconfig                        |  21 ++-
 drivers/i2c/busses/Kconfig                   |  31 +++--
 drivers/iio/adc/Kconfig                      |   2 +-
 drivers/input/gameport/Kconfig               |   4 +-
 drivers/input/serio/Kconfig                  |   2 +
 drivers/input/touchscreen/Kconfig            |   1 +
 drivers/isdn/Kconfig                         |   1 -
 drivers/isdn/hardware/mISDN/Kconfig          |  12 +-
 drivers/leds/Kconfig                         |   2 +-
 drivers/media/pci/dm1105/Kconfig             |   2 +-
 drivers/media/radio/Kconfig                  |  14 +-
 drivers/media/rc/Kconfig                     |   6 +
 drivers/message/fusion/Kconfig               |   2 +-
 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           |   2 +-
 drivers/net/ethernet/sis/Kconfig             |   4 +-
 drivers/net/ethernet/ti/Kconfig              |   2 +-
 drivers/net/ethernet/via/Kconfig             |   1 +
 drivers/net/fddi/Kconfig                     |   2 +-
 drivers/net/hamradio/Kconfig                 |   6 +-
 drivers/net/wan/Kconfig                      |   2 +-
 drivers/net/wireless/atmel/Kconfig           |   2 +-
 drivers/net/wireless/intersil/hostap/Kconfig |   2 +-
 drivers/parport/Kconfig                      |   4 +-
 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                         |  19 +--
 drivers/scsi/aic7xxx/Kconfig.aic79xx         |   2 +-
 drivers/scsi/aic7xxx/Kconfig.aic7xxx         |   2 +-
 drivers/scsi/aic94xx/Kconfig                 |   2 +-
 drivers/scsi/megaraid/Kconfig.megaraid       |   6 +-
 drivers/scsi/mvsas/Kconfig                   |   2 +-
 drivers/scsi/qla2xxx/Kconfig                 |   2 +-
 drivers/staging/sm750fb/Kconfig              |   2 +-
 drivers/staging/vt6655/Kconfig               |   2 +-
 drivers/tty/Kconfig                          |   2 +-
 drivers/tty/serial/8250/Kconfig              |   2 +-
 drivers/tty/serial/Kconfig                   |   2 +-
 drivers/usb/core/hcd-pci.c                   |   2 +
 drivers/usb/host/Kconfig                     |   4 +-
 drivers/usb/host/pci-quirks.c                | 128 ++++++++++---------
 drivers/usb/host/pci-quirks.h                |  31 +++--
 drivers/usb/host/uhci-hcd.c                  |   2 +-
 drivers/usb/host/uhci-hcd.h                  |  33 +++--
 drivers/video/fbdev/Kconfig                  |  25 ++--
 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 +
 net/ax25/Kconfig                             |   2 +-
 sound/drivers/Kconfig                        |   5 +
 sound/isa/Kconfig                            |  44 +++----
 sound/pci/Kconfig                            |  64 +++++++---
 101 files changed, 489 insertions(+), 246 deletions(-)

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
-- 
2.32.0


^ permalink raw reply	[flat|nested] 392+ messages in thread

* [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-04-29 13:49 ` Niklas Schnelle
                     ` (3 preceding siblings ...)
  (?)
@ 2022-04-29 13:49   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 arch/alpha/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 +
 16 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7d0d26b5b3f5..2b9cf1b0bdb8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
 	select AUDIT_ARCH
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_SMP_IDLE_THREAD
+	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_MOD_ARCH_SPECIFIC
 	select MODULES_USE_ELF_RELA
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e8091e2d8a8..603ce00033a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,6 +69,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 20ea89d9ac2f..234dc89a7654 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -136,6 +136,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 cb93769a9f2a..0fffe5130a80 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,6 +25,7 @@ config IA64
 	select PCI_DOMAINS if PCI
 	select PCI_MSI
 	select PCI_SYSCALL if PCI
+	select HAS_IOPORT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936cce42ae9a..54bf0a40c2f0 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,6 +18,7 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
+	select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 8cf429ad1c84..966a6682f1fc 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 de3b32a507d2..4c55df08d6f1 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 52e550b45692..741c5c64c173 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -46,6 +46,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 174edabb74fa..7133cc35b777 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -182,6 +182,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 00fd9c548f26..27fc8a450478 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,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 5f220e903e5a..6c1694e82b89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,6 +25,7 @@ config SUPERH
 	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GUP_GET_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 9200bc04701c..64736476dde8 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 b0142e01002e..9ef0438d1b7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -155,6 +155,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 087e06b4cdfd..177fed9cf20a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -91,6 +91,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
@@ -493,6 +494,9 @@ config HAS_IOMEM
 	depends on !NO_IOMEM
 	default y
 
+config HAS_IOPORT
+	def_bool ISA
+
 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] 392+ messages in thread

* [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-04-29 13:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 Itanium PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley, open list:SPARC + UltraSPARC sparc/sparc64,
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Russell King,
	Ingo Molnar, Geert Uytterhoeven, linux-pci, Matt Turner,
	Albert Ou, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Arnd Bergmann, Michal Simek,
	Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, linux-kernel, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller

We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 arch/alpha/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 +
 16 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7d0d26b5b3f5..2b9cf1b0bdb8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
 	select AUDIT_ARCH
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_SMP_IDLE_THREAD
+	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_MOD_ARCH_SPECIFIC
 	select MODULES_USE_ELF_RELA
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e8091e2d8a8..603ce00033a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,6 +69,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 20ea89d9ac2f..234dc89a7654 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -136,6 +136,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 cb93769a9f2a..0fffe5130a80 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,6 +25,7 @@ config IA64
 	select PCI_DOMAINS if PCI
 	select PCI_MSI
 	select PCI_SYSCALL if PCI
+	select HAS_IOPORT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936cce42ae9a..54bf0a40c2f0 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,6 +18,7 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
+	select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 8cf429ad1c84..966a6682f1fc 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 de3b32a507d2..4c55df08d6f1 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 52e550b45692..741c5c64c173 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -46,6 +46,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 174edabb74fa..7133cc35b777 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -182,6 +182,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 00fd9c548f26..27fc8a450478 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,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 5f220e903e5a..6c1694e82b89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,6 +25,7 @@ config SUPERH
 	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GUP_GET_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 9200bc04701c..64736476dde8 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 b0142e01002e..9ef0438d1b7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -155,6 +155,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 087e06b4cdfd..177fed9cf20a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -91,6 +91,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
@@ -493,6 +494,9 @@ config HAS_IOMEM
 	depends on !NO_IOMEM
 	default y
 
+config HAS_IOPORT
+	def_bool ISA
+
 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] 392+ messages in thread

* [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-04-29 13:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 arch/alpha/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 +
 16 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7d0d26b5b3f5..2b9cf1b0bdb8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
 	select AUDIT_ARCH
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_SMP_IDLE_THREAD
+	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_MOD_ARCH_SPECIFIC
 	select MODULES_USE_ELF_RELA
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e8091e2d8a8..603ce00033a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,6 +69,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 20ea89d9ac2f..234dc89a7654 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -136,6 +136,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 cb93769a9f2a..0fffe5130a80 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,6 +25,7 @@ config IA64
 	select PCI_DOMAINS if PCI
 	select PCI_MSI
 	select PCI_SYSCALL if PCI
+	select HAS_IOPORT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936cce42ae9a..54bf0a40c2f0 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,6 +18,7 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
+	select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 8cf429ad1c84..966a6682f1fc 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 de3b32a507d2..4c55df08d6f1 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 52e550b45692..741c5c64c173 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -46,6 +46,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 174edabb74fa..7133cc35b777 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -182,6 +182,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 00fd9c548f26..27fc8a450478 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,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 5f220e903e5a..6c1694e82b89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,6 +25,7 @@ config SUPERH
 	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GUP_GET_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 9200bc04701c..64736476dde8 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 b0142e01002e..9ef0438d1b7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -155,6 +155,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 087e06b4cdfd..177fed9cf20a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -91,6 +91,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
@@ -493,6 +494,9 @@ config HAS_IOMEM
 	depends on !NO_IOMEM
 	default y
 
+config HAS_IOPORT
+	def_bool ISA
+
 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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-04-29 13:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 arch/alpha/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 +
 16 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7d0d26b5b3f5..2b9cf1b0bdb8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
 	select AUDIT_ARCH
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_SMP_IDLE_THREAD
+	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_MOD_ARCH_SPECIFIC
 	select MODULES_USE_ELF_RELA
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e8091e2d8a8..603ce00033a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,6 +69,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 20ea89d9ac2f..234dc89a7654 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -136,6 +136,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 cb93769a9f2a..0fffe5130a80 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,6 +25,7 @@ config IA64
 	select PCI_DOMAINS if PCI
 	select PCI_MSI
 	select PCI_SYSCALL if PCI
+	select HAS_IOPORT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936cce42ae9a..54bf0a40c2f0 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,6 +18,7 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
+	select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 8cf429ad1c84..966a6682f1fc 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 de3b32a507d2..4c55df08d6f1 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 52e550b45692..741c5c64c173 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -46,6 +46,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 174edabb74fa..7133cc35b777 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -182,6 +182,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 00fd9c548f26..27fc8a450478 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,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 5f220e903e5a..6c1694e82b89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,6 +25,7 @@ config SUPERH
 	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GUP_GET_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 9200bc04701c..64736476dde8 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 b0142e01002e..9ef0438d1b7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -155,6 +155,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 087e06b4cdfd..177fed9cf20a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -91,6 +91,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
@@ -493,6 +494,9 @@ config HAS_IOMEM
 	depends on !NO_IOMEM
 	default y
 
+config HAS_IOPORT
+	def_bool ISA
+
 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] 392+ messages in thread

* [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-04-29 13:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT,
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 Itanium PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC 32-BIT AND 64-BIT,
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC sparc/sparc64

We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 arch/alpha/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 +
 16 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7d0d26b5b3f5..2b9cf1b0bdb8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
 	select AUDIT_ARCH
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_SMP_IDLE_THREAD
+	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_MOD_ARCH_SPECIFIC
 	select MODULES_USE_ELF_RELA
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e8091e2d8a8..603ce00033a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,6 +69,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 20ea89d9ac2f..234dc89a7654 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -136,6 +136,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 cb93769a9f2a..0fffe5130a80 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,6 +25,7 @@ config IA64
 	select PCI_DOMAINS if PCI
 	select PCI_MSI
 	select PCI_SYSCALL if PCI
+	select HAS_IOPORT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936cce42ae9a..54bf0a40c2f0 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,6 +18,7 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
+	select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 8cf429ad1c84..966a6682f1fc 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 de3b32a507d2..4c55df08d6f1 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 52e550b45692..741c5c64c173 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -46,6 +46,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 174edabb74fa..7133cc35b777 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -182,6 +182,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 00fd9c548f26..27fc8a450478 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,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 5f220e903e5a..6c1694e82b89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,6 +25,7 @@ config SUPERH
 	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GUP_GET_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 9200bc04701c..64736476dde8 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 b0142e01002e..9ef0438d1b7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -155,6 +155,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 087e06b4cdfd..177fed9cf20a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -91,6 +91,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
@@ -493,6 +494,9 @@ config HAS_IOMEM
 	depends on !NO_IOMEM
 	default y
 
+config HAS_IOPORT
+	def_bool ISA
+
 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] 392+ messages in thread

* [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-04-29 13:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller

We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 arch/alpha/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 +
 16 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7d0d26b5b3f5..2b9cf1b0bdb8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,6 +27,7 @@ config ALPHA
 	select AUDIT_ARCH
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_SMP_IDLE_THREAD
+	select HAS_IOPORT
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_MOD_ARCH_SPECIFIC
 	select MODULES_USE_ELF_RELA
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2e8091e2d8a8..603ce00033a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,6 +69,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 20ea89d9ac2f..234dc89a7654 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -136,6 +136,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 cb93769a9f2a..0fffe5130a80 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,6 +25,7 @@ config IA64
 	select PCI_DOMAINS if PCI
 	select PCI_MSI
 	select PCI_SYSCALL if PCI
+	select HAS_IOPORT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936cce42ae9a..54bf0a40c2f0 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,6 +18,7 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
+	select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 8cf429ad1c84..966a6682f1fc 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 de3b32a507d2..4c55df08d6f1 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 52e550b45692..741c5c64c173 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -46,6 +46,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 174edabb74fa..7133cc35b777 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -182,6 +182,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 00fd9c548f26..27fc8a450478 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -67,6 +67,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 5f220e903e5a..6c1694e82b89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,6 +25,7 @@ config SUPERH
 	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GUP_GET_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 9200bc04701c..64736476dde8 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 b0142e01002e..9ef0438d1b7d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -155,6 +155,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 087e06b4cdfd..177fed9cf20a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -91,6 +91,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
@@ -493,6 +494,9 @@ config HAS_IOMEM
 	depends on !NO_IOMEM
 	default y
 
+config HAS_IOPORT
+	def_bool ISA
+
 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] 392+ messages in thread

* [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
  (?)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-05-04 13:23   ` Rafael J. Wysocki
  2022-05-04 17:53   ` Bjorn Helgaas
  -1 siblings, 2 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Rafael J. Wysocki, open list: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 simply depend
on HAS_IOPORT.

Co-developed-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 1e34f846508f..8ad0d168004c 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,6 +5,7 @@
 
 config ARCH_SUPPORTS_ACPI
 	bool
+	depends on HAS_IOPORT
 
 menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 02/37] ata: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (2 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:27   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Damien Le Moal,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/ata/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index bb45a9c00514..a2dea866b086 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -332,6 +332,7 @@ endif # HAS_DMA
 
 config ATA_SFF
 	bool "ATA SFF support (for legacy IDE and PATA)"
+	depends on HAS_IOPORT
 	default y
 	help
 	  This option adds support for ATA controllers with SFF
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 03/37] ACPI: add dependency on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (3 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:28   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Rafael J. Wysocki, open list: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 simply depend
on HAS_IOPORT.

Co-developed-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 1e34f846508f..c90c983db94c 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
 	select CRC32
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 03/39] ata: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (4 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Damien Le Moal,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/ata/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index bb45a9c00514..a2dea866b086 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -332,6 +332,7 @@ endif # HAS_DMA
 
 config ATA_SFF
 	bool "ATA SFF support (for legacy IDE and PATA)"
+	depends on HAS_IOPORT
 	default y
 	help
 	  This option adds support for ATA controllers with SFF
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (5 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:23   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Corey Minyard, Peter Huewe, Jarkko Sakkinen,
	moderated list:IPMI SUBSYSTEM, open list:TPM DEVICE DRIVER

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: 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 55f48375e3fe..463b82935e78 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 dc56b976d816..1efb58dc1b41 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] 392+ messages in thread

* [PATCH 04/37] parport: PC style parport depends on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (6 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:28   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sudip Mukherjee

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.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/parport/Kconfig | 4 ++--
 include/linux/parport.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index 68a4fe4cd60b..31c8ec2df449 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
@@ -42,7 +41,8 @@ if PARPORT
 
 config PARPORT_PC
 	tristate "PC-style hardware"
-	depends on ARCH_MIGHT_HAVE_PC_PARPORT || (PCI && !S390)
+	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] 392+ messages in thread

* [PATCH 05/37] char: impi, tpm: depend on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (7 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:02   ` Ahmad Fatoum
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Corey Minyard, Peter Huewe, Jarkko Sakkinen,
	moderated list:IPMI SUBSYSTEM, open list:TPM DEVICE DRIVER

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: 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 55f48375e3fe..463b82935e78 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 dc56b976d816..1efb58dc1b41 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] 392+ messages in thread

* [RFC v2 05/39] comedi: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (8 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Ian Abbott, H Hartley Sweeten

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/comedi/Kconfig | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 3cb61fa2c5c3..e2f6b34315b2 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
 
@@ -100,6 +103,7 @@ if COMEDI_ISA_DRIVERS
 
 config COMEDI_PCL711
 	tristate "Advantech PCL-711/711b and ADlink ACL-8112 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Advantech PCL-711 and 711b, ADlink ACL-8112
@@ -161,6 +165,7 @@ config COMEDI_PCL730
 
 config COMEDI_PCL812
 	tristate "Advantech PCL-812/813 and ADlink ACL-8112/8113/8113/8216"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -173,6 +178,7 @@ config COMEDI_PCL812
 
 config COMEDI_PCL816
 	tristate "Advantech PCL-814 and PCL-816 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -183,6 +189,7 @@ config COMEDI_PCL816
 
 config COMEDI_PCL818
 	tristate "Advantech PCL-718 and PCL-818 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -255,6 +262,7 @@ config COMEDI_DAC02
 
 config COMEDI_DAS16M1
 	tristate "MeasurementComputing CIO-DAS16/M1DAS-16 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -278,6 +286,7 @@ config COMEDI_DAS08_ISA
 
 config COMEDI_DAS16
 	tristate "DAS-16 compatible ISA and PC/104 card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	select COMEDI_8255
@@ -296,6 +305,7 @@ config COMEDI_DAS16
 
 config COMEDI_DAS800
 	tristate "DAS800 and compatible ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Keithley Metrabyte DAS800 and compatible ISA cards
@@ -308,6 +318,7 @@ config COMEDI_DAS800
 
 config COMEDI_DAS1800
 	tristate "DAS1800 and compatible ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -323,6 +334,7 @@ config COMEDI_DAS1800
 
 config COMEDI_DAS6402
 	tristate "DAS6402 and compatible ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for DAS6402 and compatible ISA cards
@@ -402,6 +414,7 @@ config COMEDI_FL512
 
 config COMEDI_AIO_AIO12_8
 	tristate "I/O Products PC/104 AIO12-8 Analog I/O Board support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -456,6 +469,7 @@ config COMEDI_ADQ12B
 
 config COMEDI_NI_AT_A2150
 	tristate "NI AT-A2150 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -466,6 +480,7 @@ config COMEDI_NI_AT_A2150
 
 config COMEDI_NI_AT_AO
 	tristate "NI AT-AO-6/10 EISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for National Instruments AT-AO-6/10 cards
@@ -561,7 +576,7 @@ endif # COMEDI_ISA_DRIVERS
 
 menuconfig COMEDI_PCI_DRIVERS
 	tristate "Comedi PCI drivers"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  Enable support for comedi PCI drivers.
 
@@ -710,6 +725,7 @@ config COMEDI_ADL_PCI8164
 
 config COMEDI_ADL_PCI9111
 	tristate "ADLink PCI-9111HR support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for ADlink PCI9111 cards
@@ -729,6 +745,7 @@ config COMEDI_ADL_PCI9118
 
 config COMEDI_ADV_PCI1710
 	tristate "Advantech PCI-171x and PCI-1731 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Advantech PCI-1710, PCI-1710HG, PCI-1711,
@@ -773,6 +790,7 @@ config COMEDI_ADV_PCI1760
 
 config COMEDI_ADV_PCI_DIO
 	tristate "Advantech PCI DIO card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -814,6 +832,7 @@ config COMEDI_AMPLC_PC263_PCI
 
 config COMEDI_AMPLC_PCI224
 	tristate "Amplicon PCI224 and PCI234 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Amplicon PCI224 and PCI234 AO boards
@@ -823,6 +842,7 @@ config COMEDI_AMPLC_PCI224
 
 config COMEDI_AMPLC_PCI230
 	tristate "Amplicon PCI230 and PCI260 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -929,6 +949,7 @@ config COMEDI_CB_PCIDAS64
 
 config COMEDI_CB_PCIDAS
 	tristate "MeasurementComputing PCI-DAS support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -953,6 +974,7 @@ config COMEDI_CB_PCIDDA
 
 config COMEDI_CB_PCIMDAS
 	tristate "MeasurementComputing PCIM-DAS1602/16, PCIe-DAS1602/16 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -973,6 +995,7 @@ config COMEDI_CB_PCIMDDA
 
 config COMEDI_ME4000
 	tristate "Meilhaus ME-4000 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Meilhaus PCI data acquisition cards
@@ -1053,6 +1076,7 @@ config COMEDI_NI_PCIDIO
 config COMEDI_NI_PCIMIO
 	tristate "NI PCI-MIO-E series and M series support"
 	depends on HAS_DMA
+	depends on HAS_IOPORT
 	select COMEDI_NI_TIOCMD
 	select COMEDI_8255
 	help
@@ -1074,6 +1098,7 @@ config COMEDI_NI_PCIMIO
 
 config COMEDI_RTD520
 	tristate "Real Time Devices PCI4520/DM7520 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Real Time Devices PCI4520/DM7520
@@ -1114,6 +1139,7 @@ if COMEDI_PCMCIA_DRIVERS
 
 config COMEDI_CB_DAS16_CS
 	tristate "CB DAS16 series PCMCIA support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for the ComputerBoards/MeasurementComputing PCMCIA
@@ -1142,6 +1168,7 @@ config COMEDI_NI_DAQ_700_CS
 
 config COMEDI_NI_DAQ_DIO24_CS
 	tristate "NI DAQ-Card DIO-24 PCMCIA support"
+	depends on HAS_IOPORT
 	select COMEDI_8255
 	help
 	  Enable support for the National Instruments PCMCIA DAQ-Card DIO-24
@@ -1160,6 +1187,7 @@ config COMEDI_NI_LABPC_CS
 
 config COMEDI_NI_MIO_CS
 	tristate "NI DAQCard E series PCMCIA support"
+	depends on HAS_IOPORT
 	select COMEDI_NI_TIO
 	select COMEDI_8255
 	help
@@ -1248,12 +1276,14 @@ endif # COMEDI_USB_DRIVERS
 
 config COMEDI_8254
 	tristate
+	depends on HAS_IOPORT
 
 config COMEDI_8255
 	tristate
 
 config COMEDI_8255_SA
 	tristate "Standalone 8255 support"
+	depends on HAS_IOPORT
 	select COMEDI_8255
 	help
 	  Enable support for 8255 digital I/O as a standalone driver.
@@ -1302,6 +1332,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] 392+ messages in thread

* [RFC v2 06/39] counter: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (9 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, William Breathitt Gray,
	open list:COUNTER SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/counter/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
index 5edd155f1911..09e18a0eee36 100644
--- a/drivers/counter/Kconfig
+++ b/drivers/counter/Kconfig
@@ -15,6 +15,7 @@ if COUNTER
 config 104_QUAD_8
 	tristate "ACCES 104-QUAD-8 driver"
 	depends on (PC104 && X86) || COMPILE_TEST
+	depends on HAS_IOPORT
 	select ISA_BUS_API
 	help
 	  Say yes here to build support for the ACCES 104-QUAD-8 quadrature
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (10 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:28   ` Samuel Thibault
                     ` (2 more replies)
  -1 siblings, 3 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, William Hubbs, Chris Brannon, Kirk Reiser,
	Samuel Thibault, open list:SPEAKUP CONSOLE SPEECH DRIVER

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: 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] 392+ messages in thread

* [RFC v2 07/39] /dev/port: don't compile file operations without CONFIG_DEVPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (11 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

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: 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] 392+ messages in thread

* [PATCH 07/37] Input: gameport: add ISA and HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (12 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:29   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dmitry Torokhov, open list:INPUT (KEYBOARD, MOUSE,
	JOYSTICK , TOUCHSCREEN)...

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/input/gameport/Kconfig | 4 +++-
 include/linux/gameport.h       | 9 +++++++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 5a2c2fb3217d..fe73b26e647a 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.
 
@@ -53,7 +55,7 @@ config GAMEPORT_EMU10K1
 
 config GAMEPORT_FM801
 	tristate "ForteMedia FM801 gameport support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  Say Y here if you have ForteMedia FM801 PCI audio controller
 	  (Abit AU10, Genius Sound Maker, HP Workstation zx2000,
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] 392+ messages in thread

* [PATCH 08/37] comedi: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (13 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:30   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Ian Abbott, H Hartley Sweeten

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/comedi/Kconfig | 36 ++++++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/comedi/Kconfig b/drivers/comedi/Kconfig
index 3cb61fa2c5c3..0159921002b8 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
 
@@ -100,6 +103,7 @@ if COMEDI_ISA_DRIVERS
 
 config COMEDI_PCL711
 	tristate "Advantech PCL-711/711b and ADlink ACL-8112 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Advantech PCL-711 and 711b, ADlink ACL-8112
@@ -161,6 +165,7 @@ config COMEDI_PCL730
 
 config COMEDI_PCL812
 	tristate "Advantech PCL-812/813 and ADlink ACL-8112/8113/8113/8216"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -173,6 +178,7 @@ config COMEDI_PCL812
 
 config COMEDI_PCL816
 	tristate "Advantech PCL-814 and PCL-816 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -183,6 +189,7 @@ config COMEDI_PCL816
 
 config COMEDI_PCL818
 	tristate "Advantech PCL-718 and PCL-818 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -255,6 +262,7 @@ config COMEDI_DAC02
 
 config COMEDI_DAS16M1
 	tristate "MeasurementComputing CIO-DAS16/M1DAS-16 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -278,6 +286,7 @@ config COMEDI_DAS08_ISA
 
 config COMEDI_DAS16
 	tristate "DAS-16 compatible ISA and PC/104 card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	select COMEDI_8255
@@ -296,6 +305,7 @@ config COMEDI_DAS16
 
 config COMEDI_DAS800
 	tristate "DAS800 and compatible ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Keithley Metrabyte DAS800 and compatible ISA cards
@@ -308,6 +318,7 @@ config COMEDI_DAS800
 
 config COMEDI_DAS1800
 	tristate "DAS1800 and compatible ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -323,6 +334,7 @@ config COMEDI_DAS1800
 
 config COMEDI_DAS6402
 	tristate "DAS6402 and compatible ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for DAS6402 and compatible ISA cards
@@ -402,6 +414,7 @@ config COMEDI_FL512
 
 config COMEDI_AIO_AIO12_8
 	tristate "I/O Products PC/104 AIO12-8 Analog I/O Board support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -456,6 +469,7 @@ config COMEDI_ADQ12B
 
 config COMEDI_NI_AT_A2150
 	tristate "NI AT-A2150 ISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_ISADMA if ISA_DMA_API
 	select COMEDI_8254
 	help
@@ -466,6 +480,7 @@ config COMEDI_NI_AT_A2150
 
 config COMEDI_NI_AT_AO
 	tristate "NI AT-AO-6/10 EISA card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for National Instruments AT-AO-6/10 cards
@@ -561,7 +576,7 @@ endif # COMEDI_ISA_DRIVERS
 
 menuconfig COMEDI_PCI_DRIVERS
 	tristate "Comedi PCI drivers"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  Enable support for comedi PCI drivers.
 
@@ -710,6 +725,7 @@ config COMEDI_ADL_PCI8164
 
 config COMEDI_ADL_PCI9111
 	tristate "ADLink PCI-9111HR support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for ADlink PCI9111 cards
@@ -729,6 +745,7 @@ config COMEDI_ADL_PCI9118
 
 config COMEDI_ADV_PCI1710
 	tristate "Advantech PCI-171x and PCI-1731 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Advantech PCI-1710, PCI-1710HG, PCI-1711,
@@ -773,6 +790,7 @@ config COMEDI_ADV_PCI1760
 
 config COMEDI_ADV_PCI_DIO
 	tristate "Advantech PCI DIO card support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -814,6 +832,7 @@ config COMEDI_AMPLC_PC263_PCI
 
 config COMEDI_AMPLC_PCI224
 	tristate "Amplicon PCI224 and PCI234 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Amplicon PCI224 and PCI234 AO boards
@@ -823,6 +842,7 @@ config COMEDI_AMPLC_PCI224
 
 config COMEDI_AMPLC_PCI230
 	tristate "Amplicon PCI230 and PCI260 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -929,6 +949,7 @@ config COMEDI_CB_PCIDAS64
 
 config COMEDI_CB_PCIDAS
 	tristate "MeasurementComputing PCI-DAS support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -953,6 +974,7 @@ config COMEDI_CB_PCIDDA
 
 config COMEDI_CB_PCIMDAS
 	tristate "MeasurementComputing PCIM-DAS1602/16, PCIe-DAS1602/16 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	select COMEDI_8255
 	help
@@ -973,6 +995,7 @@ config COMEDI_CB_PCIMDDA
 
 config COMEDI_ME4000
 	tristate "Meilhaus ME-4000 support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Meilhaus PCI data acquisition cards
@@ -1053,6 +1076,7 @@ config COMEDI_NI_PCIDIO
 config COMEDI_NI_PCIMIO
 	tristate "NI PCI-MIO-E series and M series support"
 	depends on HAS_DMA
+	depends on HAS_IOPORT
 	select COMEDI_NI_TIOCMD
 	select COMEDI_8255
 	help
@@ -1074,6 +1098,8 @@ config COMEDI_NI_PCIMIO
 
 config COMEDI_RTD520
 	tristate "Real Time Devices PCI4520/DM7520 support"
+	depends on HAS_IOPORT
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for Real Time Devices PCI4520/DM7520
@@ -1114,6 +1140,7 @@ if COMEDI_PCMCIA_DRIVERS
 
 config COMEDI_CB_DAS16_CS
 	tristate "CB DAS16 series PCMCIA support"
+	depends on HAS_IOPORT
 	select COMEDI_8254
 	help
 	  Enable support for the ComputerBoards/MeasurementComputing PCMCIA
@@ -1142,6 +1169,7 @@ config COMEDI_NI_DAQ_700_CS
 
 config COMEDI_NI_DAQ_DIO24_CS
 	tristate "NI DAQ-Card DIO-24 PCMCIA support"
+	depends on HAS_IOPORT
 	select COMEDI_8255
 	help
 	  Enable support for the National Instruments PCMCIA DAQ-Card DIO-24
@@ -1160,6 +1188,7 @@ config COMEDI_NI_LABPC_CS
 
 config COMEDI_NI_MIO_CS
 	tristate "NI DAQCard E series PCMCIA support"
+	depends on HAS_IOPORT
 	select COMEDI_NI_TIO
 	select COMEDI_8255
 	help
@@ -1248,12 +1277,14 @@ endif # COMEDI_USB_DRIVERS
 
 config COMEDI_8254
 	tristate
+	depends on HAS_IOPORT
 
 config COMEDI_8255
 	tristate
 
 config COMEDI_8255_SA
 	tristate "Standalone 8255 support"
+	depends on HAS_IOPORT
 	select COMEDI_8255
 	help
 	  Enable support for 8255 digital I/O as a standalone driver.
@@ -1285,8 +1316,8 @@ config COMEDI_KCOMEDILIB
 	  called kcomedilib.
 
 config COMEDI_AMPLC_DIO200
-	select COMEDI_8254
 	tristate
+	select COMEDI_8254
 
 config COMEDI_AMPLC_PC236
 	tristate
@@ -1302,6 +1333,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] 392+ messages in thread

* [RFC v2 08/39] drm: handle HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dave Airlie, Gerd Hoffmann, David Airlie,
	Daniel Vetter, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
	open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list:DRM DRIVERS

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. In the bochs driver there is optional MMIO
support detected at runtime, warn if this isn't taken when
HAS_IOPORT is not defined.

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/gpu/drm/qxl/Kconfig   |  1 +
 drivers/gpu/drm/tiny/bochs.c  | 19 +++++++++++++++++++
 drivers/gpu/drm/tiny/cirrus.c |  2 ++
 3 files changed, 22 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/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index ed971c8bb446..9acc726d99ec 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 
+#include <asm/bug.h>
 #include <linux/pci.h>
 
 #include <drm/drm_aperture.h>
@@ -102,7 +103,11 @@ static void bochs_vga_writeb(struct bochs_device *bochs, u16 ioport, u8 val)
 
 		writeb(val, bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		outb(val, ioport);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+#endif
 	}
 }
 
@@ -116,7 +121,12 @@ static u8 bochs_vga_readb(struct bochs_device *bochs, u16 ioport)
 
 		return readb(bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		return inb(ioport);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+		return 0xff;
+#endif
 	}
 }
 
@@ -129,8 +139,13 @@ static u16 bochs_dispi_read(struct bochs_device *bochs, u16 reg)
 
 		ret = readw(bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		outw(reg, VBE_DISPI_IOPORT_INDEX);
 		ret = inw(VBE_DISPI_IOPORT_DATA);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+		ret = 0xffff;
+#endif
 	}
 	return ret;
 }
@@ -142,8 +157,12 @@ static void bochs_dispi_write(struct bochs_device *bochs, u16 reg, u16 val)
 
 		writew(val, bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		outw(reg, VBE_DISPI_IOPORT_INDEX);
 		outw(val, VBE_DISPI_IOPORT_DATA);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+#endif
 	}
 }
 
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index c8e791840862..0dc4788c5399 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] 392+ messages in thread

* [RFC v2 08/39] drm: handle HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, David Airlie, Greg Kroah-Hartman,
	linux-kernel, open list:DRM DRIVERS,
	open list:DRM DRIVER FOR QXL VIRTUAL GPU, Gerd Hoffmann,
	linux-pci, Dave Airlie, open list:DRM DRIVER FOR QXL VIRTUAL GPU

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. In the bochs driver there is optional MMIO
support detected at runtime, warn if this isn't taken when
HAS_IOPORT is not defined.

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/gpu/drm/qxl/Kconfig   |  1 +
 drivers/gpu/drm/tiny/bochs.c  | 19 +++++++++++++++++++
 drivers/gpu/drm/tiny/cirrus.c |  2 ++
 3 files changed, 22 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/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index ed971c8bb446..9acc726d99ec 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 
+#include <asm/bug.h>
 #include <linux/pci.h>
 
 #include <drm/drm_aperture.h>
@@ -102,7 +103,11 @@ static void bochs_vga_writeb(struct bochs_device *bochs, u16 ioport, u8 val)
 
 		writeb(val, bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		outb(val, ioport);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+#endif
 	}
 }
 
@@ -116,7 +121,12 @@ static u8 bochs_vga_readb(struct bochs_device *bochs, u16 ioport)
 
 		return readb(bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		return inb(ioport);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+		return 0xff;
+#endif
 	}
 }
 
@@ -129,8 +139,13 @@ static u16 bochs_dispi_read(struct bochs_device *bochs, u16 reg)
 
 		ret = readw(bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		outw(reg, VBE_DISPI_IOPORT_INDEX);
 		ret = inw(VBE_DISPI_IOPORT_DATA);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+		ret = 0xffff;
+#endif
 	}
 	return ret;
 }
@@ -142,8 +157,12 @@ static void bochs_dispi_write(struct bochs_device *bochs, u16 reg, u16 val)
 
 		writew(val, bochs->mmio + offset);
 	} else {
+#ifdef HAS_IOPORT
 		outw(reg, VBE_DISPI_IOPORT_INDEX);
 		outw(val, VBE_DISPI_IOPORT_DATA);
+#else
+		WARN_ONCE(1, "Non-MMIO bochs device needs HAS_IOPORT");
+#endif
 	}
 }
 
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index c8e791840862..0dc4788c5399 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] 392+ messages in thread

* [PATCH 09/37] counter: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (15 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:30   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, William Breathitt Gray,
	open list:COUNTER SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/counter/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
index 5edd155f1911..09e18a0eee36 100644
--- a/drivers/counter/Kconfig
+++ b/drivers/counter/Kconfig
@@ -15,6 +15,7 @@ if COUNTER
 config 104_QUAD_8
 	tristate "ACCES 104-QUAD-8 driver"
 	depends on (PC104 && X86) || COMPILE_TEST
+	depends on HAS_IOPORT
 	select ISA_BUS_API
 	help
 	  Say yes here to build support for the ACCES 104-QUAD-8 quadrature
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 09/39] firmware: dmi-sysfs: handle HAS_IOPORT=n
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (16 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

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: 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 3a353776bd34..384988a10d09 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_groups = dmi_sysfs_sel_groups,
 };
 
+#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] 392+ messages in thread

* [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (17 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:32   ` William Breathitt Gray
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 45764ec3b2eb..14e5998ee95c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -697,7 +697,7 @@ config GPIO_VR41XX
 
 config GPIO_VX855
 	tristate "VIA VX855/VX875 GPIO"
-	depends on (X86 || COMPILE_TEST) && PCI
+	depends on (X86 || COMPILE_TEST) && PCI && HAS_IOPORT
 	select MFD_CORE
 	select MFD_VX855
 	help
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 11/39] hwmon: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (18 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-30  0:37   ` Guenter Roeck
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jean Delvare, Guenter Roeck,
	open list:HARDWARE MONITORING

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/hwmon/Kconfig | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 68a8a27ab3b7..67a4aa2e0235 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -563,6 +563,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
@@ -574,6 +575,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
@@ -777,6 +779,7 @@ config SENSORS_CORETEMP
 
 config SENSORS_IT87
 	tristate "ITE IT87xx and compatibles"
+	depends on HAS_IOPORT
 	depends on !PPC
 	select HWMON_VID
 	help
@@ -1404,6 +1407,7 @@ config SENSORS_LM95245
 
 config SENSORS_PC87360
 	tristate "National Semiconductor PC87360 family"
+	depends on HAS_IOPORT
 	depends on !PPC
 	select HWMON_VID
 	help
@@ -1418,6 +1422,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
@@ -1449,6 +1454,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
@@ -1459,6 +1465,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
@@ -1683,7 +1690,7 @@ config SENSORS_S3C_RAW
 
 config SENSORS_SIS5595
 	tristate "Silicon Integrated Systems Corp. SiS5595"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes here you get support for the integrated sensors in
 	  SiS5595 South Bridges.
@@ -1702,6 +1709,7 @@ config SENSORS_SY7636A
 
 config SENSORS_DME1737
 	tristate "SMSC DME1737, SCH311x and compatibles"
+	depends on HAS_IOPORT
 	depends on I2C && !PPC
 	select HWMON_VID
 	help
@@ -1745,6 +1753,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
@@ -1779,6 +1788,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
@@ -1792,6 +1802,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
@@ -1805,6 +1816,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
@@ -2047,7 +2059,7 @@ config SENSORS_VIA_CPUTEMP
 
 config SENSORS_VIA686A
 	tristate "VIA686A"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes here you get support for the integrated sensors in
 	  Via 686A/B South Bridges.
@@ -2057,6 +2069,7 @@ config SENSORS_VIA686A
 
 config SENSORS_VT1211
 	tristate "VIA VT1211"
+	depends on HAS_IOPORT
 	depends on !PPC
 	select HWMON_VID
 	help
@@ -2068,7 +2081,7 @@ config SENSORS_VT1211
 
 config SENSORS_VT8231
 	tristate "VIA VT8231"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select HWMON_VID
 	help
 	  If you say yes here then you get support for the integrated sensors
@@ -2176,6 +2189,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
@@ -2188,6 +2202,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] 392+ messages in thread

* [PATCH 11/37] sound: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, moderated list:SOUND,
	Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-pci

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 sound/drivers/Kconfig |  5 +++++
 sound/pci/Kconfig     | 45 ++++++++++++++++++++++++++++++++-----------
 2 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4d250e619786 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -1,10 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config SND_MPU401_UART
 	tristate
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 
 config SND_OPL3_LIB
 	tristate
+	depends on HAS_IOPPORT
 	select SND_TIMER
 	select SND_HWDEP
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
@@ -128,6 +130,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 +155,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 +171,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
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index a55836225401..51c1f38530f6 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -26,7 +26,7 @@ config SND_ALS300
 	select SND_PCM
 	select SND_AC97_CODEC
 	select SND_OPL3_LIB
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
 
@@ -51,7 +51,7 @@ config SND_ALI5451
 	tristate "ALi M5451 PCI Audio Controller"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the integrated AC97 sound
 	  device on motherboards using the ALi M5451 Audio Controller
@@ -96,6 +96,7 @@ config SND_ATIIXP_MODEM
 
 config SND_AU8810
 	tristate "Aureal Advantage"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -110,6 +111,7 @@ config SND_AU8810
 
 config SND_AU8820
 	tristate "Aureal Vortex"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -123,6 +125,7 @@ config SND_AU8820
 
 config SND_AU8830
 	tristate "Aureal Vortex 2"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -157,7 +160,7 @@ config SND_AZT3328
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_TIMER
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for Aztech AZF3328 (PCI168)
 	  soundcards.
@@ -193,6 +196,7 @@ config SND_BT87X_OVERCLOCK
 
 config SND_CA0106
 	tristate "SB Audigy LS / Live 24bit"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
 	select SND_VMASTER
@@ -205,6 +209,7 @@ config SND_CA0106
 
 config SND_CMIPCI
 	tristate "C-Media 8338, 8738, 8768, 8770"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
@@ -221,6 +226,7 @@ config SND_OXYGEN_LIB
 
 config SND_OXYGEN
 	tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -246,6 +252,7 @@ config SND_OXYGEN
 
 config SND_CS4281
 	tristate "Cirrus Logic (Sound Fusion) CS4281"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
@@ -257,6 +264,7 @@ config SND_CS4281
 
 config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select FW_LOADER
@@ -290,6 +298,7 @@ config SND_CS5530
 config SND_CS5535AUDIO
 	tristate "CS5535/CS5536 Audio"
 	depends on X86_32 || MIPS || COMPILE_TEST
+	depends on HAS_IOPORT
 	select SND_PCM
 	select SND_AC97_CODEC
 	help
@@ -307,6 +316,7 @@ config SND_CS5535AUDIO
 
 config SND_CTXFI
 	tristate "Creative Sound Blaster X-Fi"
+	depends on HAS_IOPORT
 	select SND_PCM
 	help
 	  If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -462,13 +472,14 @@ config SND_INDIGODJX
 
 config SND_EMU10K1
 	tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
+	depends on HAS_IOPORT
 	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
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y to include support for Sound Blaster PCI 512, Live!,
 	  Audigy and E-mu APS (partially supported) soundcards.
@@ -491,7 +502,7 @@ config SND_EMU10K1X
 	tristate "Emu10k1X (Dell OEM Version)"
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the Dell OEM version of the
 	  Sound Blaster Live!.
@@ -501,6 +512,7 @@ config SND_EMU10K1X
 
 config SND_ENS1370
 	tristate "(Creative) Ensoniq AudioPCI 1370"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -511,6 +523,7 @@ config SND_ENS1370
 
 config SND_ENS1371
 	tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	help
@@ -525,7 +538,7 @@ config SND_ES1938
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Solo-1
 	  (ES1938, ES1946, ES1969) chips.
@@ -537,7 +550,7 @@ config SND_ES1968
 	tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro
 	  1/2/2E chips.
@@ -569,6 +582,7 @@ config SND_ES1968_RADIO
 
 config SND_FM801
 	tristate "ForteMedia FM801"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
@@ -624,7 +638,7 @@ config SND_ICE1712
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	select BITREVERSE
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the
 	  ICE1712 (Envy24) chip.
@@ -640,6 +654,7 @@ config SND_ICE1712
 
 config SND_ICE1724
 	tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_VMASTER
@@ -712,7 +727,7 @@ config SND_LX6464ES
 config SND_MAESTRO3
 	tristate "ESS Allegro/Maestro3"
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro 3
 	  (Allegro) chips.
@@ -753,6 +768,7 @@ config SND_NM256
 
 config SND_PCXHR
 	tristate "Digigram PCXHR"
+	depends on HAS_IOPORT
 	select FW_LOADER
 	select SND_PCM
 	select SND_HWDEP
@@ -764,6 +780,7 @@ config SND_PCXHR
 
 config SND_RIPTIDE
 	tristate "Conexant Riptide"
+	depends on HAS_IOPORT
 	select FW_LOADER
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
@@ -808,6 +825,7 @@ config SND_RME9652
 config SND_SE6X
 	tristate "Studio Evolution SE6X"
 	depends on SND_OXYGEN=n && SND_VIRTUOSO=n  # PCI ID conflict
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -830,7 +848,7 @@ config SND_SONICVIBES
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the S3
 	  SonicVibes chip.
@@ -842,7 +860,7 @@ config SND_TRIDENT
 	tristate "Trident 4D-Wave DX/NX; SiS 7018"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on Trident
 	  4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +870,7 @@ config SND_TRIDENT
 
 config SND_VIA82XX
 	tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -863,6 +882,7 @@ config SND_VIA82XX
 
 config SND_VIA82XX_MODEM
 	tristate "VIA 82C686A/B, 8233 based Modems"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	help
 	  Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +893,7 @@ config SND_VIA82XX_MODEM
 
 config SND_VIRTUOSO
 	tristate "Asus Virtuoso 66/100/200 (Xonar)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -889,6 +910,7 @@ config SND_VIRTUOSO
 
 config SND_VX222
 	tristate "Digigram VX222"
+	depends on HAS_IOPORT
 	select SND_VX_LIB
 	help
 	  Say Y here to include support for Digigram VX222 soundcards.
@@ -898,6 +920,7 @@ config SND_VX222
 
 config SND_YMFPCI
 	tristate "Yamaha YMF724/740/744/754"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 11/37] sound: add HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jaroslav Kysela, Takashi Iwai,
	moderated list:SOUND

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 sound/drivers/Kconfig |  5 +++++
 sound/pci/Kconfig     | 45 ++++++++++++++++++++++++++++++++-----------
 2 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4d250e619786 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -1,10 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config SND_MPU401_UART
 	tristate
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 
 config SND_OPL3_LIB
 	tristate
+	depends on HAS_IOPPORT
 	select SND_TIMER
 	select SND_HWDEP
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
@@ -128,6 +130,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 +155,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 +171,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
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index a55836225401..51c1f38530f6 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -26,7 +26,7 @@ config SND_ALS300
 	select SND_PCM
 	select SND_AC97_CODEC
 	select SND_OPL3_LIB
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
 
@@ -51,7 +51,7 @@ config SND_ALI5451
 	tristate "ALi M5451 PCI Audio Controller"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the integrated AC97 sound
 	  device on motherboards using the ALi M5451 Audio Controller
@@ -96,6 +96,7 @@ config SND_ATIIXP_MODEM
 
 config SND_AU8810
 	tristate "Aureal Advantage"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -110,6 +111,7 @@ config SND_AU8810
 
 config SND_AU8820
 	tristate "Aureal Vortex"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -123,6 +125,7 @@ config SND_AU8820
 
 config SND_AU8830
 	tristate "Aureal Vortex 2"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -157,7 +160,7 @@ config SND_AZT3328
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_TIMER
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for Aztech AZF3328 (PCI168)
 	  soundcards.
@@ -193,6 +196,7 @@ config SND_BT87X_OVERCLOCK
 
 config SND_CA0106
 	tristate "SB Audigy LS / Live 24bit"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
 	select SND_VMASTER
@@ -205,6 +209,7 @@ config SND_CA0106
 
 config SND_CMIPCI
 	tristate "C-Media 8338, 8738, 8768, 8770"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
@@ -221,6 +226,7 @@ config SND_OXYGEN_LIB
 
 config SND_OXYGEN
 	tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -246,6 +252,7 @@ config SND_OXYGEN
 
 config SND_CS4281
 	tristate "Cirrus Logic (Sound Fusion) CS4281"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
@@ -257,6 +264,7 @@ config SND_CS4281
 
 config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select FW_LOADER
@@ -290,6 +298,7 @@ config SND_CS5530
 config SND_CS5535AUDIO
 	tristate "CS5535/CS5536 Audio"
 	depends on X86_32 || MIPS || COMPILE_TEST
+	depends on HAS_IOPORT
 	select SND_PCM
 	select SND_AC97_CODEC
 	help
@@ -307,6 +316,7 @@ config SND_CS5535AUDIO
 
 config SND_CTXFI
 	tristate "Creative Sound Blaster X-Fi"
+	depends on HAS_IOPORT
 	select SND_PCM
 	help
 	  If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -462,13 +472,14 @@ config SND_INDIGODJX
 
 config SND_EMU10K1
 	tristate "Emu10k1 (SB Live!, Audigy, E-mu APS)"
+	depends on HAS_IOPORT
 	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
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y to include support for Sound Blaster PCI 512, Live!,
 	  Audigy and E-mu APS (partially supported) soundcards.
@@ -491,7 +502,7 @@ config SND_EMU10K1X
 	tristate "Emu10k1X (Dell OEM Version)"
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the Dell OEM version of the
 	  Sound Blaster Live!.
@@ -501,6 +512,7 @@ config SND_EMU10K1X
 
 config SND_ENS1370
 	tristate "(Creative) Ensoniq AudioPCI 1370"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -511,6 +523,7 @@ config SND_ENS1370
 
 config SND_ENS1371
 	tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	help
@@ -525,7 +538,7 @@ config SND_ES1938
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Solo-1
 	  (ES1938, ES1946, ES1969) chips.
@@ -537,7 +550,7 @@ config SND_ES1968
 	tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro
 	  1/2/2E chips.
@@ -569,6 +582,7 @@ config SND_ES1968_RADIO
 
 config SND_FM801
 	tristate "ForteMedia FM801"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
@@ -624,7 +638,7 @@ config SND_ICE1712
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	select BITREVERSE
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the
 	  ICE1712 (Envy24) chip.
@@ -640,6 +654,7 @@ config SND_ICE1712
 
 config SND_ICE1724
 	tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_VMASTER
@@ -712,7 +727,7 @@ config SND_LX6464ES
 config SND_MAESTRO3
 	tristate "ESS Allegro/Maestro3"
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro 3
 	  (Allegro) chips.
@@ -753,6 +768,7 @@ config SND_NM256
 
 config SND_PCXHR
 	tristate "Digigram PCXHR"
+	depends on HAS_IOPORT
 	select FW_LOADER
 	select SND_PCM
 	select SND_HWDEP
@@ -764,6 +780,7 @@ config SND_PCXHR
 
 config SND_RIPTIDE
 	tristate "Conexant Riptide"
+	depends on HAS_IOPORT
 	select FW_LOADER
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
@@ -808,6 +825,7 @@ config SND_RME9652
 config SND_SE6X
 	tristate "Studio Evolution SE6X"
 	depends on SND_OXYGEN=n && SND_VIRTUOSO=n  # PCI ID conflict
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -830,7 +848,7 @@ config SND_SONICVIBES
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the S3
 	  SonicVibes chip.
@@ -842,7 +860,7 @@ config SND_TRIDENT
 	tristate "Trident 4D-Wave DX/NX; SiS 7018"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on Trident
 	  4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +870,7 @@ config SND_TRIDENT
 
 config SND_VIA82XX
 	tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -863,6 +882,7 @@ config SND_VIA82XX
 
 config SND_VIA82XX_MODEM
 	tristate "VIA 82C686A/B, 8233 based Modems"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	help
 	  Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +893,7 @@ config SND_VIA82XX_MODEM
 
 config SND_VIRTUOSO
 	tristate "Asus Virtuoso 66/100/200 (Xonar)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -889,6 +910,7 @@ config SND_VIRTUOSO
 
 config SND_VX222
 	tristate "Digigram VX222"
+	depends on HAS_IOPORT
 	select SND_VX_LIB
 	help
 	  Say Y here to include support for Digigram VX222 soundcards.
@@ -898,6 +920,7 @@ config SND_VX222
 
 config SND_YMFPCI
 	tristate "Yamaha YMF724/740/744/754"
+	depends on HAS_IOPORT
 	select SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 12/39] i2c: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (20 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-05-14 14:06   ` Wolfram Sang
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, open list:I2C SUBSYSTEM HOST DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/i2c/busses/Kconfig | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a1bae59208e3..d1d97420cf10 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -18,7 +18,7 @@ config I2C_CCGX_UCSI
 
 config I2C_ALI1535
 	tristate "ALI 1535"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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
@@ -30,7 +30,7 @@ config I2C_ALI1535
 
 config I2C_ALI1563
 	tristate "ALI 1563"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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
@@ -42,7 +42,7 @@ config I2C_ALI1563
 
 config I2C_ALI15X3
 	tristate "ALI 15x3"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes to this option, support will be included for the
 	  Acer Labs Inc. (ALI) M1514 and M1543 motherboard I2C interfaces.
@@ -52,7 +52,7 @@ config I2C_ALI15X3
 
 config I2C_AMD756
 	tristate "AMD 756/766/768/8111 and nVidia nForce"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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
@@ -77,7 +77,7 @@ config I2C_AMD756_S4882
 
 config I2C_AMD8111
 	tristate "AMD 8111"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes to this option, support will be included for the
 	  second (SMBus 2.0) AMD 8111 mainboard I2C interface.
@@ -107,7 +107,7 @@ config I2C_HIX5HD2
 
 config I2C_I801
 	tristate "Intel 82801 (ICH/PCH)"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CHECK_SIGNATURE if X86 && DMI
 	select I2C_SMBUS
 	help
@@ -162,7 +162,7 @@ config I2C_I801
 
 config I2C_ISCH
 	tristate "Intel SCH SMBus 1.0"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select LPC_SCH
 	help
 	  Say Y here if you want to use SMBus controller on the Intel SCH
@@ -183,7 +183,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
@@ -229,7 +229,7 @@ config I2C_CHT_WC
 
 config I2C_NFORCE2
 	tristate "Nvidia nForce2, nForce3 and nForce4"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes to this option, support will be included for the Nvidia
 	  nForce2, nForce3 and nForce4 families of mainboard I2C interfaces.
@@ -262,7 +262,7 @@ config I2C_NVIDIA_GPU
 
 config I2C_SIS5595
 	tristate "SiS 5595"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes to this option, support will be included for the
 	  SiS5595 SMBus (a subset of I2C) interface.
@@ -272,7 +272,7 @@ config I2C_SIS5595
 
 config I2C_SIS630
 	tristate "SiS 630/730/964"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes to this option, support will be included for the
 	  SiS630, SiS730 and SiS964 SMBus (a subset of I2C) interface.
@@ -282,7 +282,7 @@ config I2C_SIS630
 
 config I2C_SIS96X
 	tristate "SiS 96x"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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
@@ -300,7 +300,7 @@ config I2C_SIS96X
 
 config I2C_VIA
 	tristate "VIA VT82C586B"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select I2C_ALGOBIT
 	help
 	  If you say yes to this option, support will be included for the VIA
@@ -311,7 +311,7 @@ config I2C_VIA
 
 config I2C_VIAPRO
 	tristate "VIA VT82C596/82C686/82xx and CX700/VX8xx/VX900"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes to this option, support will be included for the VIA
 	  VT82C596 and later SMBus interface.  Specifically, the following
@@ -849,6 +849,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
@@ -1232,6 +1233,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
@@ -1330,6 +1332,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] 392+ messages in thread

* [RFC v2 13/39] iio: adc: Kconfig: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (21 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-05-01 16:51   ` Jonathan Cameron
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jonathan Cameron,
	open list:IIO SUBSYSTEM AND DRIVERS

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: 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 71ab0a06aa82..c99843307e4f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -130,7 +130,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] 392+ messages in thread

* [PATCH 13/37] Input: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (22 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:31   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dmitry Torokhov, open list:INPUT (KEYBOARD, MOUSE,
	JOYSTICK , TOUCHSCREEN)...

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: 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 43c7d6e5bdc0..a938629d8894 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -674,6 +674,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] 392+ messages in thread

* [PATCH 14/37] iio: adc: Kconfig: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (23 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:31   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jonathan Cameron,
	open list:IIO SUBSYSTEM AND DRIVERS

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: 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 71ab0a06aa82..c99843307e4f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -130,7 +130,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] 392+ messages in thread

* [RFC v2 14/39] Input: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (24 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dmitry Torokhov, open list:INPUT (KEYBOARD, MOUSE,
	JOYSTICK , TOUCHSCREEN)...

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: 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 43c7d6e5bdc0..a938629d8894 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -674,6 +674,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] 392+ messages in thread

* [PATCH 15/37] hwmon: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (25 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:31   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jean Delvare, Guenter Roeck,
	open list:HARDWARE MONITORING

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/hwmon/Kconfig | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 68a8a27ab3b7..67a4aa2e0235 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -563,6 +563,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
@@ -574,6 +575,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
@@ -777,6 +779,7 @@ config SENSORS_CORETEMP
 
 config SENSORS_IT87
 	tristate "ITE IT87xx and compatibles"
+	depends on HAS_IOPORT
 	depends on !PPC
 	select HWMON_VID
 	help
@@ -1404,6 +1407,7 @@ config SENSORS_LM95245
 
 config SENSORS_PC87360
 	tristate "National Semiconductor PC87360 family"
+	depends on HAS_IOPORT
 	depends on !PPC
 	select HWMON_VID
 	help
@@ -1418,6 +1422,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
@@ -1449,6 +1454,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
@@ -1459,6 +1465,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
@@ -1683,7 +1690,7 @@ config SENSORS_S3C_RAW
 
 config SENSORS_SIS5595
 	tristate "Silicon Integrated Systems Corp. SiS5595"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes here you get support for the integrated sensors in
 	  SiS5595 South Bridges.
@@ -1702,6 +1709,7 @@ config SENSORS_SY7636A
 
 config SENSORS_DME1737
 	tristate "SMSC DME1737, SCH311x and compatibles"
+	depends on HAS_IOPORT
 	depends on I2C && !PPC
 	select HWMON_VID
 	help
@@ -1745,6 +1753,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
@@ -1779,6 +1788,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
@@ -1792,6 +1802,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
@@ -1805,6 +1816,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
@@ -2047,7 +2059,7 @@ config SENSORS_VIA_CPUTEMP
 
 config SENSORS_VIA686A
 	tristate "VIA686A"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you say yes here you get support for the integrated sensors in
 	  Via 686A/B South Bridges.
@@ -2057,6 +2069,7 @@ config SENSORS_VIA686A
 
 config SENSORS_VT1211
 	tristate "VIA VT1211"
+	depends on HAS_IOPORT
 	depends on !PPC
 	select HWMON_VID
 	help
@@ -2068,7 +2081,7 @@ config SENSORS_VT1211
 
 config SENSORS_VT8231
 	tristate "VIA VT8231"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select HWMON_VID
 	help
 	  If you say yes here then you get support for the integrated sensors
@@ -2176,6 +2189,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
@@ -2188,6 +2202,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] 392+ messages in thread

* [RFC v2 15/39] Input: gameport: add ISA and HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (26 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dmitry Torokhov, open list:INPUT (KEYBOARD, MOUSE,
	JOYSTICK , TOUCHSCREEN)...

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/input/gameport/Kconfig | 4 +++-
 include/linux/gameport.h       | 9 +++++++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/input/gameport/Kconfig b/drivers/input/gameport/Kconfig
index 5a2c2fb3217d..fe73b26e647a 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.
 
@@ -53,7 +55,7 @@ config GAMEPORT_EMU10K1
 
 config GAMEPORT_FM801
 	tristate "ForteMedia FM801 gameport support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  Say Y here if you have ForteMedia FM801 PCI audio controller
 	  (Abit AU10, Genius Sound Maker, HP Workstation zx2000,
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] 392+ messages in thread

* [RFC v2 16/39] leds: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (27 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 18:54   ` Pavel Machek
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Pavel Machek, open list:LED SUBSYSTEM

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: 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 6090e647daee..d05b7b035b13 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -681,7 +681,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] 392+ messages in thread

* [RFC v2 17/39] media: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (28 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 15:36   ` Sean Young
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Mauro Carvalho Chehab, Sean Young,
	open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB)

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/media/pci/dm1105/Kconfig |  2 +-
 drivers/media/radio/Kconfig      | 14 +++++++++++++-
 drivers/media/rc/Kconfig         |  6 ++++++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/dm1105/Kconfig b/drivers/media/pci/dm1105/Kconfig
index e0e3af67c99c..4498c37f4990 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 && PCI && I2C && I2C_ALGOBIT && HAS_IOPORT
 	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 cca03bd2cc42..e15d50d9161f 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -15,7 +15,7 @@ if RADIO_ADAPTERS
 
 config RADIO_MAXIRADIO
 	tristate "Guillemot MAXI Radio FM 2000 radio"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select RADIO_TEA575X
 	help
 	  Choose Y here if you have this radio card.  This card may also be
@@ -232,6 +232,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,6 +241,7 @@ if V4L_RADIO_ISA_DRIVERS
 config RADIO_AZTECH
 	tristate "Aztech/Packard Bell Radio"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  Choose Y here if you have one of these FM radio cards, and then fill
@@ -260,6 +262,7 @@ config RADIO_AZTECH_PORT
 config RADIO_CADET
 	tristate "ADS Cadet AM/FM Tuner"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	help
 	  Choose Y here if you have one of these AM/FM radio cards, and then
 	  fill in the port address below.
@@ -270,6 +273,7 @@ config RADIO_CADET
 config RADIO_GEMTEK
 	tristate "GemTek Radio card (or compatible) support"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  Choose Y here if you have this FM radio card, and then fill in the
@@ -309,6 +313,7 @@ config RADIO_GEMTEK_PROBE
 
 config RADIO_ISA
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	tristate
 
 config RADIO_MIROPCM20
@@ -329,6 +334,7 @@ config RADIO_MIROPCM20
 config RADIO_RTRACK
 	tristate "AIMSlab RadioTrack (aka RadioReveal) support"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  Choose Y here if you have one of these FM radio cards, and then fill
@@ -383,6 +389,7 @@ config RADIO_RTRACK_PORT
 config RADIO_SF16FMI
 	tristate "SF16-FMI/SF16-FMP/SF16-FMD Radio"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	help
 	  Choose Y here if you have one of these FM radio cards.
 
@@ -392,6 +399,7 @@ config RADIO_SF16FMI
 config RADIO_SF16FMR2
 	tristate "SF16-FMR2/SF16-FMD2 Radio"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_TEA575X
 	help
 	  Choose Y here if you have one of these FM radio cards.
@@ -402,6 +410,7 @@ config RADIO_SF16FMR2
 config RADIO_TERRATEC
 	tristate "TerraTec ActiveRadio ISA Standalone"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  Choose Y here if you have this FM radio card.
@@ -416,6 +425,7 @@ config RADIO_TERRATEC
 config RADIO_TRUST
 	tristate "Trust FM radio card"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  This is a driver for the Trust FM radio cards. Say Y if you have
@@ -439,6 +449,7 @@ config RADIO_TRUST_PORT
 config RADIO_TYPHOON
 	tristate "Typhoon Radio (a.k.a. EcoRadio)"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  Choose Y here if you have one of these FM radio cards, and then fill
@@ -473,6 +484,7 @@ config RADIO_TYPHOON_PORT
 config RADIO_ZOLTRIX
 	tristate "Zoltrix Radio"
 	depends on ISA || COMPILE_TEST
+	depends on HAS_IOPORT
 	select RADIO_ISA
 	help
 	  Choose Y here if you have one of these FM radio cards, and then fill
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index f560fc38895f..96528e6532fd 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -148,6 +148,7 @@ if RC_DEVICES
 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.
@@ -161,6 +162,7 @@ config IR_ENE
 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
@@ -249,6 +251,7 @@ config IR_IMON_RAW
 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
@@ -301,6 +304,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
@@ -345,6 +349,7 @@ config IR_RX51
 
 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.
@@ -412,6 +417,7 @@ config IR_TTUSBIR
 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
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 18/39] misc: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (29 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

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: 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] 392+ messages in thread

* [RFC v2 19/39] mISDN: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (30 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Karsten Keil, open list:ISDN/mISDN SUBSYSTEM

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. With that the !S390 dependency on ISDN can be
removed as all drivers without HAS_IOPORT requirement now build.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/isdn/Kconfig                |  1 -
 drivers/isdn/hardware/mISDN/Kconfig | 12 ++++++------
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/isdn/Kconfig b/drivers/isdn/Kconfig
index 2690e2c5a158..6fd1b3f84a29 100644
--- a/drivers/isdn/Kconfig
+++ b/drivers/isdn/Kconfig
@@ -6,7 +6,6 @@
 menuconfig ISDN
 	bool "ISDN support"
 	depends on NET && NETDEVICES
-	depends on !S390 && !UML
 	help
 	  ISDN ("Integrated Services Digital Network", called RNIS in France)
 	  is a fully digital telephone service that can be used for voice and
diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig
index 078eeadf707a..a35bff8a93f5 100644
--- a/drivers/isdn/hardware/mISDN/Kconfig
+++ b/drivers/isdn/hardware/mISDN/Kconfig
@@ -14,7 +14,7 @@ config MISDN_HFCPCI
 
 config MISDN_HFCMULTI
 	tristate "Support for HFC multiport cards (HFC-4S/8S/E1)"
-	depends on PCI || CPM1
+	depends on (PCI || CPM1) && HAS_IOPORT
 	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 PCI && HAS_IOPORT
 	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 PCI && HAS_IOPORT
 	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 PCI && HAS_IOPORT
 	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 PCI && HAS_IOPORT
 	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 PCI && HAS_IOPORT
 	depends on TTY
 	select MISDN_IPAC
 	select MISDN_HDLC
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 19/37] mpt fusion: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (31 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:32   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sathya Prakash, Sreekanth Reddy,
	Suganath Prabu Subramani,
	open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI),
	open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/message/fusion/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index a3d0288fd0e2..88a6e506a942 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 PCI && HAS_IOPORT
 	help
 	Say Y here to get to see options for Fusion Message
 	Passing Technology (MPT) drivers.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 20/39] mpt fusion: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (32 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sathya Prakash, Sreekanth Reddy,
	Suganath Prabu Subramani,
	open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI),
	open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/message/fusion/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index a3d0288fd0e2..88a6e506a942 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 PCI && HAS_IOPORT
 	help
 	Say Y here to get to see options for Fusion Message
 	Passing Technology (MPT) drivers.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 20/37] net: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, David S. Miller, Jakub Kicinski, Paolo Abeni,
	Michael Grzeschik, Wolfgang Grandegger, Marc Kleine-Budde,
	Jesse Brandeburg, Tony Nguyen, open list:NETWORKING DRIVERS,
	open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 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 | 2 +-
 drivers/net/ethernet/sis/Kconfig   | 4 ++--
 drivers/net/ethernet/ti/Kconfig    | 2 +-
 drivers/net/ethernet/via/Kconfig   | 1 +
 drivers/net/fddi/Kconfig           | 2 +-
 drivers/net/hamradio/Kconfig       | 6 +++---
 drivers/net/wan/Kconfig            | 2 +-
 13 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2a4f998c180..0fd284103ee4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -475,7 +475,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/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..d1d07a1d4fbc 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 || PCI || PCMCIA) && HAS_IOPORT
 	tristate "ARCnet support"
 	help
 	  If you have a network card of this type, say Y and check out the
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/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..3e727407d8f5 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 PCI && HAS_IOPORT
 	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..019810eeb68d 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 PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 3facb55b7161..6bdce8eb689d 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -41,7 +41,7 @@ config E100
 
 config E1000
 	tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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..7e498bdbca73 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
 
 config SIS900
 	tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
@@ -35,7 +35,7 @@ config SIS900
 
 config SIS190
 	tristate "SiS190/SiS191 gigabit ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..b5cc714adda4 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
 
 config TLAN
 	tristate "TI ThunderLAN support"
-	depends on (PCI || EISA)
+	depends on (PCI || EISA) && HAS_IOPORT
 	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..00773f5e4d7e 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 PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
 	depends on PCI || ARCH_VT8500 || COMPILE_TEST
+	depends on HAS_IOPORT
 	depends on HAS_DMA
 	select CRC32
 	select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..fa3f1e0fe143 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -29,7 +29,7 @@ config DEFZA
 
 config DEFXX
 	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
-	depends on FDDI && (PCI || EISA || TC)
+	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
 	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/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
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 140780ac1745..e62a51098836 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 && PCI && HAS_IOPORT
 	help
 	  Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
 	  FarSite Communications Ltd.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [Intel-wired-lan] [PATCH 20/37] net: add HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: intel-wired-lan

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 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 | 2 +-
 drivers/net/ethernet/sis/Kconfig   | 4 ++--
 drivers/net/ethernet/ti/Kconfig    | 2 +-
 drivers/net/ethernet/via/Kconfig   | 1 +
 drivers/net/fddi/Kconfig           | 2 +-
 drivers/net/hamradio/Kconfig       | 6 +++---
 drivers/net/wan/Kconfig            | 2 +-
 13 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2a4f998c180..0fd284103ee4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -475,7 +475,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/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..d1d07a1d4fbc 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 || PCI || PCMCIA) && HAS_IOPORT
 	tristate "ARCnet support"
 	help
 	  If you have a network card of this type, say Y and check out the
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/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..3e727407d8f5 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 PCI && HAS_IOPORT
 	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..019810eeb68d 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 PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 3facb55b7161..6bdce8eb689d 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -41,7 +41,7 @@ config E100
 
 config E1000
 	tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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..7e498bdbca73 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
 
 config SIS900
 	tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
@@ -35,7 +35,7 @@ config SIS900
 
 config SIS190
 	tristate "SiS190/SiS191 gigabit ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..b5cc714adda4 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
 
 config TLAN
 	tristate "TI ThunderLAN support"
-	depends on (PCI || EISA)
+	depends on (PCI || EISA) && HAS_IOPORT
 	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..00773f5e4d7e 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 PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
 	depends on PCI || ARCH_VT8500 || COMPILE_TEST
+	depends on HAS_IOPORT
 	depends on HAS_DMA
 	select CRC32
 	select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..fa3f1e0fe143 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -29,7 +29,7 @@ config DEFZA
 
 config DEFXX
 	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
-	depends on FDDI && (PCI || EISA || TC)
+	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
 	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/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
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 140780ac1745..e62a51098836 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 && PCI && HAS_IOPORT
 	help
 	  Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
 	  FarSite Communications Ltd.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 21/39] net: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
  (?)
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

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. It also turns out that with HAS_IOPORT handled
explicitly HAMRADIO does not need the !S390 dependency and successfully
builds the bpqether driver.

Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 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 | 2 +-
 drivers/net/ethernet/sis/Kconfig   | 4 ++--
 drivers/net/ethernet/ti/Kconfig    | 2 +-
 drivers/net/ethernet/via/Kconfig   | 1 +
 drivers/net/fddi/Kconfig           | 2 +-
 drivers/net/hamradio/Kconfig       | 6 +++---
 drivers/net/wan/Kconfig            | 2 +-
 net/ax25/Kconfig                   | 2 +-
 14 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2a4f998c180..5bc1324150c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -475,7 +475,7 @@ source "drivers/net/ipa/Kconfig"
 
 config NET_SB1000
 	tristate "General Instruments Surfboard 1000"
-	depends on PNP
+	depends on ISA && PNP
 	help
 	  This is a driver for the General Instrument (also known as
 	  NextLevel) SURFboard 1000 internal
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..d1d07a1d4fbc 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 || PCI || PCMCIA) && HAS_IOPORT
 	tristate "ARCnet support"
 	help
 	  If you have a network card of this type, say Y and check out the
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/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..3e727407d8f5 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 PCI && HAS_IOPORT
 	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..019810eeb68d 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 PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 3facb55b7161..6bdce8eb689d 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -41,7 +41,7 @@ config E100
 
 config E1000
 	tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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..7e498bdbca73 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
 
 config SIS900
 	tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
@@ -35,7 +35,7 @@ config SIS900
 
 config SIS190
 	tristate "SiS190/SiS191 gigabit ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..b5cc714adda4 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
 
 config TLAN
 	tristate "TI ThunderLAN support"
-	depends on (PCI || EISA)
+	depends on (PCI || EISA) && HAS_IOPORT
 	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..00773f5e4d7e 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 PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
 	depends on PCI || ARCH_VT8500 || COMPILE_TEST
+	depends on HAS_IOPORT
 	depends on HAS_DMA
 	select CRC32
 	select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..fa3f1e0fe143 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -29,7 +29,7 @@ config DEFZA
 
 config DEFXX
 	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
-	depends on FDDI && (PCI || EISA || TC)
+	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
 	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/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
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 140780ac1745..e62a51098836 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 && PCI && HAS_IOPORT
 	help
 	  Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
 	  FarSite Communications Ltd.
diff --git a/net/ax25/Kconfig b/net/ax25/Kconfig
index d3a9843a043d..f769e8f4bd02 100644
--- a/net/ax25/Kconfig
+++ b/net/ax25/Kconfig
@@ -4,7 +4,7 @@
 #
 
 menuconfig HAMRADIO
-	depends on NET && !S390
+	depends on NET
 	bool "Amateur Radio support"
 	help
 	  If you want to connect your Linux box to an amateur radio, answer Y
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [Intel-wired-lan] [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: intel-wired-lan

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. It also turns out that with HAS_IOPORT handled
explicitly HAMRADIO does not need the !S390 dependency and successfully
builds the bpqether driver.

Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 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 | 2 +-
 drivers/net/ethernet/sis/Kconfig   | 4 ++--
 drivers/net/ethernet/ti/Kconfig    | 2 +-
 drivers/net/ethernet/via/Kconfig   | 1 +
 drivers/net/fddi/Kconfig           | 2 +-
 drivers/net/hamradio/Kconfig       | 6 +++---
 drivers/net/wan/Kconfig            | 2 +-
 net/ax25/Kconfig                   | 2 +-
 14 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2a4f998c180..5bc1324150c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -475,7 +475,7 @@ source "drivers/net/ipa/Kconfig"
 
 config NET_SB1000
 	tristate "General Instruments Surfboard 1000"
-	depends on PNP
+	depends on ISA && PNP
 	help
 	  This is a driver for the General Instrument (also known as
 	  NextLevel) SURFboard 1000 internal
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..d1d07a1d4fbc 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 || PCI || PCMCIA) && HAS_IOPORT
 	tristate "ARCnet support"
 	help
 	  If you have a network card of this type, say Y and check out the
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/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..3e727407d8f5 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 PCI && HAS_IOPORT
 	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..019810eeb68d 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 PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 3facb55b7161..6bdce8eb689d 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -41,7 +41,7 @@ config E100
 
 config E1000
 	tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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..7e498bdbca73 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
 
 config SIS900
 	tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
@@ -35,7 +35,7 @@ config SIS900
 
 config SIS190
 	tristate "SiS190/SiS191 gigabit ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..b5cc714adda4 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
 
 config TLAN
 	tristate "TI ThunderLAN support"
-	depends on (PCI || EISA)
+	depends on (PCI || EISA) && HAS_IOPORT
 	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..00773f5e4d7e 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 PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
 	depends on PCI || ARCH_VT8500 || COMPILE_TEST
+	depends on HAS_IOPORT
 	depends on HAS_DMA
 	select CRC32
 	select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..fa3f1e0fe143 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -29,7 +29,7 @@ config DEFZA
 
 config DEFXX
 	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
-	depends on FDDI && (PCI || EISA || TC)
+	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
 	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/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
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 140780ac1745..e62a51098836 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 && PCI && HAS_IOPORT
 	help
 	  Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
 	  FarSite Communications Ltd.
diff --git a/net/ax25/Kconfig b/net/ax25/Kconfig
index d3a9843a043d..f769e8f4bd02 100644
--- a/net/ax25/Kconfig
+++ b/net/ax25/Kconfig
@@ -4,7 +4,7 @@
 #
 
 menuconfig HAMRADIO
-	depends on NET && !S390
+	depends on NET
 	bool "Amateur Radio support"
 	help
 	  If you want to connect your Linux box to an amateur radio, answer Y
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

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. It also turns out that with HAS_IOPORT handled
explicitly HAMRADIO does not need the !S390 dependency and successfully
builds the bpqether driver.

Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 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 | 2 +-
 drivers/net/ethernet/sis/Kconfig   | 4 ++--
 drivers/net/ethernet/ti/Kconfig    | 2 +-
 drivers/net/ethernet/via/Kconfig   | 1 +
 drivers/net/fddi/Kconfig           | 2 +-
 drivers/net/hamradio/Kconfig       | 6 +++---
 drivers/net/wan/Kconfig            | 2 +-
 net/ax25/Kconfig                   | 2 +-
 14 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2a4f998c180..5bc1324150c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -475,7 +475,7 @@ source "drivers/net/ipa/Kconfig"
 
 config NET_SB1000
 	tristate "General Instruments Surfboard 1000"
-	depends on PNP
+	depends on ISA && PNP
 	help
 	  This is a driver for the General Instrument (also known as
 	  NextLevel) SURFboard 1000 internal
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a51b9dab6d3a..d1d07a1d4fbc 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 || PCI || PCMCIA) && HAS_IOPORT
 	tristate "ARCnet support"
 	help
 	  If you have a network card of this type, say Y and check out the
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/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a4130e643342..3e727407d8f5 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 PCI && HAS_IOPORT
 	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..019810eeb68d 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 PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 3facb55b7161..6bdce8eb689d 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -41,7 +41,7 @@ config E100
 
 config E1000
 	tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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..7e498bdbca73 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -19,7 +19,7 @@ if NET_VENDOR_SIS
 
 config SIS900
 	tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
@@ -35,7 +35,7 @@ config SIS900
 
 config SIS190
 	tristate "SiS190/SiS191 gigabit ethernet support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select CRC32
 	select MII
 	help
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index affcf92cd3aa..b5cc714adda4 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -159,7 +159,7 @@ config TI_KEYSTONE_NETCP_ETHSS
 
 config TLAN
 	tristate "TI ThunderLAN support"
-	depends on (PCI || EISA)
+	depends on (PCI || EISA) && HAS_IOPORT
 	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..00773f5e4d7e 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 PCI || (OF_IRQ && GENERIC_PCI_IOMAP)
 	depends on PCI || ARCH_VT8500 || COMPILE_TEST
+	depends on HAS_IOPORT
 	depends on HAS_DMA
 	select CRC32
 	select MII
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
index 846bf41c2717..fa3f1e0fe143 100644
--- a/drivers/net/fddi/Kconfig
+++ b/drivers/net/fddi/Kconfig
@@ -29,7 +29,7 @@ config DEFZA
 
 config DEFXX
 	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
-	depends on FDDI && (PCI || EISA || TC)
+	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
 	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/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
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 140780ac1745..e62a51098836 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 && PCI && HAS_IOPORT
 	help
 	  Support for the FarSync T-Series X.21 (and V.35/V.24) cards by
 	  FarSite Communications Ltd.
diff --git a/net/ax25/Kconfig b/net/ax25/Kconfig
index d3a9843a043d..f769e8f4bd02 100644
--- a/net/ax25/Kconfig
+++ b/net/ax25/Kconfig
@@ -4,7 +4,7 @@
 #
 
 menuconfig HAMRADIO
-	depends on NET && !S390
+	depends on NET
 	bool "Amateur Radio support"
 	help
 	  If you want to connect your Linux box to an amateur radio, answer Y
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 21/37] pcmcia: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (35 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:33   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dominik Brodowski

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: 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 2ce261cfff8e..32b5cd324c58 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 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] 392+ messages in thread

* [RFC v2 22/39] parport: PC style parport depends on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (36 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sudip Mukherjee

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.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/parport/Kconfig | 4 ++--
 include/linux/parport.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index 68a4fe4cd60b..31c8ec2df449 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
@@ -42,7 +41,8 @@ if PARPORT
 
 config PARPORT_PC
 	tristate "PC-style hardware"
-	depends on ARCH_MIGHT_HAVE_PC_PARPORT || (PCI && !S390)
+	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] 392+ messages in thread

* [PATCH 22/37] platform: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (37 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:33   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Benson Leung,
	open list:CHROME HARDWARE PLATFORM SUPPORT

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: 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 75e93efd669f..51f895663e95 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] 392+ messages in thread

* [RFC v2 23/39] PCI: make quirk using inw() depend on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (38 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-06-08 18:30   ` Bjorn Helgaas
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bjorn Helgaas

In the future inw() and friends will not be compiled on architectures
without I/O port support.

Co-developed-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 da829274fc66..27db2810f034 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] 392+ messages in thread

* [PATCH 23/37] pnp: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (39 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:34   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jaroslav Kysela, Rafael J. Wysocki,
	open list:PNP SUPPORT

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: 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] 392+ messages in thread

* [RFC v2 24/39] PCI/sysfs: make I/O resource depend on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (40 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-06-08 18:32   ` Bjorn Helgaas
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bjorn Helgaas

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: 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 c263ffc5884a..eda258fa4981 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1091,6 +1091,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)
@@ -1149,6 +1150,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] 392+ messages in thread

* [PATCH 24/37] power: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (41 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:34   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sebastian Reichel,
	open list:SYSTEM RESET/SHUTDOWN DRIVERS

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: 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] 392+ messages in thread

* [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (42 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-05-03 23:38   ` Bjorn Helgaas
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Dominik Brodowski, Arnd Bergmann

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.

Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Co-developed-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 2ce261cfff8e..32b5cd324c58 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 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] 392+ messages in thread

* [PATCH 25/37] video: handle HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Helge Deller, open list:FRAMEBUFFER LAYER,
	open list:FRAMEBUFFER LAYER

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/video/fbdev/Kconfig | 25 +++++++++++++------------
 include/video/vga.h         |  8 ++++++++
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 93b8d84c34cf..e7d27c0602d5 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 && PCI && HAS_IOPORT && (BROKEN || !SPARC64)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -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
@@ -1242,7 +1243,7 @@ config FB_RADEON_DEBUG
 
 config FB_ATY128
 	tristate "ATI Rage128 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1265,7 +1266,7 @@ config FB_ATY128_BACKLIGHT
 
 config FB_ATY
 	tristate "ATI Mach64 display support" if PCI || ATARI
-	depends on FB && !SPARC32
+	depends on FB && HAS_IOPORT && !SPARC32
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1315,7 +1316,7 @@ config FB_ATY_BACKLIGHT
 
 config FB_S3
 	tristate "S3 Trio/Virge support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1374,7 +1375,7 @@ config FB_SAVAGE_ACCEL
 
 config FB_SIS
 	tristate "SiS/XGI display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1404,7 +1405,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 && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || COMPILE_TEST)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1442,7 +1443,7 @@ endif
 
 config FB_NEOMAGIC
 	tristate "NeoMagic display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_MODE_HELPERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1470,7 +1471,7 @@ config FB_KYRO
 
 config FB_3DFX
 	tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_IMAGEBLIT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1518,7 +1519,7 @@ config FB_VOODOO1
 
 config FB_VT8623
 	tristate "VIA VT8623 support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1532,7 +1533,7 @@ config FB_VT8623
 
 config FB_TRIDENT
 	tristate "Trident/CyberXXX/CyberBlade support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1554,7 +1555,7 @@ config FB_TRIDENT
 
 config FB_ARK
 	tristate "ARK 2000PV support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -2226,7 +2227,7 @@ config FB_SSD1307
 
 config FB_SM712
 	tristate "Silicon Motion SM712 framebuffer support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_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] 392+ messages in thread

* [PATCH 25/37] video: handle HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, open list:FRAMEBUFFER LAYER,
	Greg Kroah-Hartman, Helge Deller, linux-kernel,
	open list:FRAMEBUFFER LAYER, linux-pci

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/video/fbdev/Kconfig | 25 +++++++++++++------------
 include/video/vga.h         |  8 ++++++++
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 93b8d84c34cf..e7d27c0602d5 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 && PCI && HAS_IOPORT && (BROKEN || !SPARC64)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -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
@@ -1242,7 +1243,7 @@ config FB_RADEON_DEBUG
 
 config FB_ATY128
 	tristate "ATI Rage128 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1265,7 +1266,7 @@ config FB_ATY128_BACKLIGHT
 
 config FB_ATY
 	tristate "ATI Mach64 display support" if PCI || ATARI
-	depends on FB && !SPARC32
+	depends on FB && HAS_IOPORT && !SPARC32
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1315,7 +1316,7 @@ config FB_ATY_BACKLIGHT
 
 config FB_S3
 	tristate "S3 Trio/Virge support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1374,7 +1375,7 @@ config FB_SAVAGE_ACCEL
 
 config FB_SIS
 	tristate "SiS/XGI display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1404,7 +1405,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 && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || COMPILE_TEST)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1442,7 +1443,7 @@ endif
 
 config FB_NEOMAGIC
 	tristate "NeoMagic display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_MODE_HELPERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1470,7 +1471,7 @@ config FB_KYRO
 
 config FB_3DFX
 	tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_IMAGEBLIT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1518,7 +1519,7 @@ config FB_VOODOO1
 
 config FB_VT8623
 	tristate "VIA VT8623 support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1532,7 +1533,7 @@ config FB_VT8623
 
 config FB_TRIDENT
 	tristate "Trident/CyberXXX/CyberBlade support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1554,7 +1555,7 @@ config FB_TRIDENT
 
 config FB_ARK
 	tristate "ARK 2000PV support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -2226,7 +2227,7 @@ config FB_SSD1307
 
 config FB_SM712
 	tristate "Silicon Motion SM712 framebuffer support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_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] 392+ messages in thread

* [RFC v2 26/39] platform: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (44 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Benson Leung,
	open list:CHROME HARDWARE PLATFORM SUPPORT

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: 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 75e93efd669f..51f895663e95 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] 392+ messages in thread

* [PATCH 26/37] rtc: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (45 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:46   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Alessandro Zummo, Alexandre Belloni,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM

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: 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 41c65b4d2baf..e1bb11a225b2 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] 392+ messages in thread

* [RFC v2 27/39] pnp: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (46 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jaroslav Kysela, Rafael J. Wysocki,
	open list:PNP SUPPORT

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: 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] 392+ messages in thread

* [PATCH 27/37] scsi: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (47 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:46   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, James E.J. Bottomley, Martin K. Petersen,
	Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
	Nilesh Javali, supporter:QLOGIC QLA2XXX FC-SCSI DRIVER,
	open list:SCSI SUBSYSTEM, open list:MEGARAID SCSI/SAS DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/scsi/Kconfig                   | 19 ++++++++++---------
 drivers/scsi/aic7xxx/Kconfig.aic79xx   |  2 +-
 drivers/scsi/aic7xxx/Kconfig.aic7xxx   |  2 +-
 drivers/scsi/aic94xx/Kconfig           |  2 +-
 drivers/scsi/megaraid/Kconfig.megaraid |  6 +++---
 drivers/scsi/mvsas/Kconfig             |  2 +-
 drivers/scsi/qla2xxx/Kconfig           |  2 +-
 7 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..40430aa8569b 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 || PCI) && HAS_IOPORT
 	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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && SCSI
 	help
 	  This is support for the Initio INI-A100U2W SCSI host adapter.
 	  Please read the SCSI-HOWTO, available from
@@ -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).
@@ -1187,7 +1188,7 @@ config SCSI_SIM710
 
 config SCSI_DC395x
 	tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support"
-	depends on PCI && SCSI
+	depends on PCI && HAS_IOPORT && 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..4bc53eec4c83 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 PCI && HAS_IOPORT && 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..f0425145a5f4 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 (PCI || EISA) && HAS_IOPORT && 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..aaa8dadc6e1c 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 PCI && HAS_IOPORT
 	select SCSI_SAS_LIBSAS
 	select FW_LOADER
 	help
diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
index 2adc2afd9f91..3f2ce1eb081c 100644
--- a/drivers/scsi/megaraid/Kconfig.megaraid
+++ b/drivers/scsi/megaraid/Kconfig.megaraid
@@ -1,13 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config MEGARAID_NEWGEN
 	bool "LSI Logic New Generation RAID Device Drivers"
-	depends on PCI && SCSI
+	depends on PCI && HAS_IOPORT && SCSI
 	help
 	LSI Logic RAID Device Drivers
 
 config MEGARAID_MM
 	tristate "LSI Logic Management Module (New Driver)"
-	depends on PCI && SCSI && MEGARAID_NEWGEN
+	depends on PCI && HAS_IOPORT && SCSI && MEGARAID_NEWGEN
 	help
 	Management Module provides ioctl, sysfs support for LSI Logic
 	RAID controllers.
@@ -67,7 +67,7 @@ config MEGARAID_MAILBOX
 
 config MEGARAID_LEGACY
 	tristate "LSI Logic Legacy MegaRAID Driver"
-	depends on PCI && SCSI
+	depends on PCI && HAS_IOPORT && 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..5ac7fd593b17 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 PCI && HAS_IOPORT
 	select SCSI_SAS_LIBSAS
 	select FW_LOADER
 	help
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 802c373fd6d9..a584708d3056 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 PCI && HAS_IOPORT && SCSI
 	depends on SCSI_FC_ATTRS
 	depends on NVME_FC || !NVME_FC
 	select FW_LOADER
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 28/39] power: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (48 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sebastian Reichel,
	open list:SYSTEM RESET/SHUTDOWN DRIVERS

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: 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] 392+ messages in thread

* [PATCH 28/37] staging: sm750fb: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (49 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:47   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sudip Mukherjee, Teddy Wang,
	open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
	open list:STAGING SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/staging/sm750fb/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 8c0d8a873d5b..73781c5bf03a 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 && PCI && HAS_IOPORT
 	select FB_MODE_HELPERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 29/39] rtc: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (50 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-05-17 22:15   ` Alexandre Belloni
  2022-06-01 12:25   ` Maciej W. Rozycki
  -1 siblings, 2 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Alessandro Zummo, Alexandre Belloni,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM

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: 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 41c65b4d2baf..e1bb11a225b2 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] 392+ messages in thread

* [PATCH 29/37] tty: serial: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (51 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:47   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jiri Slaby, open list:SERIAL DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/tty/Kconfig        | 2 +-
 drivers/tty/serial/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc30ff93e2e4..e31cbd88f5a0 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 && PCI && HAS_IOPORT
 	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 6949e883ffab..32c946adb023 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -909,7 +909,7 @@ config SERIAL_VR41XX_CONSOLE
 
 config SERIAL_JSM
 	tristate "Digi International NEO and Classic PCI Support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select SERIAL_CORE
 	help
 	  This is a driver for Digi International's Neo and Classic series
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 30/39] scsi: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (52 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-05-04 20:42   ` Bjorn Helgaas
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, James E.J. Bottomley, Martin K. Petersen,
	Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
	Nilesh Javali, supporter:QLOGIC QLA2XXX FC-SCSI DRIVER,
	open list:SCSI SUBSYSTEM, open list:MEGARAID SCSI/SAS DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/scsi/Kconfig                   | 19 ++++++++++---------
 drivers/scsi/aic7xxx/Kconfig.aic79xx   |  2 +-
 drivers/scsi/aic7xxx/Kconfig.aic7xxx   |  2 +-
 drivers/scsi/aic94xx/Kconfig           |  2 +-
 drivers/scsi/megaraid/Kconfig.megaraid |  6 +++---
 drivers/scsi/mvsas/Kconfig             |  2 +-
 drivers/scsi/qla2xxx/Kconfig           |  2 +-
 7 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..40430aa8569b 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 || PCI) && HAS_IOPORT
 	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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && 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 PCI && HAS_IOPORT && SCSI
 	help
 	  This is support for the Initio INI-A100U2W SCSI host adapter.
 	  Please read the SCSI-HOWTO, available from
@@ -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).
@@ -1187,7 +1188,7 @@ config SCSI_SIM710
 
 config SCSI_DC395x
 	tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support"
-	depends on PCI && SCSI
+	depends on PCI && HAS_IOPORT && 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..4bc53eec4c83 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 PCI && HAS_IOPORT && 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..f0425145a5f4 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 (PCI || EISA) && HAS_IOPORT && 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..aaa8dadc6e1c 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 PCI && HAS_IOPORT
 	select SCSI_SAS_LIBSAS
 	select FW_LOADER
 	help
diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
index 2adc2afd9f91..3f2ce1eb081c 100644
--- a/drivers/scsi/megaraid/Kconfig.megaraid
+++ b/drivers/scsi/megaraid/Kconfig.megaraid
@@ -1,13 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config MEGARAID_NEWGEN
 	bool "LSI Logic New Generation RAID Device Drivers"
-	depends on PCI && SCSI
+	depends on PCI && HAS_IOPORT && SCSI
 	help
 	LSI Logic RAID Device Drivers
 
 config MEGARAID_MM
 	tristate "LSI Logic Management Module (New Driver)"
-	depends on PCI && SCSI && MEGARAID_NEWGEN
+	depends on PCI && HAS_IOPORT && SCSI && MEGARAID_NEWGEN
 	help
 	Management Module provides ioctl, sysfs support for LSI Logic
 	RAID controllers.
@@ -67,7 +67,7 @@ config MEGARAID_MAILBOX
 
 config MEGARAID_LEGACY
 	tristate "LSI Logic Legacy MegaRAID Driver"
-	depends on PCI && SCSI
+	depends on PCI && HAS_IOPORT && 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..5ac7fd593b17 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 PCI && HAS_IOPORT
 	select SCSI_SAS_LIBSAS
 	select FW_LOADER
 	help
diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
index 802c373fd6d9..a584708d3056 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 PCI && HAS_IOPORT && SCSI
 	depends on SCSI_FC_ATTRS
 	depends on NVME_FC || !NVME_FC
 	select FW_LOADER
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 30/37] watchdog: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (53 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:47   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Wim Van Sebroeck, Guenter Roeck,
	open list:WATCHDOG DEVICE DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/watchdog/Kconfig | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c4e82a8d863f..3242be37b2d7 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -453,6 +453,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
@@ -1235,6 +1236,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
@@ -2090,7 +2092,7 @@ comment "PCI-based Watchdog Cards"
 
 config PCIPCWATCHDOG
 	tristate "Berkshire Products PCI-PC Watchdog"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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,
@@ -2105,7 +2107,7 @@ config PCIPCWATCHDOG
 
 config WDTPCI
 	tristate "PCI-WDT500/501 Watchdog timer"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 31/37] drm: handle HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dave Airlie, Gerd Hoffmann, David Airlie,
	Daniel Vetter, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
	open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list:DRM DRIVERS

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: 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 627d637a1e7e..7102783809c3 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 c8e791840862..0dc4788c5399 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] 392+ messages in thread

* [PATCH 31/37] drm: handle HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, David Airlie, Greg Kroah-Hartman,
	linux-kernel, open list:DRM DRIVERS,
	open list:DRM DRIVER FOR QXL VIRTUAL GPU, Gerd Hoffmann,
	linux-pci, Dave Airlie, open list:DRM DRIVER FOR QXL VIRTUAL GPU

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: 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 627d637a1e7e..7102783809c3 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 c8e791840862..0dc4788c5399 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] 392+ messages in thread

* [RFC v2 31/39] sound: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:50   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, moderated list:SOUND,
	Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-pci

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. For SND_OPL3_LIB this adds its first
dependency so drivers currently selecting it unconditionally need to
depend on it instead.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 sound/drivers/Kconfig |  5 ++++
 sound/isa/Kconfig     | 44 ++++++++++++++---------------
 sound/pci/Kconfig     | 64 +++++++++++++++++++++++++++++--------------
 3 files changed, 70 insertions(+), 43 deletions(-)

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4d250e619786 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -1,10 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config SND_MPU401_UART
 	tristate
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 
 config SND_OPL3_LIB
 	tristate
+	depends on HAS_IOPPORT
 	select SND_TIMER
 	select SND_HWDEP
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
@@ -128,6 +130,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 +155,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 +171,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
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index 570b88e0b201..072265429f39 100644
--- a/sound/isa/Kconfig
+++ b/sound/isa/Kconfig
@@ -31,7 +31,7 @@ if SND_ISA
 
 config SND_ADLIB
 	tristate "AdLib FM card"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	help
 	  Say Y here to include support for AdLib FM cards.
 
@@ -42,7 +42,7 @@ config SND_AD1816A
 	tristate "Analog Devices SoundPort AD1816A"
 	depends on PNP
 	select ISAPNP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_TIMER
@@ -70,7 +70,7 @@ config SND_ALS100
 	tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
 	depends on PNP
 	select ISAPNP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB16_DSP
 	help
@@ -86,7 +86,7 @@ config SND_AZT1605
 	depends on SND
 	select SND_WSS_LIB
 	select SND_MPU401_UART
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	help
 	  Say Y here to include support for Aztech Sound Galaxy cards
 	  based on the AZT1605 chipset.
@@ -99,7 +99,7 @@ config SND_AZT2316
 	depends on SND
 	select SND_WSS_LIB
 	select SND_MPU401_UART
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	help
 	  Say Y here to include support for Aztech Sound Galaxy cards
 	  based on the AZT2316 chipset.
@@ -111,7 +111,7 @@ config SND_AZT2320
 	tristate "Aztech Systems AZT2320"
 	depends on PNP
 	select ISAPNP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -124,7 +124,7 @@ config SND_AZT2320
 config SND_CMI8328
 	tristate "C-Media CMI8328"
 	select SND_WSS_LIB
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	help
 	  Say Y here to include support for soundcards based on the
@@ -137,7 +137,7 @@ config SND_CMI8330
 	tristate "C-Media CMI8330"
 	select SND_WSS_LIB
 	select SND_SB16_DSP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	help
 	  Say Y here to include support for soundcards based on the
@@ -159,7 +159,7 @@ config SND_CS4231
 
 config SND_CS4236
 	tristate "Generic Cirrus Logic CS4232/CS4236+ driver"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -172,7 +172,7 @@ config SND_CS4236
 
 config SND_ES1688
 	tristate "Generic ESS ES688/ES1688 and ES968 PnP driver"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -184,7 +184,7 @@ config SND_ES1688
 
 config SND_ES18XX
 	tristate "Generic ESS ES18xx driver"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -197,7 +197,7 @@ config SND_SC6000
 	tristate "Gallant SC-6000/6600/7000 and Audio Excel DSP 16"
 	depends on HAS_IOPORT_MAP
 	select SND_WSS_LIB
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	help
 	  Say Y here to include support for Gallant SC-6000, SC-6600, SC-7000
@@ -223,7 +223,7 @@ config SND_GUSCLASSIC
 
 config SND_GUSEXTREME
 	tristate "Gravis UltraSound Extreme"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_TIMER
@@ -273,7 +273,7 @@ config SND_INTERWAVE_STB
 
 config SND_JAZZ16
 	tristate "Media Vision Jazz16 card and compatibles"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB8_DSP
 	help
@@ -289,7 +289,7 @@ config SND_JAZZ16
 
 config SND_OPL3SA2
 	tristate "Yamaha OPL3-SA2/SA3"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -301,7 +301,7 @@ config SND_OPL3SA2
 
 config SND_OPTI92X_AD1848
 	tristate "OPTi 82C92x - AD1848"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_OPL4_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
@@ -314,7 +314,7 @@ config SND_OPTI92X_AD1848
 
 config SND_OPTI92X_CS4231
 	tristate "OPTi 82C92x - CS4231"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_OPL4_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
@@ -327,7 +327,7 @@ config SND_OPTI92X_CS4231
 
 config SND_OPTI93X
 	tristate "OPTi 82C93x"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -352,7 +352,7 @@ config SND_MIRO
 
 config SND_SB8
 	tristate "Sound Blaster 1.0/2.0/Pro (8-bit)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_RAWMIDI
 	select SND_SB8_DSP
 	help
@@ -364,7 +364,7 @@ config SND_SB8
 
 config SND_SB16
 	tristate "Sound Blaster 16 (PnP)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB16_DSP
 	help
@@ -376,7 +376,7 @@ config SND_SB16
 
 config SND_SBAWE
 	tristate "Sound Blaster AWE (32,64) (PnP)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB16_DSP
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
@@ -427,7 +427,7 @@ config SND_SSCAPE
 config SND_WAVEFRONT
 	tristate "Turtle Beach Maui,Tropez,Tropez+ (Wavefront)"
 	select FW_LOADER
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index a55836225401..c9fd973a7893 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -25,8 +25,8 @@ config SND_ALS300
 	tristate "Avance Logic ALS300/ALS300+"
 	select SND_PCM
 	select SND_AC97_CODEC
-	select SND_OPL3_LIB
-	depends on ZONE_DMA
+	depends on SND_OPL3_LIB
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
 
@@ -36,7 +36,7 @@ config SND_ALS300
 config SND_ALS4000
 	tristate "Avance Logic ALS4000"
 	depends on ISA_DMA_API
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_SB_COMMON
@@ -51,7 +51,7 @@ config SND_ALI5451
 	tristate "ALi M5451 PCI Audio Controller"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the integrated AC97 sound
 	  device on motherboards using the ALi M5451 Audio Controller
@@ -96,6 +96,7 @@ config SND_ATIIXP_MODEM
 
 config SND_AU8810
 	tristate "Aureal Advantage"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -110,6 +111,7 @@ config SND_AU8810
 
 config SND_AU8820
 	tristate "Aureal Vortex"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -123,6 +125,7 @@ config SND_AU8820
 
 config SND_AU8830
 	tristate "Aureal Vortex 2"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -151,13 +154,13 @@ config SND_AW2
 
 config SND_AZT3328
 	tristate "Aztech AZF3328 / PCI168"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_TIMER
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for Aztech AZF3328 (PCI168)
 	  soundcards.
@@ -193,6 +196,7 @@ config SND_BT87X_OVERCLOCK
 
 config SND_CA0106
 	tristate "SB Audigy LS / Live 24bit"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
 	select SND_VMASTER
@@ -205,7 +209,8 @@ config SND_CA0106
 
 config SND_CMIPCI
 	tristate "C-Media 8338, 8738, 8768, 8770"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -221,6 +226,7 @@ config SND_OXYGEN_LIB
 
 config SND_OXYGEN
 	tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -246,7 +252,8 @@ config SND_OXYGEN
 
 config SND_CS4281
 	tristate "Cirrus Logic (Sound Fusion) CS4281"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	help
@@ -257,6 +264,7 @@ config SND_CS4281
 
 config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select FW_LOADER
@@ -290,6 +298,7 @@ config SND_CS5530
 config SND_CS5535AUDIO
 	tristate "CS5535/CS5536 Audio"
 	depends on X86_32 || MIPS || COMPILE_TEST
+	depends on HAS_IOPORT
 	select SND_PCM
 	select SND_AC97_CODEC
 	help
@@ -307,6 +316,7 @@ config SND_CS5535AUDIO
 
 config SND_CTXFI
 	tristate "Creative Sound Blaster X-Fi"
+	depends on HAS_IOPORT
 	select SND_PCM
 	help
 	  If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -468,7 +478,7 @@ config SND_EMU10K1
 	select SND_AC97_CODEC
 	select SND_TIMER
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y to include support for Sound Blaster PCI 512, Live!,
 	  Audigy and E-mu APS (partially supported) soundcards.
@@ -491,7 +501,7 @@ config SND_EMU10K1X
 	tristate "Emu10k1X (Dell OEM Version)"
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the Dell OEM version of the
 	  Sound Blaster Live!.
@@ -501,6 +511,7 @@ config SND_EMU10K1X
 
 config SND_ENS1370
 	tristate "(Creative) Ensoniq AudioPCI 1370"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -511,6 +522,7 @@ config SND_ENS1370
 
 config SND_ENS1371
 	tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	help
@@ -522,10 +534,10 @@ config SND_ENS1371
 
 config SND_ES1938
 	tristate "ESS ES1938/1946/1969 (Solo-1)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Solo-1
 	  (ES1938, ES1946, ES1969) chips.
@@ -537,7 +549,7 @@ config SND_ES1968
 	tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro
 	  1/2/2E chips.
@@ -569,7 +581,8 @@ config SND_ES1968_RADIO
 
 config SND_FM801
 	tristate "ForteMedia FM801"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -624,7 +637,7 @@ config SND_ICE1712
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	select BITREVERSE
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the
 	  ICE1712 (Envy24) chip.
@@ -640,6 +653,7 @@ config SND_ICE1712
 
 config SND_ICE1724
 	tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_VMASTER
@@ -712,7 +726,7 @@ config SND_LX6464ES
 config SND_MAESTRO3
 	tristate "ESS Allegro/Maestro3"
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro 3
 	  (Allegro) chips.
@@ -753,6 +767,7 @@ config SND_NM256
 
 config SND_PCXHR
 	tristate "Digigram PCXHR"
+	depends on HAS_IOPORT
 	select FW_LOADER
 	select SND_PCM
 	select SND_HWDEP
@@ -764,8 +779,9 @@ config SND_PCXHR
 
 config SND_RIPTIDE
 	tristate "Conexant Riptide"
+	depends on HAS_IOPORT
 	select FW_LOADER
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -808,6 +824,7 @@ config SND_RME9652
 config SND_SE6X
 	tristate "Studio Evolution SE6X"
 	depends on SND_OXYGEN=n && SND_VIRTUOSO=n  # PCI ID conflict
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -827,10 +844,10 @@ config SND_SIS7019
 
 config SND_SONICVIBES
 	tristate "S3 SonicVibes"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the S3
 	  SonicVibes chip.
@@ -842,7 +859,7 @@ config SND_TRIDENT
 	tristate "Trident 4D-Wave DX/NX; SiS 7018"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on Trident
 	  4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +869,7 @@ config SND_TRIDENT
 
 config SND_VIA82XX
 	tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -863,6 +881,7 @@ config SND_VIA82XX
 
 config SND_VIA82XX_MODEM
 	tristate "VIA 82C686A/B, 8233 based Modems"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	help
 	  Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +892,7 @@ config SND_VIA82XX_MODEM
 
 config SND_VIRTUOSO
 	tristate "Asus Virtuoso 66/100/200 (Xonar)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -889,6 +909,7 @@ config SND_VIRTUOSO
 
 config SND_VX222
 	tristate "Digigram VX222"
+	depends on HAS_IOPORT
 	select SND_VX_LIB
 	help
 	  Say Y here to include support for Digigram VX222 soundcards.
@@ -898,7 +919,8 @@ config SND_VX222
 
 config SND_YMFPCI
 	tristate "Yamaha YMF724/740/744/754"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	select SND_TIMER
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 31/39] sound: add HAS_IOPORT dependencies
@ 2022-04-29 13:50   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jaroslav Kysela, Takashi Iwai,
	moderated list:SOUND

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. For SND_OPL3_LIB this adds its first
dependency so drivers currently selecting it unconditionally need to
depend on it instead.

Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 sound/drivers/Kconfig |  5 ++++
 sound/isa/Kconfig     | 44 ++++++++++++++---------------
 sound/pci/Kconfig     | 64 +++++++++++++++++++++++++++++--------------
 3 files changed, 70 insertions(+), 43 deletions(-)

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index ca4cdf666f82..4d250e619786 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -1,10 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config SND_MPU401_UART
 	tristate
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 
 config SND_OPL3_LIB
 	tristate
+	depends on HAS_IOPPORT
 	select SND_TIMER
 	select SND_HWDEP
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
@@ -128,6 +130,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 +155,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 +171,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
diff --git a/sound/isa/Kconfig b/sound/isa/Kconfig
index 570b88e0b201..072265429f39 100644
--- a/sound/isa/Kconfig
+++ b/sound/isa/Kconfig
@@ -31,7 +31,7 @@ if SND_ISA
 
 config SND_ADLIB
 	tristate "AdLib FM card"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	help
 	  Say Y here to include support for AdLib FM cards.
 
@@ -42,7 +42,7 @@ config SND_AD1816A
 	tristate "Analog Devices SoundPort AD1816A"
 	depends on PNP
 	select ISAPNP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_TIMER
@@ -70,7 +70,7 @@ config SND_ALS100
 	tristate "Diamond Tech. DT-019x and Avance Logic ALSxxx"
 	depends on PNP
 	select ISAPNP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB16_DSP
 	help
@@ -86,7 +86,7 @@ config SND_AZT1605
 	depends on SND
 	select SND_WSS_LIB
 	select SND_MPU401_UART
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	help
 	  Say Y here to include support for Aztech Sound Galaxy cards
 	  based on the AZT1605 chipset.
@@ -99,7 +99,7 @@ config SND_AZT2316
 	depends on SND
 	select SND_WSS_LIB
 	select SND_MPU401_UART
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	help
 	  Say Y here to include support for Aztech Sound Galaxy cards
 	  based on the AZT2316 chipset.
@@ -111,7 +111,7 @@ config SND_AZT2320
 	tristate "Aztech Systems AZT2320"
 	depends on PNP
 	select ISAPNP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -124,7 +124,7 @@ config SND_AZT2320
 config SND_CMI8328
 	tristate "C-Media CMI8328"
 	select SND_WSS_LIB
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	help
 	  Say Y here to include support for soundcards based on the
@@ -137,7 +137,7 @@ config SND_CMI8330
 	tristate "C-Media CMI8330"
 	select SND_WSS_LIB
 	select SND_SB16_DSP
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	help
 	  Say Y here to include support for soundcards based on the
@@ -159,7 +159,7 @@ config SND_CS4231
 
 config SND_CS4236
 	tristate "Generic Cirrus Logic CS4232/CS4236+ driver"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -172,7 +172,7 @@ config SND_CS4236
 
 config SND_ES1688
 	tristate "Generic ESS ES688/ES1688 and ES968 PnP driver"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -184,7 +184,7 @@ config SND_ES1688
 
 config SND_ES18XX
 	tristate "Generic ESS ES18xx driver"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -197,7 +197,7 @@ config SND_SC6000
 	tristate "Gallant SC-6000/6600/7000 and Audio Excel DSP 16"
 	depends on HAS_IOPORT_MAP
 	select SND_WSS_LIB
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	help
 	  Say Y here to include support for Gallant SC-6000, SC-6600, SC-7000
@@ -223,7 +223,7 @@ config SND_GUSCLASSIC
 
 config SND_GUSEXTREME
 	tristate "Gravis UltraSound Extreme"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_TIMER
@@ -273,7 +273,7 @@ config SND_INTERWAVE_STB
 
 config SND_JAZZ16
 	tristate "Media Vision Jazz16 card and compatibles"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB8_DSP
 	help
@@ -289,7 +289,7 @@ config SND_JAZZ16
 
 config SND_OPL3SA2
 	tristate "Yamaha OPL3-SA2/SA3"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -301,7 +301,7 @@ config SND_OPL3SA2
 
 config SND_OPTI92X_AD1848
 	tristate "OPTi 82C92x - AD1848"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_OPL4_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
@@ -314,7 +314,7 @@ config SND_OPTI92X_AD1848
 
 config SND_OPTI92X_CS4231
 	tristate "OPTi 82C92x - CS4231"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_OPL4_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
@@ -327,7 +327,7 @@ config SND_OPTI92X_CS4231
 
 config SND_OPTI93X
 	tristate "OPTi 82C93x"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
@@ -352,7 +352,7 @@ config SND_MIRO
 
 config SND_SB8
 	tristate "Sound Blaster 1.0/2.0/Pro (8-bit)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_RAWMIDI
 	select SND_SB8_DSP
 	help
@@ -364,7 +364,7 @@ config SND_SB8
 
 config SND_SB16
 	tristate "Sound Blaster 16 (PnP)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB16_DSP
 	help
@@ -376,7 +376,7 @@ config SND_SB16
 
 config SND_SBAWE
 	tristate "Sound Blaster AWE (32,64) (PnP)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_SB16_DSP
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
@@ -427,7 +427,7 @@ config SND_SSCAPE
 config SND_WAVEFRONT
 	tristate "Turtle Beach Maui,Tropez,Tropez+ (Wavefront)"
 	select FW_LOADER
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_WSS_LIB
 	help
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index a55836225401..c9fd973a7893 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -25,8 +25,8 @@ config SND_ALS300
 	tristate "Avance Logic ALS300/ALS300+"
 	select SND_PCM
 	select SND_AC97_CODEC
-	select SND_OPL3_LIB
-	depends on ZONE_DMA
+	depends on SND_OPL3_LIB
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say 'Y' or 'M' to include support for Avance Logic ALS300/ALS300+
 
@@ -36,7 +36,7 @@ config SND_ALS300
 config SND_ALS4000
 	tristate "Avance Logic ALS4000"
 	depends on ISA_DMA_API
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_SB_COMMON
@@ -51,7 +51,7 @@ config SND_ALI5451
 	tristate "ALi M5451 PCI Audio Controller"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the integrated AC97 sound
 	  device on motherboards using the ALi M5451 Audio Controller
@@ -96,6 +96,7 @@ config SND_ATIIXP_MODEM
 
 config SND_AU8810
 	tristate "Aureal Advantage"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -110,6 +111,7 @@ config SND_AU8810
 
 config SND_AU8820
 	tristate "Aureal Vortex"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -123,6 +125,7 @@ config SND_AU8820
 
 config SND_AU8830
 	tristate "Aureal Vortex 2"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -151,13 +154,13 @@ config SND_AW2
 
 config SND_AZT3328
 	tristate "Aztech AZF3328 / PCI168"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_TIMER
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for Aztech AZF3328 (PCI168)
 	  soundcards.
@@ -193,6 +196,7 @@ config SND_BT87X_OVERCLOCK
 
 config SND_CA0106
 	tristate "SB Audigy LS / Live 24bit"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
 	select SND_VMASTER
@@ -205,7 +209,8 @@ config SND_CA0106
 
 config SND_CMIPCI
 	tristate "C-Media 8338, 8738, 8768, 8770"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_PCM
 	help
@@ -221,6 +226,7 @@ config SND_OXYGEN_LIB
 
 config SND_OXYGEN
 	tristate "C-Media 8786, 8787, 8788 (Oxygen)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -246,7 +252,8 @@ config SND_OXYGEN
 
 config SND_CS4281
 	tristate "Cirrus Logic (Sound Fusion) CS4281"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	help
@@ -257,6 +264,7 @@ config SND_CS4281
 
 config SND_CS46XX
 	tristate "Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select FW_LOADER
@@ -290,6 +298,7 @@ config SND_CS5530
 config SND_CS5535AUDIO
 	tristate "CS5535/CS5536 Audio"
 	depends on X86_32 || MIPS || COMPILE_TEST
+	depends on HAS_IOPORT
 	select SND_PCM
 	select SND_AC97_CODEC
 	help
@@ -307,6 +316,7 @@ config SND_CS5535AUDIO
 
 config SND_CTXFI
 	tristate "Creative Sound Blaster X-Fi"
+	depends on HAS_IOPORT
 	select SND_PCM
 	help
 	  If you want to use soundcards based on Creative Sound Blastr X-Fi
@@ -468,7 +478,7 @@ config SND_EMU10K1
 	select SND_AC97_CODEC
 	select SND_TIMER
 	select SND_SEQ_DEVICE if SND_SEQUENCER != n
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y to include support for Sound Blaster PCI 512, Live!,
 	  Audigy and E-mu APS (partially supported) soundcards.
@@ -491,7 +501,7 @@ config SND_EMU10K1X
 	tristate "Emu10k1X (Dell OEM Version)"
 	select SND_AC97_CODEC
 	select SND_RAWMIDI
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for the Dell OEM version of the
 	  Sound Blaster Live!.
@@ -501,6 +511,7 @@ config SND_EMU10K1X
 
 config SND_ENS1370
 	tristate "(Creative) Ensoniq AudioPCI 1370"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_PCM
 	help
@@ -511,6 +522,7 @@ config SND_ENS1370
 
 config SND_ENS1371
 	tristate "(Creative) Ensoniq AudioPCI 1371/1373"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	help
@@ -522,10 +534,10 @@ config SND_ENS1371
 
 config SND_ES1938
 	tristate "ESS ES1938/1946/1969 (Solo-1)"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Solo-1
 	  (ES1938, ES1946, ES1969) chips.
@@ -537,7 +549,7 @@ config SND_ES1968
 	tristate "ESS ES1968/1978 (Maestro-1/2/2E)"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro
 	  1/2/2E chips.
@@ -569,7 +581,8 @@ config SND_ES1968_RADIO
 
 config SND_FM801
 	tristate "ForteMedia FM801"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -624,7 +637,7 @@ config SND_ICE1712
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	select BITREVERSE
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the
 	  ICE1712 (Envy24) chip.
@@ -640,6 +653,7 @@ config SND_ICE1712
 
 config SND_ICE1724
 	tristate "ICE/VT1724/1720 (Envy24HT/PT)"
+	depends on HAS_IOPORT
 	select SND_RAWMIDI
 	select SND_AC97_CODEC
 	select SND_VMASTER
@@ -712,7 +726,7 @@ config SND_LX6464ES
 config SND_MAESTRO3
 	tristate "ESS Allegro/Maestro3"
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on ESS Maestro 3
 	  (Allegro) chips.
@@ -753,6 +767,7 @@ config SND_NM256
 
 config SND_PCXHR
 	tristate "Digigram PCXHR"
+	depends on HAS_IOPORT
 	select FW_LOADER
 	select SND_PCM
 	select SND_HWDEP
@@ -764,8 +779,9 @@ config SND_PCXHR
 
 config SND_RIPTIDE
 	tristate "Conexant Riptide"
+	depends on HAS_IOPORT
 	select FW_LOADER
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -808,6 +824,7 @@ config SND_RME9652
 config SND_SE6X
 	tristate "Studio Evolution SE6X"
 	depends on SND_OXYGEN=n && SND_VIRTUOSO=n  # PCI ID conflict
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -827,10 +844,10 @@ config SND_SIS7019
 
 config SND_SONICVIBES
 	tristate "S3 SonicVibes"
-	select SND_OPL3_LIB
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on the S3
 	  SonicVibes chip.
@@ -842,7 +859,7 @@ config SND_TRIDENT
 	tristate "Trident 4D-Wave DX/NX; SiS 7018"
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
-	depends on ZONE_DMA
+	depends on ZONE_DMA && HAS_IOPORT
 	help
 	  Say Y here to include support for soundcards based on Trident
 	  4D-Wave DX/NX or SiS 7018 chips.
@@ -852,6 +869,7 @@ config SND_TRIDENT
 
 config SND_VIA82XX
 	tristate "VIA 82C686A/B, 8233/8235 AC97 Controller"
+	depends on HAS_IOPORT
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	help
@@ -863,6 +881,7 @@ config SND_VIA82XX
 
 config SND_VIA82XX_MODEM
 	tristate "VIA 82C686A/B, 8233 based Modems"
+	depends on HAS_IOPORT
 	select SND_AC97_CODEC
 	help
 	  Say Y here to include support for the integrated MC97 modem on
@@ -873,6 +892,7 @@ config SND_VIA82XX_MODEM
 
 config SND_VIRTUOSO
 	tristate "Asus Virtuoso 66/100/200 (Xonar)"
+	depends on HAS_IOPORT
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
@@ -889,6 +909,7 @@ config SND_VIRTUOSO
 
 config SND_VX222
 	tristate "Digigram VX222"
+	depends on HAS_IOPORT
 	select SND_VX_LIB
 	help
 	  Say Y here to include support for Digigram VX222 soundcards.
@@ -898,7 +919,8 @@ config SND_VX222
 
 config SND_YMFPCI
 	tristate "Yamaha YMF724/740/744/754"
-	select SND_OPL3_LIB
+	depends on HAS_IOPORT
+	depends on SND_OPL3_LIB
 	select SND_MPU401_UART
 	select SND_AC97_CODEC
 	select SND_TIMER
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (56 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:48   ` Niklas Schnelle
  2022-05-05 21:41   ` Bjorn Helgaas
  -1 siblings, 2 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bjorn Helgaas

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: 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 c263ffc5884a..eda258fa4981 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1091,6 +1091,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)
@@ -1149,6 +1150,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] 392+ messages in thread

* [RFC v2 32/39] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (57 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Samuel Thibault, Arnd Bergmann, William Hubbs, Chris Brannon,
	Kirk Reiser, open list:SPEAKUP CONSOLE SPEECH DRIVER

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.

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Co-developed-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] 392+ messages in thread

* [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (58 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:48   ` Niklas Schnelle
  2022-05-05 21:44   ` Bjorn Helgaas
  -1 siblings, 2 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bjorn Helgaas

In the future inw() and friends will not be compiled on architectures
without I/O port support.

Co-developed-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 da829274fc66..27db2810f034 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] 392+ messages in thread

* [RFC v2 33/39] staging: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (59 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sudip Mukherjee, Teddy Wang, Forest Bond,
	open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
	open list:STAGING SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/staging/sm750fb/Kconfig | 2 +-
 drivers/staging/vt6655/Kconfig  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 8c0d8a873d5b..73781c5bf03a 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 && PCI && HAS_IOPORT
 	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..077f62ebe80c 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 PCI && HAS_IOPORT && MAC80211 && m
    help
      This is a vendor-written driver for VIA VT6655.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 34/37] firmware: dmi-sysfs: handle HAS_IOPORT=n
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (60 preceding siblings ...)
  (?)
@ 2022-04-29 13:50 ` Niklas Schnelle
  2022-04-29 14:48   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

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: 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 3a353776bd34..384988a10d09 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_groups = dmi_sysfs_sel_groups,
 };
 
+#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] 392+ messages in thread

* [RFC v2 34/39] tty: serial: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (61 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-05-02  9:15   ` Maciej W. Rozycki
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jiri Slaby, open list:SERIAL DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/tty/Kconfig             | 2 +-
 drivers/tty/serial/8250/Kconfig | 2 +-
 drivers/tty/serial/Kconfig      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc30ff93e2e4..e31cbd88f5a0 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 && PCI && HAS_IOPORT
 	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/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index cd93ea6eed65..e216bf745e78 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -6,7 +6,7 @@
 
 config SERIAL_8250
 	tristate "8250/16550 and compatible serial support"
-	depends on !S390
+	depends on HAS_IOPORT
 	select SERIAL_CORE
 	select SERIAL_MCTRL_GPIO if GPIOLIB
 	help
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 6949e883ffab..32c946adb023 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -909,7 +909,7 @@ config SERIAL_VR41XX_CONSOLE
 
 config SERIAL_JSM
 	tristate "Digi International NEO and Classic PCI Support"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	select SERIAL_CORE
 	help
 	  This is a driver for Digi International's Neo and Classic series
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 35/37] /dev/port: don't compile file operations without CONFIG_DEVPORT
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (62 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-04-29 14:49   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

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: 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] 392+ messages in thread

* [RFC v2 35/39] usb: handle HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (63 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-04-30 12:56   ` Alan Stern
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Mathias Nyman, Alan Stern,
	open list:USB SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/usb/core/hcd-pci.c    |   2 +
 drivers/usb/host/Kconfig      |   4 +-
 drivers/usb/host/pci-quirks.c | 128 ++++++++++++++++++----------------
 drivers/usb/host/pci-quirks.h |  31 +++++---
 drivers/usb/host/uhci-hcd.c   |   2 +-
 drivers/usb/host/uhci-hcd.h   |  33 +++++----
 6 files changed, 117 insertions(+), 83 deletions(-)

diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 8176bc81a635..4d119154acd0 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -212,8 +212,10 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id,
 		goto free_irq_vectors;
 	}
 
+#ifdef CONFIG_USB_PCI_AMD
 	hcd->amd_resume_bug = (usb_hcd_amd_remote_wakeup_quirk(dev) &&
 			driver->flags & (HCD_USB11 | HCD_USB3)) ? 1 : 0;
+#endif
 
 	if (driver->flags & HCD_MEMORY) {
 		/* EHCI, OHCI */
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 57ca5f97a3dc..cd1faa3174e3 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..4fd06b48149d 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,53 @@ 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);
+
+#ifdef CONFIG_HAS_IOPORT
 /*
  * Make sure the controller is completely inactive, unable to
  * generate interrupts or do DMA.
@@ -713,6 +717,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)
 {
@@ -725,6 +730,7 @@ static inline int io_type_enabled(struct pci_dev *pdev, unsigned int mask)
 
 static void quirk_usb_handoff_uhci(struct pci_dev *pdev)
 {
+#ifdef HAS_IOPORT
 	unsigned long base = 0;
 	int i;
 
@@ -739,6 +745,7 @@ static void quirk_usb_handoff_uhci(struct pci_dev *pdev)
 
 	if (base)
 		uhci_check_and_reset_hc(pdev, base);
+#endif
 }
 
 static int mmio_resource_enabled(struct pci_dev *pdev, int idx)
@@ -1273,7 +1280,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..5642318fd1d1 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -2,33 +2,48 @@
 #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);
+
+#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..be4aee1f0ca5 100644
--- a/drivers/usb/host/uhci-hcd.h
+++ b/drivers/usb/host/uhci-hcd.h
@@ -505,36 +505,43 @@ static inline bool uhci_is_aspeed(const struct uhci_hcd *uhci)
  * we use memory mapped registers.
  */
 
+#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
 #ifndef CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC
 /* Support PCI only */
 static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
 {
-	return inl(uhci->io_addr + reg);
+	return UHCI_IN(inl(uhci->io_addr + reg));
 }
 
 static inline void uhci_writel(const struct uhci_hcd *uhci, u32 val, int reg)
 {
-	outl(val, uhci->io_addr + reg);
+	UHCI_OUT(outl(val, uhci->io_addr + reg));
 }
 
 static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
 {
-	return inw(uhci->io_addr + reg);
+	return UHCI_IN(inw(uhci->io_addr + reg));
 }
 
 static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
 {
-	outw(val, uhci->io_addr + reg);
+	UHCI_OUT(outw(val, uhci->io_addr + reg));
 }
 
 static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
 {
-	return inb(uhci->io_addr + reg);
+	return UHCI_IN(inb(uhci->io_addr + reg));
 }
 
 static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
 {
-	outb(val, uhci->io_addr + reg);
+	UHCI_OUT(outb(val, uhci->io_addr + reg));
 }
 
 #else
@@ -587,7 +594,7 @@ static inline int uhci_aspeed_reg(unsigned int reg)
 static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
 {
 	if (uhci_has_pci_registers(uhci))
-		return inl(uhci->io_addr + reg);
+		return UHCI_IN(inl(uhci->io_addr + reg));
 	else if (uhci_is_aspeed(uhci))
 		return readl(uhci->regs + uhci_aspeed_reg(reg));
 #ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
@@ -601,7 +608,7 @@ 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))
-		outl(val, uhci->io_addr + reg);
+		UHCI_OUT(outl(val, uhci->io_addr + reg));
 	else if (uhci_is_aspeed(uhci))
 		writel(val, uhci->regs + uhci_aspeed_reg(reg));
 #ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
@@ -615,7 +622,7 @@ static inline void uhci_writel(const struct uhci_hcd *uhci, u32 val, int reg)
 static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
 {
 	if (uhci_has_pci_registers(uhci))
-		return inw(uhci->io_addr + reg);
+		return UHCI_IN(inw(uhci->io_addr + reg));
 	else if (uhci_is_aspeed(uhci))
 		return readl(uhci->regs + uhci_aspeed_reg(reg));
 #ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
@@ -629,7 +636,7 @@ static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
 static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
 {
 	if (uhci_has_pci_registers(uhci))
-		outw(val, uhci->io_addr + reg);
+		UHCI_OUT(outw(val, uhci->io_addr + reg));
 	else if (uhci_is_aspeed(uhci))
 		writel(val, uhci->regs + uhci_aspeed_reg(reg));
 #ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
@@ -643,7 +650,7 @@ static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
 static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
 {
 	if (uhci_has_pci_registers(uhci))
-		return inb(uhci->io_addr + reg);
+		return UHCI_IN(inb(uhci->io_addr + reg));
 	else if (uhci_is_aspeed(uhci))
 		return readl(uhci->regs + uhci_aspeed_reg(reg));
 #ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
@@ -657,7 +664,7 @@ static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
 static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
 {
 	if (uhci_has_pci_registers(uhci))
-		outb(val, uhci->io_addr + reg);
+		UHCI_OUT(outb(val, uhci->io_addr + reg));
 	else if (uhci_is_aspeed(uhci))
 		writel(val, uhci->regs + uhci_aspeed_reg(reg));
 #ifdef CONFIG_USB_UHCI_BIG_ENDIAN_MMIO
@@ -668,6 +675,8 @@ static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
 		writeb(val, uhci->regs + reg);
 }
 #endif /* CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC */
+#undef UHCI_IN
+#undef UHCI_OUT
 
 /*
  * The GRLIB GRUSBHC controller can use big endian format for its descriptors.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [PATCH 36/37] usb: handle HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (64 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-04-29 14:49   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Mathias Nyman, Alan Stern,
	open list:USB SUBSYSTEM

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/usb/core/hcd-pci.c    |   3 +-
 drivers/usb/host/Kconfig      |   4 +-
 drivers/usb/host/pci-quirks.c | 128 ++++++++++++++++++----------------
 drivers/usb/host/pci-quirks.h |  33 ++++++---
 drivers/usb/host/uhci-hcd.c   |   2 +-
 drivers/usb/host/uhci-hcd.h   |  77 +++++++++++++-------
 6 files changed, 149 insertions(+), 98 deletions(-)

diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 8176bc81a635..50f1499a073e 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 57ca5f97a3dc..cd1faa3174e3 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..01471902c274 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,53 @@ 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 +717,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 +733,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 +1278,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] 392+ messages in thread

* [RFC v2 36/39] video: handle HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
@ 2022-04-29 13:51   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Helge Deller, open list:FRAMEBUFFER LAYER,
	open list:FRAMEBUFFER LAYER

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/video/fbdev/Kconfig | 25 +++++++++++++------------
 include/video/vga.h         |  8 ++++++++
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 93b8d84c34cf..e7d27c0602d5 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 && PCI && HAS_IOPORT && (BROKEN || !SPARC64)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -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
@@ -1242,7 +1243,7 @@ config FB_RADEON_DEBUG
 
 config FB_ATY128
 	tristate "ATI Rage128 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1265,7 +1266,7 @@ config FB_ATY128_BACKLIGHT
 
 config FB_ATY
 	tristate "ATI Mach64 display support" if PCI || ATARI
-	depends on FB && !SPARC32
+	depends on FB && HAS_IOPORT && !SPARC32
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1315,7 +1316,7 @@ config FB_ATY_BACKLIGHT
 
 config FB_S3
 	tristate "S3 Trio/Virge support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1374,7 +1375,7 @@ config FB_SAVAGE_ACCEL
 
 config FB_SIS
 	tristate "SiS/XGI display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1404,7 +1405,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 && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || COMPILE_TEST)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1442,7 +1443,7 @@ endif
 
 config FB_NEOMAGIC
 	tristate "NeoMagic display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_MODE_HELPERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1470,7 +1471,7 @@ config FB_KYRO
 
 config FB_3DFX
 	tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_IMAGEBLIT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1518,7 +1519,7 @@ config FB_VOODOO1
 
 config FB_VT8623
 	tristate "VIA VT8623 support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1532,7 +1533,7 @@ config FB_VT8623
 
 config FB_TRIDENT
 	tristate "Trident/CyberXXX/CyberBlade support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1554,7 +1555,7 @@ config FB_TRIDENT
 
 config FB_ARK
 	tristate "ARK 2000PV support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -2226,7 +2227,7 @@ config FB_SSD1307
 
 config FB_SM712
 	tristate "Silicon Motion SM712 framebuffer support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_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] 392+ messages in thread

* [RFC v2 36/39] video: handle HAS_IOPORT dependencies
@ 2022-04-29 13:51   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, open list:FRAMEBUFFER LAYER,
	Greg Kroah-Hartman, Helge Deller, linux-kernel,
	open list:FRAMEBUFFER LAYER, linux-pci

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/video/fbdev/Kconfig | 25 +++++++++++++------------
 include/video/vga.h         |  8 ++++++++
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 93b8d84c34cf..e7d27c0602d5 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 && PCI && HAS_IOPORT && (BROKEN || !SPARC64)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -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
@@ -1242,7 +1243,7 @@ config FB_RADEON_DEBUG
 
 config FB_ATY128
 	tristate "ATI Rage128 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1265,7 +1266,7 @@ config FB_ATY128_BACKLIGHT
 
 config FB_ATY
 	tristate "ATI Mach64 display support" if PCI || ATARI
-	depends on FB && !SPARC32
+	depends on FB && HAS_IOPORT && !SPARC32
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1315,7 +1316,7 @@ config FB_ATY_BACKLIGHT
 
 config FB_S3
 	tristate "S3 Trio/Virge support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1374,7 +1375,7 @@ config FB_SAVAGE_ACCEL
 
 config FB_SIS
 	tristate "SiS/XGI display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1404,7 +1405,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 && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || COMPILE_TEST)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1442,7 +1443,7 @@ endif
 
 config FB_NEOMAGIC
 	tristate "NeoMagic display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_MODE_HELPERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1470,7 +1471,7 @@ config FB_KYRO
 
 config FB_3DFX
 	tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_IMAGEBLIT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1518,7 +1519,7 @@ config FB_VOODOO1
 
 config FB_VT8623
 	tristate "VIA VT8623 support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1532,7 +1533,7 @@ config FB_VT8623
 
 config FB_TRIDENT
 	tristate "Trident/CyberXXX/CyberBlade support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -1554,7 +1555,7 @@ config FB_TRIDENT
 
 config FB_ARK
 	tristate "ARK 2000PV support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
@@ -2226,7 +2227,7 @@ config FB_SSD1307
 
 config FB_SM712
 	tristate "Silicon Motion SM712 framebuffer support"
-	depends on FB && PCI
+	depends on FB && PCI && HAS_IOPORT
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_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] 392+ messages in thread

* [PATCH 37/37] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (66 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-04-29 14:49   ` Niklas Schnelle
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

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: 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] 392+ messages in thread

* [RFC v2 37/39] watchdog: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (67 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-04-30  0:38   ` Guenter Roeck
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Wim Van Sebroeck, Guenter Roeck,
	open list:WATCHDOG DEVICE DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/watchdog/Kconfig | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c4e82a8d863f..3242be37b2d7 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -453,6 +453,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
@@ -1235,6 +1236,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
@@ -2090,7 +2092,7 @@ comment "PCI-based Watchdog Cards"
 
 config PCIPCWATCHDOG
 	tristate "Berkshire Products PCI-PC Watchdog"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	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,
@@ -2105,7 +2107,7 @@ config PCIPCWATCHDOG
 
 config WDTPCI
 	tristate "PCI-WDT500/501 Watchdog timer"
-	depends on PCI
+	depends on PCI && HAS_IOPORT
 	help
 	  If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 38/39] wireless: add HAS_IOPORT dependencies
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (68 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  2022-04-29 14:40   ` Kalle Valo
  -1 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Kalle Valo, David S. Miller, Jakub Kicinski,
	Paolo Abeni, Jouni Malinen,
	open list:NETWORKING DRIVERS (WIRELESS),
	open list:NETWORKING DRIVERS

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: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/net/wireless/atmel/Kconfig           | 2 +-
 drivers/net/wireless/intersil/hostap/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/atmel/Kconfig b/drivers/net/wireless/atmel/Kconfig
index ca45a1021cf4..bafdd57b049a 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 && (PCI || PCMCIA) && HAS_IOPORT
 	select WIRELESS_EXT
 	select WEXT_PRIV
 	select FW_LOADER
diff --git a/drivers/net/wireless/intersil/hostap/Kconfig b/drivers/net/wireless/intersil/hostap/Kconfig
index c865d3156cea..2edff8efbcbb 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 PCI && HOSTAP && HAS_IOPORT
 	help
 	Host AP driver's version for Prism2/2.5/3 PC Cards in PLX9052 based
 	PCI adaptors.
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 392+ messages in thread

* [RFC v2 39/39] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
  2022-04-29 13:49 ` Niklas Schnelle
                   ` (69 preceding siblings ...)
  (?)
@ 2022-04-29 13:51 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 13:51 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Bjorn Helgaas, Mauro Carvalho Chehab, Alan Stern,
	Rafael J. Wysocki, Geert Uytterhoeven, Arnd Bergmann

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.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
Co-developed-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] 392+ messages in thread

* Re: [PATCH 05/37] char: impi, tpm: depend on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 05/37] char: impi, tpm: depend " Niklas Schnelle
@ 2022-04-29 14:02   ` Ahmad Fatoum
  0 siblings, 0 replies; 392+ messages in thread
From: Ahmad Fatoum @ 2022-04-29 14:02 UTC (permalink / raw)
  To: Niklas Schnelle, Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Corey Minyard, Peter Huewe, Jarkko Sakkinen,
	moderated list:IPMI SUBSYSTEM, open list:TPM DEVICE DRIVER,
	Pengutronix Kernel Team

Hello Niklas,

On 29.04.22 15:50, 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 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: Niklas Schnelle <schnelle@linux.ibm.com>

[snip]

> 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

This looks ugly. Can't you declare inb/outb anyway and skip the definition,
so you can use IS_ENABLED() here instead?

You can mark the declarations with __compiletime_error("some message"), so
if an IS_ENABLED() reference is not removed at compile time, you get some
readable error message instead of a link error.

Cheers,
Ahmad

>  		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 dc56b976d816..1efb58dc1b41 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 = {


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
  2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
  (?)
@ 2022-04-29 14:13     ` Marc Kleine-Budde
  -1 siblings, 0 replies; 392+ messages in thread
From: Marc Kleine-Budde @ 2022-04-29 14:13 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, David S. Miller, Jakub Kicinski,
	Paolo Abeni, Michael Grzeschik, Wolfgang Grandegger,
	Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On 29.04.2022 15:50:33, 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. It also turns out that with HAS_IOPORT handled
> explicitly HAMRADIO does not need the !S390 dependency and successfully
> builds the bpqether driver.
> 
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Co-developed-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 drivers/net/can:

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] 392+ messages in thread

* [Intel-wired-lan] [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-04-29 14:13     ` Marc Kleine-Budde
  0 siblings, 0 replies; 392+ messages in thread
From: Marc Kleine-Budde @ 2022-04-29 14:13 UTC (permalink / raw)
  To: intel-wired-lan

On 29.04.2022 15:50:33, 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. It also turns out that with HAS_IOPORT handled
> explicitly HAMRADIO does not need the !S390 dependency and successfully
> builds the bpqether driver.
> 
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Co-developed-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 drivers/net/can:

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 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20220429/e5fa92f7/attachment-0001.asc>

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-04-29 14:13     ` Marc Kleine-Budde
  0 siblings, 0 replies; 392+ messages in thread
From: Marc Kleine-Budde @ 2022-04-29 14:13 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, David S. Miller, Jakub Kicinski,
	Paolo Abeni, Michael Grzeschik, Wolfgang Grandegger,
	Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On 29.04.2022 15:50:33, 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. It also turns out that with HAS_IOPORT handled
> explicitly HAMRADIO does not need the !S390 dependency and successfully
> builds the bpqether driver.
> 
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Co-developed-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 drivers/net/can:

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] 392+ messages in thread

* Re: [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT
  2022-04-29 13:50 ` [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT Niklas Schnelle
@ 2022-04-29 14:23   ` Niklas Schnelle
  2022-04-29 14:33     ` Ahmad Fatoum
  0 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:23 UTC (permalink / raw)
  To: Arnd Bergmann, Ahmad Fatoum
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Corey Minyard, Peter Huewe, Jarkko Sakkinen,
	moderated list:IPMI SUBSYSTEM, open list:TPM DEVICE DRIVER

> Hello Niklas,
> 
> On 29.04.22 15:50, 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 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: Niklas Schnelle <schnelle@linux.ibm.com>
> 
> [snip]
> 
> > 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
> 
> This looks ugly. Can't you declare inb/outb anyway and skip the definition,
> so you can use IS_ENABLED() here instead?
> 
> You can mark the declarations with __compiletime_error("some message"), so
> if an IS_ENABLED() reference is not removed at compile time, you get some
> readable error message instead of a link error.
> 
> Cheers,
> Ahmad

I didn't know about __compiletime_error() that certainly sounds
interesting even when using a normal #ifdef.

That said either with the function not being declared or this
__compiletime_error() mechanism I would think that using IS_ENABLED()
relies on compiler optimizations not to compile in the missing/error
function call, right? I'm not sure if that is something we should do.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 02/37] ata: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 02/37] ata: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-29 14:27   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Damien Le Moal,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 03/37] ACPI: add dependency on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 03/37] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
@ 2022-04-29 14:28   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:28 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Rafael J. Wysocki, open list:ACPI

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle 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 we simply depend
> on HAS_IOPORT.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  2022-04-29 13:50 ` [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
@ 2022-04-29 14:28   ` Samuel Thibault
  2022-04-29 14:28   ` Niklas Schnelle
  2022-04-29 14:29   ` Niklas Schnelle
  2 siblings, 0 replies; 392+ messages in thread
From: Samuel Thibault @ 2022-04-29 14:28 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, William Hubbs, Chris Brannon,
	Kirk Reiser, open list:SPEAKUP CONSOLE SPEECH DRIVER

Niklas Schnelle, le ven. 29 avril 2022 15:50:09 +0200, 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: 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
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 04/37] parport: PC style parport depends on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 04/37] parport: PC style parport depends " Niklas Schnelle
@ 2022-04-29 14:28   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:28 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sudip Mukherjee

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle 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.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  2022-04-29 13:50 ` [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
  2022-04-29 14:28   ` Samuel Thibault
@ 2022-04-29 14:28   ` Niklas Schnelle
  2022-04-29 14:29   ` Niklas Schnelle
  2 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:28 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, William Hubbs, Chris Brannon, Kirk Reiser,
	Samuel Thibault, open list:SPEAKUP CONSOLE SPEECH DRIVER

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO
  2022-04-29 13:50 ` [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
  2022-04-29 14:28   ` Samuel Thibault
  2022-04-29 14:28   ` Niklas Schnelle
@ 2022-04-29 14:29   ` Niklas Schnelle
  2 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, William Hubbs, Chris Brannon, Kirk Reiser,
	Samuel Thibault, open list:SPEAKUP CONSOLE SPEECH DRIVER

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 07/37] Input: gameport: add ISA and HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 07/37] Input: gameport: add ISA and HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-29 14:29   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dmitry Torokhov, open list:INPUT (KEYBOARD, MOUSE,
	JOYSTICK , TOUCHSCREEN)...

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.



^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 08/37] comedi: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 08/37] comedi: add " Niklas Schnelle
@ 2022-04-29 14:30   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:30 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Ian Abbott, H Hartley Sweeten

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 09/37] counter: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 09/37] counter: add " Niklas Schnelle
@ 2022-04-29 14:30   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:30 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, William Breathitt Gray,
	open list:COUNTER SUBSYSTEM

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 11/37] sound: add HAS_IOPORT dependencies
  2022-04-29 13:50   ` Niklas Schnelle
@ 2022-04-29 14:30     ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:30 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jaroslav Kysela, Takashi Iwai,
	moderated list:SOUND

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 11/37] sound: add HAS_IOPORT dependencies
@ 2022-04-29 14:30     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:30 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, moderated list:SOUND,
	Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-pci

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 13/37] Input: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 13/37] Input: " Niklas Schnelle
@ 2022-04-29 14:31   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:31 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dmitry Torokhov, open list:INPUT (KEYBOARD, MOUSE,
	JOYSTICK , TOUCHSCREEN)...

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 14/37] iio: adc: Kconfig: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 14/37] iio: adc: Kconfig: " Niklas Schnelle
@ 2022-04-29 14:31   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:31 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jonathan Cameron,
	open list:IIO SUBSYSTEM AND DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 15/37] hwmon: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 15/37] hwmon: " Niklas Schnelle
@ 2022-04-29 14:31   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:31 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jean Delvare, Guenter Roeck,
	open list:HARDWARE MONITORING

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.



^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 19/37] mpt fusion: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 19/37] mpt fusion: " Niklas Schnelle
@ 2022-04-29 14:32   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:32 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sathya Prakash, Sreekanth Reddy,
	Suganath Prabu Subramani,
	open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI),
	open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 10/39] gpio: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-29 14:32   ` William Breathitt Gray
  2022-04-29 14:46     ` Niklas Schnelle
  0 siblings, 1 reply; 392+ messages in thread
From: William Breathitt Gray @ 2022-04-29 14:32 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Fri, Apr 29, 2022 at 03:50:16PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
>  drivers/gpio/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 45764ec3b2eb..14e5998ee95c 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -697,7 +697,7 @@ config GPIO_VR41XX
>  
>  config GPIO_VX855
>  	tristate "VIA VX855/VX875 GPIO"
> -	depends on (X86 || COMPILE_TEST) && PCI
> +	depends on (X86 || COMPILE_TEST) && PCI && HAS_IOPORT
>  	select MFD_CORE
>  	select MFD_VX855
>  	help
> -- 
> 2.32.0

I noticed a number of other GPIO drivers make use of inb()/outb() -- for
example the PC104 drivers -- should the respective Kconfigs for those
drivers also be adjusted here?

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 20/37] net: add HAS_IOPORT dependencies
  2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
@ 2022-04-29 14:33     ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:33 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, David S. Miller, Jakub Kicinski, Paolo Abeni,
	Michael Grzeschik, Wolfgang Grandegger, Marc Kleine-Budde,
	Jesse Brandeburg, Tony Nguyen, open list:NETWORKING DRIVERS,
	open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* [Intel-wired-lan] [PATCH 20/37] net: add HAS_IOPORT dependencies
@ 2022-04-29 14:33     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:33 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 21/37] pcmcia: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 21/37] pcmcia: " Niklas Schnelle
@ 2022-04-29 14:33   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:33 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dominik Brodowski

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 22/37] platform: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 22/37] platform: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-29 14:33   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:33 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Benson Leung,
	open list:CHROME HARDWARE PLATFORM SUPPORT

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT
  2022-04-29 14:23   ` Niklas Schnelle
@ 2022-04-29 14:33     ` Ahmad Fatoum
  2022-05-02 14:34       ` Niklas Schnelle
  0 siblings, 1 reply; 392+ messages in thread
From: Ahmad Fatoum @ 2022-04-29 14:33 UTC (permalink / raw)
  To: Niklas Schnelle, Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Corey Minyard, Peter Huewe, Jarkko Sakkinen,
	moderated list:IPMI SUBSYSTEM, open list:TPM DEVICE DRIVER,
	Pengutronix Kernel Team

Hello Niklas,

On 29.04.22 16:23, Niklas Schnelle wrote:
>> Hello Niklas,
>>
>> On 29.04.22 15:50, 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 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: Niklas Schnelle <schnelle@linux.ibm.com>
>>
>> [snip]
>>
>>> 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
>>
>> This looks ugly. Can't you declare inb/outb anyway and skip the definition,
>> so you can use IS_ENABLED() here instead?
>>
>> You can mark the declarations with __compiletime_error("some message"), so
>> if an IS_ENABLED() reference is not removed at compile time, you get some
>> readable error message instead of a link error.
>>
>> Cheers,
>> Ahmad
> 
> I didn't know about __compiletime_error() that certainly sounds
> interesting even when using a normal #ifdef.
> 
> That said either with the function not being declared or this
> __compiletime_error() mechanism I would think that using IS_ENABLED()
> relies on compiler optimizations not to compile in the missing/error
> function call, right? I'm not sure if that is something we should do.

Yes, it assumes your compiler is able to discard the body of an if (0),
which we already assume, otherwise it wouldn't make sense for any existing
code to use __compiletime_error().

To me this sounds much cleaner than #ifdefs in the midst of functions,
which are a detriment to maintainability.

Cheers,
Ahmad




> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 23/37] pnp: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 23/37] pnp: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-29 14:34   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:34 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jaroslav Kysela, Rafael J. Wysocki,
	open list:PNP SUPPORT

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 24/37] power: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 24/37] power: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-29 14:34   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:34 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sebastian Reichel,
	open list:SYSTEM RESET/SHUTDOWN DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 25/37] video: handle HAS_IOPORT dependencies
  2022-04-29 13:50   ` Niklas Schnelle
@ 2022-04-29 14:35     ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:35 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Helge Deller, open list:FRAMEBUFFER LAYER,
	open list:FRAMEBUFFER LAYER

On Fri, 2022-04-29 at 15:50 +0200, 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 and guard inline code in headers.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 25/37] video: handle HAS_IOPORT dependencies
@ 2022-04-29 14:35     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:35 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, open list:FRAMEBUFFER LAYER,
	Greg Kroah-Hartman, Helge Deller, linux-kernel,
	open list:FRAMEBUFFER LAYER, linux-pci

On Fri, 2022-04-29 at 15:50 +0200, 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 and guard inline code in headers.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 38/39] wireless: add HAS_IOPORT dependencies
  2022-04-29 13:51 ` [RFC v2 38/39] wireless: " Niklas Schnelle
@ 2022-04-29 14:40   ` Kalle Valo
  0 siblings, 0 replies; 392+ messages in thread
From: Kalle Valo @ 2022-04-29 14:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, David S. Miller, Jakub Kicinski,
	Paolo Abeni, Jouni Malinen,
	open list:NETWORKING DRIVERS (WIRELESS),
	open list:NETWORKING DRIVERS

Niklas Schnelle <schnelle@linux.ibm.com> writes:

> 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: Niklas Schnelle <schnelle@linux.ibm.com>

I assume this will go via some other tree than wireless-next:

Acked-by: Kalle Valo <kvalo@kernel.org>

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-04-29 14:32   ` William Breathitt Gray
@ 2022-04-29 14:46     ` Niklas Schnelle
  2022-04-29 15:37       ` William Breathitt Gray
  0 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:46 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

On Fri, 2022-04-29 at 10:32 -0400, William Breathitt Gray wrote:
> On Fri, Apr 29, 2022 at 03:50:16PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> > ---
> >  drivers/gpio/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index 45764ec3b2eb..14e5998ee95c 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -697,7 +697,7 @@ config GPIO_VR41XX
> >  
> >  config GPIO_VX855
> >  	tristate "VIA VX855/VX875 GPIO"
> > -	depends on (X86 || COMPILE_TEST) && PCI
> > +	depends on (X86 || COMPILE_TEST) && PCI && HAS_IOPORT
> >  	select MFD_CORE
> >  	select MFD_VX855
> >  	help
> > -- 
> > 2.32.0
> 
> I noticed a number of other GPIO drivers make use of inb()/outb() -- for
> example the PC104 drivers -- should the respective Kconfigs for those
> drivers also be adjusted here?
> 
> William Breathitt Gray

Good question. As far as I can see most (all?) of these have "select
ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
currently be repeated in architectures and doesn't have an explicit
HAS_IOPORT dependency (it maybe should have one). But it does only make
sense on architectures with HAS_IOPORT set.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 26/37] rtc: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 26/37] rtc: " Niklas Schnelle
@ 2022-04-29 14:46   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:46 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Alessandro Zummo, Alexandre Belloni,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 27/37] scsi: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 27/37] scsi: " Niklas Schnelle
@ 2022-04-29 14:46   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:46 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, James E.J. Bottomley, Martin K. Petersen,
	Hannes Reinecke, Kashyap Desai, Sumit Saxena, Shivasharan S,
	Nilesh Javali, supporter:QLOGIC QLA2XXX FC-SCSI DRIVER,
	open list:SCSI SUBSYSTEM, open list:MEGARAID SCSI/SAS DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 28/37] staging: sm750fb: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 28/37] staging: sm750fb: " Niklas Schnelle
@ 2022-04-29 14:47   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:47 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Sudip Mukherjee, Teddy Wang,
	open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
	open list:STAGING SUBSYSTEM

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 29/37] tty: serial: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 29/37] tty: serial: " Niklas Schnelle
@ 2022-04-29 14:47   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:47 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Jiri Slaby, open list:SERIAL DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 30/37] watchdog: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [PATCH 30/37] watchdog: " Niklas Schnelle
@ 2022-04-29 14:47   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:47 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Wim Van Sebroeck, Guenter Roeck,
	open list:WATCHDOG DEVICE DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 31/37] drm: handle HAS_IOPORT dependencies
  2022-04-29 13:50   ` Niklas Schnelle
@ 2022-04-29 14:47     ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:47 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Dave Airlie, Gerd Hoffmann, David Airlie,
	Daniel Vetter, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
	open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list:DRM DRIVERS

On Fri, 2022-04-29 at 15:50 +0200, 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.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 31/37] drm: handle HAS_IOPORT dependencies
@ 2022-04-29 14:47     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:47 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, Arnd Bergmann, David Airlie, Greg Kroah-Hartman,
	linux-kernel, open list:DRM DRIVERS,
	open list:DRM DRIVER FOR QXL VIRTUAL GPU, Gerd Hoffmann,
	linux-pci, Dave Airlie, open list:DRM DRIVER FOR QXL VIRTUAL GPU

On Fri, 2022-04-29 at 15:50 +0200, 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.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
@ 2022-04-29 14:48   ` Niklas Schnelle
  2022-05-05 21:41   ` Bjorn Helgaas
  1 sibling, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bjorn Helgaas

On Fri, 2022-04-29 at 15:50 +0200, 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.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
@ 2022-04-29 14:48   ` Niklas Schnelle
  2022-05-05 21:44   ` Bjorn Helgaas
  1 sibling, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bjorn Helgaas

On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> In the future inw() and friends will not be compiled on architectures
> without I/O port support.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 34/37] firmware: dmi-sysfs: handle HAS_IOPORT=n
  2022-04-29 13:50 ` [PATCH 34/37] firmware: dmi-sysfs: handle HAS_IOPORT=n Niklas Schnelle
@ 2022-04-29 14:48   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

On Fri, 2022-04-29 at 15:50 +0200, 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.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 35/37] /dev/port: don't compile file operations without CONFIG_DEVPORT
  2022-04-29 13:51 ` [PATCH 35/37] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
@ 2022-04-29 14:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

On Fri, 2022-04-29 at 15:51 +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 36/37] usb: handle HAS_IOPORT dependencies
  2022-04-29 13:51 ` [PATCH 36/37] " Niklas Schnelle
@ 2022-04-29 14:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Mathias Nyman, Alan Stern,
	open list:USB SUBSYSTEM

On Fri, 2022-04-29 at 15:51 +0200, 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.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 37/37] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n
  2022-04-29 13:51 ` [PATCH 37/37] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle
@ 2022-04-29 14:49   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-04-29 14:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci, Arnd Bergmann

On Fri, 2022-04-29 at 15:51 +0200, Niklas Schnelle wrote:
> 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---

Sorry everyone. I sent this as PATCH in error while preparing to sent
the same series as RFC. Since e-mail has no remote delete and I lack a
time machine let's just all pretend you only got the RFC.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 17/39] media: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 17/39] media: " Niklas Schnelle
@ 2022-04-29 15:36   ` Sean Young
  0 siblings, 0 replies; 392+ messages in thread
From: Sean Young @ 2022-04-29 15:36 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Mauro Carvalho Chehab,
	open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB)

On Fri, Apr 29, 2022 at 03:50:27PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
>  drivers/media/pci/dm1105/Kconfig |  2 +-
>  drivers/media/radio/Kconfig      | 14 +++++++++++++-
>  drivers/media/rc/Kconfig         |  6 ++++++

For drivers/media/rc/Kconfig:

Reviewed-by: Sean Young <sean@mess.org>

Sean

>  3 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/dm1105/Kconfig b/drivers/media/pci/dm1105/Kconfig
> index e0e3af67c99c..4498c37f4990 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 && PCI && I2C && I2C_ALGOBIT && HAS_IOPORT
>  	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 cca03bd2cc42..e15d50d9161f 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -15,7 +15,7 @@ if RADIO_ADAPTERS
>  
>  config RADIO_MAXIRADIO
>  	tristate "Guillemot MAXI Radio FM 2000 radio"
> -	depends on PCI
> +	depends on PCI && HAS_IOPORT
>  	select RADIO_TEA575X
>  	help
>  	  Choose Y here if you have this radio card.  This card may also be
> @@ -232,6 +232,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,6 +241,7 @@ if V4L_RADIO_ISA_DRIVERS
>  config RADIO_AZTECH
>  	tristate "Aztech/Packard Bell Radio"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  Choose Y here if you have one of these FM radio cards, and then fill
> @@ -260,6 +262,7 @@ config RADIO_AZTECH_PORT
>  config RADIO_CADET
>  	tristate "ADS Cadet AM/FM Tuner"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	help
>  	  Choose Y here if you have one of these AM/FM radio cards, and then
>  	  fill in the port address below.
> @@ -270,6 +273,7 @@ config RADIO_CADET
>  config RADIO_GEMTEK
>  	tristate "GemTek Radio card (or compatible) support"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  Choose Y here if you have this FM radio card, and then fill in the
> @@ -309,6 +313,7 @@ config RADIO_GEMTEK_PROBE
>  
>  config RADIO_ISA
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	tristate
>  
>  config RADIO_MIROPCM20
> @@ -329,6 +334,7 @@ config RADIO_MIROPCM20
>  config RADIO_RTRACK
>  	tristate "AIMSlab RadioTrack (aka RadioReveal) support"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  Choose Y here if you have one of these FM radio cards, and then fill
> @@ -383,6 +389,7 @@ config RADIO_RTRACK_PORT
>  config RADIO_SF16FMI
>  	tristate "SF16-FMI/SF16-FMP/SF16-FMD Radio"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	help
>  	  Choose Y here if you have one of these FM radio cards.
>  
> @@ -392,6 +399,7 @@ config RADIO_SF16FMI
>  config RADIO_SF16FMR2
>  	tristate "SF16-FMR2/SF16-FMD2 Radio"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_TEA575X
>  	help
>  	  Choose Y here if you have one of these FM radio cards.
> @@ -402,6 +410,7 @@ config RADIO_SF16FMR2
>  config RADIO_TERRATEC
>  	tristate "TerraTec ActiveRadio ISA Standalone"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  Choose Y here if you have this FM radio card.
> @@ -416,6 +425,7 @@ config RADIO_TERRATEC
>  config RADIO_TRUST
>  	tristate "Trust FM radio card"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  This is a driver for the Trust FM radio cards. Say Y if you have
> @@ -439,6 +449,7 @@ config RADIO_TRUST_PORT
>  config RADIO_TYPHOON
>  	tristate "Typhoon Radio (a.k.a. EcoRadio)"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  Choose Y here if you have one of these FM radio cards, and then fill
> @@ -473,6 +484,7 @@ config RADIO_TYPHOON_PORT
>  config RADIO_ZOLTRIX
>  	tristate "Zoltrix Radio"
>  	depends on ISA || COMPILE_TEST
> +	depends on HAS_IOPORT
>  	select RADIO_ISA
>  	help
>  	  Choose Y here if you have one of these FM radio cards, and then fill
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index f560fc38895f..96528e6532fd 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -148,6 +148,7 @@ if RC_DEVICES
>  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.
> @@ -161,6 +162,7 @@ config IR_ENE
>  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
> @@ -249,6 +251,7 @@ config IR_IMON_RAW
>  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
> @@ -301,6 +304,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
> @@ -345,6 +349,7 @@ config IR_RX51
>  
>  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.
> @@ -412,6 +417,7 @@ config IR_TTUSBIR
>  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
> -- 
> 2.32.0

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-04-29 14:46     ` Niklas Schnelle
@ 2022-04-29 15:37       ` William Breathitt Gray
  2022-05-01 21:55         ` Linus Walleij
  2022-05-02 13:21         ` Maciej W. Rozycki
  0 siblings, 2 replies; 392+ messages in thread
From: William Breathitt Gray @ 2022-04-29 15:37 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Fri, Apr 29, 2022 at 04:46:00PM +0200, Niklas Schnelle wrote:
> On Fri, 2022-04-29 at 10:32 -0400, William Breathitt Gray wrote:
> > On Fri, Apr 29, 2022 at 03:50:16PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>
> > > ---
> > >  drivers/gpio/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > > index 45764ec3b2eb..14e5998ee95c 100644
> > > --- a/drivers/gpio/Kconfig
> > > +++ b/drivers/gpio/Kconfig
> > > @@ -697,7 +697,7 @@ config GPIO_VR41XX
> > >  
> > >  config GPIO_VX855
> > >  	tristate "VIA VX855/VX875 GPIO"
> > > -	depends on (X86 || COMPILE_TEST) && PCI
> > > +	depends on (X86 || COMPILE_TEST) && PCI && HAS_IOPORT
> > >  	select MFD_CORE
> > >  	select MFD_VX855
> > >  	help
> > > -- 
> > > 2.32.0
> > 
> > I noticed a number of other GPIO drivers make use of inb()/outb() -- for
> > example the PC104 drivers -- should the respective Kconfigs for those
> > drivers also be adjusted here?
> > 
> > William Breathitt Gray
> 
> Good question. As far as I can see most (all?) of these have "select
> ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> currently be repeated in architectures and doesn't have an explicit
> HAS_IOPORT dependency (it maybe should have one). But it does only make
> sense on architectures with HAS_IOPORT set.

There is such a thing as ISA DMA, but you'll still need to initialize
the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
"config ISA" is the right thing to do: all ISA devices are expected to
communicate in some way via ioport.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 16/39] leds: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 16/39] leds: add " Niklas Schnelle
@ 2022-04-29 18:54   ` Pavel Machek
  2022-05-02  8:31     ` Niklas Schnelle
  0 siblings, 1 reply; 392+ messages in thread
From: Pavel Machek @ 2022-04-29 18:54 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, open list:LED SUBSYSTEM

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

Hi!

> 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: Niklas Schnelle <schnelle@linux.ibm.com>

I don't see a problem there.

Acked-by: Pavel Machek <pavel@ucw.cz>

(Its marked RFC so I'm not taking the patch.. right?)

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 11/39] hwmon: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 11/39] hwmon: " Niklas Schnelle
@ 2022-04-30  0:37   ` Guenter Roeck
  0 siblings, 0 replies; 392+ messages in thread
From: Guenter Roeck @ 2022-04-30  0:37 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Jean Delvare,
	open list:HARDWARE MONITORING

On Fri, Apr 29, 2022 at 03:50:17PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

... assuming that the plan is to push those together. If not let me know.

Guenter

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 37/39] watchdog: add HAS_IOPORT dependencies
  2022-04-29 13:51 ` [RFC v2 37/39] watchdog: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-30  0:38   ` Guenter Roeck
  0 siblings, 0 replies; 392+ messages in thread
From: Guenter Roeck @ 2022-04-30  0:38 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Wim Van Sebroeck,
	open list:WATCHDOG DEVICE DRIVERS

On Fri, Apr 29, 2022 at 03:51:06PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

... assuming that the plan is to push those together. If not let me know.

Guenter

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 35/39] usb: handle HAS_IOPORT dependencies
  2022-04-29 13:51 ` [RFC v2 35/39] usb: handle HAS_IOPORT dependencies Niklas Schnelle
@ 2022-04-30 12:56   ` Alan Stern
  2022-05-02  8:26     ` Niklas Schnelle
  0 siblings, 1 reply; 392+ messages in thread
From: Alan Stern @ 2022-04-30 12:56 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Mathias Nyman, open list:USB SUBSYSTEM

On Fri, Apr 29, 2022 at 03:51:02PM +0200, 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.
> 
> Co-developed-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..4fd06b48149d 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c

> @@ -632,7 +590,53 @@ 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
> @@ -1273,7 +1280,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);

We discussed this already.  quirk_usb_handoff_uhci() is supposed to be 
called even when CONFIG_USB_UHCI_HCD isn't enabled.

...

> diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> index 8ae5ccd26753..be4aee1f0ca5 100644
> --- a/drivers/usb/host/uhci-hcd.h
> +++ b/drivers/usb/host/uhci-hcd.h
> @@ -505,36 +505,43 @@ static inline bool uhci_is_aspeed(const struct uhci_hcd *uhci)
>   * we use memory mapped registers.
>   */
>  
> +#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

Should have a blank line here.

>  #ifndef CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC
>  /* Support PCI only */
>  static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
>  {
> -	return inl(uhci->io_addr + reg);
> +	return UHCI_IN(inl(uhci->io_addr + reg));
>  }
>  
>  static inline void uhci_writel(const struct uhci_hcd *uhci, u32 val, int reg)
>  {
> -	outl(val, uhci->io_addr + reg);
> +	UHCI_OUT(outl(val, uhci->io_addr + reg));
>  }
>  
>  static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
>  {
> -	return inw(uhci->io_addr + reg);
> +	return UHCI_IN(inw(uhci->io_addr + reg));
>  }
>  
>  static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
>  {
> -	outw(val, uhci->io_addr + reg);
> +	UHCI_OUT(outw(val, uhci->io_addr + reg));
>  }
>  
>  static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
>  {
> -	return inb(uhci->io_addr + reg);
> +	return UHCI_IN(inb(uhci->io_addr + reg));
>  }
>  
>  static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
>  {
> -	outb(val, uhci->io_addr + reg);
> +	UHCI_OUT(outb(val, uhci->io_addr + reg));
>  }
>  
>  #else

I thought you were going to update the definition of 
uhci_has_pci_registers().  It shouldn't do a test at runtime if 
CONFIG_HAS_IOPORT is disabled.

Alan Stern

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 13/39] iio: adc: Kconfig: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 13/39] iio: adc: Kconfig: " Niklas Schnelle
@ 2022-05-01 16:51   ` Jonathan Cameron
  0 siblings, 0 replies; 392+ messages in thread
From: Jonathan Cameron @ 2022-05-01 16:51 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, open list:IIO SUBSYSTEM AND DRIVERS

On Fri, 29 Apr 2022 15:50:20 +0200
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: Niklas Schnelle <schnelle@linux.ibm.com>

Hi.

Please call out specific driver as that'll increase chance
of relevant people noticing (there are quite a lot of ADC drivers!)

e.g.
iio: adc: ad7606: ....

Anyhow, looks fine to me

Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Thanks,


> ---
>  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 71ab0a06aa82..c99843307e4f 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -130,7 +130,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:


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-04-29 15:37       ` William Breathitt Gray
@ 2022-05-01 21:55         ` Linus Walleij
  2022-05-02 12:53           ` Niklas Schnelle
  2022-05-03 13:08           ` David Laight
  2022-05-02 13:21         ` Maciej W. Rozycki
  1 sibling, 2 replies; 392+ messages in thread
From: Linus Walleij @ 2022-05-01 21:55 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman, linux-kernel,
	linux-arch, linux-pci, Arnd Bergmann, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

On Fri, Apr 29, 2022 at 5:37 PM William Breathitt Gray
<william.gray@linaro.org> wrote:
> On Fri, Apr 29, 2022 at 04:46:00PM +0200, Niklas Schnelle wrote:

> > Good question. As far as I can see most (all?) of these have "select
> > ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> > currently be repeated in architectures and doesn't have an explicit
> > HAS_IOPORT dependency (it maybe should have one). But it does only make
> > sense on architectures with HAS_IOPORT set.
>
> There is such a thing as ISA DMA, but you'll still need to initialize
> the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> "config ISA" is the right thing to do: all ISA devices are expected to
> communicate in some way via ioport.

Adding that dependency seems like the right solution to me.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-04-29 13:49   ` Niklas Schnelle
                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-01 22:40     ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. The "depends on" relations on HAS_IOPORT
> in drivers as well as ifdefs for HAS_IOPORT specific sections will be
> added in subsequent patches on a per subsystem basis.
[...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index de3b32a507d2..4c55df08d6f1 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

 NAK, not all MIPS systems have the port I/O space, and we have it already 
handled via the NO_IOPORT_MAP option.  We'll need to have HAS_IOPORT set 
to !NO_IOPORT_MAP (or vice versa) for the MIPS architecture.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-01 22:40     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. The "depends on" relations on HAS_IOPORT
> in drivers as well as ifdefs for HAS_IOPORT specific sections will be
> added in subsequent patches on a per subsystem basis.
[...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index de3b32a507d2..4c55df08d6f1 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

 NAK, not all MIPS systems have the port I/O space, and we have it already 
handled via the NO_IOPORT_MAP option.  We'll need to have HAS_IOPORT set 
to !NO_IOPORT_MAP (or vice versa) for the MIPS architecture.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-01 22:40     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. The "depends on" relations on HAS_IOPORT
> in drivers as well as ifdefs for HAS_IOPORT specific sections will be
> added in subsequent patches on a per subsystem basis.
[...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index de3b32a507d2..4c55df08d6f1 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

 NAK, not all MIPS systems have the port I/O space, and we have it already 
handled via the NO_IOPORT_MAP option.  We'll need to have HAS_IOPORT set 
to !NO_IOPORT_MAP (or vice versa) for the MIPS architecture.

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-01 22:40     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Arnd Bergmann,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, linux-kernel, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. The "depends on" relations on HAS_IOPORT
> in drivers as well as ifdefs for HAS_IOPORT specific sections will be
> added in subsequent patches on a per subsystem basis.
[...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index de3b32a507d2..4c55df08d6f1 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

 NAK, not all MIPS systems have the port I/O space, and we have it already 
handled via the NO_IOPORT_MAP option.  We'll need to have HAS_IOPORT set 
to !NO_IOPORT_MAP (or vice versa) for the MIPS architecture.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-01 22:40     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. The "depends on" relations on HAS_IOPORT
> in drivers as well as ifdefs for HAS_IOPORT specific sections will be
> added in subsequent patches on a per subsystem basis.
[...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index de3b32a507d2..4c55df08d6f1 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

 NAK, not all MIPS systems have the port I/O space, and we have it already 
handled via the NO_IOPORT_MAP option.  We'll need to have HAS_IOPORT set 
to !NO_IOPORT_MAP (or vice versa) for the MIPS architecture.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-01 22:40     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:40 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. The "depends on" relations on HAS_IOPORT
> in drivers as well as ifdefs for HAS_IOPORT specific sections will be
> added in subsequent patches on a per subsystem basis.
[...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index de3b32a507d2..4c55df08d6f1 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

 NAK, not all MIPS systems have the port I/O space, and we have it already 
handled via the NO_IOPORT_MAP option.  We'll need to have HAS_IOPORT set 
to !NO_IOPORT_MAP (or vice versa) for the MIPS architecture.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
  2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
  (?)
@ 2022-05-01 22:48     ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:48 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

On Fri, 29 Apr 2022, 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. It also turns out that with HAS_IOPORT handled
> explicitly HAMRADIO does not need the !S390 dependency and successfully
> builds the bpqether driver.
[...]
> diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
> index 846bf41c2717..fa3f1e0fe143 100644
> --- a/drivers/net/fddi/Kconfig
> +++ b/drivers/net/fddi/Kconfig
> @@ -29,7 +29,7 @@ config DEFZA
>  
>  config DEFXX
>  	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
> -	depends on FDDI && (PCI || EISA || TC)
> +	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
>  	help
>  	  This is support for the DIGITAL series of TURBOchannel (DEFTA),
>  	  EISA (DEFEA) and PCI (DEFPA) controllers which can connect you

 NAK, this has to be sorted out differently (and I think we discussed it 
before).

 The driver works just fine with MMIO where available, so if `inb'/`outb' 
do get removed, then only parts that rely on port I/O need to be disabled.  
In fact there's already such provision there in drivers/net/fddi/defxx.c 
for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:

#if defined(CONFIG_EISA) || defined(CONFIG_PCI)
#define dfx_use_mmio bp->mmio
#else
#define dfx_use_mmio true
#endif

so I guess it's just the conditional that will have to be changed to:

#ifdef CONFIG_HAS_IOPORT

replacing the current explicit bus dependency list.  The compiler will 
then optimise away all the port I/O stuff (though I suspect dummy function 
declarations may be required for `inb'/`outb', etc.).

 I can verify a suitable change with a TURBOchannel configuration once the 
MIPS part has been sorted.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* [Intel-wired-lan] [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-05-01 22:48     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:48 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, 29 Apr 2022, 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. It also turns out that with HAS_IOPORT handled
> explicitly HAMRADIO does not need the !S390 dependency and successfully
> builds the bpqether driver.
[...]
> diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
> index 846bf41c2717..fa3f1e0fe143 100644
> --- a/drivers/net/fddi/Kconfig
> +++ b/drivers/net/fddi/Kconfig
> @@ -29,7 +29,7 @@ config DEFZA
>  
>  config DEFXX
>  	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
> -	depends on FDDI && (PCI || EISA || TC)
> +	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
>  	help
>  	  This is support for the DIGITAL series of TURBOchannel (DEFTA),
>  	  EISA (DEFEA) and PCI (DEFPA) controllers which can connect you

 NAK, this has to be sorted out differently (and I think we discussed it 
before).

 The driver works just fine with MMIO where available, so if `inb'/`outb' 
do get removed, then only parts that rely on port I/O need to be disabled.  
In fact there's already such provision there in drivers/net/fddi/defxx.c 
for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:

#if defined(CONFIG_EISA) || defined(CONFIG_PCI)
#define dfx_use_mmio bp->mmio
#else
#define dfx_use_mmio true
#endif

so I guess it's just the conditional that will have to be changed to:

#ifdef CONFIG_HAS_IOPORT

replacing the current explicit bus dependency list.  The compiler will 
then optimise away all the port I/O stuff (though I suspect dummy function 
declarations may be required for `inb'/`outb', etc.).

 I can verify a suitable change with a TURBOchannel configuration once the 
MIPS part has been sorted.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-05-01 22:48     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-01 22:48 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS, open

On Fri, 29 Apr 2022, 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. It also turns out that with HAS_IOPORT handled
> explicitly HAMRADIO does not need the !S390 dependency and successfully
> builds the bpqether driver.
[...]
> diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
> index 846bf41c2717..fa3f1e0fe143 100644
> --- a/drivers/net/fddi/Kconfig
> +++ b/drivers/net/fddi/Kconfig
> @@ -29,7 +29,7 @@ config DEFZA
>  
>  config DEFXX
>  	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
> -	depends on FDDI && (PCI || EISA || TC)
> +	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
>  	help
>  	  This is support for the DIGITAL series of TURBOchannel (DEFTA),
>  	  EISA (DEFEA) and PCI (DEFPA) controllers which can connect you

 NAK, this has to be sorted out differently (and I think we discussed it 
before).

 The driver works just fine with MMIO where available, so if `inb'/`outb' 
do get removed, then only parts that rely on port I/O need to be disabled.  
In fact there's already such provision there in drivers/net/fddi/defxx.c 
for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:

#if defined(CONFIG_EISA) || defined(CONFIG_PCI)
#define dfx_use_mmio bp->mmio
#else
#define dfx_use_mmio true
#endif

so I guess it's just the conditional that will have to be changed to:

#ifdef CONFIG_HAS_IOPORT

replacing the current explicit bus dependency list.  The compiler will 
then optimise away all the port I/O stuff (though I suspect dummy function 
declarations may be required for `inb'/`outb', etc.).

 I can verify a suitable change with a TURBOchannel configuration once the 
MIPS part has been sorted.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 35/39] usb: handle HAS_IOPORT dependencies
  2022-04-30 12:56   ` Alan Stern
@ 2022-05-02  8:26     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-02  8:26 UTC (permalink / raw)
  To: Alan Stern
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Mathias Nyman, open list:USB SUBSYSTEM

On Sat, 2022-04-30 at 08:56 -0400, Alan Stern wrote:
> On Fri, Apr 29, 2022 at 03:51:02PM +0200, 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.
> > 
> > Co-developed-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..4fd06b48149d 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > @@ -632,7 +590,53 @@ 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
> > @@ -1273,7 +1280,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);
> 
> We discussed this already.  quirk_usb_handoff_uhci() is supposed to be 
> called even when CONFIG_USB_UHCI_HCD isn't enabled.

Sorry I missed this part. Done.

> 
> ...
> 
> > diff --git a/drivers/usb/host/uhci-hcd.h b/drivers/usb/host/uhci-hcd.h
> > index 8ae5ccd26753..be4aee1f0ca5 100644
> > --- a/drivers/usb/host/uhci-hcd.h
> > +++ b/drivers/usb/host/uhci-hcd.h
> > @@ -505,36 +505,43 @@ static inline bool uhci_is_aspeed(const struct uhci_hcd *uhci)
> >   * we use memory mapped registers.
> >   */
> >  
> > +#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
> 
> Should have a blank line here.

Done

> 
> >  #ifndef CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC
> >  /* Support PCI only */
> >  static inline u32 uhci_readl(const struct uhci_hcd *uhci, int reg)
> >  {
> > -	return inl(uhci->io_addr + reg);
> > +	return UHCI_IN(inl(uhci->io_addr + reg));
> >  }
> >  
> >  static inline void uhci_writel(const struct uhci_hcd *uhci, u32 val, int reg)
> >  {
> > -	outl(val, uhci->io_addr + reg);
> > +	UHCI_OUT(outl(val, uhci->io_addr + reg));
> >  }
> >  
> >  static inline u16 uhci_readw(const struct uhci_hcd *uhci, int reg)
> >  {
> > -	return inw(uhci->io_addr + reg);
> > +	return UHCI_IN(inw(uhci->io_addr + reg));
> >  }
> >  
> >  static inline void uhci_writew(const struct uhci_hcd *uhci, u16 val, int reg)
> >  {
> > -	outw(val, uhci->io_addr + reg);
> > +	UHCI_OUT(outw(val, uhci->io_addr + reg));
> >  }
> >  
> >  static inline u8 uhci_readb(const struct uhci_hcd *uhci, int reg)
> >  {
> > -	return inb(uhci->io_addr + reg);
> > +	return UHCI_IN(inb(uhci->io_addr + reg));
> >  }
> >  
> >  static inline void uhci_writeb(const struct uhci_hcd *uhci, u8 val, int reg)
> >  {
> > -	outb(val, uhci->io_addr + reg);
> > +	UHCI_OUT(outb(val, uhci->io_addr + reg));
> >  }
> >  
> >  #else
> 
> I thought you were going to update the definition of 
> uhci_has_pci_registers().  It shouldn't do a test at runtime if 
> CONFIG_HAS_IOPORT is disabled.
> 
> Alan Stern

Good point. Done.



^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 16/39] leds: add HAS_IOPORT dependencies
  2022-04-29 18:54   ` Pavel Machek
@ 2022-05-02  8:31     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-02  8:31 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, open list:LED SUBSYSTEM

On Fri, 2022-04-29 at 20:54 +0200, Pavel Machek wrote:
> Hi!
> 
> > 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: Niklas Schnelle <schnelle@linux.ibm.com>
> 
> I don't see a problem there.
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> (Its marked RFC so I'm not taking the patch.. right?)
> 
> Best regards,
> 								Pavel

Right and thank you.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 34/39] tty: serial: add HAS_IOPORT dependencies
  2022-04-29 13:51 ` [RFC v2 34/39] tty: serial: add HAS_IOPORT dependencies Niklas Schnelle
@ 2022-05-02  9:15   ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-02  9:15 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Jiri Slaby, open list:SERIAL DRIVERS

On Fri, 29 Apr 2022, 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.
[...]
> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index cd93ea6eed65..e216bf745e78 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -6,7 +6,7 @@
>  
>  config SERIAL_8250
>  	tristate "8250/16550 and compatible serial support"
> -	depends on !S390
> +	depends on HAS_IOPORT
>  	select SERIAL_CORE
>  	select SERIAL_MCTRL_GPIO if GPIOLIB
>  	help

 Similarly here some 8250-compatible platform or PCI/e serial port devices 
use MMIO, e.g.:

serial8250.0: ttyS2 at MMIO 0x1f000900 (irq = 20, base_baud = 230400) is a 16550A

or:

0001:01:00.0: ttyS0 at MMIO 0x600c080401000 (irq = 40, base_baud = 15625000) is a 16C950/954

so this has to be sorted out within the driver rather than by disabling it 
altogether.  Possibly with a suitable conditional wired to HAS_IOPORT in 
`set_io_from_upio' in drivers/tty/serial/8250/8250_port.c.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-05-01 21:55         ` Linus Walleij
@ 2022-05-02 12:53           ` Niklas Schnelle
  2022-05-03 13:08           ` David Laight
  1 sibling, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-02 12:53 UTC (permalink / raw)
  To: Linus Walleij, William Breathitt Gray
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

On Sun, 2022-05-01 at 23:55 +0200, Linus Walleij wrote:
> On Fri, Apr 29, 2022 at 5:37 PM William Breathitt Gray
> <william.gray@linaro.org> wrote:
> > On Fri, Apr 29, 2022 at 04:46:00PM +0200, Niklas Schnelle wrote:
> > > Good question. As far as I can see most (all?) of these have "select
> > > ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> > > currently be repeated in architectures and doesn't have an explicit
> > > HAS_IOPORT dependency (it maybe should have one). But it does only make
> > > sense on architectures with HAS_IOPORT set.
> > 
> > There is such a thing as ISA DMA, but you'll still need to initialize
> > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> > "config ISA" is the right thing to do: all ISA devices are expected to
> > communicate in some way via ioport.
> 
> Adding that dependency seems like the right solution to me.
> 
> Yours,
> Linus Walleij

One thing I forgot to mention, config HAS_IOPORT does have a "def_bool
ISA" but yes I agree an explicit "depends on HAS_IOPORT" for ISA seems
more logical. I also haven't found issues trying this out locally so
far.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-04-29 15:37       ` William Breathitt Gray
  2022-05-01 21:55         ` Linus Walleij
@ 2022-05-02 13:21         ` Maciej W. Rozycki
  1 sibling, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-02 13:21 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman, linux-kernel,
	linux-arch, linux-pci, Arnd Bergmann, Linus Walleij,
	Bartosz Golaszewski, open list:GPIO SUBSYSTEM

On Fri, 29 Apr 2022, William Breathitt Gray wrote:

> > Good question. As far as I can see most (all?) of these have "select
> > ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> > currently be repeated in architectures and doesn't have an explicit
> > HAS_IOPORT dependency (it maybe should have one). But it does only make
> > sense on architectures with HAS_IOPORT set.
> 
> There is such a thing as ISA DMA, but you'll still need to initialize
> the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> "config ISA" is the right thing to do: all ISA devices are expected to
> communicate in some way via ioport.

 Strictly speaking you can make an ISA device that only does MMIO (and I 
believe in the early PC days there used to be ISA memory expansion cards 
along with the EMS standard) which is also why the host memory area in the 
15-16MiB range, the top 1MiB addressable on 16-bit ISA, can be excluded 
from decoding to DRAM and accesses made there forwarded to ISA in I 
believe all chipsets that provide actual ISA bus circuitry (rather than 
just a degenerate form like LPC).  That's an exception rather than the 
rule though, nearly all ISA devices do decode in the port I/O space.  
After all I/O is what the port I/O address space has been invented for.

 FWIW,

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT
  2022-04-29 14:33     ` Ahmad Fatoum
@ 2022-05-02 14:34       ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-02 14:34 UTC (permalink / raw)
  To: Ahmad Fatoum, Arnd Bergmann
  Cc: Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Corey Minyard, Peter Huewe, Jarkko Sakkinen,
	moderated list:IPMI SUBSYSTEM, open list:TPM DEVICE DRIVER,
	Pengutronix Kernel Team

On Fri, 2022-04-29 at 16:33 +0200, Ahmad Fatoum wrote:
> Hello Niklas,
> 
> On 29.04.22 16:23, Niklas Schnelle wrote:
> > > Hello Niklas,
> > > 
> > > On 29.04.22 15:50, 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 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: Niklas Schnelle <schnelle@linux.ibm.com>
> > > 
> > > [snip]
> > > 
> > > > 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
> > > 
> > > This looks ugly. Can't you declare inb/outb anyway and skip the definition,
> > > so you can use IS_ENABLED() here instead?
> > > 
> > > You can mark the declarations with __compiletime_error("some message"), so
> > > if an IS_ENABLED() reference is not removed at compile time, you get some
> > > readable error message instead of a link error.
> > > 
> > > Cheers,
> > > Ahmad
> > 
> > I didn't know about __compiletime_error() that certainly sounds
> > interesting even when using a normal #ifdef.
> > 
> > That said either with the function not being declared or this
> > __compiletime_error() mechanism I would think that using IS_ENABLED()
> > relies on compiler optimizations not to compile in the missing/error
> > function call, right? I'm not sure if that is something we should do.
> 
> Yes, it assumes your compiler is able to discard the body of an if (0),
> which we already assume, otherwise it wouldn't make sense for any existing
> code to use __compiletime_error().
> 
> To me this sounds much cleaner than #ifdefs in the midst of functions,
> which are a detriment to maintainability.
> 
> Cheers,
> Ahmad
> 

Ok, makes sense. I'll look into using __compiletime_error() and
IS_ENABLED().



^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
  2022-05-01 22:48     ` [Intel-wired-lan] " Maciej W. Rozycki
  (?)
@ 2022-05-03 12:45       ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-03 12:45 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

On Sun, 2022-05-01 at 23:48 +0100, Maciej W. Rozycki wrote:
> On Fri, 29 Apr 2022, 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. It also turns out that with HAS_IOPORT handled
> > explicitly HAMRADIO does not need the !S390 dependency and successfully
> > builds the bpqether driver.
> [...]
> > diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
> > index 846bf41c2717..fa3f1e0fe143 100644
> > --- a/drivers/net/fddi/Kconfig
> > +++ b/drivers/net/fddi/Kconfig
> > @@ -29,7 +29,7 @@ config DEFZA
> >  
> >  config DEFXX
> >  	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
> > -	depends on FDDI && (PCI || EISA || TC)
> > +	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
> >  	help
> >  	  This is support for the DIGITAL series of TURBOchannel (DEFTA),
> >  	  EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
> 
>  NAK, this has to be sorted out differently (and I think we discussed it 
> before).
> 
>  The driver works just fine with MMIO where available, so if `inb'/`outb' 
> do get removed, then only parts that rely on port I/O need to be disabled.  
> In fact there's already such provision there in drivers/net/fddi/defxx.c 
> for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:
> 
> #if defined(CONFIG_EISA) || defined(CONFIG_PCI)
> #define dfx_use_mmio bp->mmio
> #else
> #define dfx_use_mmio true
> #endif
> 
> so I guess it's just the conditional that will have to be changed to:
> 
> #ifdef CONFIG_HAS_IOPORT
> 
> replacing the current explicit bus dependency list.  The compiler will 
> then optimise away all the port I/O stuff (though I suspect dummy function 
> declarations may be required for `inb'/`outb', etc.).
> 
>  I can verify a suitable change with a TURBOchannel configuration once the 
> MIPS part has been sorted.
> 
>   Maciej

With dfx_use_mmio changed as you propose above things compile on s390
which previously ran into missing (now __compile_error()) inl() via
dfx_port_read_long() -> dfx_inl() ->  inl().

Looking at the other uses of dfx_use_mmio I notice however that in
dfx_get_bars(), inb() actually gets called when dfx_use_mmio is true.
This happens if dfx_bus_eisa is also true. Now that variable is just
the cached result of DFX_BUS_EISA(dev) which is defined to 0 if
CONFIG_EISA is unset. I'm not 100% sure if going through a local
variable is still considered trivial enough dead code elimination, at
least it works for me™. I did also check the GCC docs and they
explicitly say that __attribute__(error) is supposed to be used when
dead code elimination gets rid of the error paths.

I think we also need a "depends on HAS_IOPORT" for "config HAVE_EISA"
just as I'm adding for "config ISA".


^ permalink raw reply	[flat|nested] 392+ messages in thread

* [Intel-wired-lan] [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-05-03 12:45       ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-03 12:45 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2022-05-01 at 23:48 +0100, Maciej W. Rozycki wrote:
> On Fri, 29 Apr 2022, 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. It also turns out that with HAS_IOPORT handled
> > explicitly HAMRADIO does not need the !S390 dependency and successfully
> > builds the bpqether driver.
> [...]
> > diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
> > index 846bf41c2717..fa3f1e0fe143 100644
> > --- a/drivers/net/fddi/Kconfig
> > +++ b/drivers/net/fddi/Kconfig
> > @@ -29,7 +29,7 @@ config DEFZA
> >  
> >  config DEFXX
> >  	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
> > -	depends on FDDI && (PCI || EISA || TC)
> > +	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
> >  	help
> >  	  This is support for the DIGITAL series of TURBOchannel (DEFTA),
> >  	  EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
> 
>  NAK, this has to be sorted out differently (and I think we discussed it 
> before).
> 
>  The driver works just fine with MMIO where available, so if `inb'/`outb' 
> do get removed, then only parts that rely on port I/O need to be disabled.  
> In fact there's already such provision there in drivers/net/fddi/defxx.c 
> for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:
> 
> #if defined(CONFIG_EISA) || defined(CONFIG_PCI)
> #define dfx_use_mmio bp->mmio
> #else
> #define dfx_use_mmio true
> #endif
> 
> so I guess it's just the conditional that will have to be changed to:
> 
> #ifdef CONFIG_HAS_IOPORT
> 
> replacing the current explicit bus dependency list.  The compiler will 
> then optimise away all the port I/O stuff (though I suspect dummy function 
> declarations may be required for `inb'/`outb', etc.).
> 
>  I can verify a suitable change with a TURBOchannel configuration once the 
> MIPS part has been sorted.
> 
>   Maciej

With dfx_use_mmio changed as you propose above things compile on s390
which previously ran into missing (now __compile_error()) inl() via
dfx_port_read_long() -> dfx_inl() ->  inl().

Looking at the other uses of dfx_use_mmio I notice however that in
dfx_get_bars(), inb() actually gets called when dfx_use_mmio is true.
This happens if dfx_bus_eisa is also true. Now that variable is just
the cached result of DFX_BUS_EISA(dev) which is defined to 0 if
CONFIG_EISA is unset. I'm not 100% sure if going through a local
variable is still considered trivial enough dead code elimination, at
least it works for me?. I did also check the GCC docs and they
explicitly say that __attribute__(error) is supposed to be used when
dead code elimination gets rid of the error paths.

I think we also need a "depends on HAS_IOPORT" for "config HAVE_EISA"
just as I'm adding for "config ISA".


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-05-03 12:45       ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-03 12:45 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS, open

On Sun, 2022-05-01 at 23:48 +0100, Maciej W. Rozycki wrote:
> On Fri, 29 Apr 2022, 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. It also turns out that with HAS_IOPORT handled
> > explicitly HAMRADIO does not need the !S390 dependency and successfully
> > builds the bpqether driver.
> [...]
> > diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
> > index 846bf41c2717..fa3f1e0fe143 100644
> > --- a/drivers/net/fddi/Kconfig
> > +++ b/drivers/net/fddi/Kconfig
> > @@ -29,7 +29,7 @@ config DEFZA
> >  
> >  config DEFXX
> >  	tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
> > -	depends on FDDI && (PCI || EISA || TC)
> > +	depends on FDDI && (PCI || EISA || TC) && HAS_IOPORT
> >  	help
> >  	  This is support for the DIGITAL series of TURBOchannel (DEFTA),
> >  	  EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
> 
>  NAK, this has to be sorted out differently (and I think we discussed it 
> before).
> 
>  The driver works just fine with MMIO where available, so if `inb'/`outb' 
> do get removed, then only parts that rely on port I/O need to be disabled.  
> In fact there's already such provision there in drivers/net/fddi/defxx.c 
> for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:
> 
> #if defined(CONFIG_EISA) || defined(CONFIG_PCI)
> #define dfx_use_mmio bp->mmio
> #else
> #define dfx_use_mmio true
> #endif
> 
> so I guess it's just the conditional that will have to be changed to:
> 
> #ifdef CONFIG_HAS_IOPORT
> 
> replacing the current explicit bus dependency list.  The compiler will 
> then optimise away all the port I/O stuff (though I suspect dummy function 
> declarations may be required for `inb'/`outb', etc.).
> 
>  I can verify a suitable change with a TURBOchannel configuration once the 
> MIPS part has been sorted.
> 
>   Maciej

With dfx_use_mmio changed as you propose above things compile on s390
which previously ran into missing (now __compile_error()) inl() via
dfx_port_read_long() -> dfx_inl() ->  inl().

Looking at the other uses of dfx_use_mmio I notice however that in
dfx_get_bars(), inb() actually gets called when dfx_use_mmio is true.
This happens if dfx_bus_eisa is also true. Now that variable is just
the cached result of DFX_BUS_EISA(dev) which is defined to 0 if
CONFIG_EISA is unset. I'm not 100% sure if going through a local
variable is still considered trivial enough dead code elimination, at
least it works for meâ„¢. I did also check the GCC docs and they
explicitly say that __attribute__(error) is supposed to be used when
dead code elimination gets rid of the error paths.

I think we also need a "depends on HAS_IOPORT" for "config HAVE_EISA"
just as I'm adding for "config ISA".


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-05-01 21:55         ` Linus Walleij
  2022-05-02 12:53           ` Niklas Schnelle
@ 2022-05-03 13:08           ` David Laight
  2022-05-03 14:03             ` William Breathitt Gray
  2022-05-04 11:46             ` Maciej W. Rozycki
  1 sibling, 2 replies; 392+ messages in thread
From: David Laight @ 2022-05-03 13:08 UTC (permalink / raw)
  To: 'Linus Walleij', William Breathitt Gray
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman, linux-kernel,
	linux-arch, linux-pci, Arnd Bergmann, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

From: Linus Walleij
> Sent: 01 May 2022 22:56
> 
> On Fri, Apr 29, 2022 at 5:37 PM William Breathitt Gray
> <william.gray@linaro.org> wrote:
> > On Fri, Apr 29, 2022 at 04:46:00PM +0200, Niklas Schnelle wrote:
> 
> > > Good question. As far as I can see most (all?) of these have "select
> > > ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> > > currently be repeated in architectures and doesn't have an explicit
> > > HAS_IOPORT dependency (it maybe should have one). But it does only make
> > > sense on architectures with HAS_IOPORT set.
> >
> > There is such a thing as ISA DMA, but you'll still need to initialize
> > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> > "config ISA" is the right thing to do: all ISA devices are expected to
> > communicate in some way via ioport.
> 
> Adding that dependency seems like the right solution to me.

I think it all depends on what HAS_IOPORT is meant to mean and
how portable kernel binaries need to be.

x86 is (probably) the only architecture that actually has 'in'
and 'out' instructions - but that doesn't mean that some other
cpu (and I mean cpu+pcb not architecture) have the ability to
generate 'IO' bus cycles on a specific physical bus.

While the obvious case is a physical address window that generates
PCI(e) IO cycles from normal memory cycles it isn't the only one.

I've used sparc cpu systems that have pcmcia card slots.
These are pretty much ISA and the drivers might expect to
access port 0x300 (etc) - certainly that would be right on x86.

In this case is isn't so much that the ISA_BUS depends on support
for in/out but that presence of the ISA bus provides the required
in/out support.

Now, maybe, the drivers should be using some ioremap variant and
then calling ioread8() rather than directly calling inb().
But that seems orthogonal to this changeset.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
  2022-05-03 12:45       ` [Intel-wired-lan] " Niklas Schnelle
  (?)
@ 2022-05-03 13:36         ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-03 13:36 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS,
	open list:AX.25 NETWORK LAYER

On Tue, 3 May 2022, Niklas Schnelle wrote:

> >  The driver works just fine with MMIO where available, so if `inb'/`outb' 
> > do get removed, then only parts that rely on port I/O need to be disabled.  
> > In fact there's already such provision there in drivers/net/fddi/defxx.c 
> > for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:
> > 
> > #if defined(CONFIG_EISA) || defined(CONFIG_PCI)
> > #define dfx_use_mmio bp->mmio
> > #else
> > #define dfx_use_mmio true
> > #endif
> > 
> > so I guess it's just the conditional that will have to be changed to:
> > 
> > #ifdef CONFIG_HAS_IOPORT
> > 
> > replacing the current explicit bus dependency list.  The compiler will 
> > then optimise away all the port I/O stuff (though I suspect dummy function 
> > declarations may be required for `inb'/`outb', etc.).
[...]
> With dfx_use_mmio changed as you propose above things compile on s390
> which previously ran into missing (now __compile_error()) inl() via
> dfx_port_read_long() -> dfx_inl() ->  inl().

 Great, thanks for checking!  And I note referring `__compile_error' is 
roughly equivalent to a dummy declaration, so you've got that part sorted.

> Looking at the other uses of dfx_use_mmio I notice however that in
> dfx_get_bars(), inb() actually gets called when dfx_use_mmio is true.
> This happens if dfx_bus_eisa is also true. Now that variable is just
> the cached result of DFX_BUS_EISA(dev) which is defined to 0 if
> CONFIG_EISA is unset. I'm not 100% sure if going through a local
> variable is still considered trivial enough dead code elimination, at
> least it works for me™. I did also check the GCC docs and they
> explicitly say that __attribute__(error) is supposed to be used when
> dead code elimination gets rid of the error paths.

 Yeah, dead code elimination is supposed to handle such cases.  The local
automatic variable is essentially a syntactic feature not to use the same 
expression inline over and over throughout a function (for clarity the 
variable should probably be declared `const', but that is not essential) 
and it is up to the compiler whether to reuse the value previously 
calculated or to re-evaluate the expression.

> I think we also need a "depends on HAS_IOPORT" for "config HAVE_EISA"
> just as I'm adding for "config ISA".

 Oh absolutely!  There's the slot-specific port I/O space that is used to 
identify EISA option cards in device discovery, so no EISA device will 
ever work without port I/O.  Have a look at `decode_eisa_sig' in 
drivers/eisa/eisa-bus.c for the very obvious code.  Note that some ISA 
cards can be configured to appear as EISA devices as well (I have a 3c509B 
Ethernet NIC set up that way).

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* [Intel-wired-lan] [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-05-03 13:36         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-03 13:36 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, 3 May 2022, Niklas Schnelle wrote:

> >  The driver works just fine with MMIO where available, so if `inb'/`outb' 
> > do get removed, then only parts that rely on port I/O need to be disabled.  
> > In fact there's already such provision there in drivers/net/fddi/defxx.c 
> > for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:
> > 
> > #if defined(CONFIG_EISA) || defined(CONFIG_PCI)
> > #define dfx_use_mmio bp->mmio
> > #else
> > #define dfx_use_mmio true
> > #endif
> > 
> > so I guess it's just the conditional that will have to be changed to:
> > 
> > #ifdef CONFIG_HAS_IOPORT
> > 
> > replacing the current explicit bus dependency list.  The compiler will 
> > then optimise away all the port I/O stuff (though I suspect dummy function 
> > declarations may be required for `inb'/`outb', etc.).
[...]
> With dfx_use_mmio changed as you propose above things compile on s390
> which previously ran into missing (now __compile_error()) inl() via
> dfx_port_read_long() -> dfx_inl() ->  inl().

 Great, thanks for checking!  And I note referring `__compile_error' is 
roughly equivalent to a dummy declaration, so you've got that part sorted.

> Looking at the other uses of dfx_use_mmio I notice however that in
> dfx_get_bars(), inb() actually gets called when dfx_use_mmio is true.
> This happens if dfx_bus_eisa is also true. Now that variable is just
> the cached result of DFX_BUS_EISA(dev) which is defined to 0 if
> CONFIG_EISA is unset. I'm not 100% sure if going through a local
> variable is still considered trivial enough dead code elimination, at
> least it works for me?. I did also check the GCC docs and they
> explicitly say that __attribute__(error) is supposed to be used when
> dead code elimination gets rid of the error paths.

 Yeah, dead code elimination is supposed to handle such cases.  The local
automatic variable is essentially a syntactic feature not to use the same 
expression inline over and over throughout a function (for clarity the 
variable should probably be declared `const', but that is not essential) 
and it is up to the compiler whether to reuse the value previously 
calculated or to re-evaluate the expression.

> I think we also need a "depends on HAS_IOPORT" for "config HAVE_EISA"
> just as I'm adding for "config ISA".

 Oh absolutely!  There's the slot-specific port I/O space that is used to 
identify EISA option cards in device discovery, so no EISA device will 
ever work without port I/O.  Have a look at `decode_eisa_sig' in 
drivers/eisa/eisa-bus.c for the very obvious code.  Note that some ISA 
cards can be configured to appear as EISA devices as well (I have a 3c509B 
Ethernet NIC set up that way).

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 21/39] net: add HAS_IOPORT dependencies
@ 2022-05-03 13:36         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-03 13:36 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Marc Kleine-Budde, Arnd Bergmann, David S. Miller,
	Jakub Kicinski, Paolo Abeni, Michael Grzeschik,
	Wolfgang Grandegger, Jesse Brandeburg, Tony Nguyen, Ralf Baechle,
	open list:NETWORKING DRIVERS, open list:CAN NETWORK DRIVERS,
	moderated list:INTEL ETHERNET DRIVERS, open

On Tue, 3 May 2022, Niklas Schnelle wrote:

> >  The driver works just fine with MMIO where available, so if `inb'/`outb' 
> > do get removed, then only parts that rely on port I/O need to be disabled.  
> > In fact there's already such provision there in drivers/net/fddi/defxx.c 
> > for TURBOchannel systems (CONFIG_TC), which have no port I/O space either:
> > 
> > #if defined(CONFIG_EISA) || defined(CONFIG_PCI)
> > #define dfx_use_mmio bp->mmio
> > #else
> > #define dfx_use_mmio true
> > #endif
> > 
> > so I guess it's just the conditional that will have to be changed to:
> > 
> > #ifdef CONFIG_HAS_IOPORT
> > 
> > replacing the current explicit bus dependency list.  The compiler will 
> > then optimise away all the port I/O stuff (though I suspect dummy function 
> > declarations may be required for `inb'/`outb', etc.).
[...]
> With dfx_use_mmio changed as you propose above things compile on s390
> which previously ran into missing (now __compile_error()) inl() via
> dfx_port_read_long() -> dfx_inl() ->  inl().

 Great, thanks for checking!  And I note referring `__compile_error' is 
roughly equivalent to a dummy declaration, so you've got that part sorted.

> Looking at the other uses of dfx_use_mmio I notice however that in
> dfx_get_bars(), inb() actually gets called when dfx_use_mmio is true.
> This happens if dfx_bus_eisa is also true. Now that variable is just
> the cached result of DFX_BUS_EISA(dev) which is defined to 0 if
> CONFIG_EISA is unset. I'm not 100% sure if going through a local
> variable is still considered trivial enough dead code elimination, at
> least it works for meâ„¢. I did also check the GCC docs and they
> explicitly say that __attribute__(error) is supposed to be used when
> dead code elimination gets rid of the error paths.

 Yeah, dead code elimination is supposed to handle such cases.  The local
automatic variable is essentially a syntactic feature not to use the same 
expression inline over and over throughout a function (for clarity the 
variable should probably be declared `const', but that is not essential) 
and it is up to the compiler whether to reuse the value previously 
calculated or to re-evaluate the expression.

> I think we also need a "depends on HAS_IOPORT" for "config HAVE_EISA"
> just as I'm adding for "config ISA".

 Oh absolutely!  There's the slot-specific port I/O space that is used to 
identify EISA option cards in device discovery, so no EISA device will 
ever work without port I/O.  Have a look at `decode_eisa_sig' in 
drivers/eisa/eisa-bus.c for the very obvious code.  Note that some ISA 
cards can be configured to appear as EISA devices as well (I have a 3c509B 
Ethernet NIC set up that way).

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-05-03 13:08           ` David Laight
@ 2022-05-03 14:03             ` William Breathitt Gray
  2022-05-04 11:46             ` Maciej W. Rozycki
  1 sibling, 0 replies; 392+ messages in thread
From: William Breathitt Gray @ 2022-05-03 14:03 UTC (permalink / raw)
  To: David Laight
  Cc: 'Linus Walleij',
	Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman, linux-kernel,
	linux-arch, linux-pci, Arnd Bergmann, Bartosz Golaszewski,
	open list:GPIO SUBSYSTEM

[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]

On Tue, May 03, 2022 at 01:08:04PM +0000, David Laight wrote:
> From: Linus Walleij
> > Sent: 01 May 2022 22:56
> > 
> > On Fri, Apr 29, 2022 at 5:37 PM William Breathitt Gray
> > <william.gray@linaro.org> wrote:
> > > On Fri, Apr 29, 2022 at 04:46:00PM +0200, Niklas Schnelle wrote:
> > 
> > > > Good question. As far as I can see most (all?) of these have "select
> > > > ISA_BUS_API" which is "def_bool ISA". Now "config ISA" seems to
> > > > currently be repeated in architectures and doesn't have an explicit
> > > > HAS_IOPORT dependency (it maybe should have one). But it does only make
> > > > sense on architectures with HAS_IOPORT set.
> > >
> > > There is such a thing as ISA DMA, but you'll still need to initialize
> > > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> > > "config ISA" is the right thing to do: all ISA devices are expected to
> > > communicate in some way via ioport.
> > 
> > Adding that dependency seems like the right solution to me.
> 
> I think it all depends on what HAS_IOPORT is meant to mean and
> how portable kernel binaries need to be.
> 
> x86 is (probably) the only architecture that actually has 'in'
> and 'out' instructions - but that doesn't mean that some other
> cpu (and I mean cpu+pcb not architecture) have the ability to
> generate 'IO' bus cycles on a specific physical bus.
> 
> While the obvious case is a physical address window that generates
> PCI(e) IO cycles from normal memory cycles it isn't the only one.
> 
> I've used sparc cpu systems that have pcmcia card slots.
> These are pretty much ISA and the drivers might expect to
> access port 0x300 (etc) - certainly that would be right on x86.
> 
> In this case is isn't so much that the ISA_BUS depends on support
> for in/out but that presence of the ISA bus provides the required
> in/out support.

That's true, it does seem somewhat backwards to have a depends on line
when the bus is really just providing the support for devices that want
to use it rather than requiring it. Do you think a HAVE_IOPORT line
should be added independently for each driver instead of adding it to
ISA_BUS?

> Now, maybe, the drivers should be using some ioremap variant and
> then calling ioread8() rather than directly calling inb().
> But that seems orthogonal to this changeset.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

Using ioremap() does have the benefit of making it easier to reuse the
code for some of these PC104 drivers with their PCI device variants; the
ioread8() calls and such can stay the same and we just initialize to the
proper address during probe. I plan to look into this in the future
then.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 25/39] pcmcia: " Niklas Schnelle
@ 2022-05-03 23:38   ` Bjorn Helgaas
  2022-05-04 10:33     ` Arnd Bergmann
  0 siblings, 1 reply; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-03 23:38 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Dominik Brodowski, Arnd Bergmann

On Fri, Apr 29, 2022 at 03:50:41PM +0200, Niklas Schnelle wrote:
> 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.
> 
> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Co-developed-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 2ce261cfff8e..32b5cd324c58 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 HAS_IOPORT

I don't know much about PC Card.  Is there a requirement that these
devices must use I/O port space?  If so, can you include a spec
reference in the commit log?

I do see the PC Card spec, r8.1, sec 5.5.4.2.2 says:

  All CardBus PC Card adapters must support either memory-mapped I/O
  or both memory-mapped I/O and I/O space. The selection will depend
  largely on the system architecture the adapter is intended to be
  used in. The requirement to also support memory-mapped I/O, if I/O
  space is supported, is driven by the potential emergence of
  memory-mapped I/O only cards. Supporting both modes may also
  position the adapter to be sold into multiple system architectures.

which sounds like I/O space is optional.

>  	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] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-03 23:38   ` Bjorn Helgaas
@ 2022-05-04 10:33     ` Arnd Bergmann
  2022-05-04 12:38       ` Maciej W. Rozycki
                         ` (2 more replies)
  0 siblings, 3 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 10:33 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Dominik Brodowski

On Wed, May 4, 2022 at 1:38 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Apr 29, 2022 at 03:50:41PM +0200, Niklas Schnelle wrote:
> > 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.
> >
> > Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> > Co-developed-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 2ce261cfff8e..32b5cd324c58 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 HAS_IOPORT
>
> I don't know much about PC Card.  Is there a requirement that these
> devices must use I/O port space?  If so, can you include a spec
> reference in the commit log?

I think for PCMCIA devices, the dependency makes sense because
all device drivers for PCMCIA devices need I/O ports.

For cardbus, we can go either way, I don't see any reference to
I/O ports in yenta_socket.c or the pccard core, so it would build
fine with or without I/O ports.

> I do see the PC Card spec, r8.1, sec 5.5.4.2.2 says:
>
>   All CardBus PC Card adapters must support either memory-mapped I/O
>   or both memory-mapped I/O and I/O space. The selection will depend
>   largely on the system architecture the adapter is intended to be
>   used in. The requirement to also support memory-mapped I/O, if I/O
>   space is supported, is driven by the potential emergence of
>   memory-mapped I/O only cards. Supporting both modes may also
>   position the adapter to be sold into multiple system architectures.
>
> which sounds like I/O space is optional.

An earlier version of the patch series had a separate
CONFIG_LEGACY_PCI that required CONFIG_HAS_IOPORT
here, which I think made this clearer:

Almost all architectures that support CONFIG_PCI also provide
HAS_IOPORT today (at least at compile time, if not at runtime),
with s390 as a notable exception. Any machines that have legacy
PCI device support will also have I/O ports because a lot of
legacy PCI cards used it, and any machine with a pc-card slot
should also support legacy PCI devices.

If we get new architectures without I/O space in the future, they
would certainly not care about supporting old cardbus devices.

        Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-05-03 13:08           ` David Laight
  2022-05-03 14:03             ` William Breathitt Gray
@ 2022-05-04 11:46             ` Maciej W. Rozycki
  2022-05-04 12:45               ` David Laight
  1 sibling, 1 reply; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-04 11:46 UTC (permalink / raw)
  To: David Laight
  Cc: 'Linus Walleij',
	William Breathitt Gray, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bartosz Golaszewski, open list:GPIO SUBSYSTEM

On Tue, 3 May 2022, David Laight wrote:

> > > There is such a thing as ISA DMA, but you'll still need to initialize
> > > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> > > "config ISA" is the right thing to do: all ISA devices are expected to
> > > communicate in some way via ioport.
> > 
> > Adding that dependency seems like the right solution to me.
> 
> I think it all depends on what HAS_IOPORT is meant to mean and
> how portable kernel binaries need to be.
> 
> x86 is (probably) the only architecture that actually has 'in'
> and 'out' instructions - but that doesn't mean that some other
> cpu (and I mean cpu+pcb not architecture) have the ability to
> generate 'IO' bus cycles on a specific physical bus.

 I am fairly sure IA-64 has some form of IN/OUT machine instructions too.

> While the obvious case is a physical address window that generates
> PCI(e) IO cycles from normal memory cycles it isn't the only one.
> 
> I've used sparc cpu systems that have pcmcia card slots.
> These are pretty much ISA and the drivers might expect to
> access port 0x300 (etc) - certainly that would be right on x86.
> 
> In this case is isn't so much that the ISA_BUS depends on support
> for in/out but that presence of the ISA bus provides the required
> in/out support.

 Well, one can implement a pluggable PCI/e expansion card with a PCI-ISA 
bridge on it and a backplane to plug ISA cards into.  Without support for 
issuing I/O cycles to PCI from the host however you won't be able to make 
use of the ISA backplane except maybe for some ancient ISA memory cards.  
So logically I think CONFIG_ISA should depend on CONFIG_HAS_IOPORT and 
CONFIG_HAS_IOPORT ought to be selected by platform configurations.

 ISTR there was a company that manufactured a USB-ISA option (providing an 
external ISA backplane).  We never supported it, but in principle if we 
wanted to, then it would be the USB-ISA device's driver config option that 
CONFIG_ISA would additionally depend on as an alternative.  That wouldn't 
enable CONFIG_HAS_IOPORT though because the presence of this particular 
USB-ISA device would not itself permit the use of I/O cycles with any 
PCI/e buses a machine might independently have, so devices for PCI/e 
options that require port I/O shouldn't be made available at the same 
time.

 I think that company might have actually manufactured a similar PCI-ISA 
option as well, but that I suppose did rely on support for I/O cycles on 
PCI.  Early 2000s BTW.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 10:33     ` Arnd Bergmann
@ 2022-05-04 12:38       ` Maciej W. Rozycki
  2022-05-04 14:07         ` Arnd Bergmann
  2022-05-04 14:44       ` David Laight
  2022-05-04 14:59       ` Niklas Schnelle
  2 siblings, 1 reply; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-04 12:38 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Wed, 4 May 2022, Arnd Bergmann wrote:

> Almost all architectures that support CONFIG_PCI also provide
> HAS_IOPORT today (at least at compile time, if not at runtime),
> with s390 as a notable exception. Any machines that have legacy
> PCI device support will also have I/O ports because a lot of
> legacy PCI cards used it, and any machine with a pc-card slot
> should also support legacy PCI devices.
> 
> If we get new architectures without I/O space in the future, they
> would certainly not care about supporting old cardbus devices.

 POWER9 is another architecture with no port I/O space[1]:

Table 3-2. PCIe TLP command summary
-----------+-----------------------------+-------------------------------
  Class    |           Type Name         |           Notes
===========+=============================+===============================
Completion | Completion without Data     | For PCI CFG Writes (nonposted)
           |                             | or for error responses.
Completion | Completion with Data        | CI load responses.
Nonposted  | Configuration Read Request  | Outbound only.
Nonposted  | Configuration Write Request | Outbound only.
Posted     | Message Request             | Inbound only.
Nonposted  | Memory Read Request         |
Posted     | Memory Write Request        |
===========+=============================+===============================
 1. All other valid PCIe command types are ignored and dropped.
 2. Invalid PCIe request command types will result in a completion
    response of Unsupported Request.
------------------------------------+------------------------------------

that we do support -- I have such a system.  And I guess POWER10 is the 
same, as will be all future architecture updates.

References:

[1] "Power Systems Host Bridge 4 (PHB4) Specification", Version 1.0, 
    International Business Machines Corporation, 27 July 2018, Section 3.1 
    "PHB4 Command Details", p.29

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-05-04 11:46             ` Maciej W. Rozycki
@ 2022-05-04 12:45               ` David Laight
  2022-05-04 13:02                 ` Maciej W. Rozycki
  0 siblings, 1 reply; 392+ messages in thread
From: David Laight @ 2022-05-04 12:45 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: 'Linus Walleij',
	William Breathitt Gray, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bartosz Golaszewski, open list:GPIO SUBSYSTEM

From: Maciej W. Rozycki
> Sent: 04 May 2022 12:47
> 
> On Tue, 3 May 2022, David Laight wrote:
> 
> > > > There is such a thing as ISA DMA, but you'll still need to initialize
> > > > the device via the IO Port bus first, so perhaps setting HAS_IOPORT for
> > > > "config ISA" is the right thing to do: all ISA devices are expected to
> > > > communicate in some way via ioport.
> > >
> > > Adding that dependency seems like the right solution to me.
> >
> > I think it all depends on what HAS_IOPORT is meant to mean and
> > how portable kernel binaries need to be.
> >
> > x86 is (probably) the only architecture that actually has 'in'
> > and 'out' instructions - but that doesn't mean that some other
> > cpu (and I mean cpu+pcb not architecture) have the ability to
> > generate 'IO' bus cycles on a specific physical bus.
> 
>  I am fairly sure IA-64 has some form of IN/OUT machine instructions too.
> 
> > While the obvious case is a physical address window that generates
> > PCI(e) IO cycles from normal memory cycles it isn't the only one.
> >
> > I've used sparc cpu systems that have pcmcia card slots.
> > These are pretty much ISA and the drivers might expect to
> > access port 0x300 (etc) - certainly that would be right on x86.
> >
> > In this case is isn't so much that the ISA_BUS depends on support
> > for in/out but that presence of the ISA bus provides the required
> > in/out support.
> 
>  Well, one can implement a pluggable PCI/e expansion card with a PCI-ISA
> bridge on it and a backplane to plug ISA cards into.  Without support for
> issuing I/O cycles to PCI from the host however you won't be able to make
> use of the ISA backplane except maybe for some ancient ISA memory cards.
> So logically I think CONFIG_ISA should depend on CONFIG_HAS_IOPORT and
> CONFIG_HAS_IOPORT ought to be selected by platform configurations.

But generating a PCI(e) I/O cycle doesn't need the cpu to be able to
generate an I/O cycle on its local bus interface.
All that required is for the PCI(e) host bridge to determine that it
needs to relevant kind of cycle on the target bus.
This can easily be based on the physical address.

Many years ago I used a system with the strongarm SA1100/1101 pair.
(Not running Linux, but I think that it could have - slowly.)
Two (adjacent?) areas of the physical address map generated memory
and I/O cycles to a pair of pcmcia slots.
What you end up with is definitely ISA, but ARM definitely doesn't
have in/out instructions.

Now, while this is rather hypothetical, a 'generic' arm kernel running
on that hardware would be able to support drivers that expect an ISA bus.
But on different hardware the same generic kernel would have nowhere
to 'attach' the same drivers - but they could still be part of the kernel
(maybe as modules).

What you should probably be doing is (outside of 'platform' code)
change the drivers to use ioread8() instead of inb().
Then adding in the required calls to get the correct 'token' to
pass to ioread8() to perform an I/O cycle on the correct target bus.

It is really the attachment of the driver that can't succeed, not the
compilation.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 10/39] gpio: add HAS_IOPORT dependencies
  2022-05-04 12:45               ` David Laight
@ 2022-05-04 13:02                 ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-04 13:02 UTC (permalink / raw)
  To: David Laight
  Cc: 'Linus Walleij',
	William Breathitt Gray, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, linux-kernel, linux-arch, linux-pci,
	Arnd Bergmann, Bartosz Golaszewski, open list:GPIO SUBSYSTEM

On Wed, 4 May 2022, David Laight wrote:

> >  Well, one can implement a pluggable PCI/e expansion card with a PCI-ISA
> > bridge on it and a backplane to plug ISA cards into.  Without support for
> > issuing I/O cycles to PCI from the host however you won't be able to make
> > use of the ISA backplane except maybe for some ancient ISA memory cards.
> > So logically I think CONFIG_ISA should depend on CONFIG_HAS_IOPORT and
> > CONFIG_HAS_IOPORT ought to be selected by platform configurations.
> 
> But generating a PCI(e) I/O cycle doesn't need the cpu to be able to
> generate an I/O cycle on its local bus interface.
> All that required is for the PCI(e) host bridge to determine that it
> needs to relevant kind of cycle on the target bus.
> This can easily be based on the physical address.

 Sure, you can encode address spaces however you like (there are no 
special machine instructions either for PCI/e configuration space access 
that I would know of in any CPU architecture), but the host bridge must be 
willing to issue those PCI/e I/O cycles in the first place (see my other 
message on POWER9 in this thread).

> What you should probably be doing is (outside of 'platform' code)
> change the drivers to use ioread8() instead of inb().
> Then adding in the required calls to get the correct 'token' to
> pass to ioread8() to perform an I/O cycle on the correct target bus.

 Yes, probably.

> It is really the attachment of the driver that can't succeed, not the
> compilation.

 Except it makes no sense to offer those drivers for platforms known not 
to provide for port I/O on PCI/e.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT
  2022-04-29 13:50 ` [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
@ 2022-05-04 13:23   ` Rafael J. Wysocki
  2022-05-04 17:53   ` Bjorn Helgaas
  1 sibling, 0 replies; 392+ messages in thread
From: Rafael J. Wysocki @ 2022-05-04 13:23 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, Linux PCI, Arnd Bergmann, Rafael J. Wysocki,
	open list:ACPI

On Fri, Apr 29, 2022 at 3: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. As ACPI always uses I/O port access we simply depend
> on HAS_IOPORT.
>
> Co-developed-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 1e34f846508f..8ad0d168004c 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,6 +5,7 @@
>
>  config ARCH_SUPPORTS_ACPI
>         bool
> +       depends on HAS_IOPORT

This and the analogous PNP change are both fine with me.

Thanks!

>
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
> --
> 2.32.0
>

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 12:38       ` Maciej W. Rozycki
@ 2022-05-04 14:07         ` Arnd Bergmann
  2022-05-04 14:24           ` Maciej W. Rozycki
  0 siblings, 1 reply; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 14:07 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Wed, May 4, 2022 at 2:38 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Wed, 4 May 2022, Arnd Bergmann wrote:
>
> > Almost all architectures that support CONFIG_PCI also provide
> > HAS_IOPORT today (at least at compile time, if not at runtime),
> > with s390 as a notable exception. Any machines that have legacy
> > PCI device support will also have I/O ports because a lot of
> > legacy PCI cards used it, and any machine with a pc-card slot
> > should also support legacy PCI devices.
> >
> > If we get new architectures without I/O space in the future, they
> > would certainly not care about supporting old cardbus devices.
>
>  POWER9 is another architecture with no port I/O space[1]:

POWER9 is just an implementation of the power architecture
that has a particular PCI host bridge. I would assume that
arch/powerpc/ would continue to set HAS_IOPORT because
it knows how to access I/O ports at compile-time.

If a particular host bridge does not declare an I/O port range
in its DT, then of course it won't be accessible, but that is
different from architectures that have no concept of I/O ports.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 14:07         ` Arnd Bergmann
@ 2022-05-04 14:24           ` Maciej W. Rozycki
  2022-05-04 17:22             ` Bjorn Helgaas
  0 siblings, 1 reply; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-04 14:24 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Wed, 4 May 2022, Arnd Bergmann wrote:

> >  POWER9 is another architecture with no port I/O space[1]:
> 
> POWER9 is just an implementation of the power architecture
> that has a particular PCI host bridge. I would assume that
> arch/powerpc/ would continue to set HAS_IOPORT because
> it knows how to access I/O ports at compile-time.

 Well, yes, except I would expect POWER9_CPU (and any higher versions we 
eventually get) to clear HAS_IOPORT.  Generic configurations (GENERIC_CPU) 
would set HAS_IOPORT of course, as would any lower architecture variants 
that do or may support port I/O (it's not clear to me if there are any 
that do not).  Ideally a generic configuration would not issue accesses to 
random MMIO locations for port I/O accesses via `inb'/`outb', etc. for 
systems that do not support port I/O (which it now does, or at least used 
to until recently).

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 10:33     ` Arnd Bergmann
  2022-05-04 12:38       ` Maciej W. Rozycki
@ 2022-05-04 14:44       ` David Laight
  2022-05-05 12:03         ` Maciej W. Rozycki
  2022-05-04 14:59       ` Niklas Schnelle
  2 siblings, 1 reply; 392+ messages in thread
From: David Laight @ 2022-05-04 14:44 UTC (permalink / raw)
  To: 'Arnd Bergmann', Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Dominik Brodowski

From: Arnd Bergmann
> Sent: 04 May 2022 11:33
> 
> On Wed, May 4, 2022 at 1:38 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:50:41PM +0200, Niklas Schnelle wrote:
> > > 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.
> > >
> > > Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> > > Co-developed-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 2ce261cfff8e..32b5cd324c58 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 HAS_IOPORT
> >
> > I don't know much about PC Card.  Is there a requirement that these
> > devices must use I/O port space?  If so, can you include a spec
> > reference in the commit log?
> 
> I think for PCMCIA devices, the dependency makes sense because
> all device drivers for PCMCIA devices need I/O ports.

ISTR some PCMCIA linear non-volatile memory cards that only
supported memory accesses.
I'm pretty sure some didn't even decode config space properly.
(I bet none of them still work after 25 years though.)

I've used I/O addresses on pcmcia cards from sparc and ARM cpu.

> For cardbus, we can go either way, I don't see any reference to
> I/O ports in yenta_socket.c or the pccard core, so it would build
> fine with or without I/O ports.

cardbus is basically PCI.
I think you can find cardbus cards that have a pci bridge and a cable
link to an expansion chassis into which you can insert standard PCI cards.
If you are really lucky the initial enumeration allocates the
'high field' bus numbers, io addresses and plenty of memory
space to the bridge - otherwise you lose.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 10:33     ` Arnd Bergmann
  2022-05-04 12:38       ` Maciej W. Rozycki
  2022-05-04 14:44       ` David Laight
@ 2022-05-04 14:59       ` Niklas Schnelle
  2 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-04 14:59 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Dominik Brodowski

On Wed, 2022-05-04 at 12:33 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 1:38 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:50:41PM +0200, Niklas Schnelle wrote:
> > > 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.
> > > 
> > > Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> > > Co-developed-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 2ce261cfff8e..32b5cd324c58 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 HAS_IOPORT
> > 
> > I don't know much about PC Card.  Is there a requirement that these
> > devices must use I/O port space?  If so, can you include a spec
> > reference in the commit log?
> 
> I think for PCMCIA devices, the dependency makes sense because
> all device drivers for PCMCIA devices need I/O ports.
> 
> For cardbus, we can go either way, I don't see any reference to
> I/O ports in yenta_socket.c or the pccard core, so it would build
> fine with or without I/O ports.
> 
> > I do see the PC Card spec, r8.1, sec 5.5.4.2.2 says:
> > 
> >   All CardBus PC Card adapters must support either memory-mapped I/O
> >   or both memory-mapped I/O and I/O space. The selection will depend
> >   largely on the system architecture the adapter is intended to be
> >   used in. The requirement to also support memory-mapped I/O, if I/O
> >   space is supported, is driven by the potential emergence of
> >   memory-mapped I/O only cards. Supporting both modes may also
> >   position the adapter to be sold into multiple system architectures.
> > 
> > which sounds like I/O space is optional.
> 
> An earlier version of the patch series had a separate
> CONFIG_LEGACY_PCI that required CONFIG_HAS_IOPORT
> here, which I think made this clearer:
> 
> Almost all architectures that support CONFIG_PCI also provide
> HAS_IOPORT today (at least at compile time, if not at runtime),
> with s390 as a notable exception. Any machines that have legacy
> PCI device support will also have I/O ports because a lot of
> legacy PCI cards used it, and any machine with a pc-card slot
> should also support legacy PCI devices.
> 
> If we get new architectures without I/O space in the future, they
> would certainly not care about supporting old cardbus devices.
> 
>         Arnd

I tested removing the HAS_IOPORT dependency on PCCARD thus ungating
PCMCIA and CARDBUS. This then requires about 30 additional HAS_IOPORT
dependencies to build my s390 allyesconfig.

The only exceptions I found that depends on PCMCIA and isn't otherwise
dependend on ISA or a specific platform are USB_SL811_CS and
PCMCIA_RAYCS (Aviator/Raytheon 2.4GHz wireless).

As for CARDBUS the only "depends on CARDBUS" is in
drivers/net/ethernet/dec/tulip/Kconfig. Now I tested with allyesconfig
which also sets CONFIG_TULIP_MMIO and with that the drivers there did
compile. I guess one should then have "select TULIP_MMIO if
!HAS_IOPORT" in the config NET_TULIP.

So not sure, it seems unlikely we're going to see any new
PCMCIA/CardBus device drivers added and that's a lot of churn for
compile testing so few drivers but in theory it looks like it is
possible to have non-I/O port PCMCIA/CardBus.

Thanks,
Niklas


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 14:24           ` Maciej W. Rozycki
@ 2022-05-04 17:22             ` Bjorn Helgaas
  2022-05-05  8:45               ` Maciej W. Rozycki
  0 siblings, 1 reply; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 17:22 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Wed, May 04, 2022 at 03:24:39PM +0100, Maciej W. Rozycki wrote:
> On Wed, 4 May 2022, Arnd Bergmann wrote:
> 
> > >  POWER9 is another architecture with no port I/O space[1]:
> > 
> > POWER9 is just an implementation of the power architecture
> > that has a particular PCI host bridge. I would assume that
> > arch/powerpc/ would continue to set HAS_IOPORT because
> > it knows how to access I/O ports at compile-time.
> 
>  Well, yes, except I would expect POWER9_CPU (and any higher versions we 
> eventually get) to clear HAS_IOPORT.  Generic configurations (GENERIC_CPU) 
> would set HAS_IOPORT of course, as would any lower architecture variants 
> that do or may support port I/O (it's not clear to me if there are any 
> that do not).  Ideally a generic configuration would not issue accesses to 
> random MMIO locations for port I/O accesses via `inb'/`outb', etc. for 
> systems that do not support port I/O (which it now does, or at least used 
> to until recently).

It would seem weird to me that a module would build and run on a
generic kernel running on POWER9 (with some safe way of handling
inb/outb that don't actually work), but not on a kernel built
specifically for POWER9_CPU.

It sounds like inb/outb in a generic kernel on POWER9 may not
currently do something sensible, but that's fixable, e.g., make inb()
return 0xff and outb() a no-op.  I would naively expect the same
behavior in a POWER9_CPU kernel.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT
  2022-04-29 13:50 ` [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
  2022-05-04 13:23   ` Rafael J. Wysocki
@ 2022-05-04 17:53   ` Bjorn Helgaas
  2022-05-04 19:58     ` Arnd Bergmann
  1 sibling, 1 reply; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 17:53 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Rafael J. Wysocki, open list:ACPI

On Fri, Apr 29, 2022 at 03:50:00PM +0200, Niklas Schnelle 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 we simply depend
> on HAS_IOPORT.

CONFIG_ACPI depends on ARCH_SUPPORTS_ACPI, which is only set by arm64,
ia64, and x86, all of which support I/O port access.  So does this
actually solve a problem?  I wouldn't think you'd be able to build
ACPI on s390 even without this patch.

"ACPI always uses I/O port access" is a pretty broad brush, and it
would be useful to know specifically what the dependencies are.

Many ACPI hardware accesses use acpi_hw_read()/acpi_hw_write(), which
use either MMIO or I/O port accesses depending on what the firmware
told us.

> Co-developed-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 1e34f846508f..8ad0d168004c 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -5,6 +5,7 @@
>  
>  config ARCH_SUPPORTS_ACPI
>  	bool
> +	depends on HAS_IOPORT
>  
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
> -- 
> 2.32.0
> 

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT
  2022-05-04 17:53   ` Bjorn Helgaas
@ 2022-05-04 19:58     ` Arnd Bergmann
  2022-05-05  8:20       ` Niklas Schnelle
  0 siblings, 1 reply; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 19:58 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Rafael J. Wysocki, open list:ACPI

On Wed, May 4, 2022 at 7:53 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:50:00PM +0200, Niklas Schnelle 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 we simply depend
> > on HAS_IOPORT.
>
> CONFIG_ACPI depends on ARCH_SUPPORTS_ACPI, which is only set by arm64,
> ia64, and x86, all of which support I/O port access.  So does this
> actually solve a problem?  I wouldn't think you'd be able to build
> ACPI on s390 even without this patch.
> "ACPI always uses I/O port access" is a pretty broad brush, and it
> would be useful to know specifically what the dependencies are.
>
> Many ACPI hardware accesses use acpi_hw_read()/acpi_hw_write(), which
> use either MMIO or I/O port accesses depending on what the firmware
> told us.

I think this came from my original prototype of the series where I tested it
out on arm64 with HAS_IOPORT disabled. I would like to hide the definition
of inb()/outb() from include/asm-generic/io.h whenever CONFIG_HAS_IOPORT
is not set, and I was prototyping this on arm64.

There are uses of inb()/outb() in drivers/acpi/ec.c and drivers/acpi/osl.c,
which in turn are not optional in ACPI, so it seems that those are
required.

If we want to allow building arm64 without HAS_IOPORT for some reason,
that means either force-disabling ACPI as well, or changin ACPI to not
rely on port I/O. I think it's fine to leave that as a problem for whoever
wants to make HAS_IOPORT optional in the future, and drop the
dependency here.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 30/39] scsi: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 30/39] scsi: " Niklas Schnelle
@ 2022-05-04 20:42   ` Bjorn Helgaas
  2022-05-04 21:34     ` Arnd Bergmann
  0 siblings, 1 reply; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 20:42 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, James E.J. Bottomley,
	Martin K. Petersen, Hannes Reinecke, Kashyap Desai, Sumit Saxena,
	Shivasharan S, Nilesh Javali,
	supporter:QLOGIC QLA2XXX FC-SCSI DRIVER,
	open list:SCSI SUBSYSTEM, open list:MEGARAID SCSI/SAS DRIVERS

On Fri, Apr 29, 2022 at 03:50:51PM +0200, 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.

Some of these drivers support devices using either I/O ports or MMIO.
Adding the HAS_IOPORT dependency means MMIO devices that *could* work
on systems without I/O ports, won't work.

Even the MMIO-only devices are probably old and not of much interest.
But if you want to disable them even though they *could* work, I think
that's worth mentioning in the commit log.

> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
>  config SCSI_IPS
>  	tristate "IBM ServeRAID support"
> -	depends on PCI && SCSI
> +	depends on PCI && HAS_IOPORT && SCSI

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/ips.c?id=v5.17#n6867

> diff --git a/drivers/scsi/aic7xxx/Kconfig.aic7xxx b/drivers/scsi/aic7xxx/Kconfig.aic7xxx
>  config SCSI_AIC94XX
>  	tristate "Adaptec AIC94xx SAS/SATA support"
> -	depends on PCI
> +	depends on PCI && HAS_IOPORT
>  	select SCSI_SAS_LIBSAS
>  	select FW_LOADER
>  	help

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/aic7xxx/aic79xx_osm_pci.c?id=v5.17#n304

> diff --git a/drivers/scsi/megaraid/Kconfig.megaraid b/drivers/scsi/megaraid/Kconfig.megaraid
>  config MEGARAID_LEGACY
>  	tristate "LSI Logic Legacy MegaRAID Driver"
> -	depends on PCI && SCSI
> +	depends on PCI && HAS_IOPORT && SCSI

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/megaraid.c?id=v5.17#n4190

> diff --git a/drivers/scsi/mvsas/Kconfig b/drivers/scsi/mvsas/Kconfig
>  config SCSI_MVSAS
>  	tristate "Marvell 88SE64XX/88SE94XX SAS/SATA support"
> -	depends on PCI
> +	depends on PCI && HAS_IOPORT
>  	select SCSI_SAS_LIBSAS
>  	select FW_LOADER
>  	help

This turns off all MVSAS support, but apparently only mv_64xx.c uses
I/O ports:

  git grep -E "\<(in|out)[bwl]\>" drivers/scsi/mvsas
  git grep -E "\<io[rw](8|16|32)\>" drivers/scsi/mvsas

It doesn't look like the Makefile is currently set up to build
mv_64xx.c separately.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-04-29 13:49   ` Niklas Schnelle
                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-04 21:08     ` Bjorn Helgaas
  -1 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 21:08 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. 

So you plan to drop inb()/outb() on architectures where I/O port space
is optional?  So even platforms that have I/O port space may not be
able to use it?

This feels like a lot of work where the main benefit is to keep
Kconfig from offering drivers that aren't of interest on s390.

Granted, there may be issues where inb()/outb() does the wrong thing
such as dereferencing null pointers when I/O port space isn't
implemented.  I think that's a defect in inb()/outb() and could be
fixed there.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:08     ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 21:08 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. 

So you plan to drop inb()/outb() on architectures where I/O port space
is optional?  So even platforms that have I/O port space may not be
able to use it?

This feels like a lot of work where the main benefit is to keep
Kconfig from offering drivers that aren't of interest on s390.

Granted, there may be issues where inb()/outb() does the wrong thing
such as dereferencing null pointers when I/O port space isn't
implemented.  I think that's a defect in inb()/outb() and could be
fixed there.

Bjorn

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:08     ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 21:08 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman, linux-kernel,
	Palmer Dabbelt, open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. 

So you plan to drop inb()/outb() on architectures where I/O port space
is optional?  So even platforms that have I/O port space may not be
able to use it?

This feels like a lot of work where the main benefit is to keep
Kconfig from offering drivers that aren't of interest on s390.

Granted, there may be issues where inb()/outb() does the wrong thing
such as dereferencing null pointers when I/O port space isn't
implemented.  I think that's a defect in inb()/outb() and could be
fixed there.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:08     ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 21:08 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. 

So you plan to drop inb()/outb() on architectures where I/O port space
is optional?  So even platforms that have I/O port space may not be
able to use it?

This feels like a lot of work where the main benefit is to keep
Kconfig from offering drivers that aren't of interest on s390.

Granted, there may be issues where inb()/outb() does the wrong thing
such as dereferencing null pointers when I/O port space isn't
implemented.  I think that's a defect in inb()/outb() and could be
fixed there.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:08     ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 21:08 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. 

So you plan to drop inb()/outb() on architectures where I/O port space
is optional?  So even platforms that have I/O port space may not be
able to use it?

This feels like a lot of work where the main benefit is to keep
Kconfig from offering drivers that aren't of interest on s390.

Granted, there may be issues where inb()/outb() does the wrong thing
such as dereferencing null pointers when I/O port space isn't
implemented.  I think that's a defect in inb()/outb() and could be
fixed there.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:08     ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-04 21:08 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt

On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully support legacy I/O spaces such as s390 or
> where such support is optional. 

So you plan to drop inb()/outb() on architectures where I/O port space
is optional?  So even platforms that have I/O port space may not be
able to use it?

This feels like a lot of work where the main benefit is to keep
Kconfig from offering drivers that aren't of interest on s390.

Granted, there may be issues where inb()/outb() does the wrong thing
such as dereferencing null pointers when I/O port space isn't
implemented.  I think that's a defect in inb()/outb() and could be
fixed there.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-04 21:08     ` Bjorn Helgaas
                         ` (3 preceding siblings ...)
  (?)
@ 2022-05-04 21:31       ` Arnd Bergmann
  -1 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor functions inb()/outb() and friends on architectures
> > which can not meaningfully support legacy I/O spaces such as s390 or
> > where such support is optional.
>
> So you plan to drop inb()/outb() on architectures where I/O port space
> is optional?  So even platforms that have I/O port space may not be
> able to use it?
>
> This feels like a lot of work where the main benefit is to keep
> Kconfig from offering drivers that aren't of interest on s390.
>
> Granted, there may be issues where inb()/outb() does the wrong thing
> such as dereferencing null pointers when I/O port space isn't
> implemented.  I think that's a defect in inb()/outb() and could be
> fixed there.

The current implementation in asm-generic/io.h implements inb()/outb()
using readb()/writeb() with a fixed architecture specific offset.

There are three possible things that can happen here:

a) there is a host bridge driver that maps its I/O ports to this window,
    and everything works
b) the address range is reserved and accessible but no host bridge
   driver has mapped its registers there, so an access causes a
   page fault
c) the architecture does not define an offset, and accessing low I/O
    ports ends up as a NULL pointer dereference

The main goal is to avoid c), which is what happens on s390, but
can also happen elsewhere. Catching b) would be nice as well,
but is much harder to do from generic code as you'd need an
architecture specific inline asm statement to insert a ex_table
fixup, or a runtime conditional on each access.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:31       ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor functions inb()/outb() and friends on architectures
> > which can not meaningfully support legacy I/O spaces such as s390 or
> > where such support is optional.
>
> So you plan to drop inb()/outb() on architectures where I/O port space
> is optional?  So even platforms that have I/O port space may not be
> able to use it?
>
> This feels like a lot of work where the main benefit is to keep
> Kconfig from offering drivers that aren't of interest on s390.
>
> Granted, there may be issues where inb()/outb() does the wrong thing
> such as dereferencing null pointers when I/O port space isn't
> implemented.  I think that's a defect in inb()/outb() and could be
> fixed there.

The current implementation in asm-generic/io.h implements inb()/outb()
using readb()/writeb() with a fixed architecture specific offset.

There are three possible things that can happen here:

a) there is a host bridge driver that maps its I/O ports to this window,
    and everything works
b) the address range is reserved and accessible but no host bridge
   driver has mapped its registers there, so an access causes a
   page fault
c) the architecture does not define an offset, and accessing low I/O
    ports ends up as a NULL pointer dereference

The main goal is to avoid c), which is what happens on s390, but
can also happen elsewhere. Catching b) would be nice as well,
but is much harder to do from generic code as you'd need an
architecture specific inline asm statement to insert a ex_table
fixup, or a runtime conditional on each access.

         Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:31       ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor functions inb()/outb() and friends on architectures
> > which can not meaningfully support legacy I/O spaces such as s390 or
> > where such support is optional.
>
> So you plan to drop inb()/outb() on architectures where I/O port space
> is optional?  So even platforms that have I/O port space may not be
> able to use it?
>
> This feels like a lot of work where the main benefit is to keep
> Kconfig from offering drivers that aren't of interest on s390.
>
> Granted, there may be issues where inb()/outb() does the wrong thing
> such as dereferencing null pointers when I/O port space isn't
> implemented.  I think that's a defect in inb()/outb() and could be
> fixed there.

The current implementation in asm-generic/io.h implements inb()/outb()
using readb()/writeb() with a fixed architecture specific offset.

There are three possible things that can happen here:

a) there is a host bridge driver that maps its I/O ports to this window,
    and everything works
b) the address range is reserved and accessible but no host bridge
   driver has mapped its registers there, so an access causes a
   page fault
c) the architecture does not define an offset, and accessing low I/O
    ports ends up as a NULL pointer dereference

The main goal is to avoid c), which is what happens on s390, but
can also happen elsewhere. Catching b) would be nice as well,
but is much harder to do from generic code as you'd need an
architecture specific inline asm statement to insert a ex_table
fixup, or a runtime conditional on each access.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:31       ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor functions inb()/outb() and friends on architectures
> > which can not meaningfully support legacy I/O spaces such as s390 or
> > where such support is optional.
>
> So you plan to drop inb()/outb() on architectures where I/O port space
> is optional?  So even platforms that have I/O port space may not be
> able to use it?
>
> This feels like a lot of work where the main benefit is to keep
> Kconfig from offering drivers that aren't of interest on s390.
>
> Granted, there may be issues where inb()/outb() does the wrong thing
> such as dereferencing null pointers when I/O port space isn't
> implemented.  I think that's a defect in inb()/outb() and could be
> fixed there.

The current implementation in asm-generic/io.h implements inb()/outb()
using readb()/writeb() with a fixed architecture specific offset.

There are three possible things that can happen here:

a) there is a host bridge driver that maps its I/O ports to this window,
    and everything works
b) the address range is reserved and accessible but no host bridge
   driver has mapped its registers there, so an access causes a
   page fault
c) the architecture does not define an offset, and accessing low I/O
    ports ends up as a NULL pointer dereference

The main goal is to avoid c), which is what happens on s390, but
can also happen elsewhere. Catching b) would be nice as well,
but is much harder to do from generic code as you'd need an
architecture specific inline asm statement to insert a ex_table
fixup, or a runtime conditional on each access.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:31       ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor functions inb()/outb() and friends on architectures
> > which can not meaningfully support legacy I/O spaces such as s390 or
> > where such support is optional.
>
> So you plan to drop inb()/outb() on architectures where I/O port space
> is optional?  So even platforms that have I/O port space may not be
> able to use it?
>
> This feels like a lot of work where the main benefit is to keep
> Kconfig from offering drivers that aren't of interest on s390.
>
> Granted, there may be issues where inb()/outb() does the wrong thing
> such as dereferencing null pointers when I/O port space isn't
> implemented.  I think that's a defect in inb()/outb() and could be
> fixed there.

The current implementation in asm-generic/io.h implements inb()/outb()
using readb()/writeb() with a fixed architecture specific offset.

There are three possible things that can happen here:

a) there is a host bridge driver that maps its I/O ports to this window,
    and everything works
b) the address range is reserved and accessible but no host bridge
   driver has mapped its registers there, so an access causes a
   page fault
c) the architecture does not define an offset, and accessing low I/O
    ports ends up as a NULL pointer dereference

The main goal is to avoid c), which is what happens on s390, but
can also happen elsewhere. Catching b) would be nice as well,
but is much harder to do from generic code as you'd need an
architecture specific inline asm statement to insert a ex_table
fixup, or a runtime conditional on each access.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-04 21:31       ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul

On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor functions inb()/outb() and friends on architectures
> > which can not meaningfully support legacy I/O spaces such as s390 or
> > where such support is optional.
>
> So you plan to drop inb()/outb() on architectures where I/O port space
> is optional?  So even platforms that have I/O port space may not be
> able to use it?
>
> This feels like a lot of work where the main benefit is to keep
> Kconfig from offering drivers that aren't of interest on s390.
>
> Granted, there may be issues where inb()/outb() does the wrong thing
> such as dereferencing null pointers when I/O port space isn't
> implemented.  I think that's a defect in inb()/outb() and could be
> fixed there.

The current implementation in asm-generic/io.h implements inb()/outb()
using readb()/writeb() with a fixed architecture specific offset.

There are three possible things that can happen here:

a) there is a host bridge driver that maps its I/O ports to this window,
    and everything works
b) the address range is reserved and accessible but no host bridge
   driver has mapped its registers there, so an access causes a
   page fault
c) the architecture does not define an offset, and accessing low I/O
    ports ends up as a NULL pointer dereference

The main goal is to avoid c), which is what happens on s390, but
can also happen elsewhere. Catching b) would be nice as well,
but is much harder to do from generic code as you'd need an
architecture specific inline asm statement to insert a ex_table
fixup, or a runtime conditional on each access.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 30/39] scsi: add HAS_IOPORT dependencies
  2022-05-04 20:42   ` Bjorn Helgaas
@ 2022-05-04 21:34     ` Arnd Bergmann
  2022-05-05 16:06       ` Bjorn Helgaas
  0 siblings, 1 reply; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-04 21:34 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
	Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
	supporter:QLOGIC QLA2XXX FC-SCSI DRIVER,
	open list:SCSI SUBSYSTEM, open list:MEGARAID SCSI/SAS DRIVERS

On Wed, May 4, 2022 at 10:42 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Apr 29, 2022 at 03:50:51PM +0200, 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.
>
> Some of these drivers support devices using either I/O ports or MMIO.
> Adding the HAS_IOPORT dependency means MMIO devices that *could* work
> on systems without I/O ports, won't work.
>
> Even the MMIO-only devices are probably old and not of much interest.
> But if you want to disable them even though they *could* work, I think
> that's worth mentioning in the commit log.

I think this would again make more sense with the original CONFIG_LEGACY_PCI
conditional than the generic HAS_IOPORT one. I don't remember what the
objection was to that symbol.

I think the presence of inb()/outb() is a good indication that a driver is for
obsolete hardware, though of course there are important exceptions to this
that instead need to have the conditional in the code itself (8250,
vga, ipmi, ...)

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-04 21:31       ` Arnd Bergmann
                           ` (3 preceding siblings ...)
  (?)
@ 2022-05-05  8:10         ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:10 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> > 
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> > 
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> > 
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.
> 
>          Arnd

Yes and to add to this, we did try a local solution in inb()/outb()
before. This added a warning when they are used and we know at compile
time that we're dealing with case c). This approach was nacked by Linus
though as we were turning a compile time known broken case into a
runtime one:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

I do agree with this assesment and think this is the right™ approach
but it is more churn as can be seen by the size of this series. I think
longer term it could be valuable though especially if more platforms
phase out I/O port support like POWER9 for which this also allows
filtering what drivers will never work.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05  8:10         ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:10 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> > 
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> > 
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> > 
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.
> 
>          Arnd

Yes and to add to this, we did try a local solution in inb()/outb()
before. This added a warning when they are used and we know at compile
time that we're dealing with case c). This approach was nacked by Linus
though as we were turning a compile time known broken case into a
runtime one:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

I do agree with this assesment and think this is the right™ approach
but it is more churn as can be seen by the size of this series. I think
longer term it could be valuable though especially if more platforms
phase out I/O port support like POWER9 for which this also allows
filtering what drivers will never work.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05  8:10         ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:10 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, open list:M68K ARCHITECTURE,
	Ivan Kokshaysky, Paul Walmsley, Thomas Gleixner,
	moderated list:ARM PORT, Richard Henderson, Michal Simek,
	Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> > 
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> > 
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> > 
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.
> 
>          Arnd

Yes and to add to this, we did try a local solution in inb()/outb()
before. This added a warning when they are used and we know at compile
time that we're dealing with case c). This approach was nacked by Linus
though as we were turning a compile time known broken case into a
runtime one:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

I do agree with this assesment and think this is the right™ approach
but it is more churn as can be seen by the size of this series. I think
longer term it could be valuable though especially if more platforms
phase out I/O port support like POWER9 for which this also allows
filtering what drivers will never work.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05  8:10         ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:10 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> > 
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> > 
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> > 
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.
> 
>          Arnd

Yes and to add to this, we did try a local solution in inb()/outb()
before. This added a warning when they are used and we know at compile
time that we're dealing with case c). This approach was nacked by Linus
though as we were turning a compile time known broken case into a
runtime one:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

I do agree with this assesment and think this is the right™ approach
but it is more churn as can be seen by the size of this series. I think
longer term it could be valuable though especially if more platforms
phase out I/O port support like POWER9 for which this also allows
filtering what drivers will never work.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05  8:10         ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:10 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> > 
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> > 
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> > 
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.
> 
>          Arnd

Yes and to add to this, we did try a local solution in inb()/outb()
before. This added a warning when they are used and we know at compile
time that we're dealing with case c). This approach was nacked by Linus
though as we were turning a compile time known broken case into a
runtime one:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

I do agree with this assesment and think this is the rightâ„¢ approach
but it is more churn as can be seen by the size of this series. I think
longer term it could be valuable though especially if more platforms
phase out I/O port support like POWER9 for which this also allows
filtering what drivers will never work.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05  8:10         ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:10 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt, A

On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> > 
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> > 
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> > 
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.
> 
>          Arnd

Yes and to add to this, we did try a local solution in inb()/outb()
before. This added a warning when they are used and we know at compile
time that we're dealing with case c). This approach was nacked by Linus
though as we were turning a compile time known broken case into a
runtime one:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

I do agree with this assesment and think this is the rightâ„¢ approach
but it is more churn as can be seen by the size of this series. I think
longer term it could be valuable though especially if more platforms
phase out I/O port support like POWER9 for which this also allows
filtering what drivers will never work.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT
  2022-05-04 19:58     ` Arnd Bergmann
@ 2022-05-05  8:20       ` Niklas Schnelle
  2022-05-05 19:36         ` Bjorn Helgaas
  0 siblings, 1 reply; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-05  8:20 UTC (permalink / raw)
  To: Arnd Bergmann, Bjorn Helgaas
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Rafael J. Wysocki, open list:ACPI

On Wed, 2022-05-04 at 21:58 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 7:53 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:50:00PM +0200, Niklas Schnelle 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 we simply depend
> > > on HAS_IOPORT.
> > 
> > CONFIG_ACPI depends on ARCH_SUPPORTS_ACPI, which is only set by arm64,
> > ia64, and x86, all of which support I/O port access.  So does this
> > actually solve a problem?  I wouldn't think you'd be able to build
> > ACPI on s390 even without this patch.
> > "ACPI always uses I/O port access" is a pretty broad brush, and it
> > would be useful to know specifically what the dependencies are.
> > 
> > Many ACPI hardware accesses use acpi_hw_read()/acpi_hw_write(), which
> > use either MMIO or I/O port accesses depending on what the firmware
> > told us.
> 
> I think this came from my original prototype of the series where I tested it
> out on arm64 with HAS_IOPORT disabled. I would like to hide the definition
> of inb()/outb() from include/asm-generic/io.h whenever CONFIG_HAS_IOPORT
> is not set, and I was prototyping this on arm64.
> 
> There are uses of inb()/outb() in drivers/acpi/ec.c and drivers/acpi/osl.c,
> which in turn are not optional in ACPI, so it seems that those are
> required.
> 
> If we want to allow building arm64 without HAS_IOPORT for some reason,
> that means either force-disabling ACPI as well, or changin ACPI to not
> rely on port I/O. I think it's fine to leave that as a problem for whoever
> wants to make HAS_IOPORT optional in the future, and drop the
> dependency here.
> 
>        Arnd

I'll improve the commit message to make the dependency on HAS_IOPORT
more clear. I also agree with Arnd that since all architectures where
ACPI is useful have I/O ports making it work without I/O port access
compiled in is for another day.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 17:22             ` Bjorn Helgaas
@ 2022-05-05  8:45               ` Maciej W. Rozycki
  2022-05-05 19:38                 ` Bjorn Helgaas
  0 siblings, 1 reply; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-05  8:45 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Wed, 4 May 2022, Bjorn Helgaas wrote:

> >  Well, yes, except I would expect POWER9_CPU (and any higher versions we 
> > eventually get) to clear HAS_IOPORT.  Generic configurations (GENERIC_CPU) 
> > would set HAS_IOPORT of course, as would any lower architecture variants 
> > that do or may support port I/O (it's not clear to me if there are any 
> > that do not).  Ideally a generic configuration would not issue accesses to 
> > random MMIO locations for port I/O accesses via `inb'/`outb', etc. for 
> > systems that do not support port I/O (which it now does, or at least used 
> > to until recently).
> 
> It would seem weird to me that a module would build and run on a
> generic kernel running on POWER9 (with some safe way of handling
> inb/outb that don't actually work), but not on a kernel built
> specifically for POWER9_CPU.

 Why?  If you say configure your Alpha kernel for ALPHA_JENSEN, a pure 
EISA system, then you won't get PCI support nor any PCI drivers offered 
even though a generic Alpha kernel will get them all and still run on a 
Jensen system.  I find that no different from our case here.

 And if we do ever get TURBOchannel Alpha support, then a generic kernel 
configuration will offer EISA, PCI and TURBOchannel drivers, while you 
won't be offered TURBOchannel drivers for a PCI system and vice versa.  
It would make no sense to me.

 Please mind that the main objective for system-specific configurations is 
optimisation, including both size and speed, and a part of the solution is 
discarding stuff that's irrelevant for the respective system.  So in our 
case we do want any port I/O code not to be there at all in compiled code 
and consequently any driver that absolutely requires port I/O code to work 
will have to become a useless stub in its compiled form.  What would be 
the point then of having it there in the first place except to spread 
confusion?

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-04 14:44       ` David Laight
@ 2022-05-05 12:03         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-05 12:03 UTC (permalink / raw)
  To: David Laight
  Cc: 'Arnd Bergmann',
	Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Wed, 4 May 2022, David Laight wrote:

> I think you can find cardbus cards that have a pci bridge and a cable
> link to an expansion chassis into which you can insert standard PCI cards.
> If you are really lucky the initial enumeration allocates the
> 'high field' bus numbers, io addresses and plenty of memory
> space to the bridge - otherwise you lose.

 No need to rely on luck as (given that no single size fits all) we have 
the `hpbussize', `hpiosize', `hpmemsize', `hpmmioprefsize', `hpmmiosize', 
options to the `pci=...' kernel parameter for people to tune the settings 
according to their needs.  I don't have such a CardBus option, but I do 
have a couple of such ExpressCard devices, and mixed PCIe/PCI expansion 
backplanes for them.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 30/39] scsi: add HAS_IOPORT dependencies
  2022-05-04 21:34     ` Arnd Bergmann
@ 2022-05-05 16:06       ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:06 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	James E.J. Bottomley, Martin K. Petersen, Hannes Reinecke,
	Kashyap Desai, Sumit Saxena, Shivasharan S, Nilesh Javali,
	supporter:QLOGIC QLA2XXX FC-SCSI DRIVER,
	open list:SCSI SUBSYSTEM, open list:MEGARAID SCSI/SAS DRIVERS

On Wed, May 04, 2022 at 11:34:48PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 10:42 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:50:51PM +0200, 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.
> >
> > Some of these drivers support devices using either I/O ports or MMIO.
> > Adding the HAS_IOPORT dependency means MMIO devices that *could* work
> > on systems without I/O ports, won't work.
> >
> > Even the MMIO-only devices are probably old and not of much interest.
> > But if you want to disable them even though they *could* work, I think
> > that's worth mentioning in the commit log.
> 
> I think this would again make more sense with the original CONFIG_LEGACY_PCI
> conditional than the generic HAS_IOPORT one. I don't remember what the
> objection was to that symbol.

I didn't really like CONFIG_LEGACY_PCI because it wasn't clearly
defined.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-04 21:31       ` Arnd Bergmann
                           ` (3 preceding siblings ...)
  (?)
@ 2022-05-05 16:10         ` Bjorn Helgaas
  -1 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 16:10         ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 16:10         ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 16:10         ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 16:10         ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 16:10         ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 16:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul

On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > > of the I/O accessor functions inb()/outb() and friends on architectures
> > > which can not meaningfully support legacy I/O spaces such as s390 or
> > > where such support is optional.
> >
> > So you plan to drop inb()/outb() on architectures where I/O port space
> > is optional?  So even platforms that have I/O port space may not be
> > able to use it?
> >
> > This feels like a lot of work where the main benefit is to keep
> > Kconfig from offering drivers that aren't of interest on s390.
> >
> > Granted, there may be issues where inb()/outb() does the wrong thing
> > such as dereferencing null pointers when I/O port space isn't
> > implemented.  I think that's a defect in inb()/outb() and could be
> > fixed there.
> 
> The current implementation in asm-generic/io.h implements inb()/outb()
> using readb()/writeb() with a fixed architecture specific offset.
> 
> There are three possible things that can happen here:
> 
> a) there is a host bridge driver that maps its I/O ports to this window,
>     and everything works
> b) the address range is reserved and accessible but no host bridge
>    driver has mapped its registers there, so an access causes a
>    page fault
> c) the architecture does not define an offset, and accessing low I/O
>     ports ends up as a NULL pointer dereference
> 
> The main goal is to avoid c), which is what happens on s390, but
> can also happen elsewhere. Catching b) would be nice as well,
> but is much harder to do from generic code as you'd need an
> architecture specific inline asm statement to insert a ex_table
> fixup, or a runtime conditional on each access.

Or s390 could implement its own inb().

I'm hearing that generic powerpc kernels have to run both on machines
that have I/O port space and those that don't.  That makes me think
s390 could do something similar.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-05 16:10         ` Bjorn Helgaas
                             ` (3 preceding siblings ...)
  (?)
@ 2022-05-05 17:39           ` Arnd Bergmann
  -1 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-05 17:39 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic code as you'd need an
> > architecture specific inline asm statement to insert a ex_table
> > fixup, or a runtime conditional on each access.
>
> Or s390 could implement its own inb().
>
> I'm hearing that generic powerpc kernels have to run both on machines
> that have I/O port space and those that don't.  That makes me think
> s390 could do something similar.

No, this is actually the current situation, and it makes absolutely no
sense. s390 has no way of implementing inb()/outb() because there
are no instructions for it and it cannot tunnel them through a virtual
address mapping like on most of the other architectures. (it has special
instructions for accessing memory space, which is not the same as
a pointer dereference here).

The existing implementation gets flagged as a NULL pointer dereference
by a compiler warning because it effectively is.

powerpc kernels generally map the I/O space into a section of the
physical address space, where it gets mapped into a fixed virtual
address and accessed through pointer dereference. This works on
any powerpc CPU as long as it is implemented in the PCI host
bridge in the usual way. The only difference between powerpc and
arm here is that there are fewer implementations, so one can
make assumptions about which PCI host bridge is used based on
a CPU core.

     Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 17:39           ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-05 17:39 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic code as you'd need an
> > architecture specific inline asm statement to insert a ex_table
> > fixup, or a runtime conditional on each access.
>
> Or s390 could implement its own inb().
>
> I'm hearing that generic powerpc kernels have to run both on machines
> that have I/O port space and those that don't.  That makes me think
> s390 could do something similar.

No, this is actually the current situation, and it makes absolutely no
sense. s390 has no way of implementing inb()/outb() because there
are no instructions for it and it cannot tunnel them through a virtual
address mapping like on most of the other architectures. (it has special
instructions for accessing memory space, which is not the same as
a pointer dereference here).

The existing implementation gets flagged as a NULL pointer dereference
by a compiler warning because it effectively is.

powerpc kernels generally map the I/O space into a section of the
physical address space, where it gets mapped into a fixed virtual
address and accessed through pointer dereference. This works on
any powerpc CPU as long as it is implemented in the PCI host
bridge in the usual way. The only difference between powerpc and
arm here is that there are fewer implementations, so one can
make assumptions about which PCI host bridge is used based on
a CPU core.

     Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 17:39           ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-05 17:39 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic code as you'd need an
> > architecture specific inline asm statement to insert a ex_table
> > fixup, or a runtime conditional on each access.
>
> Or s390 could implement its own inb().
>
> I'm hearing that generic powerpc kernels have to run both on machines
> that have I/O port space and those that don't.  That makes me think
> s390 could do something similar.

No, this is actually the current situation, and it makes absolutely no
sense. s390 has no way of implementing inb()/outb() because there
are no instructions for it and it cannot tunnel them through a virtual
address mapping like on most of the other architectures. (it has special
instructions for accessing memory space, which is not the same as
a pointer dereference here).

The existing implementation gets flagged as a NULL pointer dereference
by a compiler warning because it effectively is.

powerpc kernels generally map the I/O space into a section of the
physical address space, where it gets mapped into a fixed virtual
address and accessed through pointer dereference. This works on
any powerpc CPU as long as it is implemented in the PCI host
bridge in the usual way. The only difference between powerpc and
arm here is that there are fewer implementations, so one can
make assumptions about which PCI host bridge is used based on
a CPU core.

     Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 17:39           ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-05 17:39 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic code as you'd need an
> > architecture specific inline asm statement to insert a ex_table
> > fixup, or a runtime conditional on each access.
>
> Or s390 could implement its own inb().
>
> I'm hearing that generic powerpc kernels have to run both on machines
> that have I/O port space and those that don't.  That makes me think
> s390 could do something similar.

No, this is actually the current situation, and it makes absolutely no
sense. s390 has no way of implementing inb()/outb() because there
are no instructions for it and it cannot tunnel them through a virtual
address mapping like on most of the other architectures. (it has special
instructions for accessing memory space, which is not the same as
a pointer dereference here).

The existing implementation gets flagged as a NULL pointer dereference
by a compiler warning because it effectively is.

powerpc kernels generally map the I/O space into a section of the
physical address space, where it gets mapped into a fixed virtual
address and accessed through pointer dereference. This works on
any powerpc CPU as long as it is implemented in the PCI host
bridge in the usual way. The only difference between powerpc and
arm here is that there are fewer implementations, so one can
make assumptions about which PCI host bridge is used based on
a CPU core.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 17:39           ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-05 17:39 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic code as you'd need an
> > architecture specific inline asm statement to insert a ex_table
> > fixup, or a runtime conditional on each access.
>
> Or s390 could implement its own inb().
>
> I'm hearing that generic powerpc kernels have to run both on machines
> that have I/O port space and those that don't.  That makes me think
> s390 could do something similar.

No, this is actually the current situation, and it makes absolutely no
sense. s390 has no way of implementing inb()/outb() because there
are no instructions for it and it cannot tunnel them through a virtual
address mapping like on most of the other architectures. (it has special
instructions for accessing memory space, which is not the same as
a pointer dereference here).

The existing implementation gets flagged as a NULL pointer dereference
by a compiler warning because it effectively is.

powerpc kernels generally map the I/O space into a section of the
physical address space, where it gets mapped into a fixed virtual
address and accessed through pointer dereference. This works on
any powerpc CPU as long as it is implemented in the PCI host
bridge in the usual way. The only difference between powerpc and
arm here is that there are fewer implementations, so one can
make assumptions about which PCI host bridge is used based on
a CPU core.

     Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 17:39           ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-05 17:39 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul

On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic code as you'd need an
> > architecture specific inline asm statement to insert a ex_table
> > fixup, or a runtime conditional on each access.
>
> Or s390 could implement its own inb().
>
> I'm hearing that generic powerpc kernels have to run both on machines
> that have I/O port space and those that don't.  That makes me think
> s390 could do something similar.

No, this is actually the current situation, and it makes absolutely no
sense. s390 has no way of implementing inb()/outb() because there
are no instructions for it and it cannot tunnel them through a virtual
address mapping like on most of the other architectures. (it has special
instructions for accessing memory space, which is not the same as
a pointer dereference here).

The existing implementation gets flagged as a NULL pointer dereference
by a compiler warning because it effectively is.

powerpc kernels generally map the I/O space into a section of the
physical address space, where it gets mapped into a fixed virtual
address and accessed through pointer dereference. This works on
any powerpc CPU as long as it is implemented in the PCI host
bridge in the usual way. The only difference between powerpc and
arm here is that there are fewer implementations, so one can
make assumptions about which PCI host bridge is used based on
a CPU core.

     Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT
  2022-05-05  8:20       ` Niklas Schnelle
@ 2022-05-05 19:36         ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:36 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Rafael J. Wysocki, open list:ACPI

On Thu, May 05, 2022 at 10:20:28AM +0200, Niklas Schnelle wrote:
> On Wed, 2022-05-04 at 21:58 +0200, Arnd Bergmann wrote:
> > On Wed, May 4, 2022 at 7:53 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Fri, Apr 29, 2022 at 03:50:00PM +0200, Niklas Schnelle 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 we simply depend
> > > > on HAS_IOPORT.
> > > 
> > > CONFIG_ACPI depends on ARCH_SUPPORTS_ACPI, which is only set by arm64,
> > > ia64, and x86, all of which support I/O port access.  So does this
> > > actually solve a problem?  I wouldn't think you'd be able to build
> > > ACPI on s390 even without this patch.
> > > "ACPI always uses I/O port access" is a pretty broad brush, and it
> > > would be useful to know specifically what the dependencies are.
> > > 
> > > Many ACPI hardware accesses use acpi_hw_read()/acpi_hw_write(), which
> > > use either MMIO or I/O port accesses depending on what the firmware
> > > told us.
> > 
> > I think this came from my original prototype of the series where I tested it
> > out on arm64 with HAS_IOPORT disabled. I would like to hide the definition
> > of inb()/outb() from include/asm-generic/io.h whenever CONFIG_HAS_IOPORT
> > is not set, and I was prototyping this on arm64.
> > 
> > There are uses of inb()/outb() in drivers/acpi/ec.c and drivers/acpi/osl.c,
> > which in turn are not optional in ACPI, so it seems that those are
> > required.
> > 
> > If we want to allow building arm64 without HAS_IOPORT for some reason,
> > that means either force-disabling ACPI as well, or changin ACPI to not
> > rely on port I/O. I think it's fine to leave that as a problem for whoever
> > wants to make HAS_IOPORT optional in the future, and drop the
> > dependency here.
> 
> I'll improve the commit message to make the dependency on HAS_IOPORT
> more clear. I also agree with Arnd that since all architectures where
> ACPI is useful have I/O ports making it work without I/O port access
> compiled in is for another day.

I don't really see the point of including this patch at all.  It
doesn't solve any existing problem.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 25/39] pcmcia: add HAS_IOPORT dependencies
  2022-05-05  8:45               ` Maciej W. Rozycki
@ 2022-05-05 19:38                 ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:38 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Dominik Brodowski

On Thu, May 05, 2022 at 09:45:14AM +0100, Maciej W. Rozycki wrote:
> On Wed, 4 May 2022, Bjorn Helgaas wrote:
> 
> > >  Well, yes, except I would expect POWER9_CPU (and any higher versions we 
> > > eventually get) to clear HAS_IOPORT.  Generic configurations (GENERIC_CPU) 
> > > would set HAS_IOPORT of course, as would any lower architecture variants 
> > > that do or may support port I/O (it's not clear to me if there are any 
> > > that do not).  Ideally a generic configuration would not issue accesses to 
> > > random MMIO locations for port I/O accesses via `inb'/`outb', etc. for 
> > > systems that do not support port I/O (which it now does, or at least used 
> > > to until recently).
> > 
> > It would seem weird to me that a module would build and run on a
> > generic kernel running on POWER9 (with some safe way of handling
> > inb/outb that don't actually work), but not on a kernel built
> > specifically for POWER9_CPU.
> 
>  Why?  If you say configure your Alpha kernel for ALPHA_JENSEN, a pure 
> EISA system, then you won't get PCI support nor any PCI drivers offered 
> even though a generic Alpha kernel will get them all and still run on a 
> Jensen system.  I find that no different from our case here.
> 
>  And if we do ever get TURBOchannel Alpha support, then a generic kernel 
> configuration will offer EISA, PCI and TURBOchannel drivers, while you 
> won't be offered TURBOchannel drivers for a PCI system and vice versa.  
> It would make no sense to me.
> 
>  Please mind that the main objective for system-specific configurations is 
> optimisation, including both size and speed, and a part of the solution is 
> discarding stuff that's irrelevant for the respective system.  So in our 
> case we do want any port I/O code not to be there at all in compiled code 
> and consequently any driver that absolutely requires port I/O code to work 
> will have to become a useless stub in its compiled form.  What would be 
> the point then of having it there in the first place except to spread 
> confusion?

Good points.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-05 17:39           ` Arnd Bergmann
                               ` (3 preceding siblings ...)
  (?)
@ 2022-05-05 19:53             ` Bjorn Helgaas
  -1 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere. Catching b) would be nice as well,
> > > but is much harder to do from generic code as you'd need an
> > > architecture specific inline asm statement to insert a ex_table
> > > fixup, or a runtime conditional on each access.
> >
> > Or s390 could implement its own inb().
> >
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).
> 
> The existing implementation gets flagged as a NULL pointer dereference
> by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's
what happens on most arches when there's no device to respond to the
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
drivers that use I/O ports in some cases but not others.  But maybe
it's the most practical way.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 19:53             ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere. Catching b) would be nice as well,
> > > but is much harder to do from generic code as you'd need an
> > > architecture specific inline asm statement to insert a ex_table
> > > fixup, or a runtime conditional on each access.
> >
> > Or s390 could implement its own inb().
> >
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).
> 
> The existing implementation gets flagged as a NULL pointer dereference
> by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's
what happens on most arches when there's no device to respond to the
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
drivers that use I/O ports in some cases but not others.  But maybe
it's the most practical way.

Bjorn

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 19:53             ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere. Catching b) would be nice as well,
> > > but is much harder to do from generic code as you'd need an
> > > architecture specific inline asm statement to insert a ex_table
> > > fixup, or a runtime conditional on each access.
> >
> > Or s390 could implement its own inb().
> >
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).
> 
> The existing implementation gets flagged as a NULL pointer dereference
> by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's
what happens on most arches when there's no device to respond to the
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
drivers that use I/O ports in some cases but not others.  But maybe
it's the most practical way.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 19:53             ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere. Catching b) would be nice as well,
> > > but is much harder to do from generic code as you'd need an
> > > architecture specific inline asm statement to insert a ex_table
> > > fixup, or a runtime conditional on each access.
> >
> > Or s390 could implement its own inb().
> >
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).
> 
> The existing implementation gets flagged as a NULL pointer dereference
> by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's
what happens on most arches when there's no device to respond to the
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
drivers that use I/O ports in some cases but not others.  But maybe
it's the most practical way.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 19:53             ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere. Catching b) would be nice as well,
> > > but is much harder to do from generic code as you'd need an
> > > architecture specific inline asm statement to insert a ex_table
> > > fixup, or a runtime conditional on each access.
> >
> > Or s390 could implement its own inb().
> >
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).
> 
> The existing implementation gets flagged as a NULL pointer dereference
> by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's
what happens on most arches when there's no device to respond to the
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
drivers that use I/O ports in some cases but not others.  But maybe
it's the most practical way.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-05 19:53             ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 19:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul

On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere. Catching b) would be nice as well,
> > > but is much harder to do from generic code as you'd need an
> > > architecture specific inline asm statement to insert a ex_table
> > > fixup, or a runtime conditional on each access.
> >
> > Or s390 could implement its own inb().
> >
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).
> 
> The existing implementation gets flagged as a NULL pointer dereference
> by a compiler warning because it effectively is.

I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
"__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
dereference because the default PCI_IOBASE is 0.

I mooted a s390 inb() implementation like "return ~0" because that's
what happens on most arches when there's no device to respond to the
inb().

The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
drivers that use I/O ports in some cases but not others.  But maybe
it's the most practical way.

Bjorn

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
  2022-04-29 14:48   ` Niklas Schnelle
@ 2022-05-05 21:41   ` Bjorn Helgaas
  1 sibling, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 21:41 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Bjorn Helgaas

Capitalize "Make" in the subject to match previous drivers/pci
history.

On Fri, Apr 29, 2022 at 03:50:55PM +0200, 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.

This doesn't quite match what the patch does.  We still *add* the
sysfs files, it's just that reads/writes return error.

> Co-developed-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 c263ffc5884a..eda258fa4981 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1091,6 +1091,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)
> @@ -1149,6 +1150,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

I would move the #ifdef inside pci_resource_io().  Only need one
#ifdef and it's closer to the inb/outb.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT
  2022-04-29 13:50 ` [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
  2022-04-29 14:48   ` Niklas Schnelle
@ 2022-05-05 21:44   ` Bjorn Helgaas
  1 sibling, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-05-05 21:44 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Bjorn Helgaas

On Fri, Apr 29, 2022 at 03:50:57PM +0200, Niklas Schnelle wrote:
> In the future inw() and friends will not be compiled on architectures
> without I/O port support.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>

After capitalizing "Make" in the subject,

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index da829274fc66..27db2810f034 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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-05 19:53             ` Bjorn Helgaas
                                 ` (3 preceding siblings ...)
  (?)
@ 2022-05-06  9:12               ` Finn Thain
  -1 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-06  9:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > >
> > > Or s390 could implement its own inb().
> > >
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:12               ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-06  9:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > >
> > > Or s390 could implement its own inb().
> > >
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:12               ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-06  9:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > >
> > > Or s390 could implement its own inb().
> > >
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:12               ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-06  9:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > >
> > > Or s390 could implement its own inb().
> > >
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:12               ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-06  9:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Arnd Bergmann, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > >
> > > Or s390 could implement its own inb().
> > >
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:12               ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-06  9:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner



On Thu, 5 May 2022, Bjorn Helgaas wrote:

> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > >
> > > Or s390 could implement its own inb().
> > >
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 

Do you mean, "the most practical way to avoid a compiler warning on s390"? 
What about "#pragma GCC diagnostic ignored"?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-05 19:53             ` Bjorn Helgaas
                                 ` (3 preceding siblings ...)
  (?)
@ 2022-05-06  9:38               ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06  9:38 UTC (permalink / raw)
  To: Bjorn Helgaas, Arnd Bergmann, John Garry
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > > 
> > > Or s390 could implement its own inb().
> > > 
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 
> Bjorn

I fear such stubs are kind of equivalent to my previous patch doing the
same in asm-generic/io.h that was pulled and then unpulled by Linus.
Maybe it would be slightly different if instead of a warning outX()
would just be a NOP and inX() just returned ~0 but we're in essence
pretending that we have these functions when we know they are nonsense.

Another argument I see is that as shown by POWER9 we might start to see
more platforms that just can't do I/O port access. E.g. I would also be
surprised if Apple's M1 has I/O port access. Sooner or later I expect
distributions on some platforms to only support such systems. For
example on ppc a server distribution might only support IBM POWER
without I/O port support before too long. Then having HAS_IOPORT allows
to get rid of drivers that won't work anyway.

There are also reports of probing a driver with I/O ports causing a
system crash on systems without I/O port support. For example in this
answer by John Garry (added so he may supply more information):

https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:38               ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06  9:38 UTC (permalink / raw)
  To: Bjorn Helgaas, Arnd Bergmann, John Garry
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > > 
> > > Or s390 could implement its own inb().
> > > 
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 
> Bjorn

I fear such stubs are kind of equivalent to my previous patch doing the
same in asm-generic/io.h that was pulled and then unpulled by Linus.
Maybe it would be slightly different if instead of a warning outX()
would just be a NOP and inX() just returned ~0 but we're in essence
pretending that we have these functions when we know they are nonsense.

Another argument I see is that as shown by POWER9 we might start to see
more platforms that just can't do I/O port access. E.g. I would also be
surprised if Apple's M1 has I/O port access. Sooner or later I expect
distributions on some platforms to only support such systems. For
example on ppc a server distribution might only support IBM POWER
without I/O port support before too long. Then having HAS_IOPORT allows
to get rid of drivers that won't work anyway.

There are also reports of probing a driver with I/O ports causing a
system crash on systems without I/O port support. For example in this
answer by John Garry (added so he may supply more information):

https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:38               ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06  9:38 UTC (permalink / raw)
  To: Bjorn Helgaas, Arnd Bergmann, John Garry
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > > 
> > > Or s390 could implement its own inb().
> > > 
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 
> Bjorn

I fear such stubs are kind of equivalent to my previous patch doing the
same in asm-generic/io.h that was pulled and then unpulled by Linus.
Maybe it would be slightly different if instead of a warning outX()
would just be a NOP and inX() just returned ~0 but we're in essence
pretending that we have these functions when we know they are nonsense.

Another argument I see is that as shown by POWER9 we might start to see
more platforms that just can't do I/O port access. E.g. I would also be
surprised if Apple's M1 has I/O port access. Sooner or later I expect
distributions on some platforms to only support such systems. For
example on ppc a server distribution might only support IBM POWER
without I/O port support before too long. Then having HAS_IOPORT allows
to get rid of drivers that won't work anyway.

There are also reports of probing a driver with I/O ports causing a
system crash on systems without I/O port support. For example in this
answer by John Garry (added so he may supply more information):

https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:38               ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06  9:38 UTC (permalink / raw)
  To: Bjorn Helgaas, Arnd Bergmann, John Garry
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > > 
> > > Or s390 could implement its own inb().
> > > 
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 
> Bjorn

I fear such stubs are kind of equivalent to my previous patch doing the
same in asm-generic/io.h that was pulled and then unpulled by Linus.
Maybe it would be slightly different if instead of a warning outX()
would just be a NOP and inX() just returned ~0 but we're in essence
pretending that we have these functions when we know they are nonsense.

Another argument I see is that as shown by POWER9 we might start to see
more platforms that just can't do I/O port access. E.g. I would also be
surprised if Apple's M1 has I/O port access. Sooner or later I expect
distributions on some platforms to only support such systems. For
example on ppc a server distribution might only support IBM POWER
without I/O port support before too long. Then having HAS_IOPORT allows
to get rid of drivers that won't work anyway.

There are also reports of probing a driver with I/O ports causing a
system crash on systems without I/O port support. For example in this
answer by John Garry (added so he may supply more information):

https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:38               ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06  9:38 UTC (permalink / raw)
  To: Bjorn Helgaas, Arnd Bergmann, John Garry
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > > 
> > > Or s390 could implement its own inb().
> > > 
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 
> Bjorn

I fear such stubs are kind of equivalent to my previous patch doing the
same in asm-generic/io.h that was pulled and then unpulled by Linus.
Maybe it would be slightly different if instead of a warning outX()
would just be a NOP and inX() just returned ~0 but we're in essence
pretending that we have these functions when we know they are nonsense.

Another argument I see is that as shown by POWER9 we might start to see
more platforms that just can't do I/O port access. E.g. I would also be
surprised if Apple's M1 has I/O port access. Sooner or later I expect
distributions on some platforms to only support such systems. For
example on ppc a server distribution might only support IBM POWER
without I/O port support before too long. Then having HAS_IOPORT allows
to get rid of drivers that won't work anyway.

There are also reports of probing a driver with I/O ports causing a
system crash on systems without I/O port support. For example in this
answer by John Garry (added so he may supply more information):

https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06  9:38               ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06  9:38 UTC (permalink / raw)
  To: Bjorn Helgaas, Arnd Bergmann, John Garry
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner

On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what happens on s390, but
> > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > but is much harder to do from generic code as you'd need an
> > > > architecture specific inline asm statement to insert a ex_table
> > > > fixup, or a runtime conditional on each access.
> > > 
> > > Or s390 could implement its own inb().
> > > 
> > > I'm hearing that generic powerpc kernels have to run both on machines
> > > that have I/O port space and those that don't.  That makes me think
> > > s390 could do something similar.
> > 
> > No, this is actually the current situation, and it makes absolutely no
> > sense. s390 has no way of implementing inb()/outb() because there
> > are no instructions for it and it cannot tunnel them through a virtual
> > address mapping like on most of the other architectures. (it has special
> > instructions for accessing memory space, which is not the same as
> > a pointer dereference here).
> > 
> > The existing implementation gets flagged as a NULL pointer dereference
> > by a compiler warning because it effectively is.
> 
> I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> dereference because the default PCI_IOBASE is 0.
> 
> I mooted a s390 inb() implementation like "return ~0" because that's
> what happens on most arches when there's no device to respond to the
> inb().
> 
> The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> drivers that use I/O ports in some cases but not others.  But maybe
> it's the most practical way.
> 
> Bjorn

I fear such stubs are kind of equivalent to my previous patch doing the
same in asm-generic/io.h that was pulled and then unpulled by Linus.
Maybe it would be slightly different if instead of a warning outX()
would just be a NOP and inX() just returned ~0 but we're in essence
pretending that we have these functions when we know they are nonsense.

Another argument I see is that as shown by POWER9 we might start to see
more platforms that just can't do I/O port access. E.g. I would also be
surprised if Apple's M1 has I/O port access. Sooner or later I expect
distributions on some platforms to only support such systems. For
example on ppc a server distribution might only support IBM POWER
without I/O port support before too long. Then having HAS_IOPORT allows
to get rid of drivers that won't work anyway.

There are also reports of probing a driver with I/O ports causing a
system crash on systems without I/O port support. For example in this
answer by John Garry (added so he may supply more information):

https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-05 17:39           ` Arnd Bergmann
                               ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 10:20             ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 5 May 2022, Arnd Bergmann wrote:

> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).

 I think I'm missing something here.  IIUC we're talking about a PCI/PCIe 
bus used with s390 hardware, right?

 (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are 
only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles 
and EISA/ISA have long been obsoleted except perhaps from some niche use.)

 If this is PCI/PCIe indeed, then an I/O access is just a different bit 
pattern put on the bus/in the TLP in the address phase.  So what is there 
inherent to the s390 architecture that prevents that different bit pattern 
from being used?

 If anything, I could imagine the same limitation as with current POWER9 
implementations, that is whatever glue is used to wire PCI/PCIe to the 
rest of the system does not implement a way to use said bit pattern (which 
has nothing to do with the POWER9 processor instruction set).

 But that has nothing to do with the presence or absence of any specific 
processor instructions.  It's just a limitation of bus glue.  So I guess 
it's just that all PCI/PCIe glue logic implementations for s390 have such 
a limitation, right?

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 10:20             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 5 May 2022, Arnd Bergmann wrote:

> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).

 I think I'm missing something here.  IIUC we're talking about a PCI/PCIe 
bus used with s390 hardware, right?

 (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are 
only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles 
and EISA/ISA have long been obsoleted except perhaps from some niche use.)

 If this is PCI/PCIe indeed, then an I/O access is just a different bit 
pattern put on the bus/in the TLP in the address phase.  So what is there 
inherent to the s390 architecture that prevents that different bit pattern 
from being used?

 If anything, I could imagine the same limitation as with current POWER9 
implementations, that is whatever glue is used to wire PCI/PCIe to the 
rest of the system does not implement a way to use said bit pattern (which 
has nothing to do with the POWER9 processor instruction set).

 But that has nothing to do with the presence or absence of any specific 
processor instructions.  It's just a limitation of bus glue.  So I guess 
it's just that all PCI/PCIe glue logic implementations for s390 have such 
a limitation, right?

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 10:20             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Thu, 5 May 2022, Arnd Bergmann wrote:

> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).

 I think I'm missing something here.  IIUC we're talking about a PCI/PCIe 
bus used with s390 hardware, right?

 (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are 
only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles 
and EISA/ISA have long been obsoleted except perhaps from some niche use.)

 If this is PCI/PCIe indeed, then an I/O access is just a different bit 
pattern put on the bus/in the TLP in the address phase.  So what is there 
inherent to the s390 architecture that prevents that different bit pattern 
from being used?

 If anything, I could imagine the same limitation as with current POWER9 
implementations, that is whatever glue is used to wire PCI/PCIe to the 
rest of the system does not implement a way to use said bit pattern (which 
has nothing to do with the POWER9 processor instruction set).

 But that has nothing to do with the presence or absence of any specific 
processor instructions.  It's just a limitation of bus glue.  So I guess 
it's just that all PCI/PCIe glue logic implementations for s390 have such 
a limitation, right?

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 10:20             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 5 May 2022, Arnd Bergmann wrote:

> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).

 I think I'm missing something here.  IIUC we're talking about a PCI/PCIe 
bus used with s390 hardware, right?

 (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are 
only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles 
and EISA/ISA have long been obsoleted except perhaps from some niche use.)

 If this is PCI/PCIe indeed, then an I/O access is just a different bit 
pattern put on the bus/in the TLP in the address phase.  So what is there 
inherent to the s390 architecture that prevents that different bit pattern 
from being used?

 If anything, I could imagine the same limitation as with current POWER9 
implementations, that is whatever glue is used to wire PCI/PCIe to the 
rest of the system does not implement a way to use said bit pattern (which 
has nothing to do with the POWER9 processor instruction set).

 But that has nothing to do with the presence or absence of any specific 
processor instructions.  It's just a limitation of bus glue.  So I guess 
it's just that all PCI/PCIe glue logic implementations for s390 have such 
a limitation, right?

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 10:20             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Thu, 5 May 2022, Arnd Bergmann wrote:

> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).

 I think I'm missing something here.  IIUC we're talking about a PCI/PCIe 
bus used with s390 hardware, right?

 (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are 
only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles 
and EISA/ISA have long been obsoleted except perhaps from some niche use.)

 If this is PCI/PCIe indeed, then an I/O access is just a different bit 
pattern put on the bus/in the TLP in the address phase.  So what is there 
inherent to the s390 architecture that prevents that different bit pattern 
from being used?

 If anything, I could imagine the same limitation as with current POWER9 
implementations, that is whatever glue is used to wire PCI/PCIe to the 
rest of the system does not implement a way to use said bit pattern (which 
has nothing to do with the POWER9 processor instruction set).

 But that has nothing to do with the presence or absence of any specific 
processor instructions.  It's just a limitation of bus glue.  So I guess 
it's just that all PCI/PCIe glue logic implementations for s390 have such 
a limitation, right?

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 10:20             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael

On Thu, 5 May 2022, Arnd Bergmann wrote:

> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't.  That makes me think
> > s390 could do something similar.
> 
> No, this is actually the current situation, and it makes absolutely no
> sense. s390 has no way of implementing inb()/outb() because there
> are no instructions for it and it cannot tunnel them through a virtual
> address mapping like on most of the other architectures. (it has special
> instructions for accessing memory space, which is not the same as
> a pointer dereference here).

 I think I'm missing something here.  IIUC we're talking about a PCI/PCIe 
bus used with s390 hardware, right?

 (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are 
only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles 
and EISA/ISA have long been obsoleted except perhaps from some niche use.)

 If this is PCI/PCIe indeed, then an I/O access is just a different bit 
pattern put on the bus/in the TLP in the address phase.  So what is there 
inherent to the s390 architecture that prevents that different bit pattern 
from being used?

 If anything, I could imagine the same limitation as with current POWER9 
implementations, that is whatever glue is used to wire PCI/PCIe to the 
rest of the system does not implement a way to use said bit pattern (which 
has nothing to do with the POWER9 processor instruction set).

 But that has nothing to do with the presence or absence of any specific 
processor instructions.  It's just a limitation of bus glue.  So I guess 
it's just that all PCI/PCIe glue logic implementations for s390 have such 
a limitation, right?

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06  9:38               ` Niklas Schnelle
                                   ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 11:07                 ` John Garry
  -1 siblings, 0 replies; 392+ messages in thread
From: John Garry @ 2022-05-06 11:07 UTC (permalink / raw)
  To: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On 06/05/2022 10:38, Niklas Schnelle wrote:
> Another argument I see is that as shown by POWER9 we might start to see
> more platforms that just can't do I/O port access. E.g. I would also be
> surprised if Apple's M1 has I/O port access. Sooner or later I expect
> distributions on some platforms to only support such systems. For
> example on ppc a server distribution might only support IBM POWER
> without I/O port support before too long. Then having HAS_IOPORT allows
> to get rid of drivers that won't work anyway.
> 
> There are also reports of probing a driver with I/O ports causing a
> system crash on systems without I/O port support. For example in this
> answer by John Garry (added so he may supply more information):
> 
> https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/
> 
> .

That issue is that drivers like hwmon f71805f use inb/outb accessors 
with hardcoded IO port addresses to probe the driver. On archs like 
arm64 or powerpc - which do not natively support inb et al - this may 
crash the system when no PCI IO space is mapped [0]. Indeed, when PCI IO 
space is mapped, it is preferable these those drivers still would not 
access these ports.

So this series from Niklas could be used as a basis to solve that 
problem, in that we could also introduce something like HARDCODED_IOPORT 
[1] to stop those drivers being built at all for arm64.

[0] 
https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
[1] 
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/

Thanks,
John

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:07                 ` John Garry
  0 siblings, 0 replies; 392+ messages in thread
From: John Garry @ 2022-05-06 11:07 UTC (permalink / raw)
  To: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On 06/05/2022 10:38, Niklas Schnelle wrote:
> Another argument I see is that as shown by POWER9 we might start to see
> more platforms that just can't do I/O port access. E.g. I would also be
> surprised if Apple's M1 has I/O port access. Sooner or later I expect
> distributions on some platforms to only support such systems. For
> example on ppc a server distribution might only support IBM POWER
> without I/O port support before too long. Then having HAS_IOPORT allows
> to get rid of drivers that won't work anyway.
> 
> There are also reports of probing a driver with I/O ports causing a
> system crash on systems without I/O port support. For example in this
> answer by John Garry (added so he may supply more information):
> 
> https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/
> 
> .

That issue is that drivers like hwmon f71805f use inb/outb accessors 
with hardcoded IO port addresses to probe the driver. On archs like 
arm64 or powerpc - which do not natively support inb et al - this may 
crash the system when no PCI IO space is mapped [0]. Indeed, when PCI IO 
space is mapped, it is preferable these those drivers still would not 
access these ports.

So this series from Niklas could be used as a basis to solve that 
problem, in that we could also introduce something like HARDCODED_IOPORT 
[1] to stop those drivers being built at all for arm64.

[0] 
https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
[1] 
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/

Thanks,
John

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:07                 ` John Garry
  0 siblings, 0 replies; 392+ messages in thread
From: John Garry @ 2022-05-06 11:07 UTC (permalink / raw)
  To: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On 06/05/2022 10:38, Niklas Schnelle wrote:
> Another argument I see is that as shown by POWER9 we might start to see
> more platforms that just can't do I/O port access. E.g. I would also be
> surprised if Apple's M1 has I/O port access. Sooner or later I expect
> distributions on some platforms to only support such systems. For
> example on ppc a server distribution might only support IBM POWER
> without I/O port support before too long. Then having HAS_IOPORT allows
> to get rid of drivers that won't work anyway.
> 
> There are also reports of probing a driver with I/O ports causing a
> system crash on systems without I/O port support. For example in this
> answer by John Garry (added so he may supply more information):
> 
> https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/
> 
> .

That issue is that drivers like hwmon f71805f use inb/outb accessors 
with hardcoded IO port addresses to probe the driver. On archs like 
arm64 or powerpc - which do not natively support inb et al - this may 
crash the system when no PCI IO space is mapped [0]. Indeed, when PCI IO 
space is mapped, it is preferable these those drivers still would not 
access these ports.

So this series from Niklas could be used as a basis to solve that 
problem, in that we could also introduce something like HARDCODED_IOPORT 
[1] to stop those drivers being built at all for arm64.

[0] 
https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
[1] 
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/

Thanks,
John

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:07                 ` John Garry
  0 siblings, 0 replies; 392+ messages in thread
From: John Garry @ 2022-05-06 11:07 UTC (permalink / raw)
  To: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On 06/05/2022 10:38, Niklas Schnelle wrote:
> Another argument I see is that as shown by POWER9 we might start to see
> more platforms that just can't do I/O port access. E.g. I would also be
> surprised if Apple's M1 has I/O port access. Sooner or later I expect
> distributions on some platforms to only support such systems. For
> example on ppc a server distribution might only support IBM POWER
> without I/O port support before too long. Then having HAS_IOPORT allows
> to get rid of drivers that won't work anyway.
> 
> There are also reports of probing a driver with I/O ports causing a
> system crash on systems without I/O port support. For example in this
> answer by John Garry (added so he may supply more information):
> 
> https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/
> 
> .

That issue is that drivers like hwmon f71805f use inb/outb accessors 
with hardcoded IO port addresses to probe the driver. On archs like 
arm64 or powerpc - which do not natively support inb et al - this may 
crash the system when no PCI IO space is mapped [0]. Indeed, when PCI IO 
space is mapped, it is preferable these those drivers still would not 
access these ports.

So this series from Niklas could be used as a basis to solve that 
problem, in that we could also introduce something like HARDCODED_IOPORT 
[1] to stop those drivers being built at all for arm64.

[0] 
https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
[1] 
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/

Thanks,
John

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:07                 ` John Garry
  0 siblings, 0 replies; 392+ messages in thread
From: John Garry @ 2022-05-06 11:07 UTC (permalink / raw)
  To: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer Dabbelt, Albert Ou, Yoshinori Sato,
	Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On 06/05/2022 10:38, Niklas Schnelle wrote:
> Another argument I see is that as shown by POWER9 we might start to see
> more platforms that just can't do I/O port access. E.g. I would also be
> surprised if Apple's M1 has I/O port access. Sooner or later I expect
> distributions on some platforms to only support such systems. For
> example on ppc a server distribution might only support IBM POWER
> without I/O port support before too long. Then having HAS_IOPORT allows
> to get rid of drivers that won't work anyway.
> 
> There are also reports of probing a driver with I/O ports causing a
> system crash on systems without I/O port support. For example in this
> answer by John Garry (added so he may supply more information):
> 
> https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/
> 
> .

That issue is that drivers like hwmon f71805f use inb/outb accessors 
with hardcoded IO port addresses to probe the driver. On archs like 
arm64 or powerpc - which do not natively support inb et al - this may 
crash the system when no PCI IO space is mapped [0]. Indeed, when PCI IO 
space is mapped, it is preferable these those drivers still would not 
access these ports.

So this series from Niklas could be used as a basis to solve that 
problem, in that we could also introduce something like HARDCODED_IOPORT 
[1] to stop those drivers being built at all for arm64.

[0] 
https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
[1] 
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/

Thanks,
John

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:07                 ` John Garry
  0 siblings, 0 replies; 392+ messages in thread
From: John Garry @ 2022-05-06 11:07 UTC (permalink / raw)
  To: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Richard Henderson, Ivan Kokshaysky,
	Matt Turner, Russell King, Catalin Marinas, Will Deacon,
	Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer,
	James E.J. Bottomley, Helge Deller, Michael Ellerman,
	Paul Walmsley, Palmer

On 06/05/2022 10:38, Niklas Schnelle wrote:
> Another argument I see is that as shown by POWER9 we might start to see
> more platforms that just can't do I/O port access. E.g. I would also be
> surprised if Apple's M1 has I/O port access. Sooner or later I expect
> distributions on some platforms to only support such systems. For
> example on ppc a server distribution might only support IBM POWER
> without I/O port support before too long. Then having HAS_IOPORT allows
> to get rid of drivers that won't work anyway.
> 
> There are also reports of probing a driver with I/O ports causing a
> system crash on systems without I/O port support. For example in this
> answer by John Garry (added so he may supply more information):
> 
> https://lore.kernel.org/lkml/db043b76-880d-5fad-69cf-96abcd9cd34f@huawei.com/
> 
> .

That issue is that drivers like hwmon f71805f use inb/outb accessors 
with hardcoded IO port addresses to probe the driver. On archs like 
arm64 or powerpc - which do not natively support inb et al - this may 
crash the system when no PCI IO space is mapped [0]. Indeed, when PCI IO 
space is mapped, it is preferable these those drivers still would not 
access these ports.

So this series from Niklas could be used as a basis to solve that 
problem, in that we could also introduce something like HARDCODED_IOPORT 
[1] to stop those drivers being built at all for arm64.

[0] 
https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisilicon.com/T/#mf86445470160c44ac110e9d200b09245169dc5b6
[1] 
https://lore.kernel.org/lkml/CAK8P3a3HHeP+Gw_k2P7Qtig0OmErf0HN30G22+qHic_uZTh11Q@mail.gmail.com/

Thanks,
John

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06  9:12               ` Finn Thain
                                   ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 11:18                 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 11:18 UTC (permalink / raw)
  To: Finn Thain, Bjorn Helgaas
  Cc: Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> 
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
> 
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > The main goal is to avoid c), which is what happens on s390, but
> > > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > > but is much harder to do from generic code as you'd need an
> > > > > architecture specific inline asm statement to insert a ex_table
> > > > > fixup, or a runtime conditional on each access.
> > > > 
> > > > Or s390 could implement its own inb().
> > > > 
> > > > I'm hearing that generic powerpc kernels have to run both on machines
> > > > that have I/O port space and those that don't.  That makes me think
> > > > s390 could do something similar.
> > > 
> > > No, this is actually the current situation, and it makes absolutely no
> > > sense. s390 has no way of implementing inb()/outb() because there
> > > are no instructions for it and it cannot tunnel them through a virtual
> > > address mapping like on most of the other architectures. (it has special
> > > instructions for accessing memory space, which is not the same as
> > > a pointer dereference here).
> > > 
> > > The existing implementation gets flagged as a NULL pointer dereference
> > > by a compiler warning because it effectively is.
> > 
> > I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> > dereference because the default PCI_IOBASE is 0.
> > 
> > I mooted a s390 inb() implementation like "return ~0" because that's
> > what happens on most arches when there's no device to respond to the
> > inb().
> > 
> > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > drivers that use I/O ports in some cases but not others.  But maybe
> > it's the most practical way.
> > 
> 
> Do you mean, "the most practical way to avoid a compiler warning on s390"? 
> What about "#pragma GCC diagnostic ignored"?

This actually happens with clang. Apart from that, I think this would
also fall under the same argument as the original patch Linus unpulled.
We would just paint over someting that we know at compile time won't
work:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:18                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 11:18 UTC (permalink / raw)
  To: Finn Thain, Bjorn Helgaas
  Cc: Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> 
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
> 
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > The main goal is to avoid c), which is what happens on s390, but
> > > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > > but is much harder to do from generic code as you'd need an
> > > > > architecture specific inline asm statement to insert a ex_table
> > > > > fixup, or a runtime conditional on each access.
> > > > 
> > > > Or s390 could implement its own inb().
> > > > 
> > > > I'm hearing that generic powerpc kernels have to run both on machines
> > > > that have I/O port space and those that don't.  That makes me think
> > > > s390 could do something similar.
> > > 
> > > No, this is actually the current situation, and it makes absolutely no
> > > sense. s390 has no way of implementing inb()/outb() because there
> > > are no instructions for it and it cannot tunnel them through a virtual
> > > address mapping like on most of the other architectures. (it has special
> > > instructions for accessing memory space, which is not the same as
> > > a pointer dereference here).
> > > 
> > > The existing implementation gets flagged as a NULL pointer dereference
> > > by a compiler warning because it effectively is.
> > 
> > I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> > dereference because the default PCI_IOBASE is 0.
> > 
> > I mooted a s390 inb() implementation like "return ~0" because that's
> > what happens on most arches when there's no device to respond to the
> > inb().
> > 
> > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > drivers that use I/O ports in some cases but not others.  But maybe
> > it's the most practical way.
> > 
> 
> Do you mean, "the most practical way to avoid a compiler warning on s390"? 
> What about "#pragma GCC diagnostic ignored"?

This actually happens with clang. Apart from that, I think this would
also fall under the same argument as the original patch Linus unpulled.
We would just paint over someting that we know at compile time won't
work:

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:18                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 11:18 UTC (permalink / raw)
  To: Finn Thain, Bjorn Helgaas
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> 
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
> 
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > The main goal is to avoid c), which is what happens on s390, but
> > > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > > but is much harder to do from generic code as you'd need an
> > > > > architecture specific inline asm statement to insert a ex_table
> > > > > fixup, or a runtime conditional on each access.
> > > > 
> > > > Or s390 could implement its own inb().
> > > > 
> > > > I'm hearing that generic powerpc kernels have to run both on machines
> > > > that have I/O port space and those that don't.  That makes me think
> > > > s390 could do something similar.
> > > 
> > > No, this is actually the current situation, and it makes absolutely no
> > > sense. s390 has no way of implementing inb()/outb() because there
> > > are no instructions for it and it cannot tunnel them through a virtual
> > > address mapping like on most of the other architectures. (it has special
> > > instructions for accessing memory space, which is not the same as
> > > a pointer dereference here).
> > > 
> > > The existing implementation gets flagged as a NULL pointer dereference
> > > by a compiler warning because it effectively is.
> > 
> > I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> > dereference because the default PCI_IOBASE is 0.
> > 
> > I mooted a s390 inb() implementation like "return ~0" because that's
> > what happens on most arches when there's no device to respond to the
> > inb().
> > 
> > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > drivers that use I/O ports in some cases but not others.  But maybe
> > it's the most practical way.
> > 
> 
> Do you mean, "the most practical way to avoid a compiler warning on s390"? 
> What about "#pragma GCC diagnostic ignored"?

This actually happens with clang. Apart from that, I think this would
also fall under the same argument as the original patch Linus unpulled.
We would just paint over someting that we know at compile time won't
work:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:18                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 11:18 UTC (permalink / raw)
  To: Finn Thain, Bjorn Helgaas
  Cc: Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> 
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
> 
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > The main goal is to avoid c), which is what happens on s390, but
> > > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > > but is much harder to do from generic code as you'd need an
> > > > > architecture specific inline asm statement to insert a ex_table
> > > > > fixup, or a runtime conditional on each access.
> > > > 
> > > > Or s390 could implement its own inb().
> > > > 
> > > > I'm hearing that generic powerpc kernels have to run both on machines
> > > > that have I/O port space and those that don't.  That makes me think
> > > > s390 could do something similar.
> > > 
> > > No, this is actually the current situation, and it makes absolutely no
> > > sense. s390 has no way of implementing inb()/outb() because there
> > > are no instructions for it and it cannot tunnel them through a virtual
> > > address mapping like on most of the other architectures. (it has special
> > > instructions for accessing memory space, which is not the same as
> > > a pointer dereference here).
> > > 
> > > The existing implementation gets flagged as a NULL pointer dereference
> > > by a compiler warning because it effectively is.
> > 
> > I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> > dereference because the default PCI_IOBASE is 0.
> > 
> > I mooted a s390 inb() implementation like "return ~0" because that's
> > what happens on most arches when there's no device to respond to the
> > inb().
> > 
> > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > drivers that use I/O ports in some cases but not others.  But maybe
> > it's the most practical way.
> > 
> 
> Do you mean, "the most practical way to avoid a compiler warning on s390"? 
> What about "#pragma GCC diagnostic ignored"?

This actually happens with clang. Apart from that, I think this would
also fall under the same argument as the original patch Linus unpulled.
We would just paint over someting that we know at compile time won't
work:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:18                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 11:18 UTC (permalink / raw)
  To: Finn Thain, Bjorn Helgaas
  Cc: Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> 
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
> 
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > The main goal is to avoid c), which is what happens on s390, but
> > > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > > but is much harder to do from generic code as you'd need an
> > > > > architecture specific inline asm statement to insert a ex_table
> > > > > fixup, or a runtime conditional on each access.
> > > > 
> > > > Or s390 could implement its own inb().
> > > > 
> > > > I'm hearing that generic powerpc kernels have to run both on machines
> > > > that have I/O port space and those that don't.  That makes me think
> > > > s390 could do something similar.
> > > 
> > > No, this is actually the current situation, and it makes absolutely no
> > > sense. s390 has no way of implementing inb()/outb() because there
> > > are no instructions for it and it cannot tunnel them through a virtual
> > > address mapping like on most of the other architectures. (it has special
> > > instructions for accessing memory space, which is not the same as
> > > a pointer dereference here).
> > > 
> > > The existing implementation gets flagged as a NULL pointer dereference
> > > by a compiler warning because it effectively is.
> > 
> > I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> > dereference because the default PCI_IOBASE is 0.
> > 
> > I mooted a s390 inb() implementation like "return ~0" because that's
> > what happens on most arches when there's no device to respond to the
> > inb().
> > 
> > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > drivers that use I/O ports in some cases but not others.  But maybe
> > it's the most practical way.
> > 
> 
> Do you mean, "the most practical way to avoid a compiler warning on s390"? 
> What about "#pragma GCC diagnostic ignored"?

This actually happens with clang. Apart from that, I think this would
also fall under the same argument as the original patch Linus unpulled.
We would just paint over someting that we know at compile time won't
work:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:18                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 11:18 UTC (permalink / raw)
  To: Finn Thain, Bjorn Helgaas
  Cc: Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley

On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> 
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
> 
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > The main goal is to avoid c), which is what happens on s390, but
> > > > > can also happen elsewhere. Catching b) would be nice as well,
> > > > > but is much harder to do from generic code as you'd need an
> > > > > architecture specific inline asm statement to insert a ex_table
> > > > > fixup, or a runtime conditional on each access.
> > > > 
> > > > Or s390 could implement its own inb().
> > > > 
> > > > I'm hearing that generic powerpc kernels have to run both on machines
> > > > that have I/O port space and those that don't.  That makes me think
> > > > s390 could do something similar.
> > > 
> > > No, this is actually the current situation, and it makes absolutely no
> > > sense. s390 has no way of implementing inb()/outb() because there
> > > are no instructions for it and it cannot tunnel them through a virtual
> > > address mapping like on most of the other architectures. (it has special
> > > instructions for accessing memory space, which is not the same as
> > > a pointer dereference here).
> > > 
> > > The existing implementation gets flagged as a NULL pointer dereference
> > > by a compiler warning because it effectively is.
> > 
> > I think s390 currently uses the inb() in asm-generic/io.h, i.e.,
> > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL pointer
> > dereference because the default PCI_IOBASE is 0.
> > 
> > I mooted a s390 inb() implementation like "return ~0" because that's
> > what happens on most arches when there's no device to respond to the
> > inb().
> > 
> > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > drivers that use I/O ports in some cases but not others.  But maybe
> > it's the most practical way.
> > 
> 
> Do you mean, "the most practical way to avoid a compiler warning on s390"? 
> What about "#pragma GCC diagnostic ignored"?

This actually happens with clang. Apart from that, I think this would
also fall under the same argument as the original patch Linus unpulled.
We would just paint over someting that we know at compile time won't
work:

https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 10:20             ` Maciej W. Rozycki
                                 ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 11:33               ` Arnd Bergmann
  -1 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 11:33 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
>  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
>  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> and EISA/ISA have long been obsoleted except perhaps from some niche use.)
>
>  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> pattern put on the bus/in the TLP in the address phase.  So what is there
> inherent to the s390 architecture that prevents that different bit pattern
> from being used?

The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.

>  If anything, I could imagine the same limitation as with current POWER9
> implementations, that is whatever glue is used to wire PCI/PCIe to the
> rest of the system does not implement a way to use said bit pattern (which
> has nothing to do with the POWER9 processor instruction set).
>
>  But that has nothing to do with the presence or absence of any specific
> processor instructions.  It's just a limitation of bus glue.  So I guess
> it's just that all PCI/PCIe glue logic implementations for s390 have such
> a limitation, right?

There are separate instructions for PCI memory and config space, but
no instructions for I/O space, or for non-PCI MMIO that it could be mapped
into.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:33               ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 11:33 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
>  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
>  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> and EISA/ISA have long been obsoleted except perhaps from some niche use.)
>
>  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> pattern put on the bus/in the TLP in the address phase.  So what is there
> inherent to the s390 architecture that prevents that different bit pattern
> from being used?

The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.

>  If anything, I could imagine the same limitation as with current POWER9
> implementations, that is whatever glue is used to wire PCI/PCIe to the
> rest of the system does not implement a way to use said bit pattern (which
> has nothing to do with the POWER9 processor instruction set).
>
>  But that has nothing to do with the presence or absence of any specific
> processor instructions.  It's just a limitation of bus glue.  So I guess
> it's just that all PCI/PCIe glue logic implementations for s390 have such
> a limitation, right?

There are separate instructions for PCI memory and config space, but
no instructions for I/O space, or for non-PCI MMIO that it could be mapped
into.

       Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:33               ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 11:33 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
>  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
>  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> and EISA/ISA have long been obsoleted except perhaps from some niche use.)
>
>  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> pattern put on the bus/in the TLP in the address phase.  So what is there
> inherent to the s390 architecture that prevents that different bit pattern
> from being used?

The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.

>  If anything, I could imagine the same limitation as with current POWER9
> implementations, that is whatever glue is used to wire PCI/PCIe to the
> rest of the system does not implement a way to use said bit pattern (which
> has nothing to do with the POWER9 processor instruction set).
>
>  But that has nothing to do with the presence or absence of any specific
> processor instructions.  It's just a limitation of bus glue.  So I guess
> it's just that all PCI/PCIe glue logic implementations for s390 have such
> a limitation, right?

There are separate instructions for PCI memory and config space, but
no instructions for I/O space, or for non-PCI MMIO that it could be mapped
into.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:33               ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 11:33 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
>  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
>  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> and EISA/ISA have long been obsoleted except perhaps from some niche use.)
>
>  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> pattern put on the bus/in the TLP in the address phase.  So what is there
> inherent to the s390 architecture that prevents that different bit pattern
> from being used?

The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.

>  If anything, I could imagine the same limitation as with current POWER9
> implementations, that is whatever glue is used to wire PCI/PCIe to the
> rest of the system does not implement a way to use said bit pattern (which
> has nothing to do with the POWER9 processor instruction set).
>
>  But that has nothing to do with the presence or absence of any specific
> processor instructions.  It's just a limitation of bus glue.  So I guess
> it's just that all PCI/PCIe glue logic implementations for s390 have such
> a limitation, right?

There are separate instructions for PCI memory and config space, but
no instructions for I/O space, or for non-PCI MMIO that it could be mapped
into.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:33               ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 11:33 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
>  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
>  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> and EISA/ISA have long been obsoleted except perhaps from some niche use.)
>
>  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> pattern put on the bus/in the TLP in the address phase.  So what is there
> inherent to the s390 architecture that prevents that different bit pattern
> from being used?

The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.

>  If anything, I could imagine the same limitation as with current POWER9
> implementations, that is whatever glue is used to wire PCI/PCIe to the
> rest of the system does not implement a way to use said bit pattern (which
> has nothing to do with the POWER9 processor instruction set).
>
>  But that has nothing to do with the presence or absence of any specific
> processor instructions.  It's just a limitation of bus glue.  So I guess
> it's just that all PCI/PCIe glue logic implementations for s390 have such
> a limitation, right?

There are separate instructions for PCI memory and config space, but
no instructions for I/O space, or for non-PCI MMIO that it could be mapped
into.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 11:33               ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 11:33 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael

On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
>  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
>  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> and EISA/ISA have long been obsoleted except perhaps from some niche use.)
>
>  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> pattern put on the bus/in the TLP in the address phase.  So what is there
> inherent to the s390 architecture that prevents that different bit pattern
> from being used?

The hardware design for PCI on s390 is very different from any other
architecture, and more abstract. Rather than implementing MMIO register
access as pointer dereference, this is a separate CPU instruction that
takes a device/bar plus offset as arguments rather than a pointer, and
Linux encodes this back into a fake __iomem token.

>  If anything, I could imagine the same limitation as with current POWER9
> implementations, that is whatever glue is used to wire PCI/PCIe to the
> rest of the system does not implement a way to use said bit pattern (which
> has nothing to do with the POWER9 processor instruction set).
>
>  But that has nothing to do with the presence or absence of any specific
> processor instructions.  It's just a limitation of bus glue.  So I guess
> it's just that all PCI/PCIe glue logic implementations for s390 have such
> a limitation, right?

There are separate instructions for PCI memory and config space, but
no instructions for I/O space, or for non-PCI MMIO that it could be mapped
into.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 11:33               ` Arnd Bergmann
                                   ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 12:27                 ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 12:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

 OK, that seems to me like a reasonable and quite a clean design (on the 
hardware side).

 So what happens if the instruction is given an I/O rather than memory BAR 
as the relevant argument?  Is the address space indicator bit (bit #0) 
simply ignored or what?

> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.

 The PCI configuration space was retrofitted into x86 systems (and is 
accessed in an awkward manner with them), but with a new design such a 
clean approach is most welcome IMHO.  Thank you for your explanation.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:27                 ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 12:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

 OK, that seems to me like a reasonable and quite a clean design (on the 
hardware side).

 So what happens if the instruction is given an I/O rather than memory BAR 
as the relevant argument?  Is the address space indicator bit (bit #0) 
simply ignored or what?

> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.

 The PCI configuration space was retrofitted into x86 systems (and is 
accessed in an awkward manner with them), but with a new design such a 
clean approach is most welcome IMHO.  Thank you for your explanation.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:27                 ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 12:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

 OK, that seems to me like a reasonable and quite a clean design (on the 
hardware side).

 So what happens if the instruction is given an I/O rather than memory BAR 
as the relevant argument?  Is the address space indicator bit (bit #0) 
simply ignored or what?

> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.

 The PCI configuration space was retrofitted into x86 systems (and is 
accessed in an awkward manner with them), but with a new design such a 
clean approach is most welcome IMHO.  Thank you for your explanation.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:27                 ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 12:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

 OK, that seems to me like a reasonable and quite a clean design (on the 
hardware side).

 So what happens if the instruction is given an I/O rather than memory BAR 
as the relevant argument?  Is the address space indicator bit (bit #0) 
simply ignored or what?

> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.

 The PCI configuration space was retrofitted into x86 systems (and is 
accessed in an awkward manner with them), but with a new design such a 
clean approach is most welcome IMHO.  Thank you for your explanation.

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:27                 ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 12:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

 OK, that seems to me like a reasonable and quite a clean design (on the 
hardware side).

 So what happens if the instruction is given an I/O rather than memory BAR 
as the relevant argument?  Is the address space indicator bit (bit #0) 
simply ignored or what?

> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.

 The PCI configuration space was retrofitted into x86 systems (and is 
accessed in an awkward manner with them), but with a new design such a 
clean approach is most welcome IMHO.  Thank you for your explanation.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:27                 ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 12:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

 OK, that seems to me like a reasonable and quite a clean design (on the 
hardware side).

 So what happens if the instruction is given an I/O rather than memory BAR 
as the relevant argument?  Is the address space indicator bit (bit #0) 
simply ignored or what?

> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.

 The PCI configuration space was retrofitted into x86 systems (and is 
accessed in an awkward manner with them), but with a new design such a 
clean approach is most welcome IMHO.  Thank you for your explanation.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 11:33               ` Arnd Bergmann
                                   ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 12:42                 ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:42 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> >  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> > 
> >  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> > only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> > and EISA/ISA have long been obsoleted except perhaps from some niche use.)
> > 
> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

Correct, we have since gained new PCI load/store instructions that
actually do take a virtual address that gets address translated to a
"physical address" for the PCI BARs. The "physical address" we get from
the platform (again via special instructions). I put "physical address"
in quotes because while they are conceptually physical addresses and
they are translated to by MMU translation tables, accessing their
virtual mapping with any instruction other then the special PCI
load/store instructions will cause addressing exceptions. So we still
don't have real MMIO but something that looks a lot more like MMIO than
we used to.

> 
> >  If anything, I could imagine the same limitation as with current POWER9
> > implementations, that is whatever glue is used to wire PCI/PCIe to the
> > rest of the system does not implement a way to use said bit pattern (which
> > has nothing to do with the POWER9 processor instruction set).
> > 
> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.
> 
>        Arnd

The config space is still accessed with the old style PCI load/store
instructions via a special extra BAR.

But yes overall on s390x we can only access PCI(e) devices via special
instructions not via real MMIO and also the OS has no direct access to
the registers of the PHB which are only accessible to firmware. 

Maybe as a bit of further background it's also important to note that
on s390x all Operating Systems run inside a hypervisor. On the lowest
level any OS can run this is a non-paging machine level hypervisor. For
PCI that means that we always have a kind of pass-through access though
without paging and hardware support for the memory partitioning this is
of course relatively simple.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:42                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:42 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> >  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> > 
> >  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> > only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> > and EISA/ISA have long been obsoleted except perhaps from some niche use.)
> > 
> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

Correct, we have since gained new PCI load/store instructions that
actually do take a virtual address that gets address translated to a
"physical address" for the PCI BARs. The "physical address" we get from
the platform (again via special instructions). I put "physical address"
in quotes because while they are conceptually physical addresses and
they are translated to by MMU translation tables, accessing their
virtual mapping with any instruction other then the special PCI
load/store instructions will cause addressing exceptions. So we still
don't have real MMIO but something that looks a lot more like MMIO than
we used to.

> 
> >  If anything, I could imagine the same limitation as with current POWER9
> > implementations, that is whatever glue is used to wire PCI/PCIe to the
> > rest of the system does not implement a way to use said bit pattern (which
> > has nothing to do with the POWER9 processor instruction set).
> > 
> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.
> 
>        Arnd

The config space is still accessed with the old style PCI load/store
instructions via a special extra BAR.

But yes overall on s390x we can only access PCI(e) devices via special
instructions not via real MMIO and also the OS has no direct access to
the registers of the PHB which are only accessible to firmware. 

Maybe as a bit of further background it's also important to note that
on s390x all Operating Systems run inside a hypervisor. On the lowest
level any OS can run this is a non-paging machine level hypervisor. For
PCI that means that we always have a kind of pass-through access though
without paging and hardware support for the memory partitioning this is
of course relatively simple.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:42                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:42 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> >  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> > 
> >  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> > only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> > and EISA/ISA have long been obsoleted except perhaps from some niche use.)
> > 
> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

Correct, we have since gained new PCI load/store instructions that
actually do take a virtual address that gets address translated to a
"physical address" for the PCI BARs. The "physical address" we get from
the platform (again via special instructions). I put "physical address"
in quotes because while they are conceptually physical addresses and
they are translated to by MMU translation tables, accessing their
virtual mapping with any instruction other then the special PCI
load/store instructions will cause addressing exceptions. So we still
don't have real MMIO but something that looks a lot more like MMIO than
we used to.

> 
> >  If anything, I could imagine the same limitation as with current POWER9
> > implementations, that is whatever glue is used to wire PCI/PCIe to the
> > rest of the system does not implement a way to use said bit pattern (which
> > has nothing to do with the POWER9 processor instruction set).
> > 
> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.
> 
>        Arnd

The config space is still accessed with the old style PCI load/store
instructions via a special extra BAR.

But yes overall on s390x we can only access PCI(e) devices via special
instructions not via real MMIO and also the OS has no direct access to
the registers of the PHB which are only accessible to firmware. 

Maybe as a bit of further background it's also important to note that
on s390x all Operating Systems run inside a hypervisor. On the lowest
level any OS can run this is a non-paging machine level hypervisor. For
PCI that means that we always have a kind of pass-through access though
without paging and hardware support for the memory partitioning this is
of course relatively simple.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:42                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:42 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> >  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> > 
> >  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> > only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> > and EISA/ISA have long been obsoleted except perhaps from some niche use.)
> > 
> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

Correct, we have since gained new PCI load/store instructions that
actually do take a virtual address that gets address translated to a
"physical address" for the PCI BARs. The "physical address" we get from
the platform (again via special instructions). I put "physical address"
in quotes because while they are conceptually physical addresses and
they are translated to by MMU translation tables, accessing their
virtual mapping with any instruction other then the special PCI
load/store instructions will cause addressing exceptions. So we still
don't have real MMIO but something that looks a lot more like MMIO than
we used to.

> 
> >  If anything, I could imagine the same limitation as with current POWER9
> > implementations, that is whatever glue is used to wire PCI/PCIe to the
> > rest of the system does not implement a way to use said bit pattern (which
> > has nothing to do with the POWER9 processor instruction set).
> > 
> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.
> 
>        Arnd

The config space is still accessed with the old style PCI load/store
instructions via a special extra BAR.

But yes overall on s390x we can only access PCI(e) devices via special
instructions not via real MMIO and also the OS has no direct access to
the registers of the PHB which are only accessible to firmware. 

Maybe as a bit of further background it's also important to note that
on s390x all Operating Systems run inside a hypervisor. On the lowest
level any OS can run this is a non-paging machine level hypervisor. For
PCI that means that we always have a kind of pass-through access though
without paging and hardware support for the memory partitioning this is
of course relatively simple.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:42                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:42 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> >  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> > 
> >  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> > only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> > and EISA/ISA have long been obsoleted except perhaps from some niche use.)
> > 
> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

Correct, we have since gained new PCI load/store instructions that
actually do take a virtual address that gets address translated to a
"physical address" for the PCI BARs. The "physical address" we get from
the platform (again via special instructions). I put "physical address"
in quotes because while they are conceptually physical addresses and
they are translated to by MMU translation tables, accessing their
virtual mapping with any instruction other then the special PCI
load/store instructions will cause addressing exceptions. So we still
don't have real MMIO but something that looks a lot more like MMIO than
we used to.

> 
> >  If anything, I could imagine the same limitation as with current POWER9
> > implementations, that is whatever glue is used to wire PCI/PCIe to the
> > rest of the system does not implement a way to use said bit pattern (which
> > has nothing to do with the POWER9 processor instruction set).
> > 
> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.
> 
>        Arnd

The config space is still accessed with the old style PCI load/store
instructions via a special extra BAR.

But yes overall on s390x we can only access PCI(e) devices via special
instructions not via real MMIO and also the OS has no direct access to
the registers of the PHB which are only accessible to firmware. 

Maybe as a bit of further background it's also important to note that
on s390x all Operating Systems run inside a hypervisor. On the lowest
level any OS can run this is a non-paging machine level hypervisor. For
PCI that means that we always have a kind of pass-through access though
without paging and hardware support for the memory partitioning this is
of course relatively simple.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:42                 ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:42 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley

On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> >  I think I'm missing something here.  IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> > 
> >  (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
> > only PCI/PCIe and EISA/ISA buses out there that define I/O access cycles
> > and EISA/ISA have long been obsoleted except perhaps from some niche use.)
> > 
> >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase.  So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
> 
> The hardware design for PCI on s390 is very different from any other
> architecture, and more abstract. Rather than implementing MMIO register
> access as pointer dereference, this is a separate CPU instruction that
> takes a device/bar plus offset as arguments rather than a pointer, and
> Linux encodes this back into a fake __iomem token.

Correct, we have since gained new PCI load/store instructions that
actually do take a virtual address that gets address translated to a
"physical address" for the PCI BARs. The "physical address" we get from
the platform (again via special instructions). I put "physical address"
in quotes because while they are conceptually physical addresses and
they are translated to by MMU translation tables, accessing their
virtual mapping with any instruction other then the special PCI
load/store instructions will cause addressing exceptions. So we still
don't have real MMIO but something that looks a lot more like MMIO than
we used to.

> 
> >  If anything, I could imagine the same limitation as with current POWER9
> > implementations, that is whatever glue is used to wire PCI/PCIe to the
> > rest of the system does not implement a way to use said bit pattern (which
> > has nothing to do with the POWER9 processor instruction set).
> > 
> >  But that has nothing to do with the presence or absence of any specific
> > processor instructions.  It's just a limitation of bus glue.  So I guess
> > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > a limitation, right?
> 
> There are separate instructions for PCI memory and config space, but
> no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> into.
> 
>        Arnd

The config space is still accessed with the old style PCI load/store
instructions via a special extra BAR.

But yes overall on s390x we can only access PCI(e) devices via special
instructions not via real MMIO and also the OS has no direct access to
the registers of the PHB which are only accessible to firmware. 

Maybe as a bit of further background it's also important to note that
on s390x all Operating Systems run inside a hypervisor. On the lowest
level any OS can run this is a non-paging machine level hypervisor. For
PCI that means that we always have a kind of pass-through access though
without paging and hardware support for the memory partitioning this is
of course relatively simple.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:27                 ` Maciej W. Rozycki
                                     ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 12:53                   ` David Laight
  -1 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 12:53 UTC (permalink / raw)
  To: 'Maciej W. Rozycki', Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
> 
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

You don't understand something...

For a memory BAR pci_ioremap() returns a token that can be used with readl().
On most architectures readl() is just a memory access.
This all fails on an I/O BAR.

For an I/O BAR you want a similar pair of functions.
On x86 the access function would need to use the 'in/out' instructions but
there is no requirement for the token to be the native io port number.
On many non-x86 architectures the access function would be a simple memory
access - but a specific system (eg many ppc) may never actually allow
such mappings to succeed.

You might also want a third PCI mapping function that can map a memory
BAR or an I/O BAR - with a suitable access function.
On x86 this would need something like ioread8() for accesses.
Except that function uses small integers for io port numbers
(which is inherently dangerous).

Nothing except the architecture specific implementation of the function
to access an io BAR would ever go near a function called inb().

The same is really true for other bus type - including ISA and EISA.
(Ignoring the horrid of probing ISI bus devices - hopefully they
are in the ACPI tables??_
If a driver is probed on a ISA bus there ought to be functions
equivalent to pci_ioremap() (for both memory and IO addresses)
that return tokens appropriate for the specific bus.

That is all a different load of churn.


> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> >
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is
> accessed in an awkward manner with them), but with a new design such a
> clean approach is most welcome IMHO.  Thank you for your explanation.

Actually I think x86 was the initial system for PCI.
The PCI config space 'mess' is all about trying to make
something that wouldn't break existing memory maps.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 12:53 UTC (permalink / raw)
  To: 'Maciej W. Rozycki', Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
> 
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

You don't understand something...

For a memory BAR pci_ioremap() returns a token that can be used with readl().
On most architectures readl() is just a memory access.
This all fails on an I/O BAR.

For an I/O BAR you want a similar pair of functions.
On x86 the access function would need to use the 'in/out' instructions but
there is no requirement for the token to be the native io port number.
On many non-x86 architectures the access function would be a simple memory
access - but a specific system (eg many ppc) may never actually allow
such mappings to succeed.

You might also want a third PCI mapping function that can map a memory
BAR or an I/O BAR - with a suitable access function.
On x86 this would need something like ioread8() for accesses.
Except that function uses small integers for io port numbers
(which is inherently dangerous).

Nothing except the architecture specific implementation of the function
to access an io BAR would ever go near a function called inb().

The same is really true for other bus type - including ISA and EISA.
(Ignoring the horrid of probing ISI bus devices - hopefully they
are in the ACPI tables??_
If a driver is probed on a ISA bus there ought to be functions
equivalent to pci_ioremap() (for both memory and IO addresses)
that return tokens appropriate for the specific bus.

That is all a different load of churn.


> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> >
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is
> accessed in an awkward manner with them), but with a new design such a
> clean approach is most welcome IMHO.  Thank you for your explanation.

Actually I think x86 was the initial system for PCI.
The PCI config space 'mess' is all about trying to make
something that wouldn't break existing memory maps.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 12:53 UTC (permalink / raw)
  To: 'Maciej W. Rozycki', Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
> 
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

You don't understand something...

For a memory BAR pci_ioremap() returns a token that can be used with readl().
On most architectures readl() is just a memory access.
This all fails on an I/O BAR.

For an I/O BAR you want a similar pair of functions.
On x86 the access function would need to use the 'in/out' instructions but
there is no requirement for the token to be the native io port number.
On many non-x86 architectures the access function would be a simple memory
access - but a specific system (eg many ppc) may never actually allow
such mappings to succeed.

You might also want a third PCI mapping function that can map a memory
BAR or an I/O BAR - with a suitable access function.
On x86 this would need something like ioread8() for accesses.
Except that function uses small integers for io port numbers
(which is inherently dangerous).

Nothing except the architecture specific implementation of the function
to access an io BAR would ever go near a function called inb().

The same is really true for other bus type - including ISA and EISA.
(Ignoring the horrid of probing ISI bus devices - hopefully they
are in the ACPI tables??_
If a driver is probed on a ISA bus there ought to be functions
equivalent to pci_ioremap() (for both memory and IO addresses)
that return tokens appropriate for the specific bus.

That is all a different load of churn.


> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> >
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is
> accessed in an awkward manner with them), but with a new design such a
> clean approach is most welcome IMHO.  Thank you for your explanation.

Actually I think x86 was the initial system for PCI.
The PCI config space 'mess' is all about trying to make
something that wouldn't break existing memory maps.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 12:53 UTC (permalink / raw)
  To: 'Maciej W. Rozycki', Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
> 
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

You don't understand something...

For a memory BAR pci_ioremap() returns a token that can be used with readl().
On most architectures readl() is just a memory access.
This all fails on an I/O BAR.

For an I/O BAR you want a similar pair of functions.
On x86 the access function would need to use the 'in/out' instructions but
there is no requirement for the token to be the native io port number.
On many non-x86 architectures the access function would be a simple memory
access - but a specific system (eg many ppc) may never actually allow
such mappings to succeed.

You might also want a third PCI mapping function that can map a memory
BAR or an I/O BAR - with a suitable access function.
On x86 this would need something like ioread8() for accesses.
Except that function uses small integers for io port numbers
(which is inherently dangerous).

Nothing except the architecture specific implementation of the function
to access an io BAR would ever go near a function called inb().

The same is really true for other bus type - including ISA and EISA.
(Ignoring the horrid of probing ISI bus devices - hopefully they
are in the ACPI tables??_
If a driver is probed on a ISA bus there ought to be functions
equivalent to pci_ioremap() (for both memory and IO addresses)
that return tokens appropriate for the specific bus.

That is all a different load of churn.


> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> >
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is
> accessed in an awkward manner with them), but with a new design such a
> clean approach is most welcome IMHO.  Thank you for your explanation.

Actually I think x86 was the initial system for PCI.
The PCI config space 'mess' is all about trying to make
something that wouldn't break existing memory maps.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 12:53 UTC (permalink / raw)
  To: 'Maciej W. Rozycki', Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
> 
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

You don't understand something...

For a memory BAR pci_ioremap() returns a token that can be used with readl().
On most architectures readl() is just a memory access.
This all fails on an I/O BAR.

For an I/O BAR you want a similar pair of functions.
On x86 the access function would need to use the 'in/out' instructions but
there is no requirement for the token to be the native io port number.
On many non-x86 architectures the access function would be a simple memory
access - but a specific system (eg many ppc) may never actually allow
such mappings to succeed.

You might also want a third PCI mapping function that can map a memory
BAR or an I/O BAR - with a suitable access function.
On x86 this would need something like ioread8() for accesses.
Except that function uses small integers for io port numbers
(which is inherently dangerous).

Nothing except the architecture specific implementation of the function
to access an io BAR would ever go near a function called inb().

The same is really true for other bus type - including ISA and EISA.
(Ignoring the horrid of probing ISI bus devices - hopefully they
are in the ACPI tables??_
If a driver is probed on a ISA bus there ought to be functions
equivalent to pci_ioremap() (for both memory and IO addresses)
that return tokens appropriate for the specific bus.

That is all a different load of churn.


> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> >
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is
> accessed in an awkward manner with them), but with a new design such a
> clean approach is most welcome IMHO.  Thank you for your explanation.

Actually I think x86 was the initial system for PCI.
The PCI config space 'mess' is all about trying to make
something that wouldn't break existing memory maps.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 12:53 UTC (permalink / raw)
  To: 'Maciej W. Rozycki', Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar

From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
> 
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

You don't understand something...

For a memory BAR pci_ioremap() returns a token that can be used with readl().
On most architectures readl() is just a memory access.
This all fails on an I/O BAR.

For an I/O BAR you want a similar pair of functions.
On x86 the access function would need to use the 'in/out' instructions but
there is no requirement for the token to be the native io port number.
On many non-x86 architectures the access function would be a simple memory
access - but a specific system (eg many ppc) may never actually allow
such mappings to succeed.

You might also want a third PCI mapping function that can map a memory
BAR or an I/O BAR - with a suitable access function.
On x86 this would need something like ioread8() for accesses.
Except that function uses small integers for io port numbers
(which is inherently dangerous).

Nothing except the architecture specific implementation of the function
to access an io BAR would ever go near a function called inb().

The same is really true for other bus type - including ISA and EISA.
(Ignoring the horrid of probing ISI bus devices - hopefully they
are in the ACPI tables??_
If a driver is probed on a ISA bus there ought to be functions
equivalent to pci_ioremap() (for both memory and IO addresses)
that return tokens appropriate for the specific bus.

That is all a different load of churn.


> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> >
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is
> accessed in an awkward manner with them), but with a new design such a
> clean approach is most welcome IMHO.  Thank you for your explanation.

Actually I think x86 was the initial system for PCI.
The PCI config space 'mess' is all about trying to make
something that wouldn't break existing memory maps.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:27                 ` Maciej W. Rozycki
                                     ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 12:53                   ` Arnd Bergmann
  -1 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 12:53 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
>
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
>
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness.  Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.

        Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 12:53 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
>
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
>
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness.  Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.

        Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 12:53 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
>
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
>
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness.  Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.

        Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 12:53 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
>
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
>
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness.  Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 12:53 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
>
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
>
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness.  Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.

        Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:53                   ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-06 12:53 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou

On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> >
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
>
>  OK, that seems to me like a reasonable and quite a clean design (on the
> hardware side).
>
>  So what happens if the instruction is given an I/O rather than memory BAR
> as the relevant argument?  Is the address space indicator bit (bit #0)
> simply ignored or what?

Not sure. My best guess is that it would actually work as you'd expect,
but is deliberately left out of the architecture specification so they don't
have to to validate the correctness.  Note that only a small number of
PCIe cards are actually supported by IBM, and I think the firmware
only passes devices to the OS if they are whitelisted.

        Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:27                 ` Maciej W. Rozycki
                                     ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 12:55                   ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:55 UTC (permalink / raw)
  To: Maciej W. Rozycki, Arnd Bergmann
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> > 
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the 
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR 
> as the relevant argument?  Is the address space indicator bit (bit #0) 
> simply ignored or what?

See my answer to Arnd for some more background but there simply isn't a
way to formulate an I/O access. In the old style PCI instructions the
BAR number and the function handle are put in a register before the
access. BAR number 15 is used to access config space. If there is no
BAR for that number the instruction fails with a non-zero CC.

> 
> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> > 
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is 
> accessed in an awkward manner with them), but with a new design such a 
> clean approach is most welcome IMHO.  Thank you for your explanation.
> 
>   Maciej

Well our design is a retrofit too considering s390x is a direct
decendent of IBM System/360 which one could argue to have been the
first ISA. But yes as PCI support was only added with PCIe and with a
machine level hypervisor already in place we do get shielded a lot from
the gritty details.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:55                   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:55 UTC (permalink / raw)
  To: Maciej W. Rozycki, Arnd Bergmann
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> > 
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the 
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR 
> as the relevant argument?  Is the address space indicator bit (bit #0) 
> simply ignored or what?

See my answer to Arnd for some more background but there simply isn't a
way to formulate an I/O access. In the old style PCI instructions the
BAR number and the function handle are put in a register before the
access. BAR number 15 is used to access config space. If there is no
BAR for that number the instruction fails with a non-zero CC.

> 
> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> > 
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is 
> accessed in an awkward manner with them), but with a new design such a 
> clean approach is most welcome IMHO.  Thank you for your explanation.
> 
>   Maciej

Well our design is a retrofit too considering s390x is a direct
decendent of IBM System/360 which one could argue to have been the
first ISA. But yes as PCI support was only added with PCIe and with a
machine level hypervisor already in place we do get shielded a lot from
the gritty details.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:55                   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:55 UTC (permalink / raw)
  To: Maciej W. Rozycki, Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> > 
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the 
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR 
> as the relevant argument?  Is the address space indicator bit (bit #0) 
> simply ignored or what?

See my answer to Arnd for some more background but there simply isn't a
way to formulate an I/O access. In the old style PCI instructions the
BAR number and the function handle are put in a register before the
access. BAR number 15 is used to access config space. If there is no
BAR for that number the instruction fails with a non-zero CC.

> 
> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> > 
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is 
> accessed in an awkward manner with them), but with a new design such a 
> clean approach is most welcome IMHO.  Thank you for your explanation.
> 
>   Maciej

Well our design is a retrofit too considering s390x is a direct
decendent of IBM System/360 which one could argue to have been the
first ISA. But yes as PCI support was only added with PCIe and with a
machine level hypervisor already in place we do get shielded a lot from
the gritty details.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:55                   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:55 UTC (permalink / raw)
  To: Maciej W. Rozycki, Arnd Bergmann
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> > 
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the 
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR 
> as the relevant argument?  Is the address space indicator bit (bit #0) 
> simply ignored or what?

See my answer to Arnd for some more background but there simply isn't a
way to formulate an I/O access. In the old style PCI instructions the
BAR number and the function handle are put in a register before the
access. BAR number 15 is used to access config space. If there is no
BAR for that number the instruction fails with a non-zero CC.

> 
> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> > 
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is 
> accessed in an awkward manner with them), but with a new design such a 
> clean approach is most welcome IMHO.  Thank you for your explanation.
> 
>   Maciej

Well our design is a retrofit too considering s390x is a direct
decendent of IBM System/360 which one could argue to have been the
first ISA. But yes as PCI support was only added with PCIe and with a
machine level hypervisor already in place we do get shielded a lot from
the gritty details.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:55                   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:55 UTC (permalink / raw)
  To: Maciej W. Rozycki, Arnd Bergmann
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> > 
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the 
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR 
> as the relevant argument?  Is the address space indicator bit (bit #0) 
> simply ignored or what?

See my answer to Arnd for some more background but there simply isn't a
way to formulate an I/O access. In the old style PCI instructions the
BAR number and the function handle are put in a register before the
access. BAR number 15 is used to access config space. If there is no
BAR for that number the instruction fails with a non-zero CC.

> 
> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> > 
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is 
> accessed in an awkward manner with them), but with a new design such a 
> clean approach is most welcome IMHO.  Thank you for your explanation.
> 
>   Maciej

Well our design is a retrofit too considering s390x is a direct
decendent of IBM System/360 which one could argue to have been the
first ISA. But yes as PCI support was only added with PCIe and with a
machine level hypervisor already in place we do get shielded a lot from
the gritty details.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 12:55                   ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 12:55 UTC (permalink / raw)
  To: Maciej W. Rozycki, Arnd Bergmann
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley

On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
> 
> > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > inherent to the s390 architecture that prevents that different bit pattern
> > > from being used?
> > 
> > The hardware design for PCI on s390 is very different from any other
> > architecture, and more abstract. Rather than implementing MMIO register
> > access as pointer dereference, this is a separate CPU instruction that
> > takes a device/bar plus offset as arguments rather than a pointer, and
> > Linux encodes this back into a fake __iomem token.
> 
>  OK, that seems to me like a reasonable and quite a clean design (on the 
> hardware side).
> 
>  So what happens if the instruction is given an I/O rather than memory BAR 
> as the relevant argument?  Is the address space indicator bit (bit #0) 
> simply ignored or what?

See my answer to Arnd for some more background but there simply isn't a
way to formulate an I/O access. In the old style PCI instructions the
BAR number and the function handle are put in a register before the
access. BAR number 15 is used to access config space. If there is no
BAR for that number the instruction fails with a non-zero CC.

> 
> > >  But that has nothing to do with the presence or absence of any specific
> > > processor instructions.  It's just a limitation of bus glue.  So I guess
> > > it's just that all PCI/PCIe glue logic implementations for s390 have such
> > > a limitation, right?
> > 
> > There are separate instructions for PCI memory and config space, but
> > no instructions for I/O space, or for non-PCI MMIO that it could be mapped
> > into.
> 
>  The PCI configuration space was retrofitted into x86 systems (and is 
> accessed in an awkward manner with them), but with a new design such a 
> clean approach is most welcome IMHO.  Thank you for your explanation.
> 
>   Maciej

Well our design is a retrofit too considering s390x is a direct
decendent of IBM System/360 which one could argue to have been the
first ISA. But yes as PCI support was only added with PCIe and with a
machine level hypervisor already in place we do get shielded a lot from
the gritty details.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:53                   ` David Laight
                                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 13:08                     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 13:08 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, May 6, 2022 at 2:56 PM David Laight <David.Laight@aculab.com> wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > >
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> >
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> >
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> You don't understand something...
>
> For a memory BAR pci_ioremap() returns a token that can be used with readl().
> On most architectures readl() is just a memory access.
> This all fails on an I/O BAR.
>
> For an I/O BAR you want a similar pair of functions.
> On x86 the access function would need to use the 'in/out' instructions but
> there is no requirement for the token to be the native io port number.
> On many non-x86 architectures the access function would be a simple memory
> access - but a specific system (eg many ppc) may never actually allow
> such mappings to succeed.
>
> You might also want a third PCI mapping function that can map a memory
> BAR or an I/O BAR - with a suitable access function.
> On x86 this would need something like ioread8() for accesses.
> Except that function uses small integers for io port numbers
> (which is inherently dangerous).
>
> Nothing except the architecture specific implementation of the function
> to access an io BAR would ever go near a function called inb().
>
> The same is really true for other bus type - including ISA and EISA.
> (Ignoring the horrid of probing ISI bus devices - hopefully they
> are in the ACPI tables??_
> If a driver is probed on a ISA bus there ought to be functions
> equivalent to pci_ioremap() (for both memory and IO addresses)
> that return tokens appropriate for the specific bus.
>
> That is all a different load of churn.

A loooong time ago,  it was suggested to add register accessor
functions to struct device, so e.g. readl(dev, offset) would call
into these accessors, which would implement the bus-specific behavior.
No more worries about readl(), __raw_readl(), ioread32b(), or whatever
quirk is needed, at the (small on nowadays' machines) expense of
some indirection...

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:08                     ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 13:08 UTC (permalink / raw)
  To: David Laight
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Bjorn Helgaas, linux-pci, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller, Maciej W. Rozycki

On Fri, May 6, 2022 at 2:56 PM David Laight <David.Laight@aculab.com> wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > >
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> >
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> >
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> You don't understand something...
>
> For a memory BAR pci_ioremap() returns a token that can be used with readl().
> On most architectures readl() is just a memory access.
> This all fails on an I/O BAR.
>
> For an I/O BAR you want a similar pair of functions.
> On x86 the access function would need to use the 'in/out' instructions but
> there is no requirement for the token to be the native io port number.
> On many non-x86 architectures the access function would be a simple memory
> access - but a specific system (eg many ppc) may never actually allow
> such mappings to succeed.
>
> You might also want a third PCI mapping function that can map a memory
> BAR or an I/O BAR - with a suitable access function.
> On x86 this would need something like ioread8() for accesses.
> Except that function uses small integers for io port numbers
> (which is inherently dangerous).
>
> Nothing except the architecture specific implementation of the function
> to access an io BAR would ever go near a function called inb().
>
> The same is really true for other bus type - including ISA and EISA.
> (Ignoring the horrid of probing ISI bus devices - hopefully they
> are in the ACPI tables??_
> If a driver is probed on a ISA bus there ought to be functions
> equivalent to pci_ioremap() (for both memory and IO addresses)
> that return tokens appropriate for the specific bus.
>
> That is all a different load of churn.

A loooong time ago,  it was suggested to add register accessor
functions to struct device, so e.g. readl(dev, offset) would call
into these accessors, which would implement the bus-specific behavior.
No more worries about readl(), __raw_readl(), ioread32b(), or whatever
quirk is needed, at the (small on nowadays' machines) expense of
some indirection...

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:08                     ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 13:08 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, May 6, 2022 at 2:56 PM David Laight <David.Laight@aculab.com> wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > >
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> >
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> >
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> You don't understand something...
>
> For a memory BAR pci_ioremap() returns a token that can be used with readl().
> On most architectures readl() is just a memory access.
> This all fails on an I/O BAR.
>
> For an I/O BAR you want a similar pair of functions.
> On x86 the access function would need to use the 'in/out' instructions but
> there is no requirement for the token to be the native io port number.
> On many non-x86 architectures the access function would be a simple memory
> access - but a specific system (eg many ppc) may never actually allow
> such mappings to succeed.
>
> You might also want a third PCI mapping function that can map a memory
> BAR or an I/O BAR - with a suitable access function.
> On x86 this would need something like ioread8() for accesses.
> Except that function uses small integers for io port numbers
> (which is inherently dangerous).
>
> Nothing except the architecture specific implementation of the function
> to access an io BAR would ever go near a function called inb().
>
> The same is really true for other bus type - including ISA and EISA.
> (Ignoring the horrid of probing ISI bus devices - hopefully they
> are in the ACPI tables??_
> If a driver is probed on a ISA bus there ought to be functions
> equivalent to pci_ioremap() (for both memory and IO addresses)
> that return tokens appropriate for the specific bus.
>
> That is all a different load of churn.

A loooong time ago,  it was suggested to add register accessor
functions to struct device, so e.g. readl(dev, offset) would call
into these accessors, which would implement the bus-specific behavior.
No more worries about readl(), __raw_readl(), ioread32b(), or whatever
quirk is needed, at the (small on nowadays' machines) expense of
some indirection...

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:08                     ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 13:08 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, May 6, 2022 at 2:56 PM David Laight <David.Laight@aculab.com> wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > >
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> >
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> >
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> You don't understand something...
>
> For a memory BAR pci_ioremap() returns a token that can be used with readl().
> On most architectures readl() is just a memory access.
> This all fails on an I/O BAR.
>
> For an I/O BAR you want a similar pair of functions.
> On x86 the access function would need to use the 'in/out' instructions but
> there is no requirement for the token to be the native io port number.
> On many non-x86 architectures the access function would be a simple memory
> access - but a specific system (eg many ppc) may never actually allow
> such mappings to succeed.
>
> You might also want a third PCI mapping function that can map a memory
> BAR or an I/O BAR - with a suitable access function.
> On x86 this would need something like ioread8() for accesses.
> Except that function uses small integers for io port numbers
> (which is inherently dangerous).
>
> Nothing except the architecture specific implementation of the function
> to access an io BAR would ever go near a function called inb().
>
> The same is really true for other bus type - including ISA and EISA.
> (Ignoring the horrid of probing ISI bus devices - hopefully they
> are in the ACPI tables??_
> If a driver is probed on a ISA bus there ought to be functions
> equivalent to pci_ioremap() (for both memory and IO addresses)
> that return tokens appropriate for the specific bus.
>
> That is all a different load of churn.

A loooong time ago,  it was suggested to add register accessor
functions to struct device, so e.g. readl(dev, offset) would call
into these accessors, which would implement the bus-specific behavior.
No more worries about readl(), __raw_readl(), ioread32b(), or whatever
quirk is needed, at the (small on nowadays' machines) expense of
some indirection...

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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:08                     ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 13:08 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, May 6, 2022 at 2:56 PM David Laight <David.Laight@aculab.com> wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > >
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> >
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> >
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> You don't understand something...
>
> For a memory BAR pci_ioremap() returns a token that can be used with readl().
> On most architectures readl() is just a memory access.
> This all fails on an I/O BAR.
>
> For an I/O BAR you want a similar pair of functions.
> On x86 the access function would need to use the 'in/out' instructions but
> there is no requirement for the token to be the native io port number.
> On many non-x86 architectures the access function would be a simple memory
> access - but a specific system (eg many ppc) may never actually allow
> such mappings to succeed.
>
> You might also want a third PCI mapping function that can map a memory
> BAR or an I/O BAR - with a suitable access function.
> On x86 this would need something like ioread8() for accesses.
> Except that function uses small integers for io port numbers
> (which is inherently dangerous).
>
> Nothing except the architecture specific implementation of the function
> to access an io BAR would ever go near a function called inb().
>
> The same is really true for other bus type - including ISA and EISA.
> (Ignoring the horrid of probing ISI bus devices - hopefully they
> are in the ACPI tables??_
> If a driver is probed on a ISA bus there ought to be functions
> equivalent to pci_ioremap() (for both memory and IO addresses)
> that return tokens appropriate for the specific bus.
>
> That is all a different load of churn.

A loooong time ago,  it was suggested to add register accessor
functions to struct device, so e.g. readl(dev, offset) would call
into these accessors, which would implement the bus-specific behavior.
No more worries about readl(), __raw_readl(), ioread32b(), or whatever
quirk is needed, at the (small on nowadays' machines) expense of
some indirection...

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:08                     ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 13:08 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)

On Fri, May 6, 2022 at 2:56 PM David Laight <David.Laight@aculab.com> wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > >
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> >
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> >
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> You don't understand something...
>
> For a memory BAR pci_ioremap() returns a token that can be used with readl().
> On most architectures readl() is just a memory access.
> This all fails on an I/O BAR.
>
> For an I/O BAR you want a similar pair of functions.
> On x86 the access function would need to use the 'in/out' instructions but
> there is no requirement for the token to be the native io port number.
> On many non-x86 architectures the access function would be a simple memory
> access - but a specific system (eg many ppc) may never actually allow
> such mappings to succeed.
>
> You might also want a third PCI mapping function that can map a memory
> BAR or an I/O BAR - with a suitable access function.
> On x86 this would need something like ioread8() for accesses.
> Except that function uses small integers for io port numbers
> (which is inherently dangerous).
>
> Nothing except the architecture specific implementation of the function
> to access an io BAR would ever go near a function called inb().
>
> The same is really true for other bus type - including ISA and EISA.
> (Ignoring the horrid of probing ISI bus devices - hopefully they
> are in the ACPI tables??_
> If a driver is probed on a ISA bus there ought to be functions
> equivalent to pci_ioremap() (for both memory and IO addresses)
> that return tokens appropriate for the specific bus.
>
> That is all a different load of churn.

A loooong time ago,  it was suggested to add register accessor
functions to struct device, so e.g. readl(dev, offset) would call
into these accessors, which would implement the bus-specific behavior.
No more worries about readl(), __raw_readl(), ioread32b(), or whatever
quirk is needed, at the (small on nowadays' machines) expense of
some indirection...

Gr{oetje,eeting}s,

                        Geert

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:53                   ` David Laight
                                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 13:15                     ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:15 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO.  Thank you for your explanation.
> 
> Actually I think x86 was the initial system for PCI.
> The PCI config space 'mess' is all about trying to make
> something that wouldn't break existing memory maps.

 It was retrofitted in that x86 systems already existed for ~15 years when 
PCI came into picture.  Therefore the makers of the CPU ISA couldn't have 
envisaged the need for config access instructions like they did for memory 
and port access.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:15 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO.  Thank you for your explanation.
> 
> Actually I think x86 was the initial system for PCI.
> The PCI config space 'mess' is all about trying to make
> something that wouldn't break existing memory maps.

 It was retrofitted in that x86 systems already existed for ~15 years when 
PCI came into picture.  Therefore the makers of the CPU ISA couldn't have 
envisaged the need for config access instructions like they did for memory 
and port access.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:15 UTC (permalink / raw)
  To: David Laight
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Arnd Bergmann, Michal Simek,
	Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, open list:MIPS, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO.  Thank you for your explanation.
> 
> Actually I think x86 was the initial system for PCI.
> The PCI config space 'mess' is all about trying to make
> something that wouldn't break existing memory maps.

 It was retrofitted in that x86 systems already existed for ~15 years when 
PCI came into picture.  Therefore the makers of the CPU ISA couldn't have 
envisaged the need for config access instructions like they did for memory 
and port access.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:15 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO.  Thank you for your explanation.
> 
> Actually I think x86 was the initial system for PCI.
> The PCI config space 'mess' is all about trying to make
> something that wouldn't break existing memory maps.

 It was retrofitted in that x86 systems already existed for ~15 years when 
PCI came into picture.  Therefore the makers of the CPU ISA couldn't have 
envisaged the need for config access instructions like they did for memory 
and port access.

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:15 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO.  Thank you for your explanation.
> 
> Actually I think x86 was the initial system for PCI.
> The PCI config space 'mess' is all about trying to make
> something that wouldn't break existing memory maps.

 It was retrofitted in that x86 systems already existed for ~15 years when 
PCI came into picture.  Therefore the makers of the CPU ISA couldn't have 
envisaged the need for config access instructions like they did for memory 
and port access.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:15 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King

On Fri, 6 May 2022, David Laight wrote:

> >  The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO.  Thank you for your explanation.
> 
> Actually I think x86 was the initial system for PCI.
> The PCI config space 'mess' is all about trying to make
> something that wouldn't break existing memory maps.

 It was retrofitted in that x86 systems already existed for ~15 years when 
PCI came into picture.  Therefore the makers of the CPU ISA couldn't have 
envisaged the need for config access instructions like they did for memory 
and port access.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:53                   ` Arnd Bergmann
                                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 13:15                     ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > 
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > > 
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> > 
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> > 
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.
> 
>         Arnd

Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > 
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > > 
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> > 
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> > 
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.
> 
>         Arnd

Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > 
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > > 
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> > 
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> > 
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.
> 
>         Arnd

Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > 
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > > 
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> > 
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> > 
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.
> 
>         Arnd

Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > 
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > > 
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> > 
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> > 
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.
> 
>         Arnd

Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:15                     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-06 13:15 UTC (permalink / raw)
  To: Arnd Bergmann, Maciej W. Rozycki
  Cc: Bjorn Helgaas, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley

On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > 
> > > >  If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase.  So what is there
> > > > inherent to the s390 architecture that prevents that different bit pattern
> > > > from being used?
> > > 
> > > The hardware design for PCI on s390 is very different from any other
> > > architecture, and more abstract. Rather than implementing MMIO register
> > > access as pointer dereference, this is a separate CPU instruction that
> > > takes a device/bar plus offset as arguments rather than a pointer, and
> > > Linux encodes this back into a fake __iomem token.
> > 
> >  OK, that seems to me like a reasonable and quite a clean design (on the
> > hardware side).
> > 
> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.
> 
>         Arnd

Yes, though in Linux we do try hard to work with whatever is plugged
in. We did benefit from this in the past working with a new NIC from a
different vendor with 0 additional changes. Also you can use vfio-pci
to pass-through arbitrary PCI devices to a QEMU emulating s390x.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 12:53                   ` Arnd Bergmann
                                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 13:16                     ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.

 That makes sense, thanks!

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:16                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.

 That makes sense, thanks!

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:16                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.

 That makes sense, thanks!

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:16                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.

 That makes sense, thanks!

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:16                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.

 That makes sense, thanks!

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:16                     ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bjorn Helgaas, Niklas Schnelle, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael

On Fri, 6 May 2022, Arnd Bergmann wrote:

> >  So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument?  Is the address space indicator bit (bit #0)
> > simply ignored or what?
> 
> Not sure. My best guess is that it would actually work as you'd expect,
> but is deliberately left out of the architecture specification so they don't
> have to to validate the correctness.  Note that only a small number of
> PCIe cards are actually supported by IBM, and I think the firmware
> only passes devices to the OS if they are whitelisted.

 That makes sense, thanks!

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 13:15                     ` Maciej W. Rozycki
                                         ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 13:28                       ` David Laight
  -1 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 13:28 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
> 
> > >  The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO.  Thank you for your explanation.
> >
> > Actually I think x86 was the initial system for PCI.
> > The PCI config space 'mess' is all about trying to make
> > something that wouldn't break existing memory maps.
> 
>  It was retrofitted in that x86 systems already existed for ~15 years when
> PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> envisaged the need for config access instructions like they did for memory
> and port access.

Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
#2 is probably the first one and maps all of PCI config space into
4k of IO space (PCI bridges aren't supported).
#1 requires a pair of accesses (and SMP locking).

Neither is really horrid.

For horrid try the ISApnp interface.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:28                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 13:28 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Arnd Bergmann, Michal Simek,
	Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, open list:MIPS, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
> 
> > >  The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO.  Thank you for your explanation.
> >
> > Actually I think x86 was the initial system for PCI.
> > The PCI config space 'mess' is all about trying to make
> > something that wouldn't break existing memory maps.
> 
>  It was retrofitted in that x86 systems already existed for ~15 years when
> PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> envisaged the need for config access instructions like they did for memory
> and port access.

Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
#2 is probably the first one and maps all of PCI config space into
4k of IO space (PCI bridges aren't supported).
#1 requires a pair of accesses (and SMP locking).

Neither is really horrid.

For horrid try the ISApnp interface.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:28                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 13:28 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
> 
> > >  The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO.  Thank you for your explanation.
> >
> > Actually I think x86 was the initial system for PCI.
> > The PCI config space 'mess' is all about trying to make
> > something that wouldn't break existing memory maps.
> 
>  It was retrofitted in that x86 systems already existed for ~15 years when
> PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> envisaged the need for config access instructions like they did for memory
> and port access.

Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
#2 is probably the first one and maps all of PCI config space into
4k of IO space (PCI bridges aren't supported).
#1 requires a pair of accesses (and SMP locking).

Neither is really horrid.

For horrid try the ISApnp interface.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:28                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 13:28 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
> 
> > >  The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO.  Thank you for your explanation.
> >
> > Actually I think x86 was the initial system for PCI.
> > The PCI config space 'mess' is all about trying to make
> > something that wouldn't break existing memory maps.
> 
>  It was retrofitted in that x86 systems already existed for ~15 years when
> PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> envisaged the need for config access instructions like they did for memory
> and port access.

Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
#2 is probably the first one and maps all of PCI config space into
4k of IO space (PCI bridges aren't supported).
#1 requires a pair of accesses (and SMP locking).

Neither is really horrid.

For horrid try the ISApnp interface.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:28                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 13:28 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
> 
> > >  The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO.  Thank you for your explanation.
> >
> > Actually I think x86 was the initial system for PCI.
> > The PCI config space 'mess' is all about trying to make
> > something that wouldn't break existing memory maps.
> 
>  It was retrofitted in that x86 systems already existed for ~15 years when
> PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> envisaged the need for config access instructions like they did for memory
> and port access.

Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
#2 is probably the first one and maps all of PCI config space into
4k of IO space (PCI bridges aren't supported).
#1 requires a pair of accesses (and SMP locking).

Neither is really horrid.

For horrid try the ISApnp interface.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:28                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 13:28 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King

From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
> 
> > >  The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO.  Thank you for your explanation.
> >
> > Actually I think x86 was the initial system for PCI.
> > The PCI config space 'mess' is all about trying to make
> > something that wouldn't break existing memory maps.
> 
>  It was retrofitted in that x86 systems already existed for ~15 years when
> PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> envisaged the need for config access instructions like they did for memory
> and port access.

Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
#2 is probably the first one and maps all of PCI config space into
4k of IO space (PCI bridges aren't supported).
#1 requires a pair of accesses (and SMP locking).

Neither is really horrid.

For horrid try the ISApnp interface.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 13:08                     ` Geert Uytterhoeven
                                         ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 13:40                       ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Geert Uytterhoeven wrote:

> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

 I guess you'd need an additional parameter for the endianness policy 
required (to match either bit or byte lanes, according to ultimate data 
interpretation) where crossing between buses of a different endianness 
each.  Otherwise you'd end up with the mess elsewhere.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:40                       ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Geert Uytterhoeven wrote:

> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

 I guess you'd need an additional parameter for the endianness policy 
required (to match either bit or byte lanes, according to ultimate data 
interpretation) where crossing between buses of a different endianness 
each.  Otherwise you'd end up with the mess elsewhere.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:40                       ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Bjorn Helgaas, linux-pci, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, David Laight, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Geert Uytterhoeven wrote:

> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

 I guess you'd need an additional parameter for the endianness policy 
required (to match either bit or byte lanes, according to ultimate data 
interpretation) where crossing between buses of a different endianness 
each.  Otherwise you'd end up with the mess elsewhere.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:40                       ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Geert Uytterhoeven wrote:

> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

 I guess you'd need an additional parameter for the endianness policy 
required (to match either bit or byte lanes, according to ultimate data 
interpretation) where crossing between buses of a different endianness 
each.  Otherwise you'd end up with the mess elsewhere.

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:40                       ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, Geert Uytterhoeven wrote:

> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

 I guess you'd need an additional parameter for the endianness policy 
required (to match either bit or byte lanes, according to ultimate data 
interpretation) where crossing between buses of a different endianness 
each.  Otherwise you'd end up with the mess elsewhere.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 13:40                       ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 13:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)

On Fri, 6 May 2022, Geert Uytterhoeven wrote:

> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

 I guess you'd need an additional parameter for the endianness policy 
required (to match either bit or byte lanes, according to ultimate data 
interpretation) where crossing between buses of a different endianness 
each.  Otherwise you'd end up with the mess elsewhere.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 13:08                     ` Geert Uytterhoeven
                                         ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 14:03                       ` David Laight
  -1 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 14:03 UTC (permalink / raw)
  To: 'Geert Uytterhoeven'
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > equivalent to pci_ioremap() (for both memory and IO addresses)
> > that return tokens appropriate for the specific bus.
> >
> > That is all a different load of churn.
> 
> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

I was just thinking that the access functions might need a 'device'.
Although you also need the BAR (or equivalent).
So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).
Clearly the 'dev' parameter could be compiled out for non-DEBUG
build on x86 - leaving the current(ish) object code.

You don't want an indirect call (this year), but maybe real
function call and a few tests won't make that much difference.
They might affect PCIe writes, but PCIe reads are so slow you
need to avoid them whenever possible.
I've not timed reads into something like an ethernet chip,
but into our fpga they are probably 1000 clocks+.

OTOH I wouldn't want any overhead on the PIO fifo reads
on one of our small ppc devices.
We push a lot of data though that fifo and anything extra
would kill performance.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:03                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 14:03 UTC (permalink / raw)
  To: 'Geert Uytterhoeven'
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > equivalent to pci_ioremap() (for both memory and IO addresses)
> > that return tokens appropriate for the specific bus.
> >
> > That is all a different load of churn.
> 
> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

I was just thinking that the access functions might need a 'device'.
Although you also need the BAR (or equivalent).
So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).
Clearly the 'dev' parameter could be compiled out for non-DEBUG
build on x86 - leaving the current(ish) object code.

You don't want an indirect call (this year), but maybe real
function call and a few tests won't make that much difference.
They might affect PCIe writes, but PCIe reads are so slow you
need to avoid them whenever possible.
I've not timed reads into something like an ethernet chip,
but into our fpga they are probably 1000 clocks+.

OTOH I wouldn't want any overhead on the PIO fifo reads
on one of our small ppc devices.
We push a lot of data though that fifo and anything extra
would kill performance.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:03                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 14:03 UTC (permalink / raw)
  To: 'Geert Uytterhoeven'
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Bjorn Helgaas, linux-pci, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller, Maciej W. Rozycki

From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > equivalent to pci_ioremap() (for both memory and IO addresses)
> > that return tokens appropriate for the specific bus.
> >
> > That is all a different load of churn.
> 
> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

I was just thinking that the access functions might need a 'device'.
Although you also need the BAR (or equivalent).
So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).
Clearly the 'dev' parameter could be compiled out for non-DEBUG
build on x86 - leaving the current(ish) object code.

You don't want an indirect call (this year), but maybe real
function call and a few tests won't make that much difference.
They might affect PCIe writes, but PCIe reads are so slow you
need to avoid them whenever possible.
I've not timed reads into something like an ethernet chip,
but into our fpga they are probably 1000 clocks+.

OTOH I wouldn't want any overhead on the PIO fifo reads
on one of our small ppc devices.
We push a lot of data though that fifo and anything extra
would kill performance.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:03                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 14:03 UTC (permalink / raw)
  To: 'Geert Uytterhoeven'
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > equivalent to pci_ioremap() (for both memory and IO addresses)
> > that return tokens appropriate for the specific bus.
> >
> > That is all a different load of churn.
> 
> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

I was just thinking that the access functions might need a 'device'.
Although you also need the BAR (or equivalent).
So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).
Clearly the 'dev' parameter could be compiled out for non-DEBUG
build on x86 - leaving the current(ish) object code.

You don't want an indirect call (this year), but maybe real
function call and a few tests won't make that much difference.
They might affect PCIe writes, but PCIe reads are so slow you
need to avoid them whenever possible.
I've not timed reads into something like an ethernet chip,
but into our fpga they are probably 1000 clocks+.

OTOH I wouldn't want any overhead on the PIO fifo reads
on one of our small ppc devices.
We push a lot of data though that fifo and anything extra
would kill performance.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:03                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 14:03 UTC (permalink / raw)
  To: 'Geert Uytterhoeven'
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

RnJvbTogR2VlcnQgVXl0dGVyaG9ldmVuDQo+IFNlbnQ6IDA2IE1heSAyMDIyIDE0OjA5DQouLi4N
Cj4gPiBUaGUgc2FtZSBpcyByZWFsbHkgdHJ1ZSBmb3Igb3RoZXIgYnVzIHR5cGUgLSBpbmNsdWRp
bmcgSVNBIGFuZCBFSVNBLg0KPiA+IChJZ25vcmluZyB0aGUgaG9ycmlkIG9mIHByb2JpbmcgSVNJ
IGJ1cyBkZXZpY2VzIC0gaG9wZWZ1bGx5IHRoZXkNCj4gPiBhcmUgaW4gdGhlIEFDUEkgdGFibGVz
Pz9fDQo+ID4gSWYgYSBkcml2ZXIgaXMgcHJvYmVkIG9uIGEgSVNBIGJ1cyB0aGVyZSBvdWdodCB0
byBiZSBmdW5jdGlvbnMNCj4gPiBlcXVpdmFsZW50IHRvIHBjaV9pb3JlbWFwKCkgKGZvciBib3Ro
IG1lbW9yeSBhbmQgSU8gYWRkcmVzc2VzKQ0KPiA+IHRoYXQgcmV0dXJuIHRva2VucyBhcHByb3By
aWF0ZSBmb3IgdGhlIHNwZWNpZmljIGJ1cy4NCj4gPg0KPiA+IFRoYXQgaXMgYWxsIGEgZGlmZmVy
ZW50IGxvYWQgb2YgY2h1cm4uDQo+IA0KPiBBIGxvb29vbmcgdGltZSBhZ28sICBpdCB3YXMgc3Vn
Z2VzdGVkIHRvIGFkZCByZWdpc3RlciBhY2Nlc3Nvcg0KPiBmdW5jdGlvbnMgdG8gc3RydWN0IGRl
dmljZSwgc28gZS5nLiByZWFkbChkZXYsIG9mZnNldCkgd291bGQgY2FsbA0KPiBpbnRvIHRoZXNl
IGFjY2Vzc29ycywgd2hpY2ggd291bGQgaW1wbGVtZW50IHRoZSBidXMtc3BlY2lmaWMgYmVoYXZp
b3IuDQo+IE5vIG1vcmUgd29ycmllcyBhYm91dCByZWFkbCgpLCBfX3Jhd19yZWFkbCgpLCBpb3Jl
YWQzMmIoKSwgb3Igd2hhdGV2ZXINCj4gcXVpcmsgaXMgbmVlZGVkLCBhdCB0aGUgKHNtYWxsIG9u
IG5vd2FkYXlzJyBtYWNoaW5lcykgZXhwZW5zZSBvZg0KPiBzb21lIGluZGlyZWN0aW9uLi4uDQoN
Ckkgd2FzIGp1c3QgdGhpbmtpbmcgdGhhdCB0aGUgYWNjZXNzIGZ1bmN0aW9ucyBtaWdodCBuZWVk
IGEgJ2RldmljZScuDQpBbHRob3VnaCB5b3UgYWxzbyBuZWVkIHRoZSBCQVIgKG9yIGVxdWl2YWxl
bnQpLg0KU28gcmVhZGwoZGV2LCBiYXJfdG9rZW4sIG9mZnNldCkgb3IgcmVhZGwoZGV2LCBiYXJf
dG9rZW4gKyBvZmZzZXQpLg0KQ2xlYXJseSB0aGUgJ2RldicgcGFyYW1ldGVyIGNvdWxkIGJlIGNv
bXBpbGVkIG91dCBmb3Igbm9uLURFQlVHDQpidWlsZCBvbiB4ODYgLSBsZWF2aW5nIHRoZSBjdXJy
ZW50KGlzaCkgb2JqZWN0IGNvZGUuDQoNCllvdSBkb24ndCB3YW50IGFuIGluZGlyZWN0IGNhbGwg
KHRoaXMgeWVhciksIGJ1dCBtYXliZSByZWFsDQpmdW5jdGlvbiBjYWxsIGFuZCBhIGZldyB0ZXN0
cyB3b24ndCBtYWtlIHRoYXQgbXVjaCBkaWZmZXJlbmNlLg0KVGhleSBtaWdodCBhZmZlY3QgUENJ
ZSB3cml0ZXMsIGJ1dCBQQ0llIHJlYWRzIGFyZSBzbyBzbG93IHlvdQ0KbmVlZCB0byBhdm9pZCB0
aGVtIHdoZW5ldmVyIHBvc3NpYmxlLg0KSSd2ZSBub3QgdGltZWQgcmVhZHMgaW50byBzb21ldGhp
bmcgbGlrZSBhbiBldGhlcm5ldCBjaGlwLA0KYnV0IGludG8gb3VyIGZwZ2EgdGhleSBhcmUgcHJv
YmFibHkgMTAwMCBjbG9ja3MrLg0KDQpPVE9IIEkgd291bGRuJ3Qgd2FudCBhbnkgb3ZlcmhlYWQg
b24gdGhlIFBJTyBmaWZvIHJlYWRzDQpvbiBvbmUgb2Ygb3VyIHNtYWxsIHBwYyBkZXZpY2VzLg0K
V2UgcHVzaCBhIGxvdCBvZiBkYXRhIHRob3VnaCB0aGF0IGZpZm8gYW5kIGFueXRoaW5nIGV4dHJh
DQp3b3VsZCBraWxsIHBlcmZvcm1hbmNlLg0KDQoJRGF2aWQNCg0KLQ0KUmVnaXN0ZXJlZCBBZGRy
ZXNzIExha2VzaWRlLCBCcmFtbGV5IFJvYWQsIE1vdW50IEZhcm0sIE1pbHRvbiBLZXluZXMsIE1L
MSAxUFQsIFVLDQpSZWdpc3RyYXRpb24gTm86IDEzOTczODYgKFdhbGVzKQ0K

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:03                       ` David Laight
  0 siblings, 0 replies; 392+ messages in thread
From: David Laight @ 2022-05-06 14:03 UTC (permalink / raw)
  To: 'Geert Uytterhoeven'
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)

From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > equivalent to pci_ioremap() (for both memory and IO addresses)
> > that return tokens appropriate for the specific bus.
> >
> > That is all a different load of churn.
> 
> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

I was just thinking that the access functions might need a 'device'.
Although you also need the BAR (or equivalent).
So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).
Clearly the 'dev' parameter could be compiled out for non-DEBUG
build on x86 - leaving the current(ish) object code.

You don't want an indirect call (this year), but maybe real
function call and a few tests won't make that much difference.
They might affect PCIe writes, but PCIe reads are so slow you
need to avoid them whenever possible.
I've not timed reads into something like an ethernet chip,
but into our fpga they are probably 1000 clocks+.

OTOH I wouldn't want any overhead on the PIO fifo reads
on one of our small ppc devices.
We push a lot of data though that fifo and anything extra
would kill performance.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 13:28                       ` David Laight
                                           ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 14:44                         ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 14:44 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
> 
> Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> #2 is probably the first one and maps all of PCI config space into
> 4k of IO space (PCI bridges aren't supported).

 This one is even more horrid than #1 in that it requires two separate 
preparatory I/O writes rather than just one, one to the Forward Register 
(at 0xcfa) to set the bus number, and another to the Configuration Space 
Enable Register (at 0xcf8) to set the function number, before you can 
issue a configuration read or write to a device.  So you need MP locking 
too.

 NB only peer bridges aren't supported with this mechanism, normal PCI-PCI 
bridges are, via the Forward Register.

> #1 requires a pair of accesses (and SMP locking).
> 
> Neither is really horrid.

 Both are.  First neither is MP-safe and second both are indirect in that 
you need to poke at some chipset registers before you can issue the actual 
read or write.

 Sane access would require a single CPU instruction to read or write from 
the configuration space.  To access the conventional PCI configuration 
space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of 
address space.  Such amount of address space seems affordable even with 
32-bit systems.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:44                         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 14:44 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
> 
> Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> #2 is probably the first one and maps all of PCI config space into
> 4k of IO space (PCI bridges aren't supported).

 This one is even more horrid than #1 in that it requires two separate 
preparatory I/O writes rather than just one, one to the Forward Register 
(at 0xcfa) to set the bus number, and another to the Configuration Space 
Enable Register (at 0xcf8) to set the function number, before you can 
issue a configuration read or write to a device.  So you need MP locking 
too.

 NB only peer bridges aren't supported with this mechanism, normal PCI-PCI 
bridges are, via the Forward Register.

> #1 requires a pair of accesses (and SMP locking).
> 
> Neither is really horrid.

 Both are.  First neither is MP-safe and second both are indirect in that 
you need to poke at some chipset registers before you can issue the actual 
read or write.

 Sane access would require a single CPU instruction to read or write from 
the configuration space.  To access the conventional PCI configuration 
space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of 
address space.  Such amount of address space seems affordable even with 
32-bit systems.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:44                         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 14:44 UTC (permalink / raw)
  To: David Laight
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Arnd Bergmann, Michal Simek,
	Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, open list:MIPS, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
> 
> Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> #2 is probably the first one and maps all of PCI config space into
> 4k of IO space (PCI bridges aren't supported).

 This one is even more horrid than #1 in that it requires two separate 
preparatory I/O writes rather than just one, one to the Forward Register 
(at 0xcfa) to set the bus number, and another to the Configuration Space 
Enable Register (at 0xcf8) to set the function number, before you can 
issue a configuration read or write to a device.  So you need MP locking 
too.

 NB only peer bridges aren't supported with this mechanism, normal PCI-PCI 
bridges are, via the Forward Register.

> #1 requires a pair of accesses (and SMP locking).
> 
> Neither is really horrid.

 Both are.  First neither is MP-safe and second both are indirect in that 
you need to poke at some chipset registers before you can issue the actual 
read or write.

 Sane access would require a single CPU instruction to read or write from 
the configuration space.  To access the conventional PCI configuration 
space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of 
address space.  Such amount of address space seems affordable even with 
32-bit systems.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:44                         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 14:44 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
> 
> Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> #2 is probably the first one and maps all of PCI config space into
> 4k of IO space (PCI bridges aren't supported).

 This one is even more horrid than #1 in that it requires two separate 
preparatory I/O writes rather than just one, one to the Forward Register 
(at 0xcfa) to set the bus number, and another to the Configuration Space 
Enable Register (at 0xcf8) to set the function number, before you can 
issue a configuration read or write to a device.  So you need MP locking 
too.

 NB only peer bridges aren't supported with this mechanism, normal PCI-PCI 
bridges are, via the Forward Register.

> #1 requires a pair of accesses (and SMP locking).
> 
> Neither is really horrid.

 Both are.  First neither is MP-safe and second both are indirect in that 
you need to poke at some chipset registers before you can issue the actual 
read or write.

 Sane access would require a single CPU instruction to read or write from 
the configuration space.  To access the conventional PCI configuration 
space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of 
address space.  Such amount of address space seems affordable even with 
32-bit systems.

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:44                         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 14:44 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Fri, 6 May 2022, David Laight wrote:

> >  It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
> 
> Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> #2 is probably the first one and maps all of PCI config space into
> 4k of IO space (PCI bridges aren't supported).

 This one is even more horrid than #1 in that it requires two separate 
preparatory I/O writes rather than just one, one to the Forward Register 
(at 0xcfa) to set the bus number, and another to the Configuration Space 
Enable Register (at 0xcf8) to set the function number, before you can 
issue a configuration read or write to a device.  So you need MP locking 
too.

 NB only peer bridges aren't supported with this mechanism, normal PCI-PCI 
bridges are, via the Forward Register.

> #1 requires a pair of accesses (and SMP locking).
> 
> Neither is really horrid.

 Both are.  First neither is MP-safe and second both are indirect in that 
you need to poke at some chipset registers before you can issue the actual 
read or write.

 Sane access would require a single CPU instruction to read or write from 
the configuration space.  To access the conventional PCI configuration 
space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of 
address space.  Such amount of address space seems affordable even with 
32-bit systems.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:44                         ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 14:44 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, Rich Felker, open list:IA64 (Itanium) PLATFORM,
	open list:SUPERH, Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King

On Fri, 6 May 2022, David Laight wrote:

> >  It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
> 
> Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> #2 is probably the first one and maps all of PCI config space into
> 4k of IO space (PCI bridges aren't supported).

 This one is even more horrid than #1 in that it requires two separate 
preparatory I/O writes rather than just one, one to the Forward Register 
(at 0xcfa) to set the bus number, and another to the Configuration Space 
Enable Register (at 0xcf8) to set the function number, before you can 
issue a configuration read or write to a device.  So you need MP locking 
too.

 NB only peer bridges aren't supported with this mechanism, normal PCI-PCI 
bridges are, via the Forward Register.

> #1 requires a pair of accesses (and SMP locking).
> 
> Neither is really horrid.

 Both are.  First neither is MP-safe and second both are indirect in that 
you need to poke at some chipset registers before you can issue the actual 
read or write.

 Sane access would require a single CPU instruction to read or write from 
the configuration space.  To access the conventional PCI configuration 
space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of 
address space.  Such amount of address space seems affordable even with 
32-bit systems.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 14:44                         ` Maciej W. Rozycki
                                             ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 14:56                           ` Geert Uytterhoeven
  -1 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 14:56 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Maciej,

On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > >  It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need for config access instructions like they did for memory
> > > and port access.
> >
> > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> > #2 is probably the first one and maps all of PCI config space into
> > 4k of IO space (PCI bridges aren't supported).
>
>  This one is even more horrid than #1 in that it requires two separate
> preparatory I/O writes rather than just one, one to the Forward Register
> (at 0xcfa) to set the bus number, and another to the Configuration Space
> Enable Register (at 0xcf8) to set the function number, before you can
> issue a configuration read or write to a device.  So you need MP locking
> too.
>
>  NB only peer bridges aren't supported with this mechanism, normal PCI-PCI
> bridges are, via the Forward Register.
>
> > #1 requires a pair of accesses (and SMP locking).
> >
> > Neither is really horrid.
>
>  Both are.  First neither is MP-safe and second both are indirect in that
> you need to poke at some chipset registers before you can issue the actual
> read or write.
>
>  Sane access would require a single CPU instruction to read or write from
> the configuration space.  To access the conventional PCI configuration
> space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> address space.  Such amount of address space seems affordable even with
> 32-bit systems.

Won't have fit in the legacy 1 MiB space ("640 KiB...").

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:56                           ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 14:56 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Maciej,

On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > >  It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need for config access instructions like they did for memory
> > > and port access.
> >
> > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> > #2 is probably the first one and maps all of PCI config space into
> > 4k of IO space (PCI bridges aren't supported).
>
>  This one is even more horrid than #1 in that it requires two separate
> preparatory I/O writes rather than just one, one to the Forward Register
> (at 0xcfa) to set the bus number, and another to the Configuration Space
> Enable Register (at 0xcf8) to set the function number, before you can
> issue a configuration read or write to a device.  So you need MP locking
> too.
>
>  NB only peer bridges aren't supported with this mechanism, normal PCI-PCI
> bridges are, via the Forward Register.
>
> > #1 requires a pair of accesses (and SMP locking).
> >
> > Neither is really horrid.
>
>  Both are.  First neither is MP-safe and second both are indirect in that
> you need to poke at some chipset registers before you can issue the actual
> read or write.
>
>  Sane access would require a single CPU instruction to read or write from
> the configuration space.  To access the conventional PCI configuration
> space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> address space.  Such amount of address space seems affordable even with
> 32-bit systems.

Won't have fit in the legacy 1 MiB space ("640 KiB...").

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:56                           ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 14:56 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Bjorn Helgaas, linux-pci, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, David Laight, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Maciej,

On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > >  It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need for config access instructions like they did for memory
> > > and port access.
> >
> > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> > #2 is probably the first one and maps all of PCI config space into
> > 4k of IO space (PCI bridges aren't supported).
>
>  This one is even more horrid than #1 in that it requires two separate
> preparatory I/O writes rather than just one, one to the Forward Register
> (at 0xcfa) to set the bus number, and another to the Configuration Space
> Enable Register (at 0xcf8) to set the function number, before you can
> issue a configuration read or write to a device.  So you need MP locking
> too.
>
>  NB only peer bridges aren't supported with this mechanism, normal PCI-PCI
> bridges are, via the Forward Register.
>
> > #1 requires a pair of accesses (and SMP locking).
> >
> > Neither is really horrid.
>
>  Both are.  First neither is MP-safe and second both are indirect in that
> you need to poke at some chipset registers before you can issue the actual
> read or write.
>
>  Sane access would require a single CPU instruction to read or write from
> the configuration space.  To access the conventional PCI configuration
> space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> address space.  Such amount of address space seems affordable even with
> 32-bit systems.

Won't have fit in the legacy 1 MiB space ("640 KiB...").

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:56                           ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 14:56 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Maciej,

On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > >  It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need for config access instructions like they did for memory
> > > and port access.
> >
> > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> > #2 is probably the first one and maps all of PCI config space into
> > 4k of IO space (PCI bridges aren't supported).
>
>  This one is even more horrid than #1 in that it requires two separate
> preparatory I/O writes rather than just one, one to the Forward Register
> (at 0xcfa) to set the bus number, and another to the Configuration Space
> Enable Register (at 0xcf8) to set the function number, before you can
> issue a configuration read or write to a device.  So you need MP locking
> too.
>
>  NB only peer bridges aren't supported with this mechanism, normal PCI-PCI
> bridges are, via the Forward Register.
>
> > #1 requires a pair of accesses (and SMP locking).
> >
> > Neither is really horrid.
>
>  Both are.  First neither is MP-safe and second both are indirect in that
> you need to poke at some chipset registers before you can issue the actual
> read or write.
>
>  Sane access would require a single CPU instruction to read or write from
> the configuration space.  To access the conventional PCI configuration
> space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> address space.  Such amount of address space seems affordable even with
> 32-bit systems.

Won't have fit in the legacy 1 MiB space ("640 KiB...").

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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:56                           ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 14:56 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Maciej,

On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > >  It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need for config access instructions like they did for memory
> > > and port access.
> >
> > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> > #2 is probably the first one and maps all of PCI config space into
> > 4k of IO space (PCI bridges aren't supported).
>
>  This one is even more horrid than #1 in that it requires two separate
> preparatory I/O writes rather than just one, one to the Forward Register
> (at 0xcfa) to set the bus number, and another to the Configuration Space
> Enable Register (at 0xcf8) to set the function number, before you can
> issue a configuration read or write to a device.  So you need MP locking
> too.
>
>  NB only peer bridges aren't supported with this mechanism, normal PCI-PCI
> bridges are, via the Forward Register.
>
> > #1 requires a pair of accesses (and SMP locking).
> >
> > Neither is really horrid.
>
>  Both are.  First neither is MP-safe and second both are indirect in that
> you need to poke at some chipset registers before you can issue the actual
> read or write.
>
>  Sane access would require a single CPU instruction to read or write from
> the configuration space.  To access the conventional PCI configuration
> space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> address space.  Such amount of address space seems affordable even with
> 32-bit systems.

Won't have fit in the legacy 1 MiB space ("640 KiB...").

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 14:56                           ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 14:56 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci

Hi Maciej,

On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > >  It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture.  Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need for config access instructions like they did for memory
> > > and port access.
> >
> > Rev 2.0 of the PCI spec (1993) defines two mechanisms for config cycles.
> > #2 is probably the first one and maps all of PCI config space into
> > 4k of IO space (PCI bridges aren't supported).
>
>  This one is even more horrid than #1 in that it requires two separate
> preparatory I/O writes rather than just one, one to the Forward Register
> (at 0xcfa) to set the bus number, and another to the Configuration Space
> Enable Register (at 0xcf8) to set the function number, before you can
> issue a configuration read or write to a device.  So you need MP locking
> too.
>
>  NB only peer bridges aren't supported with this mechanism, normal PCI-PCI
> bridges are, via the Forward Register.
>
> > #1 requires a pair of accesses (and SMP locking).
> >
> > Neither is really horrid.
>
>  Both are.  First neither is MP-safe and second both are indirect in that
> you need to poke at some chipset registers before you can issue the actual
> read or write.
>
>  Sane access would require a single CPU instruction to read or write from
> the configuration space.  To access the conventional PCI configuration
> space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> address space.  Such amount of address space seems affordable even with
> 32-bit systems.

Won't have fit in the legacy 1 MiB space ("640 KiB...").

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 14:03                       ` David Laight
                                           ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 15:02                         ` Geert Uytterhoeven
  -1 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 15:02 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi David

On Fri, May 6, 2022 at 4:05 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> > > If a driver is probed on a ISA bus there ought to be functions
> > > equivalent to pci_ioremap() (for both memory and IO addresses)
> > > that return tokens appropriate for the specific bus.
> > >
> > > That is all a different load of churn.
> >
> > A loooong time ago,  it was suggested to add register accessor
> > functions to struct device, so e.g. readl(dev, offset) would call
> > into these accessors, which would implement the bus-specific behavior.
> > No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> > quirk is needed, at the (small on nowadays' machines) expense of
> > some indirection...
>
> I was just thinking that the access functions might need a 'device'.
> Although you also need the BAR (or equivalent).
> So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).

Note that we do have such a system: regmap.

> Clearly the 'dev' parameter could be compiled out for non-DEBUG
> build on x86 - leaving the current(ish) object code.

Assumed all devices are PCI devices.
E.g. USB devices would still need the indirection.

> You don't want an indirect call (this year), but maybe real
> function call and a few tests won't make that much difference.
> They might affect PCIe writes, but PCIe reads are so slow you
> need to avoid them whenever possible.
> I've not timed reads into something like an ethernet chip,
> but into our fpga they are probably 1000 clocks+.
>
> OTOH I wouldn't want any overhead on the PIO fifo reads
> on one of our small ppc devices.
> We push a lot of data though that fifo and anything extra
> would kill performance.

Right.

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:02                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 15:02 UTC (permalink / raw)
  To: David Laight
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Bjorn Helgaas, linux-pci, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller, Maciej W. Rozycki

Hi David

On Fri, May 6, 2022 at 4:05 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> > > If a driver is probed on a ISA bus there ought to be functions
> > > equivalent to pci_ioremap() (for both memory and IO addresses)
> > > that return tokens appropriate for the specific bus.
> > >
> > > That is all a different load of churn.
> >
> > A loooong time ago,  it was suggested to add register accessor
> > functions to struct device, so e.g. readl(dev, offset) would call
> > into these accessors, which would implement the bus-specific behavior.
> > No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> > quirk is needed, at the (small on nowadays' machines) expense of
> > some indirection...
>
> I was just thinking that the access functions might need a 'device'.
> Although you also need the BAR (or equivalent).
> So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).

Note that we do have such a system: regmap.

> Clearly the 'dev' parameter could be compiled out for non-DEBUG
> build on x86 - leaving the current(ish) object code.

Assumed all devices are PCI devices.
E.g. USB devices would still need the indirection.

> You don't want an indirect call (this year), but maybe real
> function call and a few tests won't make that much difference.
> They might affect PCIe writes, but PCIe reads are so slow you
> need to avoid them whenever possible.
> I've not timed reads into something like an ethernet chip,
> but into our fpga they are probably 1000 clocks+.
>
> OTOH I wouldn't want any overhead on the PIO fifo reads
> on one of our small ppc devices.
> We push a lot of data though that fifo and anything extra
> would kill performance.

Right.

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:02                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 15:02 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi David

On Fri, May 6, 2022 at 4:05 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> > > If a driver is probed on a ISA bus there ought to be functions
> > > equivalent to pci_ioremap() (for both memory and IO addresses)
> > > that return tokens appropriate for the specific bus.
> > >
> > > That is all a different load of churn.
> >
> > A loooong time ago,  it was suggested to add register accessor
> > functions to struct device, so e.g. readl(dev, offset) would call
> > into these accessors, which would implement the bus-specific behavior.
> > No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> > quirk is needed, at the (small on nowadays' machines) expense of
> > some indirection...
>
> I was just thinking that the access functions might need a 'device'.
> Although you also need the BAR (or equivalent).
> So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).

Note that we do have such a system: regmap.

> Clearly the 'dev' parameter could be compiled out for non-DEBUG
> build on x86 - leaving the current(ish) object code.

Assumed all devices are PCI devices.
E.g. USB devices would still need the indirection.

> You don't want an indirect call (this year), but maybe real
> function call and a few tests won't make that much difference.
> They might affect PCIe writes, but PCIe reads are so slow you
> need to avoid them whenever possible.
> I've not timed reads into something like an ethernet chip,
> but into our fpga they are probably 1000 clocks+.
>
> OTOH I wouldn't want any overhead on the PIO fifo reads
> on one of our small ppc devices.
> We push a lot of data though that fifo and anything extra
> would kill performance.

Right.

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:02                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 15:02 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi David

On Fri, May 6, 2022 at 4:05 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> > > If a driver is probed on a ISA bus there ought to be functions
> > > equivalent to pci_ioremap() (for both memory and IO addresses)
> > > that return tokens appropriate for the specific bus.
> > >
> > > That is all a different load of churn.
> >
> > A loooong time ago,  it was suggested to add register accessor
> > functions to struct device, so e.g. readl(dev, offset) would call
> > into these accessors, which would implement the bus-specific behavior.
> > No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> > quirk is needed, at the (small on nowadays' machines) expense of
> > some indirection...
>
> I was just thinking that the access functions might need a 'device'.
> Although you also need the BAR (or equivalent).
> So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).

Note that we do have such a system: regmap.

> Clearly the 'dev' parameter could be compiled out for non-DEBUG
> build on x86 - leaving the current(ish) object code.

Assumed all devices are PCI devices.
E.g. USB devices would still need the indirection.

> You don't want an indirect call (this year), but maybe real
> function call and a few tests won't make that much difference.
> They might affect PCIe writes, but PCIe reads are so slow you
> need to avoid them whenever possible.
> I've not timed reads into something like an ethernet chip,
> but into our fpga they are probably 1000 clocks+.
>
> OTOH I wouldn't want any overhead on the PIO fifo reads
> on one of our small ppc devices.
> We push a lot of data though that fifo and anything extra
> would kill performance.

Right.

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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:02                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 15:02 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi David

On Fri, May 6, 2022 at 4:05 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> > > If a driver is probed on a ISA bus there ought to be functions
> > > equivalent to pci_ioremap() (for both memory and IO addresses)
> > > that return tokens appropriate for the specific bus.
> > >
> > > That is all a different load of churn.
> >
> > A loooong time ago,  it was suggested to add register accessor
> > functions to struct device, so e.g. readl(dev, offset) would call
> > into these accessors, which would implement the bus-specific behavior.
> > No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> > quirk is needed, at the (small on nowadays' machines) expense of
> > some indirection...
>
> I was just thinking that the access functions might need a 'device'.
> Although you also need the BAR (or equivalent).
> So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).

Note that we do have such a system: regmap.

> Clearly the 'dev' parameter could be compiled out for non-DEBUG
> build on x86 - leaving the current(ish) object code.

Assumed all devices are PCI devices.
E.g. USB devices would still need the indirection.

> You don't want an indirect call (this year), but maybe real
> function call and a few tests won't make that much difference.
> They might affect PCIe writes, but PCIe reads are so slow you
> need to avoid them whenever possible.
> I've not timed reads into something like an ethernet chip,
> but into our fpga they are probably 1000 clocks+.
>
> OTOH I wouldn't want any overhead on the PIO fifo reads
> on one of our small ppc devices.
> We push a lot of data though that fifo and anything extra
> would kill performance.

Right.

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:02                         ` Geert Uytterhoeven
  0 siblings, 0 replies; 392+ messages in thread
From: Geert Uytterhoeven @ 2022-05-06 15:02 UTC (permalink / raw)
  To: David Laight
  Cc: Maciej W. Rozycki, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)

Hi David

On Fri, May 6, 2022 at 4:05 PM David Laight <David.Laight@aculab.com> wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> > > If a driver is probed on a ISA bus there ought to be functions
> > > equivalent to pci_ioremap() (for both memory and IO addresses)
> > > that return tokens appropriate for the specific bus.
> > >
> > > That is all a different load of churn.
> >
> > A loooong time ago,  it was suggested to add register accessor
> > functions to struct device, so e.g. readl(dev, offset) would call
> > into these accessors, which would implement the bus-specific behavior.
> > No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> > quirk is needed, at the (small on nowadays' machines) expense of
> > some indirection...
>
> I was just thinking that the access functions might need a 'device'.
> Although you also need the BAR (or equivalent).
> So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).

Note that we do have such a system: regmap.

> Clearly the 'dev' parameter could be compiled out for non-DEBUG
> build on x86 - leaving the current(ish) object code.

Assumed all devices are PCI devices.
E.g. USB devices would still need the indirection.

> You don't want an indirect call (this year), but maybe real
> function call and a few tests won't make that much difference.
> They might affect PCIe writes, but PCIe reads are so slow you
> need to avoid them whenever possible.
> I've not timed reads into something like an ethernet chip,
> but into our fpga they are probably 1000 clocks+.
>
> OTOH I wouldn't want any overhead on the PIO fifo reads
> on one of our small ppc devices.
> We push a lot of data though that fifo and anything extra
> would kill performance.

Right.

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] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 14:56                           ` Geert Uytterhoeven
                                               ` (3 preceding siblings ...)
  (?)
@ 2022-05-06 15:03                             ` Maciej W. Rozycki
  -1 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 15:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Geert,
> >  Sane access would require a single CPU instruction to read or write from
> > the configuration space.  To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space.  Such amount of address space seems affordable even with
> > 32-bit systems.
> 
> Won't have fit in the legacy 1 MiB space ("640 KiB...").

 Haha, but anyway you're supposed to use BIOS calls under DOS and the like 
so it doesn't really matter.  You can't poke at the APIC in the legacy 
space either.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:03                             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 15:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, Linux Kernel Mailing List,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Bjorn Helgaas, linux-pci, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	open list:MIPS, David Laight, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Geert,
> >  Sane access would require a single CPU instruction to read or write from
> > the configuration space.  To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space.  Such amount of address space seems affordable even with
> > 32-bit systems.
> 
> Won't have fit in the legacy 1 MiB space ("640 KiB...").

 Haha, but anyway you're supposed to use BIOS calls under DOS and the like 
so it doesn't really matter.  You can't poke at the APIC in the legacy 
space either.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:03                             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 15:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Geert,
> >  Sane access would require a single CPU instruction to read or write from
> > the configuration space.  To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space.  Such amount of address space seems affordable even with
> > 32-bit systems.
> 
> Won't have fit in the legacy 1 MiB space ("640 KiB...").

 Haha, but anyway you're supposed to use BIOS calls under DOS and the like 
so it doesn't really matter.  You can't poke at the APIC in the legacy 
space either.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:03                             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 15:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Geert,
> >  Sane access would require a single CPU instruction to read or write from
> > the configuration space.  To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space.  Such amount of address space seems affordable even with
> > 32-bit systems.
> 
> Won't have fit in the legacy 1 MiB space ("640 KiB...").

 Haha, but anyway you're supposed to use BIOS calls under DOS and the like 
so it doesn't really matter.  You can't poke at the APIC in the legacy 
space either.

  Maciej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:03                             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 15:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, linux-pci, Bjorn Helgaas, Matt Turner,
	Albert Ou, Arnd Bergmann, Niklas Schnelle,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Michal Simek, Thomas Bogendoerfer, open list:PARISC ARCHITECTURE,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Palmer Dabbelt,
	open list:ALPHA PORT, Borislav Petkov,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

Hi Geert,
> >  Sane access would require a single CPU instruction to read or write from
> > the configuration space.  To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space.  Such amount of address space seems affordable even with
> > 32-bit systems.
> 
> Won't have fit in the legacy 1 MiB space ("640 KiB...").

 Haha, but anyway you're supposed to use BIOS calls under DOS and the like 
so it doesn't really matter.  You can't poke at the APIC in the legacy 
space either.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-06 15:03                             ` Maciej W. Rozycki
  0 siblings, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-05-06 15:03 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: David Laight, Arnd Bergmann, Rich Felker,
	open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)

Hi Geert,
> >  Sane access would require a single CPU instruction to read or write from
> > the configuration space.  To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space.  Such amount of address space seems affordable even with
> > 32-bit systems.
> 
> Won't have fit in the legacy 1 MiB space ("640 KiB...").

 Haha, but anyway you're supposed to use BIOS calls under DOS and the like 
so it doesn't really matter.  You can't poke at the APIC in the legacy 
space either.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-06 11:18                 ` Niklas Schnelle
                                     ` (3 preceding siblings ...)
  (?)
@ 2022-05-07  0:01                   ` Finn Thain
  -1 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07  0:01 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Bjorn Helgaas, Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Fri, 6 May 2022, Niklas Schnelle wrote:

> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > 
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > 
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > > The main goal is to avoid c), which is what happens on s390, 
> > > > > > but can also happen elsewhere. Catching b) would be nice as 
> > > > > > well, but is much harder to do from generic code as you'd need 
> > > > > > an architecture specific inline asm statement to insert a 
> > > > > > ex_table fixup, or a runtime conditional on each access.
> > > > > 
> > > > > Or s390 could implement its own inb().
> > > > > 
> > > > > I'm hearing that generic powerpc kernels have to run both on 
> > > > > machines that have I/O port space and those that don't.  That 
> > > > > makes me think s390 could do something similar.
> > > > 
> > > > No, this is actually the current situation, and it makes 
> > > > absolutely no sense. s390 has no way of implementing inb()/outb() 
> > > > because there are no instructions for it and it cannot tunnel them 
> > > > through a virtual address mapping like on most of the other 
> > > > architectures. (it has special instructions for accessing memory 
> > > > space, which is not the same as a pointer dereference here).
> > > > 
> > > > The existing implementation gets flagged as a NULL pointer 
> > > > dereference by a compiler warning because it effectively is.
> > > 
> > > I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
> > > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
> > > pointer dereference because the default PCI_IOBASE is 0.
> > > 
> > > I mooted a s390 inb() implementation like "return ~0" because that's 
> > > what happens on most arches when there's no device to respond to the 
> > > inb().
> > > 
> > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
> > > drivers that use I/O ports in some cases but not others.  But maybe 
> > > it's the most practical way.
> > > 
> > 
> > Do you mean, "the most practical way to avoid a compiler warning on 
> > s390"? What about "#pragma GCC diagnostic ignored"?
> 
> This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

> Apart from that, I think this would also fall under the same argument as 
> the original patch Linus unpulled. We would just paint over someting 
> that we know at compile time won't work:
> 
> https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> 

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07  0:01                   ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07  0:01 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	open list:M68K ARCHITECTURE, Ivan Kokshaysky, Paul Walmsley,
	Thomas Gleixner, moderated list:ARM PORT, Richard Henderson,
	Arnd Bergmann, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller


On Fri, 6 May 2022, Niklas Schnelle wrote:

> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > 
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > 
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > > The main goal is to avoid c), which is what happens on s390, 
> > > > > > but can also happen elsewhere. Catching b) would be nice as 
> > > > > > well, but is much harder to do from generic code as you'd need 
> > > > > > an architecture specific inline asm statement to insert a 
> > > > > > ex_table fixup, or a runtime conditional on each access.
> > > > > 
> > > > > Or s390 could implement its own inb().
> > > > > 
> > > > > I'm hearing that generic powerpc kernels have to run both on 
> > > > > machines that have I/O port space and those that don't.  That 
> > > > > makes me think s390 could do something similar.
> > > > 
> > > > No, this is actually the current situation, and it makes 
> > > > absolutely no sense. s390 has no way of implementing inb()/outb() 
> > > > because there are no instructions for it and it cannot tunnel them 
> > > > through a virtual address mapping like on most of the other 
> > > > architectures. (it has special instructions for accessing memory 
> > > > space, which is not the same as a pointer dereference here).
> > > > 
> > > > The existing implementation gets flagged as a NULL pointer 
> > > > dereference by a compiler warning because it effectively is.
> > > 
> > > I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
> > > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
> > > pointer dereference because the default PCI_IOBASE is 0.
> > > 
> > > I mooted a s390 inb() implementation like "return ~0" because that's 
> > > what happens on most arches when there's no device to respond to the 
> > > inb().
> > > 
> > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
> > > drivers that use I/O ports in some cases but not others.  But maybe 
> > > it's the most practical way.
> > > 
> > 
> > Do you mean, "the most practical way to avoid a compiler warning on 
> > s390"? What about "#pragma GCC diagnostic ignored"?
> 
> This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

> Apart from that, I think this would also fall under the same argument as 
> the original patch Linus unpulled. We would just paint over someting 
> that we know at compile time won't work:
> 
> https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> 

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07  0:01                   ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07  0:01 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Bjorn Helgaas, Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Fri, 6 May 2022, Niklas Schnelle wrote:

> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > 
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > 
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > > The main goal is to avoid c), which is what happens on s390, 
> > > > > > but can also happen elsewhere. Catching b) would be nice as 
> > > > > > well, but is much harder to do from generic code as you'd need 
> > > > > > an architecture specific inline asm statement to insert a 
> > > > > > ex_table fixup, or a runtime conditional on each access.
> > > > > 
> > > > > Or s390 could implement its own inb().
> > > > > 
> > > > > I'm hearing that generic powerpc kernels have to run both on 
> > > > > machines that have I/O port space and those that don't.  That 
> > > > > makes me think s390 could do something similar.
> > > > 
> > > > No, this is actually the current situation, and it makes 
> > > > absolutely no sense. s390 has no way of implementing inb()/outb() 
> > > > because there are no instructions for it and it cannot tunnel them 
> > > > through a virtual address mapping like on most of the other 
> > > > architectures. (it has special instructions for accessing memory 
> > > > space, which is not the same as a pointer dereference here).
> > > > 
> > > > The existing implementation gets flagged as a NULL pointer 
> > > > dereference by a compiler warning because it effectively is.
> > > 
> > > I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
> > > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
> > > pointer dereference because the default PCI_IOBASE is 0.
> > > 
> > > I mooted a s390 inb() implementation like "return ~0" because that's 
> > > what happens on most arches when there's no device to respond to the 
> > > inb().
> > > 
> > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
> > > drivers that use I/O ports in some cases but not others.  But maybe 
> > > it's the most practical way.
> > > 
> > 
> > Do you mean, "the most practical way to avoid a compiler warning on 
> > s390"? What about "#pragma GCC diagnostic ignored"?
> 
> This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

> Apart from that, I think this would also fall under the same argument as 
> the original patch Linus unpulled. We would just paint over someting 
> that we know at compile time won't work:
> 
> https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> 

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07  0:01                   ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07  0:01 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Bjorn Helgaas, Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Fri, 6 May 2022, Niklas Schnelle wrote:

> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > 
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > 
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > > The main goal is to avoid c), which is what happens on s390, 
> > > > > > but can also happen elsewhere. Catching b) would be nice as 
> > > > > > well, but is much harder to do from generic code as you'd need 
> > > > > > an architecture specific inline asm statement to insert a 
> > > > > > ex_table fixup, or a runtime conditional on each access.
> > > > > 
> > > > > Or s390 could implement its own inb().
> > > > > 
> > > > > I'm hearing that generic powerpc kernels have to run both on 
> > > > > machines that have I/O port space and those that don't.  That 
> > > > > makes me think s390 could do something similar.
> > > > 
> > > > No, this is actually the current situation, and it makes 
> > > > absolutely no sense. s390 has no way of implementing inb()/outb() 
> > > > because there are no instructions for it and it cannot tunnel them 
> > > > through a virtual address mapping like on most of the other 
> > > > architectures. (it has special instructions for accessing memory 
> > > > space, which is not the same as a pointer dereference here).
> > > > 
> > > > The existing implementation gets flagged as a NULL pointer 
> > > > dereference by a compiler warning because it effectively is.
> > > 
> > > I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
> > > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
> > > pointer dereference because the default PCI_IOBASE is 0.
> > > 
> > > I mooted a s390 inb() implementation like "return ~0" because that's 
> > > what happens on most arches when there's no device to respond to the 
> > > inb().
> > > 
> > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
> > > drivers that use I/O ports in some cases but not others.  But maybe 
> > > it's the most practical way.
> > > 
> > 
> > Do you mean, "the most practical way to avoid a compiler warning on 
> > s390"? What about "#pragma GCC diagnostic ignored"?
> 
> This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

> Apart from that, I think this would also fall under the same argument as 
> the original patch Linus unpulled. We would just paint over someting 
> that we know at compile time won't work:
> 
> https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> 

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07  0:01                   ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07  0:01 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Bjorn Helgaas, Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Yoshinori Sato, Rich Felker, David S. Miller, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Fri, 6 May 2022, Niklas Schnelle wrote:

> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > 
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > 
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > > The main goal is to avoid c), which is what happens on s390, 
> > > > > > but can also happen elsewhere. Catching b) would be nice as 
> > > > > > well, but is much harder to do from generic code as you'd need 
> > > > > > an architecture specific inline asm statement to insert a 
> > > > > > ex_table fixup, or a runtime conditional on each access.
> > > > > 
> > > > > Or s390 could implement its own inb().
> > > > > 
> > > > > I'm hearing that generic powerpc kernels have to run both on 
> > > > > machines that have I/O port space and those that don't.  That 
> > > > > makes me think s390 could do something similar.
> > > > 
> > > > No, this is actually the current situation, and it makes 
> > > > absolutely no sense. s390 has no way of implementing inb()/outb() 
> > > > because there are no instructions for it and it cannot tunnel them 
> > > > through a virtual address mapping like on most of the other 
> > > > architectures. (it has special instructions for accessing memory 
> > > > space, which is not the same as a pointer dereference here).
> > > > 
> > > > The existing implementation gets flagged as a NULL pointer 
> > > > dereference by a compiler warning because it effectively is.
> > > 
> > > I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
> > > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
> > > pointer dereference because the default PCI_IOBASE is 0.
> > > 
> > > I mooted a s390 inb() implementation like "return ~0" because that's 
> > > what happens on most arches when there's no device to respond to the 
> > > inb().
> > > 
> > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
> > > drivers that use I/O ports in some cases but not others.  But maybe 
> > > it's the most practical way.
> > > 
> > 
> > Do you mean, "the most practical way to avoid a compiler warning on 
> > s390"? What about "#pragma GCC diagnostic ignored"?
> 
> This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

> Apart from that, I think this would also fall under the same argument as 
> the original patch Linus unpulled. We would just paint over someting 
> that we know at compile time won't work:
> 
> https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> 

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07  0:01                   ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07  0:01 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Bjorn Helgaas, Arnd Bergmann, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
	Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
	Michael Ellerman, Paul Walmsley, Palmer Dabbelt, Albert Ou


On Fri, 6 May 2022, Niklas Schnelle wrote:

> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > 
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > 
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > > > The main goal is to avoid c), which is what happens on s390, 
> > > > > > but can also happen elsewhere. Catching b) would be nice as 
> > > > > > well, but is much harder to do from generic code as you'd need 
> > > > > > an architecture specific inline asm statement to insert a 
> > > > > > ex_table fixup, or a runtime conditional on each access.
> > > > > 
> > > > > Or s390 could implement its own inb().
> > > > > 
> > > > > I'm hearing that generic powerpc kernels have to run both on 
> > > > > machines that have I/O port space and those that don't.  That 
> > > > > makes me think s390 could do something similar.
> > > > 
> > > > No, this is actually the current situation, and it makes 
> > > > absolutely no sense. s390 has no way of implementing inb()/outb() 
> > > > because there are no instructions for it and it cannot tunnel them 
> > > > through a virtual address mapping like on most of the other 
> > > > architectures. (it has special instructions for accessing memory 
> > > > space, which is not the same as a pointer dereference here).
> > > > 
> > > > The existing implementation gets flagged as a NULL pointer 
> > > > dereference by a compiler warning because it effectively is.
> > > 
> > > I think s390 currently uses the inb() in asm-generic/io.h, i.e., 
> > > "__raw_readb(PCI_IOBASE + addr)".  I understand that's a NULL 
> > > pointer dereference because the default PCI_IOBASE is 0.
> > > 
> > > I mooted a s390 inb() implementation like "return ~0" because that's 
> > > what happens on most arches when there's no device to respond to the 
> > > inb().
> > > 
> > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter 
> > > drivers that use I/O ports in some cases but not others.  But maybe 
> > > it's the most practical way.
> > > 
> > 
> > Do you mean, "the most practical way to avoid a compiler warning on 
> > s390"? What about "#pragma GCC diagnostic ignored"?
> 
> This actually happens with clang.

That suggests a clang bug to me. If you believe GCC should behave like 
clang, then I guess the pragma above really is the one you want. If you 
somehow feel that the kernel should cater to gcc and clang even where they 
disagree then you would have to use "#pragma clang diagnostic ignored".

> Apart from that, I think this would also fall under the same argument as 
> the original patch Linus unpulled. We would just paint over someting 
> that we know at compile time won't work:
> 
> https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> 

I wasn't advocating adding any warnings.

If you know at compile time that a driver won't work, the usual solution 
is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no 
longer appropriate for drivers that use IO ports?

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-07  0:01                   ` Finn Thain
                                       ` (3 preceding siblings ...)
  (?)
@ 2022-05-07 13:14                     ` Arnd Bergmann
  -1 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-07 13:14 UTC (permalink / raw)
  To: Finn Thain
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what happens on most arches when there's no device to respond to the
> > > > inb().
> > > >
> > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > it's the most practical way.
> > > >
> > >
> > > Do you mean, "the most practical way to avoid a compiler warning on
> > > s390"? What about "#pragma GCC diagnostic ignored"?
> >
> > This actually happens with clang.
>
> That suggests a clang bug to me. If you believe GCC should behave like
> clang, then I guess the pragma above really is the one you want. If you
> somehow feel that the kernel should cater to gcc and clang even where they
> disagree then you would have to use "#pragma clang diagnostic ignored".

I don't see how you can blame the compiler for this. On architectures
with a zero PCI_IOBASE, an inb(0x2f8) literally becomes

        var = *(u8*)((NULL + 0x2f8);

If you run a driver that does this, the kernel gets a page fault for
the NULL page
and reports an Oops. clang tells you 'warning: performing pointer
arithmetic on a null pointer has undefined behavior', which is not exactly
spot on, but close enough to warn you that you probably shouldn't do this. gcc
doesn't warn here, but it does warn about an array out-of-bounds access when
you pass such a pointer into memcpy or another string function.

> > Apart from that, I think this would also fall under the same argument as
> > the original patch Linus unpulled. We would just paint over someting
> > that we know at compile time won't work:
> >
> > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >
>
> I wasn't advocating adding any warnings.
>
> If you know at compile time that a driver won't work, the usual solution
> is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> longer appropriate for drivers that use IO ports?

This was never an option, we rely on 'make allmodconfig' to build without
warnings on all architectures for finding regressions. Any driver that depends
on architecture specific interfaces must not get selected on architectures that
don't have those interfaces.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 13:14                     ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-07 13:14 UTC (permalink / raw)
  To: Finn Thain
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what happens on most arches when there's no device to respond to the
> > > > inb().
> > > >
> > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > it's the most practical way.
> > > >
> > >
> > > Do you mean, "the most practical way to avoid a compiler warning on
> > > s390"? What about "#pragma GCC diagnostic ignored"?
> >
> > This actually happens with clang.
>
> That suggests a clang bug to me. If you believe GCC should behave like
> clang, then I guess the pragma above really is the one you want. If you
> somehow feel that the kernel should cater to gcc and clang even where they
> disagree then you would have to use "#pragma clang diagnostic ignored".

I don't see how you can blame the compiler for this. On architectures
with a zero PCI_IOBASE, an inb(0x2f8) literally becomes

        var = *(u8*)((NULL + 0x2f8);

If you run a driver that does this, the kernel gets a page fault for
the NULL page
and reports an Oops. clang tells you 'warning: performing pointer
arithmetic on a null pointer has undefined behavior', which is not exactly
spot on, but close enough to warn you that you probably shouldn't do this. gcc
doesn't warn here, but it does warn about an array out-of-bounds access when
you pass such a pointer into memcpy or another string function.

> > Apart from that, I think this would also fall under the same argument as
> > the original patch Linus unpulled. We would just paint over someting
> > that we know at compile time won't work:
> >
> > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >
>
> I wasn't advocating adding any warnings.
>
> If you know at compile time that a driver won't work, the usual solution
> is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> longer appropriate for drivers that use IO ports?

This was never an option, we rely on 'make allmodconfig' to build without
warnings on all architectures for finding regressions. Any driver that depends
on architecture specific interfaces must not get selected on architectures that
don't have those interfaces.

         Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 13:14                     ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-07 13:14 UTC (permalink / raw)
  To: Finn Thain
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller

On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what happens on most arches when there's no device to respond to the
> > > > inb().
> > > >
> > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > it's the most practical way.
> > > >
> > >
> > > Do you mean, "the most practical way to avoid a compiler warning on
> > > s390"? What about "#pragma GCC diagnostic ignored"?
> >
> > This actually happens with clang.
>
> That suggests a clang bug to me. If you believe GCC should behave like
> clang, then I guess the pragma above really is the one you want. If you
> somehow feel that the kernel should cater to gcc and clang even where they
> disagree then you would have to use "#pragma clang diagnostic ignored".

I don't see how you can blame the compiler for this. On architectures
with a zero PCI_IOBASE, an inb(0x2f8) literally becomes

        var = *(u8*)((NULL + 0x2f8);

If you run a driver that does this, the kernel gets a page fault for
the NULL page
and reports an Oops. clang tells you 'warning: performing pointer
arithmetic on a null pointer has undefined behavior', which is not exactly
spot on, but close enough to warn you that you probably shouldn't do this. gcc
doesn't warn here, but it does warn about an array out-of-bounds access when
you pass such a pointer into memcpy or another string function.

> > Apart from that, I think this would also fall under the same argument as
> > the original patch Linus unpulled. We would just paint over someting
> > that we know at compile time won't work:
> >
> > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >
>
> I wasn't advocating adding any warnings.
>
> If you know at compile time that a driver won't work, the usual solution
> is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> longer appropriate for drivers that use IO ports?

This was never an option, we rely on 'make allmodconfig' to build without
warnings on all architectures for finding regressions. Any driver that depends
on architecture specific interfaces must not get selected on architectures that
don't have those interfaces.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 13:14                     ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-07 13:14 UTC (permalink / raw)
  To: Finn Thain
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what happens on most arches when there's no device to respond to the
> > > > inb().
> > > >
> > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > it's the most practical way.
> > > >
> > >
> > > Do you mean, "the most practical way to avoid a compiler warning on
> > > s390"? What about "#pragma GCC diagnostic ignored"?
> >
> > This actually happens with clang.
>
> That suggests a clang bug to me. If you believe GCC should behave like
> clang, then I guess the pragma above really is the one you want. If you
> somehow feel that the kernel should cater to gcc and clang even where they
> disagree then you would have to use "#pragma clang diagnostic ignored".

I don't see how you can blame the compiler for this. On architectures
with a zero PCI_IOBASE, an inb(0x2f8) literally becomes

        var = *(u8*)((NULL + 0x2f8);

If you run a driver that does this, the kernel gets a page fault for
the NULL page
and reports an Oops. clang tells you 'warning: performing pointer
arithmetic on a null pointer has undefined behavior', which is not exactly
spot on, but close enough to warn you that you probably shouldn't do this. gcc
doesn't warn here, but it does warn about an array out-of-bounds access when
you pass such a pointer into memcpy or another string function.

> > Apart from that, I think this would also fall under the same argument as
> > the original patch Linus unpulled. We would just paint over someting
> > that we know at compile time won't work:
> >
> > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >
>
> I wasn't advocating adding any warnings.
>
> If you know at compile time that a driver won't work, the usual solution
> is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> longer appropriate for drivers that use IO ports?

This was never an option, we rely on 'make allmodconfig' to build without
warnings on all architectures for finding regressions. Any driver that depends
on architecture specific interfaces must not get selected on architectures that
don't have those interfaces.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 13:14                     ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-07 13:14 UTC (permalink / raw)
  To: Finn Thain
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)

On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what happens on most arches when there's no device to respond to the
> > > > inb().
> > > >
> > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > it's the most practical way.
> > > >
> > >
> > > Do you mean, "the most practical way to avoid a compiler warning on
> > > s390"? What about "#pragma GCC diagnostic ignored"?
> >
> > This actually happens with clang.
>
> That suggests a clang bug to me. If you believe GCC should behave like
> clang, then I guess the pragma above really is the one you want. If you
> somehow feel that the kernel should cater to gcc and clang even where they
> disagree then you would have to use "#pragma clang diagnostic ignored".

I don't see how you can blame the compiler for this. On architectures
with a zero PCI_IOBASE, an inb(0x2f8) literally becomes

        var = *(u8*)((NULL + 0x2f8);

If you run a driver that does this, the kernel gets a page fault for
the NULL page
and reports an Oops. clang tells you 'warning: performing pointer
arithmetic on a null pointer has undefined behavior', which is not exactly
spot on, but close enough to warn you that you probably shouldn't do this. gcc
doesn't warn here, but it does warn about an array out-of-bounds access when
you pass such a pointer into memcpy or another string function.

> > Apart from that, I think this would also fall under the same argument as
> > the original patch Linus unpulled. We would just paint over someting
> > that we know at compile time won't work:
> >
> > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >
>
> I wasn't advocating adding any warnings.
>
> If you know at compile time that a driver won't work, the usual solution
> is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> longer appropriate for drivers that use IO ports?

This was never an option, we rely on 'make allmodconfig' to build without
warnings on all architectures for finding regressions. Any driver that depends
on architecture specific interfaces must not get selected on architectures that
don't have those interfaces.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 13:14                     ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-07 13:14 UTC (permalink / raw)
  To: Finn Thain
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael

On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what happens on most arches when there's no device to respond to the
> > > > inb().
> > > >
> > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > it's the most practical way.
> > > >
> > >
> > > Do you mean, "the most practical way to avoid a compiler warning on
> > > s390"? What about "#pragma GCC diagnostic ignored"?
> >
> > This actually happens with clang.
>
> That suggests a clang bug to me. If you believe GCC should behave like
> clang, then I guess the pragma above really is the one you want. If you
> somehow feel that the kernel should cater to gcc and clang even where they
> disagree then you would have to use "#pragma clang diagnostic ignored".

I don't see how you can blame the compiler for this. On architectures
with a zero PCI_IOBASE, an inb(0x2f8) literally becomes

        var = *(u8*)((NULL + 0x2f8);

If you run a driver that does this, the kernel gets a page fault for
the NULL page
and reports an Oops. clang tells you 'warning: performing pointer
arithmetic on a null pointer has undefined behavior', which is not exactly
spot on, but close enough to warn you that you probably shouldn't do this. gcc
doesn't warn here, but it does warn about an array out-of-bounds access when
you pass such a pointer into memcpy or another string function.

> > Apart from that, I think this would also fall under the same argument as
> > the original patch Linus unpulled. We would just paint over someting
> > that we know at compile time won't work:
> >
> > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> >
>
> I wasn't advocating adding any warnings.
>
> If you know at compile time that a driver won't work, the usual solution
> is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> longer appropriate for drivers that use IO ports?

This was never an option, we rely on 'make allmodconfig' to build without
warnings on all architectures for finding regressions. Any driver that depends
on architecture specific interfaces must not get selected on architectures that
don't have those interfaces.

         Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-07 13:14                     ` Arnd Bergmann
                                         ` (3 preceding siblings ...)
  (?)
@ 2022-05-07 23:59                       ` Finn Thain
  -1 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07 23:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


Hi Arnd,

On Sat, 7 May 2022, Arnd Bergmann wrote:

> On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > > what happens on most arches when there's no device to respond to the
> > > > > inb().
> > > > >
> > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > > it's the most practical way.
> > > > >
> > > >
> > > > Do you mean, "the most practical way to avoid a compiler warning on
> > > > s390"? What about "#pragma GCC diagnostic ignored"?
> > >
> > > This actually happens with clang.
> >
> > That suggests a clang bug to me. If you believe GCC should behave like
> > clang, then I guess the pragma above really is the one you want. If you
> > somehow feel that the kernel should cater to gcc and clang even where they
> > disagree then you would have to use "#pragma clang diagnostic ignored".
> 
> I don't see how you can blame the compiler for this. On architectures
> with a zero PCI_IOBASE, an inb(0x2f8) literally becomes
> 
>         var = *(u8*)((NULL + 0x2f8);
> 
> If you run a driver that does this, the kernel gets a page fault for
> the NULL page
> and reports an Oops. clang tells you 'warning: performing pointer
> arithmetic on a null pointer has undefined behavior', which is not exactly
> spot on, but close enough to warn you that you probably shouldn't do this. gcc
> doesn't warn here, but it does warn about an array out-of-bounds access when
> you pass such a pointer into memcpy or another string function.
> 

The appeal to UB is weak IMHO. Pointer arithmetic with a zero value is 
unambiguous and the compiler generates the code to implement the expected 
behaviour just fine.

UB is literally an omission in the standard. Well, low level programming 
has always been beyond the scope of C standards. If architectural-level 
code wants to do arithmetic with an arbitrary integer values, and the 
compiler doesn't like it, then the relevant warnings should be disabled 
for those expressions.

> > > Apart from that, I think this would also fall under the same argument as
> > > the original patch Linus unpulled. We would just paint over someting
> > > that we know at compile time won't work:
> > >
> > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> > >
> >
> > I wasn't advocating adding any warnings.
> >
> > If you know at compile time that a driver won't work, the usual solution
> > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> > longer appropriate for drivers that use IO ports?
> 
> This was never an option, we rely on 'make allmodconfig' to build 
> without warnings on all architectures for finding regressions.

"All modules on all architectures with all compilers and checkers with all 
warnings enabled"? That's not even vaguely realistic.

How about, "All modules on all architectures with a nominated compiler 
with the appropriate warnings enabled."

> Any driver that depends on architecture specific interfaces must not get 
> selected on architectures that don't have those interfaces.
> 

Kconfig always met that need before we got saddled with -Werror.

That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
control -Werror, which could be disabled for .config files (like make 
allmodconfig) where it is not helping.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 23:59                       ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07 23:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


Hi Arnd,

On Sat, 7 May 2022, Arnd Bergmann wrote:

> On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > > what happens on most arches when there's no device to respond to the
> > > > > inb().
> > > > >
> > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > > it's the most practical way.
> > > > >
> > > >
> > > > Do you mean, "the most practical way to avoid a compiler warning on
> > > > s390"? What about "#pragma GCC diagnostic ignored"?
> > >
> > > This actually happens with clang.
> >
> > That suggests a clang bug to me. If you believe GCC should behave like
> > clang, then I guess the pragma above really is the one you want. If you
> > somehow feel that the kernel should cater to gcc and clang even where they
> > disagree then you would have to use "#pragma clang diagnostic ignored".
> 
> I don't see how you can blame the compiler for this. On architectures
> with a zero PCI_IOBASE, an inb(0x2f8) literally becomes
> 
>         var = *(u8*)((NULL + 0x2f8);
> 
> If you run a driver that does this, the kernel gets a page fault for
> the NULL page
> and reports an Oops. clang tells you 'warning: performing pointer
> arithmetic on a null pointer has undefined behavior', which is not exactly
> spot on, but close enough to warn you that you probably shouldn't do this. gcc
> doesn't warn here, but it does warn about an array out-of-bounds access when
> you pass such a pointer into memcpy or another string function.
> 

The appeal to UB is weak IMHO. Pointer arithmetic with a zero value is 
unambiguous and the compiler generates the code to implement the expected 
behaviour just fine.

UB is literally an omission in the standard. Well, low level programming 
has always been beyond the scope of C standards. If architectural-level 
code wants to do arithmetic with an arbitrary integer values, and the 
compiler doesn't like it, then the relevant warnings should be disabled 
for those expressions.

> > > Apart from that, I think this would also fall under the same argument as
> > > the original patch Linus unpulled. We would just paint over someting
> > > that we know at compile time won't work:
> > >
> > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> > >
> >
> > I wasn't advocating adding any warnings.
> >
> > If you know at compile time that a driver won't work, the usual solution
> > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> > longer appropriate for drivers that use IO ports?
> 
> This was never an option, we rely on 'make allmodconfig' to build 
> without warnings on all architectures for finding regressions.

"All modules on all architectures with all compilers and checkers with all 
warnings enabled"? That's not even vaguely realistic.

How about, "All modules on all architectures with a nominated compiler 
with the appropriate warnings enabled."

> Any driver that depends on architecture specific interfaces must not get 
> selected on architectures that don't have those interfaces.
> 

Kconfig always met that need before we got saddled with -Werror.

That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
control -Werror, which could be disabled for .config files (like make 
allmodconfig) where it is not helping.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 23:59                       ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07 23:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller


Hi Arnd,

On Sat, 7 May 2022, Arnd Bergmann wrote:

> On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > > what happens on most arches when there's no device to respond to the
> > > > > inb().
> > > > >
> > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > > it's the most practical way.
> > > > >
> > > >
> > > > Do you mean, "the most practical way to avoid a compiler warning on
> > > > s390"? What about "#pragma GCC diagnostic ignored"?
> > >
> > > This actually happens with clang.
> >
> > That suggests a clang bug to me. If you believe GCC should behave like
> > clang, then I guess the pragma above really is the one you want. If you
> > somehow feel that the kernel should cater to gcc and clang even where they
> > disagree then you would have to use "#pragma clang diagnostic ignored".
> 
> I don't see how you can blame the compiler for this. On architectures
> with a zero PCI_IOBASE, an inb(0x2f8) literally becomes
> 
>         var = *(u8*)((NULL + 0x2f8);
> 
> If you run a driver that does this, the kernel gets a page fault for
> the NULL page
> and reports an Oops. clang tells you 'warning: performing pointer
> arithmetic on a null pointer has undefined behavior', which is not exactly
> spot on, but close enough to warn you that you probably shouldn't do this. gcc
> doesn't warn here, but it does warn about an array out-of-bounds access when
> you pass such a pointer into memcpy or another string function.
> 

The appeal to UB is weak IMHO. Pointer arithmetic with a zero value is 
unambiguous and the compiler generates the code to implement the expected 
behaviour just fine.

UB is literally an omission in the standard. Well, low level programming 
has always been beyond the scope of C standards. If architectural-level 
code wants to do arithmetic with an arbitrary integer values, and the 
compiler doesn't like it, then the relevant warnings should be disabled 
for those expressions.

> > > Apart from that, I think this would also fall under the same argument as
> > > the original patch Linus unpulled. We would just paint over someting
> > > that we know at compile time won't work:
> > >
> > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> > >
> >
> > I wasn't advocating adding any warnings.
> >
> > If you know at compile time that a driver won't work, the usual solution
> > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> > longer appropriate for drivers that use IO ports?
> 
> This was never an option, we rely on 'make allmodconfig' to build 
> without warnings on all architectures for finding regressions.

"All modules on all architectures with all compilers and checkers with all 
warnings enabled"? That's not even vaguely realistic.

How about, "All modules on all architectures with a nominated compiler 
with the appropriate warnings enabled."

> Any driver that depends on architecture specific interfaces must not get 
> selected on architectures that don't have those interfaces.
> 

Kconfig always met that need before we got saddled with -Werror.

That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
control -Werror, which could be disabled for .config files (like make 
allmodconfig) where it is not helping.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 23:59                       ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07 23:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


Hi Arnd,

On Sat, 7 May 2022, Arnd Bergmann wrote:

> On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > > what happens on most arches when there's no device to respond to the
> > > > > inb().
> > > > >
> > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > > it's the most practical way.
> > > > >
> > > >
> > > > Do you mean, "the most practical way to avoid a compiler warning on
> > > > s390"? What about "#pragma GCC diagnostic ignored"?
> > >
> > > This actually happens with clang.
> >
> > That suggests a clang bug to me. If you believe GCC should behave like
> > clang, then I guess the pragma above really is the one you want. If you
> > somehow feel that the kernel should cater to gcc and clang even where they
> > disagree then you would have to use "#pragma clang diagnostic ignored".
> 
> I don't see how you can blame the compiler for this. On architectures
> with a zero PCI_IOBASE, an inb(0x2f8) literally becomes
> 
>         var = *(u8*)((NULL + 0x2f8);
> 
> If you run a driver that does this, the kernel gets a page fault for
> the NULL page
> and reports an Oops. clang tells you 'warning: performing pointer
> arithmetic on a null pointer has undefined behavior', which is not exactly
> spot on, but close enough to warn you that you probably shouldn't do this. gcc
> doesn't warn here, but it does warn about an array out-of-bounds access when
> you pass such a pointer into memcpy or another string function.
> 

The appeal to UB is weak IMHO. Pointer arithmetic with a zero value is 
unambiguous and the compiler generates the code to implement the expected 
behaviour just fine.

UB is literally an omission in the standard. Well, low level programming 
has always been beyond the scope of C standards. If architectural-level 
code wants to do arithmetic with an arbitrary integer values, and the 
compiler doesn't like it, then the relevant warnings should be disabled 
for those expressions.

> > > Apart from that, I think this would also fall under the same argument as
> > > the original patch Linus unpulled. We would just paint over someting
> > > that we know at compile time won't work:
> > >
> > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> > >
> >
> > I wasn't advocating adding any warnings.
> >
> > If you know at compile time that a driver won't work, the usual solution
> > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> > longer appropriate for drivers that use IO ports?
> 
> This was never an option, we rely on 'make allmodconfig' to build 
> without warnings on all architectures for finding regressions.

"All modules on all architectures with all compilers and checkers with all 
warnings enabled"? That's not even vaguely realistic.

How about, "All modules on all architectures with a nominated compiler 
with the appropriate warnings enabled."

> Any driver that depends on architecture specific interfaces must not get 
> selected on architectures that don't have those interfaces.
> 

Kconfig always met that need before we got saddled with -Werror.

That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
control -Werror, which could be disabled for .config files (like make 
allmodconfig) where it is not helping.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 23:59                       ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07 23:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


Hi Arnd,

On Sat, 7 May 2022, Arnd Bergmann wrote:

> On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > > what happens on most arches when there's no device to respond to the
> > > > > inb().
> > > > >
> > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > > it's the most practical way.
> > > > >
> > > >
> > > > Do you mean, "the most practical way to avoid a compiler warning on
> > > > s390"? What about "#pragma GCC diagnostic ignored"?
> > >
> > > This actually happens with clang.
> >
> > That suggests a clang bug to me. If you believe GCC should behave like
> > clang, then I guess the pragma above really is the one you want. If you
> > somehow feel that the kernel should cater to gcc and clang even where they
> > disagree then you would have to use "#pragma clang diagnostic ignored".
> 
> I don't see how you can blame the compiler for this. On architectures
> with a zero PCI_IOBASE, an inb(0x2f8) literally becomes
> 
>         var = *(u8*)((NULL + 0x2f8);
> 
> If you run a driver that does this, the kernel gets a page fault for
> the NULL page
> and reports an Oops. clang tells you 'warning: performing pointer
> arithmetic on a null pointer has undefined behavior', which is not exactly
> spot on, but close enough to warn you that you probably shouldn't do this. gcc
> doesn't warn here, but it does warn about an array out-of-bounds access when
> you pass such a pointer into memcpy or another string function.
> 

The appeal to UB is weak IMHO. Pointer arithmetic with a zero value is 
unambiguous and the compiler generates the code to implement the expected 
behaviour just fine.

UB is literally an omission in the standard. Well, low level programming 
has always been beyond the scope of C standards. If architectural-level 
code wants to do arithmetic with an arbitrary integer values, and the 
compiler doesn't like it, then the relevant warnings should be disabled 
for those expressions.

> > > Apart from that, I think this would also fall under the same argument as
> > > the original patch Linus unpulled. We would just paint over someting
> > > that we know at compile time won't work:
> > >
> > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> > >
> >
> > I wasn't advocating adding any warnings.
> >
> > If you know at compile time that a driver won't work, the usual solution
> > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> > longer appropriate for drivers that use IO ports?
> 
> This was never an option, we rely on 'make allmodconfig' to build 
> without warnings on all architectures for finding regressions.

"All modules on all architectures with all compilers and checkers with all 
warnings enabled"? That's not even vaguely realistic.

How about, "All modules on all architectures with a nominated compiler 
with the appropriate warnings enabled."

> Any driver that depends on architecture specific interfaces must not get 
> selected on architectures that don't have those interfaces.
> 

Kconfig always met that need before we got saddled with -Werror.

That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
control -Werror, which could be disabled for .config files (like make 
allmodconfig) where it is not helping.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-07 23:59                       ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-07 23:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael


Hi Arnd,

On Sat, 7 May 2022, Arnd Bergmann wrote:

> On Sat, May 7, 2022 at 2:01 AM Finn Thain <fthain@linux-m68k.org> wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > > what happens on most arches when there's no device to respond to the
> > > > > inb().
> > > > >
> > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter
> > > > > drivers that use I/O ports in some cases but not others.  But maybe
> > > > > it's the most practical way.
> > > > >
> > > >
> > > > Do you mean, "the most practical way to avoid a compiler warning on
> > > > s390"? What about "#pragma GCC diagnostic ignored"?
> > >
> > > This actually happens with clang.
> >
> > That suggests a clang bug to me. If you believe GCC should behave like
> > clang, then I guess the pragma above really is the one you want. If you
> > somehow feel that the kernel should cater to gcc and clang even where they
> > disagree then you would have to use "#pragma clang diagnostic ignored".
> 
> I don't see how you can blame the compiler for this. On architectures
> with a zero PCI_IOBASE, an inb(0x2f8) literally becomes
> 
>         var = *(u8*)((NULL + 0x2f8);
> 
> If you run a driver that does this, the kernel gets a page fault for
> the NULL page
> and reports an Oops. clang tells you 'warning: performing pointer
> arithmetic on a null pointer has undefined behavior', which is not exactly
> spot on, but close enough to warn you that you probably shouldn't do this. gcc
> doesn't warn here, but it does warn about an array out-of-bounds access when
> you pass such a pointer into memcpy or another string function.
> 

The appeal to UB is weak IMHO. Pointer arithmetic with a zero value is 
unambiguous and the compiler generates the code to implement the expected 
behaviour just fine.

UB is literally an omission in the standard. Well, low level programming 
has always been beyond the scope of C standards. If architectural-level 
code wants to do arithmetic with an arbitrary integer values, and the 
compiler doesn't like it, then the relevant warnings should be disabled 
for those expressions.

> > > Apart from that, I think this would also fall under the same argument as
> > > the original patch Linus unpulled. We would just paint over someting
> > > that we know at compile time won't work:
> > >
> > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
> > >
> >
> > I wasn't advocating adding any warnings.
> >
> > If you know at compile time that a driver won't work, the usual solution
> > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no
> > longer appropriate for drivers that use IO ports?
> 
> This was never an option, we rely on 'make allmodconfig' to build 
> without warnings on all architectures for finding regressions.

"All modules on all architectures with all compilers and checkers with all 
warnings enabled"? That's not even vaguely realistic.

How about, "All modules on all architectures with a nominated compiler 
with the appropriate warnings enabled."

> Any driver that depends on architecture specific interfaces must not get 
> selected on architectures that don't have those interfaces.
> 

Kconfig always met that need before we got saddled with -Werror.

That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
control -Werror, which could be disabled for .config files (like make 
allmodconfig) where it is not helping.

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
  2022-05-07 23:59                       ` Finn Thain
                                           ` (3 preceding siblings ...)
  (?)
@ 2022-05-08  0:15                         ` Finn Thain
  -1 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-08  0:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Sun, 8 May 2022, I wrote:

> 
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
> control -Werror, which could be disabled for .config files (like make 
> allmodconfig) where it is not helping.
> 

I just noticed that we already have CONFIG_WERROR. So perhaps something 
like this would help.

diff --git a/init/Kconfig b/init/Kconfig
index ddcbefe535e9..765d83fb148e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -150,6 +150,8 @@ config WERROR
 
 	  However, if you have a new (or very old) compiler with odd and
 	  unusual warnings, or you have some architecture with problems,
+	  or if you are using a compiler that doesn't happen to interpret
+	  the C standards in quite the same way as some other compilers,
 	  you may need to disable this config option in order to
 	  successfully build the kernel.
 

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-08  0:15                         ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-08  0:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Sun, 8 May 2022, I wrote:

> 
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
> control -Werror, which could be disabled for .config files (like make 
> allmodconfig) where it is not helping.
> 

I just noticed that we already have CONFIG_WERROR. So perhaps something 
like this would help.

diff --git a/init/Kconfig b/init/Kconfig
index ddcbefe535e9..765d83fb148e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -150,6 +150,8 @@ config WERROR
 
 	  However, if you have a new (or very old) compiler with odd and
 	  unusual warnings, or you have some architecture with problems,
+	  or if you are using a compiler that doesn't happen to interpret
+	  the C standards in quite the same way as some other compilers,
 	  you may need to disable this config option in order to
 	  successfully build the kernel.
 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-08  0:15                         ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-08  0:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Rich Felker, open list:IA64 (Itanium) PLATFORM, open list:SUPERH,
	Catalin Marinas, Dave Hansen, open list:MIPS,
	James E.J. Bottomley,
	open list:SPARC + UltraSPARC (sparc/sparc64),
	open list:RISC-V ARCHITECTURE, Will Deacon, linux-arch,
	Yoshinori Sato, Helge Deller,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Russell King, Ingo Molnar, Geert Uytterhoeven, linux-pci,
	Bjorn Helgaas, Matt Turner, Albert Ou, Arnd Bergmann,
	Niklas Schnelle, open list:M68K ARCHITECTURE, Ivan Kokshaysky,
	Paul Walmsley, Thomas Gleixner, moderated list:ARM PORT,
	Richard Henderson, Michal Simek, Thomas Bogendoerfer,
	open list:PARISC ARCHITECTURE, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Palmer Dabbelt, open list:ALPHA PORT,
	Borislav Petkov, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	David S. Miller


On Sun, 8 May 2022, I wrote:

> 
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
> control -Werror, which could be disabled for .config files (like make 
> allmodconfig) where it is not helping.
> 

I just noticed that we already have CONFIG_WERROR. So perhaps something 
like this would help.

diff --git a/init/Kconfig b/init/Kconfig
index ddcbefe535e9..765d83fb148e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -150,6 +150,8 @@ config WERROR
 
 	  However, if you have a new (or very old) compiler with odd and
 	  unusual warnings, or you have some architecture with problems,
+	  or if you are using a compiler that doesn't happen to interpret
+	  the C standards in quite the same way as some other compilers,
 	  you may need to disable this config option in order to
 	  successfully build the kernel.
 

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-08  0:15                         ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-08  0:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Sun, 8 May 2022, I wrote:

> 
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
> control -Werror, which could be disabled for .config files (like make 
> allmodconfig) where it is not helping.
> 

I just noticed that we already have CONFIG_WERROR. So perhaps something 
like this would help.

diff --git a/init/Kconfig b/init/Kconfig
index ddcbefe535e9..765d83fb148e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -150,6 +150,8 @@ config WERROR
 
 	  However, if you have a new (or very old) compiler with odd and
 	  unusual warnings, or you have some architecture with problems,
+	  or if you are using a compiler that doesn't happen to interpret
+	  the C standards in quite the same way as some other compilers,
 	  you may need to disable this config option in order to
 	  successfully build the kernel.
 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-08  0:15                         ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-08  0:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael Ellerman, Paul Walmsley, Palmer Dabbelt,
	Albert Ou, Yoshinori Sato, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	open list:ALPHA PORT, moderated list:ARM PORT,
	open list:IA64 (Itanium) PLATFORM, open list:M68K ARCHITECTURE,
	open list:MIPS, open list:PARISC ARCHITECTURE,
	open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
	open list:RISC-V ARCHITECTURE, open list:SUPERH,
	open list:SPARC + UltraSPARC (sparc/sparc64)


On Sun, 8 May 2022, I wrote:

> 
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
> control -Werror, which could be disabled for .config files (like make 
> allmodconfig) where it is not helping.
> 

I just noticed that we already have CONFIG_WERROR. So perhaps something 
like this would help.

diff --git a/init/Kconfig b/init/Kconfig
index ddcbefe535e9..765d83fb148e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -150,6 +150,8 @@ config WERROR
 
 	  However, if you have a new (or very old) compiler with odd and
 	  unusual warnings, or you have some architecture with problems,
+	  or if you are using a compiler that doesn't happen to interpret
+	  the C standards in quite the same way as some other compilers,
 	  you may need to disable this config option in order to
 	  successfully build the kernel.
 

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
@ 2022-05-08  0:15                         ` Finn Thain
  0 siblings, 0 replies; 392+ messages in thread
From: Finn Thain @ 2022-05-08  0:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Bjorn Helgaas, Arnd Bergmann,
	Greg Kroah-Hartman, Linux Kernel Mailing List, linux-arch,
	linux-pci, Richard Henderson, Ivan Kokshaysky, Matt Turner,
	Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Michal Simek, Thomas Bogendoerfer, James E.J. Bottomley,
	Helge Deller, Michael


On Sun, 8 May 2022, I wrote:

> 
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to 
> control -Werror, which could be disabled for .config files (like make 
> allmodconfig) where it is not helping.
> 

I just noticed that we already have CONFIG_WERROR. So perhaps something 
like this would help.

diff --git a/init/Kconfig b/init/Kconfig
index ddcbefe535e9..765d83fb148e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -150,6 +150,8 @@ config WERROR
 
 	  However, if you have a new (or very old) compiler with odd and
 	  unusual warnings, or you have some architecture with problems,
+	  or if you are using a compiler that doesn't happen to interpret
+	  the C standards in quite the same way as some other compilers,
 	  you may need to disable this config option in order to
 	  successfully build the kernel.
 

^ permalink raw reply related	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
  2022-04-29 13:50   ` Niklas Schnelle
@ 2022-05-09  8:53     ` Takashi Iwai
  -1 siblings, 0 replies; 392+ messages in thread
From: Takashi Iwai @ 2022-05-09  8:53 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: linux-arch, Arnd Bergmann, moderated list:SOUND, Arnd Bergmann,
	Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-pci

On Fri, 29 Apr 2022 15:50:54 +0200,
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. For SND_OPL3_LIB this adds its first
> dependency so drivers currently selecting it unconditionally need to
> depend on it instead.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
>  sound/drivers/Kconfig |  5 ++++
>  sound/isa/Kconfig     | 44 ++++++++++++++---------------
>  sound/pci/Kconfig     | 64 +++++++++++++++++++++++++++++--------------
>  3 files changed, 70 insertions(+), 43 deletions(-)
> 
> diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
> index ca4cdf666f82..4d250e619786 100644
> --- a/sound/drivers/Kconfig
> +++ b/sound/drivers/Kconfig
> @@ -1,10 +1,12 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config SND_MPU401_UART
>  	tristate
> +	depends on HAS_IOPORT
>  	select SND_RAWMIDI
>  
>  config SND_OPL3_LIB
>  	tristate
> +	depends on HAS_IOPPORT
>  	select SND_TIMER
>  	select SND_HWDEP
>  	select SND_SEQ_DEVICE if SND_SEQUENCER != n

Both of those are the items to be reverse-selected, so cannot fulfill
the dependency with depends-on.  That is, the items that select those
should have the dependency on HAS_IOPORT instead.

That is, a change like below:

> --- a/sound/isa/Kconfig
> +++ b/sound/isa/Kconfig
> @@ -31,7 +31,7 @@ if SND_ISA
>  
>  config SND_ADLIB
>  	tristate "AdLib FM card"
> -	select SND_OPL3_LIB
> +	depends on SND_OPL3_LIB

... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
to be selected.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
@ 2022-05-09  8:53     ` Takashi Iwai
  0 siblings, 0 replies; 392+ messages in thread
From: Takashi Iwai @ 2022-05-09  8:53 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Jaroslav Kysela, Takashi Iwai,
	moderated list:SOUND

On Fri, 29 Apr 2022 15:50:54 +0200,
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. For SND_OPL3_LIB this adds its first
> dependency so drivers currently selecting it unconditionally need to
> depend on it instead.
> 
> Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
>  sound/drivers/Kconfig |  5 ++++
>  sound/isa/Kconfig     | 44 ++++++++++++++---------------
>  sound/pci/Kconfig     | 64 +++++++++++++++++++++++++++++--------------
>  3 files changed, 70 insertions(+), 43 deletions(-)
> 
> diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
> index ca4cdf666f82..4d250e619786 100644
> --- a/sound/drivers/Kconfig
> +++ b/sound/drivers/Kconfig
> @@ -1,10 +1,12 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config SND_MPU401_UART
>  	tristate
> +	depends on HAS_IOPORT
>  	select SND_RAWMIDI
>  
>  config SND_OPL3_LIB
>  	tristate
> +	depends on HAS_IOPPORT
>  	select SND_TIMER
>  	select SND_HWDEP
>  	select SND_SEQ_DEVICE if SND_SEQUENCER != n

Both of those are the items to be reverse-selected, so cannot fulfill
the dependency with depends-on.  That is, the items that select those
should have the dependency on HAS_IOPORT instead.

That is, a change like below:

> --- a/sound/isa/Kconfig
> +++ b/sound/isa/Kconfig
> @@ -31,7 +31,7 @@ if SND_ISA
>  
>  config SND_ADLIB
>  	tristate "AdLib FM card"
> -	select SND_OPL3_LIB
> +	depends on SND_OPL3_LIB

... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
to be selected.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
  2022-05-09  8:53     ` Takashi Iwai
@ 2022-05-09  9:20       ` Arnd Bergmann
  -1 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-09  9:20 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: linux-arch, moderated list:SOUND, Arnd Bergmann, Niklas Schnelle,
	Greg Kroah-Hartman, Takashi Iwai, Linux Kernel Mailing List,
	linux-pci

On Mon, May 9, 2022 at 10:53 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 29 Apr 2022 15:50:54 +0200, Niklas Schnelle wrote:

> >
> >  config SND_OPL3_LIB
> >       tristate
> > +     depends on HAS_IOPPORT
> >       select SND_TIMER
> >       select SND_HWDEP
> >       select SND_SEQ_DEVICE if SND_SEQUENCER != n
>
> Both of those are the items to be reverse-selected, so cannot fulfill
> the dependency with depends-on.  That is, the items that select those
> should have the dependency on HAS_IOPORT instead.
>
> That is, a change like below:
>
> > --- a/sound/isa/Kconfig
> > +++ b/sound/isa/Kconfig
> > @@ -31,7 +31,7 @@ if SND_ISA
> >
> >  config SND_ADLIB
> >       tristate "AdLib FM card"
> > -     select SND_OPL3_LIB
> > +     depends on SND_OPL3_LIB
>
> ... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
> to be selected.

Right, I missed that in my review. Not sure if this was a mistake in
my original patch or if it started in a later version.

I think for the ISA drivers, I would still add 'depends on HAS_IOPORT'
to both CONFIG_SND_ISA and CONFIG_SND_OPL3_LIB if only to
make it easier to understand, even though CONFIG_ISA requires
HAS_IOPORT already, and CONFIG_SND_OPL3_LIB cannot be
selected by itself.

For the PCI drivers, I think we need to add the same dependency
on anything that either selects SND_OPL3_LIB or calls inb()/outb()
directly.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
@ 2022-05-09  9:20       ` Arnd Bergmann
  0 siblings, 0 replies; 392+ messages in thread
From: Arnd Bergmann @ 2022-05-09  9:20 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Jaroslav Kysela, Takashi Iwai, moderated list:SOUND

On Mon, May 9, 2022 at 10:53 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Fri, 29 Apr 2022 15:50:54 +0200, Niklas Schnelle wrote:

> >
> >  config SND_OPL3_LIB
> >       tristate
> > +     depends on HAS_IOPPORT
> >       select SND_TIMER
> >       select SND_HWDEP
> >       select SND_SEQ_DEVICE if SND_SEQUENCER != n
>
> Both of those are the items to be reverse-selected, so cannot fulfill
> the dependency with depends-on.  That is, the items that select those
> should have the dependency on HAS_IOPORT instead.
>
> That is, a change like below:
>
> > --- a/sound/isa/Kconfig
> > +++ b/sound/isa/Kconfig
> > @@ -31,7 +31,7 @@ if SND_ISA
> >
> >  config SND_ADLIB
> >       tristate "AdLib FM card"
> > -     select SND_OPL3_LIB
> > +     depends on SND_OPL3_LIB
>
> ... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
> to be selected.

Right, I missed that in my review. Not sure if this was a mistake in
my original patch or if it started in a later version.

I think for the ISA drivers, I would still add 'depends on HAS_IOPORT'
to both CONFIG_SND_ISA and CONFIG_SND_OPL3_LIB if only to
make it easier to understand, even though CONFIG_ISA requires
HAS_IOPORT already, and CONFIG_SND_OPL3_LIB cannot be
selected by itself.

For the PCI drivers, I think we need to add the same dependency
on anything that either selects SND_OPL3_LIB or calls inb()/outb()
directly.

       Arnd

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
  2022-05-09  9:20       ` Arnd Bergmann
@ 2022-05-09 10:07         ` Takashi Iwai
  -1 siblings, 0 replies; 392+ messages in thread
From: Takashi Iwai @ 2022-05-09 10:07 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arch, moderated list:SOUND, Arnd Bergmann, Niklas Schnelle,
	Greg Kroah-Hartman, Takashi Iwai, Linux Kernel Mailing List,
	linux-pci

On Mon, 09 May 2022 11:20:33 +0200,
Arnd Bergmann wrote:
> 
> On Mon, May 9, 2022 at 10:53 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Fri, 29 Apr 2022 15:50:54 +0200, Niklas Schnelle wrote:
> 
> > >
> > >  config SND_OPL3_LIB
> > >       tristate
> > > +     depends on HAS_IOPPORT
> > >       select SND_TIMER
> > >       select SND_HWDEP
> > >       select SND_SEQ_DEVICE if SND_SEQUENCER != n
> >
> > Both of those are the items to be reverse-selected, so cannot fulfill
> > the dependency with depends-on.  That is, the items that select those
> > should have the dependency on HAS_IOPORT instead.
> >
> > That is, a change like below:
> >
> > > --- a/sound/isa/Kconfig
> > > +++ b/sound/isa/Kconfig
> > > @@ -31,7 +31,7 @@ if SND_ISA
> > >
> > >  config SND_ADLIB
> > >       tristate "AdLib FM card"
> > > -     select SND_OPL3_LIB
> > > +     depends on SND_OPL3_LIB
> >
> > ... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
> > to be selected.
> 
> Right, I missed that in my review. Not sure if this was a mistake in
> my original patch or if it started in a later version.
> 
> I think for the ISA drivers, I would still add 'depends on HAS_IOPORT'
> to both CONFIG_SND_ISA and CONFIG_SND_OPL3_LIB if only to
> make it easier to understand, even though CONFIG_ISA requires
> HAS_IOPORT already, and CONFIG_SND_OPL3_LIB cannot be
> selected by itself.

Yes, that makes sense.

> For the PCI drivers, I think we need to add the same dependency
> on anything that either selects SND_OPL3_LIB or calls inb()/outb()
> directly.

Agreed.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
@ 2022-05-09 10:07         ` Takashi Iwai
  0 siblings, 0 replies; 392+ messages in thread
From: Takashi Iwai @ 2022-05-09 10:07 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Niklas Schnelle, Arnd Bergmann, Greg Kroah-Hartman,
	Linux Kernel Mailing List, linux-arch, linux-pci,
	Jaroslav Kysela, Takashi Iwai, moderated list:SOUND

On Mon, 09 May 2022 11:20:33 +0200,
Arnd Bergmann wrote:
> 
> On Mon, May 9, 2022 at 10:53 AM Takashi Iwai <tiwai@suse.de> wrote:
> > On Fri, 29 Apr 2022 15:50:54 +0200, Niklas Schnelle wrote:
> 
> > >
> > >  config SND_OPL3_LIB
> > >       tristate
> > > +     depends on HAS_IOPPORT
> > >       select SND_TIMER
> > >       select SND_HWDEP
> > >       select SND_SEQ_DEVICE if SND_SEQUENCER != n
> >
> > Both of those are the items to be reverse-selected, so cannot fulfill
> > the dependency with depends-on.  That is, the items that select those
> > should have the dependency on HAS_IOPORT instead.
> >
> > That is, a change like below:
> >
> > > --- a/sound/isa/Kconfig
> > > +++ b/sound/isa/Kconfig
> > > @@ -31,7 +31,7 @@ if SND_ISA
> > >
> > >  config SND_ADLIB
> > >       tristate "AdLib FM card"
> > > -     select SND_OPL3_LIB
> > > +     depends on SND_OPL3_LIB
> >
> > ... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
> > to be selected.
> 
> Right, I missed that in my review. Not sure if this was a mistake in
> my original patch or if it started in a later version.
> 
> I think for the ISA drivers, I would still add 'depends on HAS_IOPORT'
> to both CONFIG_SND_ISA and CONFIG_SND_OPL3_LIB if only to
> make it easier to understand, even though CONFIG_ISA requires
> HAS_IOPORT already, and CONFIG_SND_OPL3_LIB cannot be
> selected by itself.

Yes, that makes sense.

> For the PCI drivers, I think we need to add the same dependency
> on anything that either selects SND_OPL3_LIB or calls inb()/outb()
> directly.

Agreed.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
  2022-05-09 10:07         ` Takashi Iwai
@ 2022-05-09 12:14           ` Niklas Schnelle
  -1 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-09 12:14 UTC (permalink / raw)
  To: Takashi Iwai, Arnd Bergmann
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Linux Kernel Mailing List,
	linux-arch, linux-pci, Jaroslav Kysela, Takashi Iwai,
	moderated list:SOUND

On Mon, 2022-05-09 at 12:07 +0200, Takashi Iwai wrote:
> On Mon, 09 May 2022 11:20:33 +0200,
> Arnd Bergmann wrote:
> > On Mon, May 9, 2022 at 10:53 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Fri, 29 Apr 2022 15:50:54 +0200, Niklas Schnelle wrote:
> > > >  config SND_OPL3_LIB
> > > >       tristate
> > > > +     depends on HAS_IOPPORT
> > > >       select SND_TIMER
> > > >       select SND_HWDEP
> > > >       select SND_SEQ_DEVICE if SND_SEQUENCER != n
> > > 
> > > Both of those are the items to be reverse-selected, so cannot fulfill
> > > the dependency with depends-on.  That is, the items that select those
> > > should have the dependency on HAS_IOPORT instead.
> > > 
> > > That is, a change like below:
> > > 
> > > > --- a/sound/isa/Kconfig
> > > > +++ b/sound/isa/Kconfig
> > > > @@ -31,7 +31,7 @@ if SND_ISA
> > > > 
> > > >  config SND_ADLIB
> > > >       tristate "AdLib FM card"
> > > > -     select SND_OPL3_LIB
> > > > +     depends on SND_OPL3_LIB
> > > 
> > > ... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
> > > to be selected.
> > 
> > Right, I missed that in my review. Not sure if this was a mistake in
> > my original patch or if it started in a later version.

I added this part recently I think even after your review so the fault
is entirely mine.

> > 
> > I think for the ISA drivers, I would still add 'depends on HAS_IOPORT'
> > to both CONFIG_SND_ISA and CONFIG_SND_OPL3_LIB if only to
> > make it easier to understand, even though CONFIG_ISA requires
> > HAS_IOPORT already, and CONFIG_SND_OPL3_LIB cannot be
> > selected by itself.
> 
> Yes, that makes sense.

Good, incorporating this now and it looks like this works.

> 
> > For the PCI drivers, I think we need to add the same dependency
> > on anything that either selects SND_OPL3_LIB or calls inb()/outb()
> > directly.
> 
> Agreed.

Same as above and thanks for spotting my mistake.



^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 31/39] sound: add HAS_IOPORT dependencies
@ 2022-05-09 12:14           ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-09 12:14 UTC (permalink / raw)
  To: Takashi Iwai, Arnd Bergmann
  Cc: linux-arch, moderated list:SOUND, Arnd Bergmann,
	Greg Kroah-Hartman, Takashi Iwai, Linux Kernel Mailing List,
	linux-pci

On Mon, 2022-05-09 at 12:07 +0200, Takashi Iwai wrote:
> On Mon, 09 May 2022 11:20:33 +0200,
> Arnd Bergmann wrote:
> > On Mon, May 9, 2022 at 10:53 AM Takashi Iwai <tiwai@suse.de> wrote:
> > > On Fri, 29 Apr 2022 15:50:54 +0200, Niklas Schnelle wrote:
> > > >  config SND_OPL3_LIB
> > > >       tristate
> > > > +     depends on HAS_IOPPORT
> > > >       select SND_TIMER
> > > >       select SND_HWDEP
> > > >       select SND_SEQ_DEVICE if SND_SEQUENCER != n
> > > 
> > > Both of those are the items to be reverse-selected, so cannot fulfill
> > > the dependency with depends-on.  That is, the items that select those
> > > should have the dependency on HAS_IOPORT instead.
> > > 
> > > That is, a change like below:
> > > 
> > > > --- a/sound/isa/Kconfig
> > > > +++ b/sound/isa/Kconfig
> > > > @@ -31,7 +31,7 @@ if SND_ISA
> > > > 
> > > >  config SND_ADLIB
> > > >       tristate "AdLib FM card"
> > > > -     select SND_OPL3_LIB
> > > > +     depends on SND_OPL3_LIB
> > > 
> > > ... won't work.  CONFIG_SND_OPL3_LIB is not enabled by itself but only
> > > to be selected.
> > 
> > Right, I missed that in my review. Not sure if this was a mistake in
> > my original patch or if it started in a later version.

I added this part recently I think even after your review so the fault
is entirely mine.

> > 
> > I think for the ISA drivers, I would still add 'depends on HAS_IOPORT'
> > to both CONFIG_SND_ISA and CONFIG_SND_OPL3_LIB if only to
> > make it easier to understand, even though CONFIG_ISA requires
> > HAS_IOPORT already, and CONFIG_SND_OPL3_LIB cannot be
> > selected by itself.
> 
> Yes, that makes sense.

Good, incorporating this now and it looks like this works.

> 
> > For the PCI drivers, I think we need to add the same dependency
> > on anything that either selects SND_OPL3_LIB or calls inb()/outb()
> > directly.
> 
> Agreed.

Same as above and thanks for spotting my mistake.



^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 12/39] i2c: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 12/39] i2c: " Niklas Schnelle
@ 2022-05-14 14:06   ` Wolfram Sang
  0 siblings, 0 replies; 392+ messages in thread
From: Wolfram Sang @ 2022-05-14 14:06 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, open list:I2C SUBSYSTEM HOST DRIVERS

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

On Fri, Apr 29, 2022 at 03:50:19PM +0200, 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: Niklas Schnelle <schnelle@linux.ibm.com>

What has changed since RFC v1?

> @@ -1232,6 +1233,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

Didn't you want to drop this one?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 29/39] rtc: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 29/39] rtc: " Niklas Schnelle
@ 2022-05-17 22:15   ` Alexandre Belloni
  2022-05-18 13:47     ` Niklas Schnelle
  2022-06-01 12:25   ` Maciej W. Rozycki
  1 sibling, 1 reply; 392+ messages in thread
From: Alexandre Belloni @ 2022-05-17 22:15 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Alessandro Zummo,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM

Hi,

On 29/04/2022 15:50:49+0200, 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.
> 

I'm fine taking that this cycle if there are no dependencies. Should I?

> Co-developed-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 41c65b4d2baf..e1bb11a225b2 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
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 29/39] rtc: add HAS_IOPORT dependencies
  2022-05-17 22:15   ` Alexandre Belloni
@ 2022-05-18 13:47     ` Niklas Schnelle
  0 siblings, 0 replies; 392+ messages in thread
From: Niklas Schnelle @ 2022-05-18 13:47 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Alessandro Zummo,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM

On Wed, 2022-05-18 at 00:15 +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 29/04/2022 15:50:49+0200, 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.
> > 
> 
> I'm fine taking that this cycle if there are no dependencies. Should I?
> 

I'd say the dependency here is the first patch in the series and we
don't seem to have full consensus on this yet. So as of now I sadly
don't think so.


^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 29/39] rtc: add HAS_IOPORT dependencies
  2022-04-29 13:50 ` [RFC v2 29/39] rtc: " Niklas Schnelle
  2022-05-17 22:15   ` Alexandre Belloni
@ 2022-06-01 12:25   ` Maciej W. Rozycki
  1 sibling, 0 replies; 392+ messages in thread
From: Maciej W. Rozycki @ 2022-06-01 12:25 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Alessandro Zummo, Alexandre Belloni,
	open list:REAL TIME CLOCK (RTC) SUBSYSTEM

On Fri, 29 Apr 2022, Niklas Schnelle wrote:

> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 41c65b4d2baf..e1bb11a225b2 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

 Umm, I missed this one previously and this is wrong.  We use this driver 
for the DECstation machines (CONFIG_MIPS/CONFIG_MACH_DECSTATION) and those 
do not use (nor indeed have) port I/O as they are TURBOchannel systems and 
they only have a single (memory) address space.  Consequently their DS1287 
chip is memory-mapped (in a linear fashion actually, i.e. there's no 
visible address/data register and individual locations are accessible with 
single CPU instructions), cf. arch/mips/include/asm/mach-dec/mc146818rtc.h 
(that probably ought to be converted to `readb'/`writeb' one day).

 So this has to be sorted differently, perhaps by just:

+	depends on HAS_IOPORT || MACH_DECSTATION

 Note that other machines handled by the MIPS port do use port I/O, cf. 
arch/mips/include/asm/mach-*/mc146818rtc.h.

  Maciej

^ permalink raw reply	[flat|nested] 392+ messages in thread

* Re: [RFC v2 23/39] PCI: make quirk using inw() depend on HAS_IOPORT
  2022-04-29 13:50 ` [RFC v2 23/39] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
@ 2022-06-08 18:30   ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-06-08 18:30 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Bjorn Helgaas

In subject, s/make quirk/Make quirk/

On Fri, Apr 29, 2022 at 03:50:37PM +0200, Niklas Schnelle wrote:
> In the future inw() and friends will not be compiled on architectures
> without I/O port support.

Commit log should say what the patch does.  Even if it's in the
subject, make the commit log stand alone.

With the above,

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> Co-developed-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 da829274fc66..27db2810f034 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] 392+ messages in thread

* Re: [RFC v2 24/39] PCI/sysfs: make I/O resource depend on HAS_IOPORT
  2022-04-29 13:50 ` [RFC v2 24/39] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
@ 2022-06-08 18:32   ` Bjorn Helgaas
  0 siblings, 0 replies; 392+ messages in thread
From: Bjorn Helgaas @ 2022-06-08 18:32 UTC (permalink / raw)
  To: Niklas Schnelle
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, linux-arch,
	linux-pci, Arnd Bergmann, Bjorn Helgaas

On Fri, Apr 29, 2022 at 03:50:39PM +0200, 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.

Same comments as for 23/39.

Once addressed,

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

One more comment below.

> Co-developed-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 c263ffc5884a..eda258fa4981 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1091,6 +1091,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)
> @@ -1149,6 +1150,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

I would probably move the #ifdefs inside the function to avoid
repeating the function signature.

> +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	[flat|nested] 392+ messages in thread

end of thread, other threads:[~2022-06-08 18:32 UTC | newest]

Thread overview: 392+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-29 13:49 [RFC v2 00/39] Kconfig: Introduce HAS_IOPORT config option Niklas Schnelle
2022-04-29 13:49 ` Niklas Schnelle
2022-04-29 13:49 ` [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-04-29 13:49   ` Niklas Schnelle
2022-05-01 22:40   ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-01 22:40     ` Maciej W. Rozycki
2022-05-04 21:08   ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:08     ` Bjorn Helgaas
2022-05-04 21:31     ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-04 21:31       ` Arnd Bergmann
2022-05-05  8:10       ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05  8:10         ` Niklas Schnelle
2022-05-05 16:10       ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 16:10         ` Bjorn Helgaas
2022-05-05 17:39         ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 17:39           ` Arnd Bergmann
2022-05-05 19:53           ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-05 19:53             ` Bjorn Helgaas
2022-05-06  9:12             ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06  9:12               ` Finn Thain
2022-05-06 11:18               ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-06 11:18                 ` Niklas Schnelle
2022-05-07  0:01                 ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07  0:01                   ` Finn Thain
2022-05-07 13:14                   ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 13:14                     ` Arnd Bergmann
2022-05-07 23:59                     ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-07 23:59                       ` Finn Thain
2022-05-08  0:15                       ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-08  0:15                         ` Finn Thain
2022-05-06  9:38             ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06  9:38               ` Niklas Schnelle
2022-05-06 11:07               ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 11:07                 ` John Garry
2022-05-06 10:20           ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 10:20             ` Maciej W. Rozycki
2022-05-06 11:33             ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 11:33               ` Arnd Bergmann
2022-05-06 12:27               ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:27                 ` Maciej W. Rozycki
2022-05-06 12:53                 ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 12:53                   ` David Laight
2022-05-06 13:08                   ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:08                     ` Geert Uytterhoeven
2022-05-06 13:40                     ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 13:40                       ` Maciej W. Rozycki
2022-05-06 14:03                     ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 14:03                       ` David Laight
2022-05-06 15:02                       ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 15:02                         ` Geert Uytterhoeven
2022-05-06 13:15                   ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:15                     ` Maciej W. Rozycki
2022-05-06 13:28                     ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 13:28                       ` David Laight
2022-05-06 14:44                       ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:44                         ` Maciej W. Rozycki
2022-05-06 14:56                         ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 14:56                           ` Geert Uytterhoeven
2022-05-06 15:03                           ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 15:03                             ` Maciej W. Rozycki
2022-05-06 12:53                 ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 12:53                   ` Arnd Bergmann
2022-05-06 13:15                   ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:15                     ` Niklas Schnelle
2022-05-06 13:16                   ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 13:16                     ` Maciej W. Rozycki
2022-05-06 12:55                 ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:55                   ` Niklas Schnelle
2022-05-06 12:42               ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-05-06 12:42                 ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 02/39] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
2022-05-04 13:23   ` Rafael J. Wysocki
2022-05-04 17:53   ` Bjorn Helgaas
2022-05-04 19:58     ` Arnd Bergmann
2022-05-05  8:20       ` Niklas Schnelle
2022-05-05 19:36         ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 02/37] ata: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:27   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 03/37] ACPI: add dependency on HAS_IOPORT Niklas Schnelle
2022-04-29 14:28   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 03/39] ata: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT Niklas Schnelle
2022-04-29 14:23   ` Niklas Schnelle
2022-04-29 14:33     ` Ahmad Fatoum
2022-05-02 14:34       ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 04/37] parport: PC style parport depends " Niklas Schnelle
2022-04-29 14:28   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 05/37] char: impi, tpm: depend " Niklas Schnelle
2022-04-29 14:02   ` Ahmad Fatoum
2022-04-29 13:50 ` [RFC v2 05/39] comedi: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 06/39] counter: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 06/37] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
2022-04-29 14:28   ` Samuel Thibault
2022-04-29 14:28   ` Niklas Schnelle
2022-04-29 14:29   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 07/39] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
2022-04-29 13:50 ` [PATCH 07/37] Input: gameport: add ISA and HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:29   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 08/37] comedi: add " Niklas Schnelle
2022-04-29 14:30   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 08/39] drm: handle " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 09/37] counter: add " Niklas Schnelle
2022-04-29 14:30   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 09/39] firmware: dmi-sysfs: handle HAS_IOPORT=n Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 10/39] gpio: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:32   ` William Breathitt Gray
2022-04-29 14:46     ` Niklas Schnelle
2022-04-29 15:37       ` William Breathitt Gray
2022-05-01 21:55         ` Linus Walleij
2022-05-02 12:53           ` Niklas Schnelle
2022-05-03 13:08           ` David Laight
2022-05-03 14:03             ` William Breathitt Gray
2022-05-04 11:46             ` Maciej W. Rozycki
2022-05-04 12:45               ` David Laight
2022-05-04 13:02                 ` Maciej W. Rozycki
2022-05-02 13:21         ` Maciej W. Rozycki
2022-04-29 13:50 ` [RFC v2 11/39] hwmon: " Niklas Schnelle
2022-04-30  0:37   ` Guenter Roeck
2022-04-29 13:50 ` [PATCH 11/37] sound: " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 14:30   ` Niklas Schnelle
2022-04-29 14:30     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 12/39] i2c: " Niklas Schnelle
2022-05-14 14:06   ` Wolfram Sang
2022-04-29 13:50 ` [RFC v2 13/39] iio: adc: Kconfig: " Niklas Schnelle
2022-05-01 16:51   ` Jonathan Cameron
2022-04-29 13:50 ` [PATCH 13/37] Input: " Niklas Schnelle
2022-04-29 14:31   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 14/37] iio: adc: Kconfig: " Niklas Schnelle
2022-04-29 14:31   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 14/39] Input: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 15/37] hwmon: " Niklas Schnelle
2022-04-29 14:31   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 15/39] Input: gameport: add ISA and " Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 16/39] leds: add " Niklas Schnelle
2022-04-29 18:54   ` Pavel Machek
2022-05-02  8:31     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 17/39] media: " Niklas Schnelle
2022-04-29 15:36   ` Sean Young
2022-04-29 13:50 ` [RFC v2 18/39] misc: " Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 19/39] mISDN: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 19/37] mpt fusion: " Niklas Schnelle
2022-04-29 14:32   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 20/39] " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 20/37] net: " Niklas Schnelle
2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
2022-04-29 14:33   ` Niklas Schnelle
2022-04-29 14:33     ` [Intel-wired-lan] " Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 21/39] " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 13:50   ` [Intel-wired-lan] " Niklas Schnelle
2022-04-29 14:13   ` Marc Kleine-Budde
2022-04-29 14:13     ` Marc Kleine-Budde
2022-04-29 14:13     ` [Intel-wired-lan] " Marc Kleine-Budde
2022-05-01 22:48   ` Maciej W. Rozycki
2022-05-01 22:48     ` Maciej W. Rozycki
2022-05-01 22:48     ` [Intel-wired-lan] " Maciej W. Rozycki
2022-05-03 12:45     ` Niklas Schnelle
2022-05-03 12:45       ` Niklas Schnelle
2022-05-03 12:45       ` [Intel-wired-lan] " Niklas Schnelle
2022-05-03 13:36       ` Maciej W. Rozycki
2022-05-03 13:36         ` Maciej W. Rozycki
2022-05-03 13:36         ` [Intel-wired-lan] " Maciej W. Rozycki
2022-04-29 13:50 ` [PATCH 21/37] pcmcia: " Niklas Schnelle
2022-04-29 14:33   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 22/39] parport: PC style parport depends on HAS_IOPORT Niklas Schnelle
2022-04-29 13:50 ` [PATCH 22/37] platform: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:33   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 23/39] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
2022-06-08 18:30   ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 23/37] pnp: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:34   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 24/39] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
2022-06-08 18:32   ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 24/37] power: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 14:34   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 25/39] pcmcia: " Niklas Schnelle
2022-05-03 23:38   ` Bjorn Helgaas
2022-05-04 10:33     ` Arnd Bergmann
2022-05-04 12:38       ` Maciej W. Rozycki
2022-05-04 14:07         ` Arnd Bergmann
2022-05-04 14:24           ` Maciej W. Rozycki
2022-05-04 17:22             ` Bjorn Helgaas
2022-05-05  8:45               ` Maciej W. Rozycki
2022-05-05 19:38                 ` Bjorn Helgaas
2022-05-04 14:44       ` David Laight
2022-05-05 12:03         ` Maciej W. Rozycki
2022-05-04 14:59       ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 25/37] video: handle " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 14:35   ` Niklas Schnelle
2022-04-29 14:35     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 26/39] platform: add " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 26/37] rtc: " Niklas Schnelle
2022-04-29 14:46   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 27/39] pnp: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 27/37] scsi: " Niklas Schnelle
2022-04-29 14:46   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 28/39] power: " Niklas Schnelle
2022-04-29 13:50 ` [PATCH 28/37] staging: sm750fb: " Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 29/39] rtc: " Niklas Schnelle
2022-05-17 22:15   ` Alexandre Belloni
2022-05-18 13:47     ` Niklas Schnelle
2022-06-01 12:25   ` Maciej W. Rozycki
2022-04-29 13:50 ` [PATCH 29/37] tty: serial: " Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 30/39] scsi: " Niklas Schnelle
2022-05-04 20:42   ` Bjorn Helgaas
2022-05-04 21:34     ` Arnd Bergmann
2022-05-05 16:06       ` Bjorn Helgaas
2022-04-29 13:50 ` [PATCH 30/37] watchdog: " Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 31/37] drm: handle " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-04-29 14:47   ` Niklas Schnelle
2022-04-29 14:47     ` Niklas Schnelle
2022-04-29 13:50 ` [RFC v2 31/39] sound: add " Niklas Schnelle
2022-04-29 13:50   ` Niklas Schnelle
2022-05-09  8:53   ` Takashi Iwai
2022-05-09  8:53     ` Takashi Iwai
2022-05-09  9:20     ` Arnd Bergmann
2022-05-09  9:20       ` Arnd Bergmann
2022-05-09 10:07       ` Takashi Iwai
2022-05-09 10:07         ` Takashi Iwai
2022-05-09 12:14         ` Niklas Schnelle
2022-05-09 12:14           ` Niklas Schnelle
2022-04-29 13:50 ` [PATCH 32/37] PCI/sysfs: make I/O resource depend on HAS_IOPORT Niklas Schnelle
2022-04-29 14:48   ` Niklas Schnelle
2022-05-05 21:41   ` Bjorn Helgaas
2022-04-29 13:50 ` [RFC v2 32/39] speakup: add HAS_IOPORT dependency for SPEAKUP_SERIALIO Niklas Schnelle
2022-04-29 13:50 ` [PATCH 33/37] PCI: make quirk using inw() depend on HAS_IOPORT Niklas Schnelle
2022-04-29 14:48   ` Niklas Schnelle
2022-05-05 21:44   ` Bjorn Helgaas
2022-04-29 13:50 ` [RFC v2 33/39] staging: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-29 13:50 ` [PATCH 34/37] firmware: dmi-sysfs: handle HAS_IOPORT=n Niklas Schnelle
2022-04-29 14:48   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 34/39] tty: serial: add HAS_IOPORT dependencies Niklas Schnelle
2022-05-02  9:15   ` Maciej W. Rozycki
2022-04-29 13:51 ` [PATCH 35/37] /dev/port: don't compile file operations without CONFIG_DEVPORT Niklas Schnelle
2022-04-29 14:49   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 35/39] usb: handle HAS_IOPORT dependencies Niklas Schnelle
2022-04-30 12:56   ` Alan Stern
2022-05-02  8:26     ` Niklas Schnelle
2022-04-29 13:51 ` [PATCH 36/37] " Niklas Schnelle
2022-04-29 14:49   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 36/39] video: " Niklas Schnelle
2022-04-29 13:51   ` Niklas Schnelle
2022-04-29 13:51 ` [PATCH 37/37] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle
2022-04-29 14:49   ` Niklas Schnelle
2022-04-29 13:51 ` [RFC v2 37/39] watchdog: add HAS_IOPORT dependencies Niklas Schnelle
2022-04-30  0:38   ` Guenter Roeck
2022-04-29 13:51 ` [RFC v2 38/39] wireless: " Niklas Schnelle
2022-04-29 14:40   ` Kalle Valo
2022-04-29 13:51 ` [RFC v2 39/39] asm-generic/io.h: drop inb() etc for HAS_IOPORT=n Niklas Schnelle

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.