Make several Kconfig options depend on HAS_IOMEM

In thread of one patch posting, LKP test robot reported some compiling errors, paste the LKP report link here:

https://lore.kernel.org/all/[email protected]/T/#u

In the config file, several Kconfig options are like below:
------
'# CONFIG_PCI is not set' CONFIG_OF_EARLY_FLATTREE=y CONFIG_DMA_DECLARE_COHERENT=y
------

The reason is (words arranged from Niklas):
===
On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

So make several Kconfig options depend on HAS_IOMEM so that it won't build in those driver code if PCI is unset.

Baoquan He (8):
idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM
char: xillybus: make XILLYBUS_OF depend on HAS_IOMEM
misc: open-dice: make OPEN_DICE depend on HAS_IOMEM pcmcia : make PCMCIA depend on HAS_IOMEM
net: altera-tse: make ALTERA_TSE depend on HAS_IOMEM irqchip/al-fic: make AL_FIC depend on HAS_IOMEM
clk: fixed-mmio: make COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM
of: make OF_EARLY_FLATTREE depend on HAS_IOMEM

 drivers/char/xillybus/Kconfig       | 2 +-
 drivers/clk/Kconfig                 | 1 +
 drivers/dma/Kconfig                 | 2 ++
 drivers/irqchip/Kconfig             | 1 +
 drivers/misc/Kconfig                | 1 +
 drivers/net/ethernet/altera/Kconfig | 1 +
 drivers/of/Kconfig                  | 2 +-
 drivers/pcmcia/Kconfig              | 1 +
 8 files changed, 9 insertions(+), 2 deletions(-)

2.34.1

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset.

--------
ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined!
ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined!
--------

---
 drivers/dma/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

index 644c188d6a11..08fdd0e2ed1b 100644
@@ -211,6 +211,7 @@ config FSL_DMA
 config FSL_EDMA
 	tristate "Freescale eDMA engine support"
 	depends on OF
+	depends on HAS_IOMEM
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	help

@@ -280,6 +281,7 @@ config IMX_SDMA
 
 config INTEL_IDMA64
 	tristate "Intel integrated DMA 64-bit support"
+	depends on HAS_IOMEM
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	help

2.34.1

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let XILLYBUS_OF depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset:

------
ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined!
------

---
 drivers/char/xillybus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index a8036dad437e..f51d533390a9 100644
@@ -29,7 +29,7 @@ config XILLYBUS_PCIE
 
 config XILLYBUS_OF
 	tristate "Xillybus over Device Tree"
-	depends on OF && HAS_DMA
+	depends on OF && HAS_DMA && HAS_IOMEM
 	help
 	  Set to M if you want Xillybus to find its resources from the
 	  Open Firmware Flattened Device Tree. If the target is an embedded

2.34.1

I stand corrected. Thank you.

Eli

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let OPEN_DICE depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset:

------
ERROR: modpost: "devm_memremap" [drivers/misc/open-dice.ko] undefined!
ERROR: modpost: "devm_memunmap" [drivers/misc/open-dice.ko] undefined!
------

---
 drivers/misc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

index 75e427f124b2..cadd4a820c03 100644
@@ -496,6 +496,7 @@ config HISI_HIKEY_USB
 config OPEN_DICE
 	tristate "Open Profile for DICE driver"
 	depends on OF_RESERVED_MEM
+	depends on HAS_IOMEM
 	help
 	  This driver exposes a DICE reserved memory region to userspace via
 	  a character device. The memory region contains Compound Device

2.34.1

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let depend PCMCIA on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset.

------
ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
cistpl.c:(.text+0x1202): undefined reference to `ioremap'
ld: cistpl.c:(.text+0x13b0): undefined reference to `iounmap'
ld: cistpl.c:(.text+0x14a6): undefined reference to `iounmap'
ld: cistpl.c:(.text+0x1544): undefined reference to `ioremap'
ld: drivers/pcmcia/cistpl.o: in function `release_cis_mem':
cistpl.c:(.text+0x3f14): undefined reference to `iounmap'
------

Besides, many other Kconfig option, e.g IPWIRELESS, PCMCIA_PCNET, PCMCIA_FMVJ18X, PCMCIA_SMC91C92 which depends on PCMCIA also will cause compiling error if enabled.

------
ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined!
ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined!

ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/fujitsu/fmvj18x_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/fujitsu/fmvj18x_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/smsc/smc91c92_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/smsc/smc91c92_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/xircom/xirc2ps_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/xircom/xirc2ps_cs.ko] undefined!
ERROR: modpost: "devm_ioremap" [drivers/net/ethernet/altera/altera_tse.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/arcnet/com90xx.ko] undefined!
------

