diff mbox

[1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

Message ID 1459275781-3863-1-git-send-email-robh@kernel.org
State New
Headers show

Commit Message

Rob Herring (Arm) March 29, 2016, 6:23 p.m. UTC
Drivers shouldn't have to care about HAS_IOMEM to compile and having to
causes a Kconfig mess:

warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
needs. This fixes build errors for UM allyesconfig:

drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
     iounmap(base);

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>

---
 include/asm-generic/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.5.0

Comments

Arnd Bergmann March 29, 2016, 7:37 p.m. UTC | #1
On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:
> Drivers shouldn't have to care about HAS_IOMEM to compile and having to

> causes a Kconfig mess:

> 

> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

> 

> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

> needs. This fixes build errors for UM allyesconfig:

> 

> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>      iounmap(base);

> 

> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

> Cc: Arnd Bergmann <arnd@arndb.de>

> Cc: linux-arch@vger.kernel.org

> Signed-off-by: Rob Herring <robh@kernel.org>


(adding Richard and the UML list to cc)

I actually prototyped a patch that did the opposite: remove the readl/writel/...
definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
but see below for what I did.

I think it makes sense to do either one or the other.

	Arnddiff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a043107..f6dc17a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -8,6 +8,7 @@ source "drivers/tty/Kconfig"
 
 config DEVMEM
 	bool "/dev/mem virtual device support"
+	depends on HAS_IOMEM
 	default y
 	help
 	  Say Y here if you want to support the /dev/mem device.
@@ -17,6 +18,7 @@ config DEVMEM
 
 config DEVKMEM
 	bool "/dev/kmem virtual device support"
+	depends on HAS_IOMEM
 	default y
 	help
 	  Say Y here if you want to support the /dev/kmem device. The
@@ -94,6 +96,7 @@ config BFIN_OTP_WRITE_ENABLE
 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
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 4f6f94c..eedd129 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -91,6 +91,7 @@ void __weak unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
 }
 #endif
 
+#ifdef CONFIG_DEVMEM
 /*
  * This funcion reads the *physical* memory. The f_pos points directly to the
  * memory location.
@@ -219,6 +220,7 @@ static ssize_t write_mem(struct file *file, const char __user *buf,
 	*ppos += written;
 	return written;
 }
+#endif
 
 int __weak phys_mem_access_prot_allowed(struct file *file,
 	unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
@@ -312,6 +314,7 @@ static inline int private_mapping_ok(struct vm_area_struct *vma)
 }
 #endif
 
+#ifdef CONFIG_DEVMEM
 static const struct vm_operations_struct mmap_mem_ops = {
 #ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys
@@ -351,7 +354,9 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
 	}
 	return 0;
 }
+#endif
 
+#ifdef CONFIG_DEVKMEM
 static int mmap_kmem(struct file *file, struct vm_area_struct *vma)
 {
 	unsigned long pfn;
@@ -552,7 +557,9 @@ static ssize_t write_kmem(struct file *file, const char __user *buf,
 	*ppos = p;
 	return virtr + wrote ? : err;
 }
+#endif
 
+#ifdef CONFIG_DEVPORT
 static ssize_t read_port(struct file *file, char __user *buf,
 			 size_t count, loff_t *ppos)
 {
@@ -594,6 +601,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)
@@ -710,10 +718,12 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
 	return ret;
 }
 
+#ifdef CONFIG_DEVPORT
 static int open_port(struct inode *inode, struct file *filp)
 {
 	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
+#endif
 
 #define zero_lseek	null_lseek
 #define full_lseek      null_lseek
@@ -722,6 +732,7 @@ static int open_port(struct inode *inode, struct file *filp)
 #define open_mem	open_port
 #define open_kmem	open_mem
 
+#ifdef CONFIG_DEVMEM
 static const struct file_operations __maybe_unused mem_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_mem,
@@ -733,7 +744,9 @@ static const struct file_operations __maybe_unused mem_fops = {
 	.mmap_capabilities = memory_mmap_capabilities,
 #endif
 };
+#endif
 
+#ifdef CONFIG_DEVKMEM
 static const struct file_operations __maybe_unused kmem_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_kmem,
@@ -745,6 +758,7 @@ static const struct file_operations __maybe_unused kmem_fops = {
 	.mmap_capabilities = memory_mmap_capabilities,
 #endif
 };
+#endif
 
 static const struct file_operations null_fops = {
 	.llseek		= null_lseek,
@@ -755,12 +769,14 @@ static const struct file_operations null_fops = {
 	.splice_write	= splice_write_null,
 };
 
+#ifdef CONFIG_DEVPORT
 static const struct file_operations __maybe_unused 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,
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db740..6b58974 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -38,6 +38,7 @@ config DIGICOLOR_TIMER
 config DW_APB_TIMER
 	bool "DW APB timer driver" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS
+	depends on HAS_IOMEM
 	help
 	  Enables the support for the dw_apb timer.
 
@@ -64,6 +65,7 @@ config ARMADA_370_XP_TIMER
 config MESON6_TIMER
 	bool "Meson6 timer driver" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS
+	depends on HAS_IOMEM
 	select CLKSRC_MMIO
 	help
 	  Enables the support for the Meson6 timer driver.
@@ -114,6 +116,7 @@ config CADENCE_TTC_TIMER
 config ASM9260_TIMER
 	bool "ASM9260 timer driver" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS
+	depends on HAS_IOMEM
 	select CLKSRC_MMIO
 	select CLKSRC_OF
 	help
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index 3a75f42..adf1391 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -4,6 +4,7 @@
 
 menuconfig FMC
 	tristate "FMC support"
+	depends on HAS_IOMEM
 	help
 
 	  FMC (FPGA Mezzanine Carrier) is a mechanical and electrical
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c9b9fdf..36c54af 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -21,6 +21,7 @@ config FPGA_MGR_SOCFPGA
 
 config FPGA_MGR_ZYNQ_FPGA
 	tristate "Xilinx Zynq FPGA"
+	depends on HAS_IOMEM
 	help
 	  FPGA manager driver support for Xilinx Zynq FPGAs.
 
diff --git a/drivers/hwtracing/intel_th/Kconfig b/drivers/hwtracing/intel_th/Kconfig
index b7a9073..467dae9 100644
--- a/drivers/hwtracing/intel_th/Kconfig
+++ b/drivers/hwtracing/intel_th/Kconfig
@@ -1,5 +1,6 @@
 config INTEL_TH
 	tristate "Intel(R) Trace Hub controller"
+	depends on HAS_IOMEM
 	help
 	  Intel(R) Trace Hub (TH) is a set of hardware blocks (subdevices) that
 	  produce, switch and output trace data from multiple hardware and
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de..6ff6246 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -999,6 +999,7 @@ config MFD_SUN6I_PRCM
 
 config MFD_SYSCON
 	bool "System Controller Register R/W Based on Regmap"
+	depends on HAS_IOMEM
 	select REGMAP_MMIO
 	help
 	  Select this option to enable accessing system control registers
diff --git a/drivers/misc/altera-stapl/Kconfig b/drivers/misc/altera-stapl/Kconfig
index 7f01d8e..c7e4c77 100644
--- a/drivers/misc/altera-stapl/Kconfig
+++ b/drivers/misc/altera-stapl/Kconfig
@@ -2,7 +2,7 @@ comment "Altera FPGA firmware download module"
 
 config ALTERA_STAPL
 	tristate "Altera FPGA firmware download module"
-	depends on I2C
+	depends on I2C && HAS_IOPORT
 	default n
 	help
 	  An Altera FPGA module. Say Y when you want to support this tool.
diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
index 3b3dabc..189ddce 100644
--- a/drivers/mtd/chips/Kconfig
+++ b/drivers/mtd/chips/Kconfig
@@ -3,6 +3,7 @@ menu "RAM/ROM/Flash chip drivers"
 
 config MTD_CFI
 	tristate "Detect flash chips by Common Flash Interface (CFI) probe"
+	depends on HAS_IOMEM
 	select MTD_GEN_PROBE
 	select MTD_CFI_UTIL
 	help
@@ -15,6 +16,7 @@ config MTD_CFI
 
 config MTD_JEDECPROBE
 	tristate "Detect non-CFI AMD/JEDEC-compatible flash chips"
+	depends on HAS_IOMEM
 	select MTD_GEN_PROBE
 	select MTD_CFI_UTIL
 	help
@@ -207,12 +209,14 @@ config MTD_CFI_UTIL
 
 config MTD_RAM
 	tristate "Support for RAM chips in bus mapping"
+	depends on HAS_IOMEM
 	help
 	  This option enables basic support for RAM chips accessed through
 	  a bus mapping driver.
 
 config MTD_ROM
 	tristate "Support for ROM chips in bus mapping"
+	depends on HAS_IOMEM
 	help
 	  This option enables basic support for ROM chips accessed through
 	  a bus mapping driver.
diff --git a/drivers/mtd/lpddr/Kconfig b/drivers/mtd/lpddr/Kconfig
index 3a19cbe..07dd95a 100644
--- a/drivers/mtd/lpddr/Kconfig
+++ b/drivers/mtd/lpddr/Kconfig
@@ -4,6 +4,7 @@ menu "LPDDR & LPDDR2 PCM memory drivers"
 config MTD_LPDDR
 	tristate "Support for LPDDR flash chips"
 	select MTD_QINFO_PROBE
+	depends on HAS_IOMEM
 	help
 	  This option enables support of LPDDR (Low power double data rate)
 	  flash chips. Synonymous with Mobile-DDR. It is a new standard for
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 7c95a65..86a9604 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -3,7 +3,8 @@ menu "Mapping drivers for chip access"
 	depends on HAS_IOMEM
 
 config MTD_COMPLEX_MAPPINGS
-	bool "Support non-linear mappings of flash chips"
+	bool "Support non-linear mappings of flash chips" if HAS_IOMEM
+	default !HAS_IOMEM
 	help
 	  This causes the chip drivers to allow for complicated
 	  paged mappings of flash chips.
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 20f01b3..6ed3de7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -12,7 +12,7 @@ config MTD_NAND_ECC_SMC
 
 menuconfig MTD_NAND
 	tristate "NAND Device Support"
-	depends on MTD
+	depends on MTD && HAS_IOMEM
 	select MTD_NAND_IDS
 	select MTD_NAND_ECC
 	help
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 0dc9275..83befab 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -9,6 +9,7 @@ if MTD_SPI_NOR
 
 config MTD_MT81xx_NOR
 	tristate "Mediatek MT81xx SPI NOR flash controller"
+	depends on HAS_IOMEM
 	help
 	  This enables access to SPI NOR flash, using MT81xx SPI NOR flash
 	  controller. This controller does not support generic SPI BUS, it only
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 6d04183..b1e268b 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -132,6 +132,7 @@ config CAN_RCAR
 config CAN_SUN4I
 	tristate "Allwinner A10 CAN controller"
 	depends on MACH_SUN4I || MACH_SUN7I || COMPILE_TEST
+	depends on HAS_IOMEM
 	---help---
 	  Say Y here if you want to use CAN controller found on Allwinner
 	  A10/A20 SoCs.
diff --git a/drivers/net/hamradio/Kconfig b/drivers/net/hamradio/Kconfig
index bf5e596..507f7a5 100644
--- a/drivers/net/hamradio/Kconfig
+++ b/drivers/net/hamradio/Kconfig
@@ -113,7 +113,8 @@ config SCC_TRXECHO
 
 config BAYCOM_SER_FDX
 	tristate "BAYCOM ser12 fullduplex driver for AX.25"
-	depends on AX25 && !S390
+	depends on AX25
+	depends on HAS_IOPORT
 	select CRC_CCITT
 	---help---
 	  This is one of two drivers for Baycom style simple amateur radio
@@ -133,7 +134,8 @@ config BAYCOM_SER_FDX
 
 config BAYCOM_SER_HDX
 	tristate "BAYCOM ser12 halfduplex driver for AX.25"
-	depends on AX25 && !S390
+	depends on AX25
+	depends on HAS_IOPORT
 	select CRC_CCITT
 	---help---
 	  This is one of two drivers for Baycom style simple amateur radio
@@ -181,7 +183,8 @@ config BAYCOM_EPP
 
 config YAM
 	tristate "YAM driver for AX.25"
-	depends on AX25 && !S390
+	depends on AX25
+	depends on 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/nvmem/Kconfig b/drivers/nvmem/Kconfig
index bc4ea58..6ef3d0a 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -1,6 +1,7 @@
 menuconfig NVMEM
 	tristate "NVMEM Support"
 	select REGMAP
+	depends on HAS_IOMEM
 	help
 	  Support for NVMEM(Non Volatile Memory) devices like EEPROM, EFUSES...
 
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e7e117d..d2216df 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -30,9 +30,10 @@ config PHY_BERLIN_SATA
 	  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
 config ARMADA375_USBCLUSTER_PHY
-	def_bool y
-	depends on MACH_ARMADA_375 || COMPILE_TEST
+	bool "ARMADA 375 USB cluster PHY driver" if COMPILE_TEST && !MACH_ARMADA_375
+	def_bool MACH_ARMADA_375
 	depends on OF
+	depends on HAS_IOMEM
 	select GENERIC_PHY
 
 config PHY_DM816X_USB
@@ -128,6 +129,7 @@ config PHY_RCAR_GEN3_USB2
 config OMAP_CONTROL_PHY
 	tristate "OMAP CONTROL PHY Driver"
 	depends on ARCH_OMAP2PLUS || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  Enable this to add support for the PHY part present in the control
 	  module. This driver has API to power on the USB2 PHY and to write to
@@ -224,6 +226,8 @@ config PHY_MT65XX_USB3
 
 config PHY_HI6220_USB
 	tristate "hi6220 USB PHY support"
+	depends on ARM64 || COMPILE_TEST
+	depends on HAS_IOMEM
 	select GENERIC_PHY
 	select MFD_SYSCON
 	help
@@ -401,6 +405,7 @@ config PHY_CYGNUS_PCIE
 	tristate "Broadcom Cygnus PCIe PHY driver"
 	depends on OF && (ARCH_BCM_CYGNUS || COMPILE_TEST)
 	select GENERIC_PHY
+	depends on HAS_IOMEM
 	default ARCH_BCM_CYGNUS
 	help
 	  Enable this to support the Broadcom Cygnus PCIe PHY.
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..bb5bd1b 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -41,7 +41,7 @@ config POWER_RESET_AXXIA
 config POWER_RESET_BRCMSTB
 	bool "Broadcom STB reset driver"
 	depends on ARM || MIPS || COMPILE_TEST
-	depends on MFD_SYSCON
+	depends on MFD_SYSCON && HAS_IOMEM
 	default ARCH_BRCMSTB
 	help
 	  This driver provides restart support for Broadcom STB boards.
@@ -148,6 +148,7 @@ config POWER_RESET_KEYSTONE
 config POWER_RESET_SYSCON
 	bool "Generic SYSCON regmap reset driver"
 	depends on OF
+	depends on HAS_IOMEM
 	select MFD_SYSCON
 	help
 	  Reboot support for generic SYSCON mapped register reset.
@@ -155,6 +156,7 @@ config POWER_RESET_SYSCON
 config POWER_RESET_SYSCON_POWEROFF
 	bool "Generic SYSCON regmap poweroff driver"
 	depends on OF
+	depends on HAS_IOMEM
 	select MFD_SYSCON
 	help
 	  Poweroff support for generic SYSCON mapped register poweroff.
diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
index e7255f8..e1ba4aa 100644
--- a/drivers/staging/comedi/Kconfig
+++ b/drivers/staging/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
@@ -87,6 +88,7 @@ config COMEDI_SERIAL2002
 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
 
@@ -97,6 +99,7 @@ endif # COMEDI_MISC_DRIVERS
 
 menuconfig COMEDI_ISA_DRIVERS
 	bool "Comedi ISA and PC/104 drivers"
+	depends on HAS_IOPORT
 	---help---
 	  Enable comedi ISA and PC/104 drivers to be built
 
@@ -1110,7 +1113,7 @@ endif # COMEDI_PCI_DRIVERS
 
 menuconfig COMEDI_PCMCIA_DRIVERS
 	tristate "Comedi PCMCIA drivers"
-	depends on PCMCIA
+	depends on PCMCIA && HAS_IOPORT
 	---help---
 	  Enable support for comedi PCMCIA drivers.
 
@@ -1262,6 +1265,7 @@ config COMEDI_8255
 config COMEDI_8255_SA
 	tristate "Standalone 8255 support"
 	select COMEDI_8255
+	depends on HAS_IOPORT
 	---help---
 	  Enable support for 8255 digital I/O as a standalone driver.
 
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8cc4ac6..31ae027 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -178,6 +178,7 @@ config THERMAL_EMULATION
 config HISI_THERMAL
 	tristate "Hisilicon thermal driver"
 	depends on (ARCH_HISI && CPU_THERMAL && OF) || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  Enable this to plug hisilicon's thermal sensor driver into the Linux
 	  thermal framework. cpufreq is used as the cooling device to throttle
@@ -198,6 +199,7 @@ config SPEAR_THERMAL
 	bool "SPEAr thermal sensor driver"
 	depends on PLAT_SPEAR || COMPILE_TEST
 	depends on OF
+	depends on HAS_IOMEM
 	help
 	  Enable this to plug the SPEAr thermal sensor driver into the Linux
 	  thermal framework.
@@ -206,6 +208,7 @@ config ROCKCHIP_THERMAL
 	tristate "Rockchip thermal driver"
 	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	depends on RESET_CONTROLLER
+	depends on HAS_IOMEM
 	help
 	  Rockchip thermal driver provides support for Temperature sensor
 	  ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
@@ -216,6 +219,7 @@ config RCAR_THERMAL
 	tristate "Renesas R-Car thermal driver"
 	depends on ARCH_SHMOBILE || COMPILE_TEST
 	depends on HAS_IOMEM
+	depends on HAS_IOMEM
 	help
 	  Enable this to plug the R-Car thermal sensor driver into the Linux
 	  thermal framework.
@@ -223,6 +227,7 @@ config RCAR_THERMAL
 config KIRKWOOD_THERMAL
 	tristate "Temperature sensor on Marvell Kirkwood SoCs"
 	depends on MACH_KIRKWOOD || COMPILE_TEST
+	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Support for the Kirkwood thermal sensor driver into the Linux thermal
@@ -231,6 +236,7 @@ config KIRKWOOD_THERMAL
 config DOVE_THERMAL
 	tristate "Temperature sensor on Marvell Dove SoCs"
 	depends on ARCH_DOVE || MACH_DOVE || COMPILE_TEST
+	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Support for the Dove thermal sensor driver in the Linux thermal
@@ -249,6 +255,7 @@ config DB8500_THERMAL
 config ARMADA_THERMAL
 	tristate "Armada 370/XP thermal management"
 	depends on ARCH_MVEBU || COMPILE_TEST
+	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Enable this option if you want to have support for thermal management
@@ -366,12 +373,12 @@ config INTEL_PCH_THERMAL
 	  programmable trip points and other information.
 
 menu "Texas Instruments thermal drivers"
-depends on ARCH_HAS_BANDGAP || COMPILE_TEST
+depends on ARCH_HAS_BANDGAP || (COMPILE_TEST && HAS_IOMEM)
 source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
 menu "Samsung thermal drivers"
-depends on ARCH_EXYNOS || COMPILE_TEST
+depends on ARCH_EXYNOS || (COMPILE_TEST && HAS_IOMEM)
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 3c1c967..a5d0f12 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -916,6 +916,7 @@ static inline void irq_gc_lock(struct irq_chip_generic *gc) { }
 static inline void irq_gc_unlock(struct irq_chip_generic *gc) { }
 #endif
 
+#ifdef CONFIG_HAS_IOMEM
 static inline void irq_reg_writel(struct irq_chip_generic *gc,
 				  u32 val, int reg_offset)
 {
@@ -933,5 +934,6 @@ static inline u32 irq_reg_readl(struct irq_chip_generic *gc,
 	else
 		return readl(gc->reg_base + reg_offset);
 }
+#endif
 
 #endif /* _LINUX_IRQ_H */
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..d5db153 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -310,6 +310,7 @@ uint32_t cfi_send_gen_cmd(u_char cmd, uint32_t cmd_addr, uint32_t base,
 				struct map_info *map, struct cfi_private *cfi,
 				int type, map_word *prev_val);
 