---
 drivers/pcmcia/Kconfig | 1 +
 1 file changed, 1 insertion(+)

index e72419d7e72e..dddb235dd020 100644
@@ -19,6 +19,7 @@ if PCCARD
 
 config PCMCIA
 	tristate "16-bit PCMCIA support"
+	depends on HAS_IOMEM
 	select CRC32
 	default y
 	help

2.34.1

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let ALTERA_TSE depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset:

------
ERROR: modpost: "devm_ioremap" [drivers/net/ethernet/altera/altera_tse.ko] undefined!
------

---
 drivers/net/ethernet/altera/Kconfig | 1 +
 1 file changed, 1 insertion(+)

index 17985319088c..4ef819a9a1ad 100644
@@ -2,6 +2,7 @@
 config ALTERA_TSE
 	tristate "Altera Triple-Speed Ethernet MAC support"
 	depends on HAS_DMA
+	depends on HAS_IOMEM
 	select PHYLIB
 	select PHYLINK
 	select PCS_LYNX

2.34.1

I wonder if this should also have:

Thanks, Simon.

Agree, it's worth having Fixes tag.

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let AL_FIC depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset:

------
ld: drivers/irqchip/irq-al-fic.o: in function `al_fic_init_dt':
irq-al-fic.c:(.init.text+0x76): undefined reference to `of_iomap'
ld: irq-al-fic.c:(.init.text+0x4ce): undefined reference to `iounmap'
------

---
 drivers/irqchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

index 09e422da482f..4b9036c6d45b 100644
@@ -89,6 +89,7 @@ config ALPINE_MSI
 config AL_FIC
 	bool "Amazon's Annapurna Labs Fabric Interrupt Controller"
 	depends on OF
+	depends on HAS_IOMEM
 	select GENERIC_IRQ_CHIP
 	select IRQ_DOMAIN
 	help

2.34.1

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

Here let COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset:

------
ld: drivers/clk/clk-fixed-mmio.o: in function `fixed_mmio_clk_setup':
clk-fixed-mmio.c:(.text+0x5e): undefined reference to `of_iomap'
ld: clk-fixed-mmio.c:(.text+0xba): undefined reference to `iounmap'
------

---
 drivers/clk/Kconfig | 1 +
 1 file changed, 1 insertion(+)

index 93f38a8178ba..6b3b424addab 100644
@@ -444,6 +444,7 @@ config COMMON_CLK_BD718XX
 config COMMON_CLK_FIXED_MMIO
 	bool "Clock driver for Memory Mapped Fixed values"
 	depends on COMMON_CLK && OF
+	depends on HAS_IOMEM
 	help
 	  Support for Memory Mapped IO Fixed clocks
 

2.34.1

Quoting Baoquan He (2023-07-07 06:58:51)

Applied to clk-fixes

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available.

In LKP error report at below on s390:
------
ld: kernel/dma/coherent.o: in function `dma_init_coherent_memory':
coherent.c:(.text+0x102): undefined reference to `memremap'
ld: coherent.c:(.text+0x226): undefined reference to `memunmap'
ld: kernel/dma/coherent.o: in function `dma_declare_coherent_memory':
coherent.c:(.text+0x8b8): undefined reference to `memunmap'
ld: kernel/dma/coherent.o: in function `dma_release_coherent_memory':
coherent.c:(.text+0x9aa): undefined reference to `memunmap'
------

In the config file, several Kconfig options are:
------
'# CONFIG_PCI is not set'
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_DMA_DECLARE_COHERENT=y
------

So, enabling OF_EARLY_FLATTREE will select DMA_DECLARE_COHERENT and cause above building errors even though they are not needed because CONFIG_PCI is disabled.

Here let OF_EARLY_FLATTREE depend on HAS_IOMEM so that it won't be built to cause compiling error if PCI is unset.

---
 drivers/of/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index e40f10bf2ba4..da9826accb1b 100644
@@ -55,7 +55,7 @@ config OF_FLATTREE
 
 config OF_EARLY_FLATTREE
 	bool
-	select DMA_DECLARE_COHERENT if HAS_DMA
+	select DMA_DECLARE_COHERENT if HAS_DMA && HAS_IOMEM
 	select OF_FLATTREE
 
 config OF_PROMTREE

2.34.1

Applied, thanks!

Applied, thanks!

[1/8] idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM

      commit: 33629b377856fe5722a2a813b83d21e88281d474

Best regards,

~Vinod