+#ifdef CONFIG_HAS_IOMEM
 static inline uint8_t cfi_read_query(struct map_info *map, uint32_t addr)
 {
 	map_word val = map_read(map, addr);
@@ -341,6 +342,7 @@ static inline uint16_t cfi_read_query16(struct map_info *map, uint32_t addr)
 		return cfi32_to_cpu(map, val.x[0]);
 	}
 }
+#endif
 
 void cfi_udelay(int us);
 
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 58f3ba7..07c0d497 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -410,6 +410,7 @@ static inline map_word map_word_ff(struct map_info *map)
 	return r;
 }
 
+#ifdef CONFIG_HAS_IOMEM
 static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
 {
 	map_word r;
@@ -463,6 +464,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co
 {
 	memcpy_toio(map->virt + to, from, len);
 }
+#endif
 
 #ifdef CONFIG_MTD_COMPLEX_MAPPINGS
 #define map_read(map, ofs) (map)->read(map, ofs)
diff --git a/kernel/resource.c b/kernel/resource.c
index 09c0597..efd5c9e 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -29,7 +29,9 @@
 struct resource ioport_resource = {
 	.name	= "PCI IO",
 	.start	= 0,
+#ifdef CONFIG_HAS_IOPORT
 	.end	= IO_SPACE_LIMIT,
+#endif
 	.flags	= IORESOURCE_IO,
 };
 EXPORT_SYMBOL(ioport_resource);
diff --git a/lib/Kconfig b/lib/Kconfig
index 133ebc0..38ff36d 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -382,9 +382,14 @@ config HAS_IOMEM
 	select GENERIC_IO
 	default y
 
+config HAS_IOPORT
+	bool
+	depends on HAS_IOMEM && !NO_IOPORT
+	default y
+
 config HAS_IOPORT_MAP
 	bool
-	depends on HAS_IOMEM && !NO_IOPORT_MAP
+	depends on HAS_IOMEM && HAS_IOPORT && !NO_IOPORT_MAP
 	default y
 
 config HAS_DMA
diff --git a/mm/bootmem.c b/mm/bootmem.c
index 91e32bc..3471237 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -99,7 +99,7 @@ static unsigned long __init init_bootmem_core(bootmem_data_t *bdata,
 	unsigned long mapsize;
 
 	mminit_validate_memmodel_limits(&start, &end);
-	bdata->node_bootmem_map = phys_to_virt(PFN_PHYS(mapstart));
+	bdata->node_bootmem_map = __va(PFN_PHYS(mapstart));
 	bdata->node_min_pfn = start;
 	bdata->node_low_pfn = end;
 	link_bootmem(bdata);
@@ -585,7 +585,7 @@ find_block:
 				PFN_UP(end_off), BOOTMEM_EXCLUSIVE))
 			BUG();
 
-		region = phys_to_virt(PFN_PHYS(bdata->node_min_pfn) +
+		region = __va(PFN_PHYS(bdata->node_min_pfn) +
 				start_off);
 		memset(region, 0, size);
 		/*

Richard Weinberger March 29, 2016, 7:50 p.m. UTC | #2
Am 29.03.2016 um 21:37 schrieb Arnd Bergmann:
> On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:

>> Drivers shouldn't have to care about HAS_IOMEM to compile and having to

>> causes a Kconfig mess:

>>

>> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

>> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

>>

>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

>> needs. This fixes build errors for UM allyesconfig:

>>

>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>>      iounmap(base);

>>

>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

>> Cc: Arnd Bergmann <arnd@arndb.de>

>> Cc: linux-arch@vger.kernel.org

>> Signed-off-by: Rob Herring <robh@kernel.org>

> 

> (adding Richard and the UML list to cc)


For the above error I've sent already a fix:
https://lkml.org/lkml/2016/3/25/321

> I actually prototyped a patch that did the opposite: remove the readl/writel/...

> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

> but see below for what I did.

> 

> I think it makes sense to do either one or the other.

> 

> 	Arnd

> 

> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig

> index a043107..f6dc17a 100644

> --- a/drivers/char/Kconfig

> +++ b/drivers/char/Kconfig

> @@ -8,6 +8,7 @@ source "drivers/tty/Kconfig"

>  

>  config DEVMEM

>  	bool "/dev/mem virtual device support"

> +	depends on HAS_IOMEM


Hmm, this means no /dev/mem device for UML? (And some s390 variants).
Not sure if this a good idea.
But I like it more than having ioremap/iounmap stubs for !HAS_IOMEM. :)

Thanks,
//richard
Rob Herring (Arm) March 29, 2016, 8:13 p.m. UTC | #3
On Tue, Mar 29, 2016 at 2:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:

>> Drivers shouldn't have to care about HAS_IOMEM to compile and having to

>> causes a Kconfig mess:

>>

>> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

>> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

>>

>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

>> needs. This fixes build errors for UM allyesconfig:

>>

>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>>      iounmap(base);

>>

>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

>> Cc: Arnd Bergmann <arnd@arndb.de>

>> Cc: linux-arch@vger.kernel.org

>> Signed-off-by: Rob Herring <robh@kernel.org>

>

> (adding Richard and the UML list to cc)

>

> I actually prototyped a patch that did the opposite: remove the readl/writel/...

> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

> but see below for what I did.


Ewww. Why do the opposite of what we do for every other Kconfig symbol
which is provide empty functions? It really only functions as a
disable on UML flag which runs counter to enabling drivers to build
for all arches.

I actually started a patch to remove the HAS_IOMEM dependency
everywhere (or just the per driver cases). It didn't break as bad as I
expected, but became more than I wanted to fix. Mainly, all the devm_
variants also need empty versions or to be always enabled.

Rob
Krzysztof Kozlowski March 30, 2016, 4:19 a.m. UTC | #4
On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring <robh@kernel.org> wrote:
> Drivers shouldn't have to care about HAS_IOMEM to compile and having to

> causes a Kconfig mess:

>

> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

>

> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

> needs. This fixes build errors for UM allyesconfig:

>

> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>      iounmap(base);

>

> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

> Cc: Arnd Bergmann <arnd@arndb.de>

> Cc: linux-arch@vger.kernel.org

> Signed-off-by: Rob Herring <robh@kernel.org>

> ---

>  include/asm-generic/io.h | 2 +-

>  1 file changed, 1 insertion(+), 1 deletion(-)


Some time ago I posted patches adding the dependency, but that path
looks like a better approach:

Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>


Best regards,
Krzysztof
Richard Weinberger March 30, 2016, 7:50 a.m. UTC | #5
Am 29.03.2016 um 22:13 schrieb Rob Herring:
>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

>>> needs. This fixes build errors for UM allyesconfig:

>>>

>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>>>      iounmap(base);

>>>

>>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

>>> Cc: Arnd Bergmann <arnd@arndb.de>

>>> Cc: linux-arch@vger.kernel.org

>>> Signed-off-by: Rob Herring <robh@kernel.org>

>>

>> (adding Richard and the UML list to cc)

>>

>> I actually prototyped a patch that did the opposite: remove the readl/writel/...

>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

>> but see below for what I did.

> 

> Ewww. Why do the opposite of what we do for every other Kconfig symbol

> which is provide empty functions? It really only functions as a

> disable on UML flag which runs counter to enabling drivers to build

> for all arches.

> 

> I actually started a patch to remove the HAS_IOMEM dependency

> everywhere (or just the per driver cases). It didn't break as bad as I

> expected, but became more than I wanted to fix. Mainly, all the devm_

> variants also need empty versions or to be always enabled.


The root cause of the problem is COMPILE_TEST. People who use it need to
get forced to think about the consequences.
COMPILE_TEST means that the driver will also be build on not so fancy archs
like UML, s390 and m68k where you don't have IOMEM or also DMA in every
possible configuration.
So a quick build test on x86 is not sufficient.

This is why I'm absolutely not a fan of having stubs for iounmap() an friends
for UML. It only tries to bypass the root cause.
What is next? Stubs for DMA? PCI? For everything else that does not build?

With COMPILE_TEST we have created a monster and now we have to deal with it in terms of
having correct dependencies when COMPILE_TEST is being used.

Thanks,
//richard
Arnd Bergmann March 30, 2016, 8:04 a.m. UTC | #6
On Wednesday 30 March 2016 09:50:22 Richard Weinberger wrote:
> Am 29.03.2016 um 22:13 schrieb Rob Herring:

> >>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

> >>> needs. This fixes build errors for UM allyesconfig:

> >>>

> >>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

> >>>      iounmap(base);

> >>>

> >>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

> >>> Cc: Arnd Bergmann <arnd@arndb.de>

> >>> Cc: linux-arch@vger.kernel.org

> >>> Signed-off-by: Rob Herring <robh@kernel.org>

> >>

> >> (adding Richard and the UML list to cc)

> >>

> >> I actually prototyped a patch that did the opposite: remove the readl/writel/...

> >> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

> >> but see below for what I did.

> > 

> > Ewww. Why do the opposite of what we do for every other Kconfig symbol

> > which is provide empty functions? It really only functions as a

> > disable on UML flag which runs counter to enabling drivers to build

> > for all arches.

> > 

> > I actually started a patch to remove the HAS_IOMEM dependency

> > everywhere (or just the per driver cases). It didn't break as bad as I

> > expected, but became more than I wanted to fix. Mainly, all the devm_

> > variants also need empty versions or to be always enabled.

> 

> The root cause of the problem is COMPILE_TEST. People who use it need to

> get forced to think about the consequences.

> COMPILE_TEST means that the driver will also be build on not so fancy archs

> like UML, s390 and m68k where you don't have IOMEM or also DMA in every

> possible configuration.

> So a quick build test on x86 is not sufficient.

> 

> This is why I'm absolutely not a fan of having stubs for iounmap() an friends

> for UML. It only tries to bypass the root cause.

> What is next? Stubs for DMA? PCI? For everything else that does not build?

> 

> With COMPILE_TEST we have created a monster and now we have to deal with it in terms of

> having correct dependencies when COMPILE_TEST is being used.

> 


One way out of this would be accept that UML is just too different
from the other architectures, and make COMPILE_TEST itself depend
on !UML.

COMPILE_TEST is highly valuable for me, because it means that all the
ARM specific drivers can now be build-tested on x86 and they show up
for anyone doing allmodconfig builds. If we introduce a regression
in any of the drivers, it gets caught much quicker because many
subsystem maintainers run an x86 allmodconfig build after pulling
downstream maintainer trees. There is also stuff like Coverity that
only ever runs on x86.

It does make sense to have COMPILE_TEST imply that we are able
to build things on all architectures, not just x86 in addition to
the platform a driver is meant for, but the value of compile-testing
a random driver with UML in particular approaches zero, and instead
causes lots of work.

	Arnd
Richard Weinberger March 30, 2016, 8:13 a.m. UTC | #7
Am 30.03.2016 um 10:04 schrieb Arnd Bergmann:
> On Wednesday 30 March 2016 09:50:22 Richard Weinberger wrote:

>> Am 29.03.2016 um 22:13 schrieb Rob Herring:

>>>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

>>>>> needs. This fixes build errors for UM allyesconfig:

>>>>>

>>>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>>>>>      iounmap(base);

>>>>>

>>>>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

>>>>> Cc: Arnd Bergmann <arnd@arndb.de>

>>>>> Cc: linux-arch@vger.kernel.org

>>>>> Signed-off-by: Rob Herring <robh@kernel.org>

>>>>

>>>> (adding Richard and the UML list to cc)

>>>>

>>>> I actually prototyped a patch that did the opposite: remove the readl/writel/...

>>>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

>>>> but see below for what I did.

>>>

>>> Ewww. Why do the opposite of what we do for every other Kconfig symbol

>>> which is provide empty functions? It really only functions as a

>>> disable on UML flag which runs counter to enabling drivers to build

>>> for all arches.

>>>

>>> I actually started a patch to remove the HAS_IOMEM dependency

>>> everywhere (or just the per driver cases). It didn't break as bad as I

>>> expected, but became more than I wanted to fix. Mainly, all the devm_

>>> variants also need empty versions or to be always enabled.

>>

>> The root cause of the problem is COMPILE_TEST. People who use it need to

>> get forced to think about the consequences.

>> COMPILE_TEST means that the driver will also be build on not so fancy archs

>> like UML, s390 and m68k where you don't have IOMEM or also DMA in every

>> possible configuration.

>> So a quick build test on x86 is not sufficient.

>>

>> This is why I'm absolutely not a fan of having stubs for iounmap() an friends

>> for UML. It only tries to bypass the root cause.

>> What is next? Stubs for DMA? PCI? For everything else that does not build?

>>

>> With COMPILE_TEST we have created a monster and now we have to deal with it in terms of

>> having correct dependencies when COMPILE_TEST is being used.

>>

> 

> One way out of this would be accept that UML is just too different

> from the other architectures, and make COMPILE_TEST itself depend

> on !UML.

> 

> COMPILE_TEST is highly valuable for me, because it means that all the

> ARM specific drivers can now be build-tested on x86 and they show up

> for anyone doing allmodconfig builds. If we introduce a regression

> in any of the drivers, it gets caught much quicker because many

> subsystem maintainers run an x86 allmodconfig build after pulling

> downstream maintainer trees. There is also stuff like Coverity that

> only ever runs on x86.

> 

> It does make sense to have COMPILE_TEST imply that we are able

> to build things on all architectures, not just x86 in addition to

> the platform a driver is meant for, but the value of compile-testing

> a random driver with UML in particular approaches zero, and instead

> causes lots of work.


I fully understand your point of view. COMPILE_TEST is a monster that
can do the heavy lifting for you, but monsters also have claws and fangs. ;-)

Having COMPILE_TEST having depend on !UML works for me. But don't
we have other archs without io mem? At least a few years ago while
porting nandsim to UML I found s390 that lacks of io mem too.

Maybe we depend COMPILE_TEST on HAS_IOMEM?

Thanks,
//richard
Arnd Bergmann March 30, 2016, 10:03 a.m. UTC | #8
On Wednesday 30 March 2016 10:13:53 Richard Weinberger wrote:
> 

> I fully understand your point of view. COMPILE_TEST is a monster that

> can do the heavy lifting for you, but monsters also have claws and fangs. 

> 

> Having COMPILE_TEST having depend on !UML works for me. But don't

> we have other archs without io mem? At least a few years ago while

> porting nandsim to UML I found s390 that lacks of io mem too.


s390 gained IOMEM support when they started having PCI attachments.

arch/score selects NO_IOMEM, though they do in fact use MMIO, and
I'm sure their architecture has lots of other problems with build
testing that nobody cares about.

arch/tile can select NO_IOMEM when PCI is disabled, they might
care about this, though I think they also have other build-time
issues.

> Maybe we depend COMPILE_TEST on HAS_IOMEM?


That sounds fine with me as well.

	Arnd
Rob Herring (Arm) March 30, 2016, 1:29 p.m. UTC | #9
On Wed, Mar 30, 2016 at 5:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 30 March 2016 10:13:53 Richard Weinberger wrote:

>>

>> I fully understand your point of view. COMPILE_TEST is a monster that

>> can do the heavy lifting for you, but monsters also have claws and fangs.

>>

>> Having COMPILE_TEST having depend on !UML works for me. But don't

>> we have other archs without io mem? At least a few years ago while

>> porting nandsim to UML I found s390 that lacks of io mem too.

>

> s390 gained IOMEM support when they started having PCI attachments.


I'm confused how s390 defines HAS_IOMEM and includes it from lib/Kconfig though.

> arch/score selects NO_IOMEM, though they do in fact use MMIO, and

> I'm sure their architecture has lots of other problems with build

> testing that nobody cares about.

>

> arch/tile can select NO_IOMEM when PCI is disabled, they might

> care about this, though I think they also have other build-time

> issues.

>

>> Maybe we depend COMPILE_TEST on HAS_IOMEM?

>

> That sounds fine with me as well.


That or !UML is fine, but I still think we should rid drivers from
depending on HAS_IOMEM. We probably still have cases where the only
dependency besides the driver's subsystem is HAS_IOMEM.

Rob
Arnd Bergmann March 30, 2016, 1:51 p.m. UTC | #10
On Wednesday 30 March 2016 08:29:45 Rob Herring wrote:
> On Wed, Mar 30, 2016 at 5:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > On Wednesday 30 March 2016 10:13:53 Richard Weinberger wrote:

> >>

> >> I fully understand your point of view. COMPILE_TEST is a monster that

> >> can do the heavy lifting for you, but monsters also have claws and fangs.

> >>

> >> Having COMPILE_TEST having depend on !UML works for me. But don't

> >> we have other archs without io mem? At least a few years ago while

> >> porting nandsim to UML I found s390 that lacks of io mem too.

> >

> > s390 gained IOMEM support when they started having PCI attachments.

> 

> I'm confused how s390 defines HAS_IOMEM and includes it from lib/Kconfig though.


Kconfig can define the same symbol multiple times, which is really
confusing. I only checked for NO_IOMEM, which s390 no longer defines,
but I have not checked what actually happens in case of two conflicting
definitions, where the one lib/Kconfig defaults to 'y' and the one in
arch/s390 defaults to CONFIG_PCI.

	Arnd
Geert Uytterhoeven March 30, 2016, 8:08 p.m. UTC | #11
Hi Rob,

On Tue, Mar 29, 2016 at 10:13 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Mar 29, 2016 at 2:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:

>> On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:

>>> Drivers shouldn't have to care about HAS_IOMEM to compile and having to

>>> causes a Kconfig mess:

>>>

>>> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

>>> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

>>>

>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

>>> needs. This fixes build errors for UM allyesconfig:

>>>

>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>>>      iounmap(base);

>>>

>>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

>>> Cc: Arnd Bergmann <arnd@arndb.de>

>>> Cc: linux-arch@vger.kernel.org

>>> Signed-off-by: Rob Herring <robh@kernel.org>

>>

>> (adding Richard and the UML list to cc)

>>

>> I actually prototyped a patch that did the opposite: remove the readl/writel/...

>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

>> but see below for what I did.

>

> Ewww. Why do the opposite of what we do for every other Kconfig symbol

> which is provide empty functions? It really only functions as a

> disable on UML flag which runs counter to enabling drivers to build

> for all arches.


Usually the empty function fall into one of two classes:
  1. They return an error, so drivers will abort their initialization,
  2. They are a plain no-op, for functions with harmless side-effects.

The !MMU versions are not dummies, but assume a transparent translation.
This may lead to drivers continuing their initialization and crashing the
system.

> I actually started a patch to remove the HAS_IOMEM dependency

> everywhere (or just the per driver cases). It didn't break as bad as I

> expected, but became more than I wanted to fix. Mainly, all the devm_

> variants also need empty versions or to be always enabled.


Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||
COMPILE_TEST"?

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
Richard Weinberger March 30, 2016, 8:35 p.m. UTC | #12
Am 30.03.2016 um 22:08 schrieb Geert Uytterhoeven:
>> I actually started a patch to remove the HAS_IOMEM dependency

>> everywhere (or just the per driver cases). It didn't break as bad as I

>> expected, but became more than I wanted to fix. Mainly, all the devm_

>> variants also need empty versions or to be always enabled.

> 

> Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||

> COMPILE_TEST"?


Another idea, the issue with COMPILE_TEST is that it is automatically selected
by make targets such as allyesconfig or allmodconfig.
Couldn't we make COMPILE_TEST just harder to select?
i.e. that with allyesconfig it is still disabled and if someone really wants to
do a compile test of anything we could issue something like "make allyesconfig COMPILE_TEST=y"
to have COMPILE_TEST selected?

Thanks,
//richard
Arnd Bergmann March 30, 2016, 8:38 p.m. UTC | #13
On Wednesday 30 March 2016 22:35:37 Richard Weinberger wrote:
> Am 30.03.2016 um 22:08 schrieb Geert Uytterhoeven:

> >> I actually started a patch to remove the HAS_IOMEM dependency

> >> everywhere (or just the per driver cases). It didn't break as bad as I

> >> expected, but became more than I wanted to fix. Mainly, all the devm_

> >> variants also need empty versions or to be always enabled.

> > 

> > Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||

> > COMPILE_TEST"?

> 

> Another idea, the issue with COMPILE_TEST is that it is automatically selected

> by make targets such as allyesconfig or allmodconfig.

> Couldn't we make COMPILE_TEST just harder to select?

> i.e. that with allyesconfig it is still disabled and if someone really wants to

> do a compile test of anything we could issue something like "make allyesconfig COMPILE_TEST=y"

> to have COMPILE_TEST selected?

> 


I think it's essential for allmodconfig and allyesconfig to enable
COMPILE_TEST: the only reason for ever building those configurations
is for compile tests.

	Arnd
Rob Herring (Arm) March 30, 2016, 9:20 p.m. UTC | #14
On Wed, Mar 30, 2016 at 3:08 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Rob,

>

> On Tue, Mar 29, 2016 at 10:13 PM, Rob Herring <robh@kernel.org> wrote:

>> On Tue, Mar 29, 2016 at 2:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:

>>> On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:

>>>> Drivers shouldn't have to care about HAS_IOMEM to compile and having to

>>>> causes a Kconfig mess:

>>>>

>>>> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

>>>> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

>>>>

>>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our

>>>> needs. This fixes build errors for UM allyesconfig:

>>>>

>>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]

>>>>      iounmap(base);

>>>>

>>>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>

>>>> Cc: Arnd Bergmann <arnd@arndb.de>

>>>> Cc: linux-arch@vger.kernel.org

>>>> Signed-off-by: Rob Herring <robh@kernel.org>

>>>

>>> (adding Richard and the UML list to cc)

>>>

>>> I actually prototyped a patch that did the opposite: remove the readl/writel/...

>>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,

>>> but see below for what I did.

>>

>> Ewww. Why do the opposite of what we do for every other Kconfig symbol

>> which is provide empty functions? It really only functions as a

>> disable on UML flag which runs counter to enabling drivers to build

>> for all arches.

>

> Usually the empty function fall into one of two classes:

>   1. They return an error, so drivers will abort their initialization,

>   2. They are a plain no-op, for functions with harmless side-effects.

>

> The !MMU versions are not dummies, but assume a transparent translation.

> This may lead to drivers continuing their initialization and crashing the

> system.


I thought about this, but how could you even get to the point of
having some physical address passed to the driver? Perhaps some old
ISA driver, but I'm not sure memory ranges were ever fixed (only i/o).
We're really only talking about UML here.

It can be done though, it's just more ifdef'ery.

>> I actually started a patch to remove the HAS_IOMEM dependency

>> everywhere (or just the per driver cases). It didn't break as bad as I

>> expected, but became more than I wanted to fix. Mainly, all the devm_

>> variants also need empty versions or to be always enabled.

>

> Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||

> COMPILE_TEST"?


Why? Most are either HAS_IOMEM or HAS_IOMEM && COMPILE_TEST.

Rob
Geert Uytterhoeven March 31, 2016, 8:39 a.m. UTC | #15
Hi Rob,

On Wed, Mar 30, 2016 at 11:20 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Mar 30, 2016 at 3:08 PM, Geert Uytterhoeven

> <geert@linux-m68k.org> wrote:

>> On Tue, Mar 29, 2016 at 10:13 PM, Rob Herring <robh@kernel.org> wrote:

>>> Ewww. Why do the opposite of what we do for every other Kconfig symbol

>>> which is provide empty functions? It really only functions as a

>>> disable on UML flag which runs counter to enabling drivers to build

>>> for all arches.

>>

>> Usually the empty function fall into one of two classes:

>>   1. They return an error, so drivers will abort their initialization,

>>   2. They are a plain no-op, for functions with harmless side-effects.

>>

>> The !MMU versions are not dummies, but assume a transparent translation.

>> This may lead to drivers continuing their initialization and crashing the

>> system.

>

> I thought about this, but how could you even get to the point of

> having some physical address passed to the driver? Perhaps some old

> ISA driver, but I'm not sure memory ranges were ever fixed (only i/o).

> We're really only talking about UML here.


Hmm, perhaps it indeed can't happen.

>>> I actually started a patch to remove the HAS_IOMEM dependency

>>> everywhere (or just the per driver cases). It didn't break as bad as I

>>> expected, but became more than I wanted to fix. Mainly, all the devm_

>>> variants also need empty versions or to be always enabled.

>>

>> Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||

>> COMPILE_TEST"?

>

> Why? Most are either HAS_IOMEM or HAS_IOMEM && COMPILE_TEST.


COMPILE_TEST is meant to enable drivers that are not useful, due to missing
infrastructure.
Without having it enabled, you don't want to include useless drivers.
If you have dummies, you still want the HAS_IOMEM dependency to avoid
compiling useless drivers. I.e. it's a hint for distros, who don't want to ship
useless drivers.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
diff mbox

Patch

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index eed3bbe..03160b0 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -753,7 +753,7 @@  static inline void *phys_to_virt(unsigned long address)
  * ioremap_*() variant as defined to itself to avoid the default NULL return.
  */
 
-#ifdef CONFIG_MMU
+#if defined(CONFIG_MMU) && defined(CONFIG_HAS_IOMEM)
 
 #ifndef ioremap_uc
 #define ioremap_uc ioremap_uc