drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

Several drivers need 'devm_ioremap_resource' which need HAS_IOMEM enabled. So let them depend on HAS_IOMEM.

The related error (with allmodconfig under score):

MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!

Signed-off-by Chen Gang <[email protected]>

---
 drivers/input/serio/Kconfig     | 3 ++-
 drivers/pwm/Kconfig             | 2 +-
 drivers/staging/iio/adc/Kconfig | 2 +-
 drivers/watchdog/Kconfig        | 3 ++-
 4 files changed, 6 insertions(+), 4 deletions(-)

drivers/input/serio/Kconfig +2 -1

index bc2d474..449d45f 100644
@@ -244,6 +244,7 @@ config SERIO_PS2MULT
 
 config SERIO_ARC_PS2
 	tristate "ARC PS/2 support"
+	depends on HAS_IOMEM
 	help
 	  Say Y here if you have an ARC FPGA platform with a PS/2
 	  controller in it.

@@ -263,7 +264,7 @@ config SERIO_APBPS2
 
 config SERIO_OLPC_APSP
 	tristate "OLPC AP-SP input support"
-	depends on OLPC || COMPILE_TEST
+	depends on (OLPC || COMPILE_TEST) && HAS_IOMEM
 	help
 	  Say Y here if you want support for the keyboard and touchpad included
 	  in the OLPC XO-1.75 and XO-4 laptops.

drivers/pwm/Kconfig +1 -1

index 4ad7b89..2faf5ce 100644
@@ -82,7 +82,7 @@ config PWM_BFIN
 
 config PWM_CLPS711X
 	tristate "CLPS711X PWM support"
-	depends on ARCH_CLPS711X || COMPILE_TEST
+	depends on (ARCH_CLPS711X || COMPILE_TEST) && HAS_IOMEM
 	help
 	  Generic PWM framework driver for Cirrus Logic CLPS711X.
 

drivers/staging/iio/adc/Kconfig +1 -1

index b87e382..4e927d2 100644
@@ -94,7 +94,7 @@ config LPC32XX_ADC
 
 config MXS_LRADC
 	tristate "Freescale i.MX23/i.MX28 LRADC"
-	depends on ARCH_MXS || COMPILE_TEST
+	depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
 	depends on INPUT
 	select STMP_DEVICE
 	select IIO_BUFFER

drivers/watchdog/Kconfig +2 -1

index 76dd541..0e4abb2 100644
@@ -113,6 +113,7 @@ config WM8350_WATCHDOG
 
 config XILINX_WATCHDOG
 	tristate "Xilinx Watchdog timer"
+	depends on HAS_IOMEM
 	select WATCHDOG_CORE
 	help
 	  Watchdog driver for the xps_timebase_wdt ip core.

@@ -434,7 +435,7 @@ config SIRFSOC_WATCHDOG
 
 config TEGRA_WATCHDOG
 	tristate "Tegra watchdog"
-	depends on ARCH_TEGRA || COMPILE_TEST
+	depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM
 	select WATCHDOG_CORE
 	help
 	  Say Y here to include support for the watchdog timer

And also find a compiler issue, I will try to fix it, but shall not notify kernel mailing list, again. The related issue is below (it seems a kernel issue, but in fact, it is a compiler's issue):

CC [M] drivers/staging/lustre/lustre/ptlrpc/sec.o
drivers/staging/lustre/lustre/ptlrpc/sec.c: In function 'sptlrpc_cli_ctx_expire':
drivers/staging/lustre/lustre/ptlrpc/sec.c:309:13: error: 'struct ptlrpc_ctx_ops' has no member named '__die'

    ctx->cc_ops->die(ctx, 0);
               ^
  drivers/staging/lustre/lustre/ptlrpc/sec.c: In function 'ctx_refresh_timeout':
  drivers/staging/lustre/lustre/ptlrpc/sec.c:594:26: error: 'struct ptlrpc_ctx_ops' has no member named '__die'
     req->rq_cli_ctx->cc_ops->die(req->rq_cli_ctx, 0);
                            ^

make[5]: *** [drivers/staging/lustre/lustre/ptlrpc/sec.o] Error 1 make[4]: *** [drivers/staging/lustre/lustre/ptlrpc] Error 2 make[3]: *** [drivers/staging/lustre/lustre] Error 2 make[2]: *** [drivers/staging/lustre] Error 2
make[1]: *** [drivers/staging] Error 2
make: *** [drivers] Error 2

Several drivers need 'devm_ioremap_resource' which need HAS_IOMEM enabled. So let them depend on HAS_IOMEM.

The related error (with allmodconfig under score):

MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko]
undefined! ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] undefined! ERROR:
"devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined! ERROR:
"devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!

Quoted 5 lines

Several drivers need 'devm_ioremap_resource' which need HAS_IOMEM enabled. So let them depend on HAS_IOMEM.

The related error (with allmodconfig under score):

Quoted 8 lines

MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko]
undefined! ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] undefined! ERROR:
"devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined! ERROR:
"devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!

This stuff should go through different trees, so I'd suggest to split this into multiple patches. Thanks for catching this stuff !

Best regards,
Marek Vasut

As I said before, some configurations don't make sense.

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 7 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Quoted 3 lines

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

Quoted 12 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 10 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

Quoted 2 lines

And what should this stub do?
Except calling BUG()...

return NULL;

It's for compile testing, it's not meant to work at runtime.

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:

Quoted 16 lines · Richard Weinberger

Quoted 14 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 10 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

Quoted 3 lines

return NULL;

It's for compile testing, it's not meant to work at runtime.

Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think?

Quoted 19 lines · Richard Weinberger

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:

Quoted 18 lines · Richard Weinberger

Quoted 8 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 7 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Quoted 6 lines

Quoted 3 lines

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

return NULL;

Quoted 5 lines

Quoted 1 line

It's for compile testing, it's not meant to work at runtime.

Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think?

The kernel will still be working fine and you can run it on a system. The drivers which use ioremap() or similar are probably not instantiated on a system that does not provide HAS_IOMEM. But even if it was the driver should handle ioremap() returning NULL gracefully and abort the driver probe. That said you'll probably not run a kernel that was built with COMPILE_TEST on your real hardware since it contains so many drivers that are completely useless on your hardware. The idea of COMPILE_TEST is to have as much compile test exposure as possible to the code that is enabled by COMPILE_TEST. Stubbing out ioremap() and friends when HAS_IOMEM is not set and COMPILE_TEST is set makes it easier to get there.

Quoted 17 lines · Richard Weinberger

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:

Quoted 16 lines · Richard Weinberger

Quoted 14 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 10 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

Quoted 7 lines

Quoted 3 lines

return NULL;

It's for compile testing, it's not meant to work at runtime.

Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think?

The kernel will still be working fine and you can run it on a system. The drivers which use ioremap() or similar are probably not instantiated on a system that does not provide HAS_IOMEM. But even if it was the driver should handle ioremap() returning NULL gracefully and abort the driver probe. That said you'll probably not run a kernel that was built with COMPILE_TEST on your real hardware since it contains so many drivers that are completely useless on your hardware. The idea of COMPILE_TEST is to have as much compile test exposure as possible to the code that is enabled by COMPILE_TEST. Stubbing out ioremap() and friends when HAS_IOMEM is not set and COMPILE_TEST is set makes it easier to get there.

Quoted 26 lines · Richard Weinberger

Quoted 17 lines

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:

Quoted 16 lines · Richard Weinberger

Quoted 14 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 10 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

Quoted 7 lines

Quoted 3 lines

return NULL;

It's for compile testing, it's not meant to work at runtime.

Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think?

Quoted 10 lines

The kernel will still be working fine and you can run it on a system. The drivers which use ioremap() or similar are probably not instantiated on a system that does not provide HAS_IOMEM. But even if it was the driver should handle ioremap() returning NULL gracefully and abort the driver probe. That said you'll probably not run a kernel that was built with COMPILE_TEST on your real hardware since it contains so many drivers that are completely useless on your hardware. The idea of COMPILE_TEST is to have as much compile test exposure as possible to the code that is enabled by COMPILE_TEST. Stubbing out ioremap() and friends when HAS_IOMEM is not set and COMPILE_TEST is set makes it easier to get there.

I run my kernels with COMPILE_TEST enabled as I need to build test things that I don't happen to use.

I like the 'return NULL' option for this, it hits us all the time, might as well fix it properly like this so that we don't have to deal with Kconfig changes everywhere.

Also put a big "This platform does not support IOMEM" error printk in there, so that people have a chance to figure out what is going on if they happen to run such a driver on a platform that can't support it.

Am 13.07.2014 21:22, schrieb Greg Kroah-Hartman:

Quoted 45 lines · Lars-Peter Clausen

Quoted 26 lines · Richard Weinberger

Quoted 17 lines

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:

Quoted 16 lines · Richard Weinberger

Quoted 14 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 10 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

Quoted 7 lines

Quoted 3 lines

return NULL;

It's for compile testing, it's not meant to work at runtime.

Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think?

Quoted 10 lines

The kernel will still be working fine and you can run it on a system. The drivers which use ioremap() or similar are probably not instantiated on a system that does not provide HAS_IOMEM. But even if it was the driver should handle ioremap() returning NULL gracefully and abort the driver probe. That said you'll probably not run a kernel that was built with COMPILE_TEST on your real hardware since it contains so many drivers that are completely useless on your hardware. The idea of COMPILE_TEST is to have as much compile test exposure as possible to the code that is enabled by COMPILE_TEST. Stubbing out ioremap() and friends when HAS_IOMEM is not set and COMPILE_TEST is set makes it easier to get there.

I run my kernels with COMPILE_TEST enabled as I need to build test things that I don't happen to use.

I like the 'return NULL' option for this, it hits us all the time, might as well fix it properly like this so that we don't have to deal with Kconfig changes everywhere.

Quoted 3 lines

Also put a big "This platform does not support IOMEM" error printk in there, so that people have a chance to figure out what is going on if they happen to run such a driver on a platform that can't support it.

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

Quoted 5 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 4 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

Quoted 4 lines

Quoted 1 line

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that physically does not exist. This will always result in a failure.

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 8 lines · Richard Weinberger

Quoted 7 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

Quoted 6 lines

Quoted 2 lines

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that physically does not exist. This will always result in a failure.

Okay, you have convinced me. :)

Quoted 12 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <richard-/[email protected]>…

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 11 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

Quoted 6 lines

Quoted 3 lines

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that physically does not exist. This will always result in a failure.

Okay, you have convinced me. :)

OK, thank all of you, and I shall send the related patch for it.

I will try to finish it within this week.

Quoted 15 lines · Chen Gang

Quoted 12 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <[email protected]> 写道：

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 11 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that physically does not exist. This will always result in a failure.

Okay, you have convinced me. :)

After search the history patches, I found one related patch which made by myself (when I am in Asianux):

   "https://lkml.org/lkml/2013/7/1/641"

For me, it is a long discussion, and forced many members have to join in. Please help check again.

Quoted 27 lines · Chen Gang

Quoted 23 lines · Chen Gang

Quoted 20 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <[email protected]> 写道：

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 18 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any
different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that
physically does not exist. This will always result in a failure.

Quoted 2 lines

Quoted 2 lines

Okay, you have convinced me. :)

Quoted 8 lines

After search the history patches, I found one related patch which made by myself (when I am in Asianux):

   "https://lkml.org/lkml/2013/7/1/641"

For me, it is a long discussion, and forced many members have to join in. Please help check again.

One thing you could try would be to return NULL (or where appropriate an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT, ie dont take COMPILE_TEST into account at all. Obviously that means you won't be able to dump a warning message in the COMPILE_TEST case, but at least the code would compile. The rejection of above patch would make a good case for this approach.

Quoted 37 lines · Guenter Roeck

Quoted 27 lines · Chen Gang

Quoted 23 lines · Chen Gang

Quoted 20 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <[email protected]> 写道：

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 18 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any
different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that
physically does not exist. This will always result in a failure.

Quoted 2 lines

Quoted 2 lines

Okay, you have convinced me. :)

Quoted 8 lines

After search the history patches, I found one related patch which made by myself (when I am in Asianux):

   "https://lkml.org/lkml/2013/7/1/641"

For me, it is a long discussion, and forced many members have to join in. Please help check again.

Quoted 7 lines

One thing you could try would be to return NULL (or where appropriate an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT, ie dont take COMPILE_TEST into account at all. Obviously that means you won't be able to dump a warning message in the COMPILE_TEST case, but at least the code would compile. The rejection of above patch would make a good case for this approach.

OK, thanks: at least, it can be improved. But still welcome any other opinions of another related members.

Quoted 40 lines · Chen Gang

Quoted 37 lines · Guenter Roeck

Quoted 35 lines · Chen Gang

Quoted 23 lines · Chen Gang

Quoted 20 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <[email protected]> 写道：

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 18 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any
different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that
physically does not exist. This will always result in a failure.

Quoted 2 lines

Quoted 2 lines

Okay, you have convinced me. :)

After search the history patches, I found one related patch which made by myself (when I am in Asianux):

   "https://lkml.org/lkml/2013/7/1/641"

For me, it is a long discussion, and forced many members have to join in. Please help check again.

Quoted 7 lines

Quoted 7 lines

One thing you could try would be to return NULL (or where appropriate an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT, ie dont take COMPILE_TEST into account at all. Obviously that means you won't be able to dump a warning message in the COMPILE_TEST case, but at least the code would compile. The rejection of above patch would make a good case for this approach.

Quoted 4 lines

OK, thanks: at least, it can be improved. But still welcome any other opinions of another related members.

If no reply within 3 days (2014-07-18), I shall try to send related patch for it within this week end (2014-07-20).

Thanks.

Quoted 41 lines · Chen Gang

Quoted 40 lines · Chen Gang

Quoted 37 lines · Guenter Roeck

Quoted 35 lines · Chen Gang

Quoted 23 lines · Chen Gang

Quoted 20 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <[email protected]> 写道：

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 18 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any
different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that
physically does not exist. This will always result in a failure.

Quoted 2 lines

Quoted 2 lines

Okay, you have convinced me. :)

After search the history patches, I found one related patch which made by myself (when I am in Asianux):

    "https://lkml.org/lkml/2013/7/1/641"

For me, it is a long discussion, and forced many members have to join in. Please help check again.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

One thing you could try would be to return NULL (or where appropriate an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT, ie dont take COMPILE_TEST into account at all. Obviously that means you won't be able to dump a warning message in the COMPILE_TEST case, but at least the code would compile. The rejection of above patch would make a good case for this approach.

For me, only let 'devm_io*map*' support COMPILE_TEST is OK, that can fix all related issues:

[PATCH] lib: devres: Add dumy functions to support COMPILE_TEST when no IOMEM

For some architectures which no IOMEM, 'devres' will be skipped. But many drivers may still want COMPILE_TEST, so let 'devres' support it.

The related error (with allmodconfig under score):

MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined!

Signed-off-by Chen Gang <[email protected]>

---
  include/linux/device.h |  9 +++++++++
  include/linux/io.h     | 30 +++++++++++++++++++++++++++++-
  2 files changed, 38 insertions(+), 1 deletion(-)

include/linux/device.h +0 -0

index c2421e0..a7500c3 100644

include/linux/device.h +3 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
  /* allows to add/remove a custom action to devres stack */
  int devm_add_action(struct device *dev, void (*action)(void *), void *data);

include/linux/io.h +1 -0

index b76e6e5..59128aa 100644
@@ -58,14 +58,42 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
  }
  #endif
 
+#ifdef CONFIG_HAS_IOMEM

include/linux/io.h +13 -1

+	return NULL;
+}
+
+static inline void devm_iounmap(struct device *dev, void __iomem *addr)
+{
+}
+
+static inline void devm_ioremap_release(struct device *dev, void *res)
+{
+}
+
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
+
  int check_signature(const volatile void __iomem *io_addr,
  			const unsigned char *signature, int length);
-void devm_ioremap_release(struct device *dev, void *res);
 
  /*
   * Some systems do not have legacy ISA devices.

Quoted 97 lines · Chen Gang

Quoted 41 lines · Chen Gang

Quoted 40 lines · Chen Gang

Quoted 37 lines · Guenter Roeck

Quoted 35 lines · Chen Gang

Quoted 23 lines · Chen Gang

Quoted 20 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <[email protected]> 写道：

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 18 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any
different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that
physically does not exist. This will always result in a failure.

Quoted 2 lines

Quoted 2 lines

Okay, you have convinced me. :)

After search the history patches, I found one related patch which made by myself (when I am in Asianux):

   "https://lkml.org/lkml/2013/7/1/641"

For me, it is a long discussion, and forced many members have to join in. Please help check again.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

One thing you could try would be to return NULL (or where appropriate an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT, ie dont take COMPILE_TEST into account at all. Obviously that means you won't be able to dump a warning message in the COMPILE_TEST case, but at least the code would compile. The rejection of above patch would make a good case for this approach.

For me, only let 'devm_io*map*' support COMPILE_TEST is OK, that can fix all related issues:

[PATCH] lib: devres: Add dumy functions to support COMPILE_TEST when no IOMEM

For some architectures which no IOMEM, 'devres' will be skipped. But many drivers may still want COMPILE_TEST, so let 'devres' support it.

The related error (with allmodconfig under score):

MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined!

Signed-off-by Chen Gang <[email protected]>

---
 include/linux/device.h |  9 +++++++++
 include/linux/io.h     | 30 +++++++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 1 deletion(-)

include/linux/device.h +0 -0

index c2421e0..a7500c3 100644
@@ -630,7 +630,16 @@ extern unsigned long devm_get_free_pages(struct device *dev,
 					 gfp_t gfp_mask, unsigned int order);
 extern void devm_free_pages(struct device *dev, unsigned long addr);
 

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 635

Quoted 3 lines

include/linux/device.h +2 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+#elif defined(CONFIG_COMPILE_TEST)

I would make it #else

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 639

Quoted 4 lines

include/linux/device.h +4 -0

+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+						struct resource *res)
+{
+	pr_warn("no hardware io memory, only for COMPILE_TEST\n");

dev_warn

include/linux/device.h +0 -0

index c2421e0..a7500c3 100644

include/linux/device.h +2 -0

+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */
 int devm_add_action(struct device *dev, void (*action)(void *), void *data);

include/linux/io.h +2 -0

index b76e6e5..59128aa 100644
@@ -58,14 +58,42 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
 }
 #endif
 
+#ifdef CONFIG_HAS_IOMEM
+
 void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,

On Thu, Jul 17, 2014 at 09:27:58AM +0800, Chen Gang wrote:
[...]

Quoted 8 lines

include/linux/device.h +0 -0

index c2421e0..a7500c3 100644
@@ -630,7 +630,16 @@ extern unsigned long devm_get_free_pages(struct device *dev,
 					 gfp_t gfp_mask, unsigned int order);
 extern void devm_free_pages(struct device *dev, unsigned long addr);
 

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 639

Quoted 7 lines

include/linux/device.h +6 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+						struct resource *res)
+{
+	pr_warn("no hardware io memory, only for COMPILE_TEST\n");

Maybe: "Hardware doesn't support memory-mapped I/O"? I'm not sure if it's useful to include the reference to COMPILE_TEST, especially since the #elif will be dropped in favour of a simple #else.

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 640

Quoted 1 line

include/linux/device.h +1 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);

There's apparently an IOMEM_ERR_PTR() for this nowadays...

Quoted 16 lines

include/linux/device.h +2 -0

+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */
 int devm_add_action(struct device *dev, void (*action)(void *), void *data);

include/linux/io.h +2 -0

index b76e6e5..59128aa 100644
@@ -58,14 +58,42 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
 }
 #endif
 
+#ifdef CONFIG_HAS_IOMEM
+
 void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,

include/linux/io.h static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr) · line 73

Quoted 10 lines

include/linux/io.h +6 -0

 			    unsigned long size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
 				    unsigned long size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
+void devm_ioremap_release(struct device *dev, void *res);
+
+#elif defined(CONFIG_COMPILE_TEST)
+
+static inline void __iomem *devm_ioremap(struct device *dev,
+				resource_size_t offset, unsigned long size)

For consistency with other functions above, please keep arguments on subsequent lines aligned with the first argument on the first line, like so:

static inline void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset, unsigned long size)

include/linux/io.h static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr) · line 83

Quoted 10 lines

include/linux/io.h +10 -0

+{
+	pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+	return NULL;
+}
+static inline void __iomem *devm_ioremap_nocache(struct device *dev,
+				resource_size_t offset, unsigned long size)
+{
+	pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+	return NULL;
+}

Perhaps this should call devm_ioremap() so we don't have to repeat the same error message? Or maybe make it:

	#define devm_ioremap_nocache devm_ioremap

Quoted 4 lines

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 640

Quoted 1 line

include/linux/device.h +1 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);

There's apparently an IOMEM_ERR_PTR() for this nowadays...

IOMEM_ERR_PTR() is defined within "lib/devres.c", not in "./include". But may we move it from "lib/devres.c" to "./include/linux/err.h"?

For me, I am not quite sure, it may need additional discussion, but at least, that will be another patch.

Quoted 5 lines · Chen Gang

Quoted 4 lines

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 640

Quoted 1 line

include/linux/device.h +1 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);

There's apparently an IOMEM_ERR_PTR() for this nowadays...

Quoted 5 lines

IOMEM_ERR_PTR() is defined within "lib/devres.c", not in "./include". But may we move it from "lib/devres.c" to "./include/linux/err.h"?

For me, I am not quite sure, it may need additional discussion, but at least, that will be another patch.

Yes. Move it there. That is the right place.

Quoted 6 lines · Dan Carpenter

Quoted 5 lines · Chen Gang

Quoted 4 lines

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 640

Quoted 1 line

include/linux/device.h +1 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);

There's apparently an IOMEM_ERR_PTR() for this nowadays...

Quoted 8 lines

Quoted 5 lines

IOMEM_ERR_PTR() is defined within "lib/devres.c", not in "./include". But may we move it from "lib/devres.c" to "./include/linux/err.h"?

For me, I am not quite sure, it may need additional discussion, but at least, that will be another patch.

Yes. Move it there. That is the right place.

OK, thanks, if no another objections within 2 days, I shall send another related patch for it.

Quoted 9 lines · Chen Gang

Quoted 6 lines · Dan Carpenter

Quoted 5 lines · Chen Gang

Quoted 4 lines

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 640

Quoted 1 line

include/linux/device.h +1 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);

There's apparently an IOMEM_ERR_PTR() for this nowadays...

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

IOMEM_ERR_PTR() is defined within "lib/devres.c", not in "./include". But may we move it from "lib/devres.c" to "./include/linux/err.h"?

For me, I am not quite sure, it may need additional discussion, but at least, that will be another patch.

Yes. Move it there. That is the right place.

Sorry for replying late about IOMEM_ERR_PTR().

Although no objections within 2 days, for me, when move something to generic header file, it is not only for future using, but also for solving current issue, or it has to be suspended for waiting 'trigger'.

So for me, the patch about IOMEM_ERR_PTR() need be suspended, until some member find an issue which may be related with IOMEM_ERR_PTR(), more or less.

Quoted 27 lines · Chen Gang

Quoted 9 lines · Chen Gang

Quoted 6 lines · Dan Carpenter

Quoted 5 lines · Chen Gang

Quoted 4 lines

Review

Quoted 1 line

(quoted diff) +1 -0

+	return (__force void __iomem *)ERR_PTR(-ENXIO);

There's apparently an IOMEM_ERR_PTR() for this nowadays...

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

IOMEM_ERR_PTR() is defined within "lib/devres.c", not in "./include". But may we move it from "lib/devres.c" to "./include/linux/err.h"?

For me, I am not quite sure, it may need additional discussion, but at least, that will be another patch.

Yes. Move it there. That is the right place.

Sorry for replying late about IOMEM_ERR_PTR().

Although no objections within 2 days, for me, when move something to generic header file, it is not only for future using, but also for solving current issue, or it has to be suspended for waiting 'trigger'.

Quoted 3 lines

So for me, the patch about IOMEM_ERR_PTR() need be suspended, until some member find an issue which may be related with IOMEM_ERR_PTR(), more or less.

Matthias Brugger already moved it to include/linux/io.h on Friday.

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

Quoted 5 lines

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

Am 17.07.2014 11:20, schrieb Arnd Bergmann:

Quoted 27 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

Quoted 5 lines

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Quoted 5 lines

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

Huh? UML (v3.16-rc5-143-gb6603fe) builds fine here. What build issue are you facing?

Quoted 28 lines

Am 17.07.2014 11:20, schrieb Arnd Bergmann:

Quoted 27 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

Quoted 5 lines

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Quoted 7 lines

Quoted 5 lines

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

Huh? UML (v3.16-rc5-143-gb6603fe) builds fine here. What build issue are you facing?

This is what I got upon trying earlier. I have not attempted to look into why this is happening. Note this is on linux-next from yesterday, not mainline as I incorrectly stated above.

In file included from ../arch/um/include/asm/fixmap.h:58:0,

                 from ../arch/um/include/asm/pgtable.h:11,
                 from ../include/linux/mm.h:51,
                 from ../kernel/uid16.c:6:

../include/asm-generic/fixmap.h: In function 'fix_to_virt':
../include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);

Quoted 11 lines

This is what I got upon trying earlier. I have not attempted to look into why this is happening. Note this is on linux-next from yesterday, not mainline as I incorrectly stated above.

In file included from ../arch/um/include/asm/fixmap.h:58:0,

                 from ../arch/um/include/asm/pgtable.h:11,
                 from ../include/linux/mm.h:51,
                 from ../kernel/uid16.c:6:

../include/asm-generic/fixmap.h: In function 'fix_to_virt':
../include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);

So, this is next-20140716?
I don't see the fixmap issue you're reporting, also not on the most recent next.

Am 17.07.2014 12:28, schrieb Arnd Bergmann:

Quoted 41 lines · On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:

Quoted 28 lines

Am 17.07.2014 11:20, schrieb Arnd Bergmann:

Quoted 27 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

Quoted 5 lines

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Quoted 7 lines

Quoted 5 lines

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

Huh? UML (v3.16-rc5-143-gb6603fe) builds fine here. What build issue are you facing?

This is what I got upon trying earlier. I have not attempted to look into why this is happening. Note this is on linux-next from yesterday, not mainline as I incorrectly stated above.

Quoted 7 lines

In file included from ../arch/um/include/asm/fixmap.h:58:0,

                 from ../arch/um/include/asm/pgtable.h:11,
                 from ../include/linux/mm.h:51,
                 from ../kernel/uid16.c:6:

../include/asm-generic/fixmap.h: In function 'fix_to_virt':
../include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);

So, this is next-20140716?
I don't see the fixmap issue you're reporting, also not on the most recent next.

All I see is the known ext4 issue with CONFIG_SMP=n:

fs/ext4/super.c: In function ‘ext4_commit_super’:
fs/ext4/super.c:4547:41: error: ‘struct percpu_counter’ has no member named ‘counters’
if (EXT4_SB(sb)->s_freeclusters_counter.counters)

                                         ^

fs/ext4/super.c:4551:39: error: ‘struct percpu_counter’ has no member named ‘counters’
if (EXT4_SB(sb)->s_freeinodes_counter.counters)

Quoted 5 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

Quoted 20 lines · Arnd Bergmann

Quoted 5 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

                                         gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
 /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

Quoted 7 lines

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Architecture members and driver members really have different tastes, they are different roles. It really need additional discussion.

For me, I only want to change devm_io*map*, not touch so much.

Welcome any other members' idea or suggestions.

Quoted 6 lines

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

In latest gcc and binutils, can compile score cross compiler successfully for building kernel (but I am not quite sure whether the compiling result are really OK, but I guess so).

Quoted 8 lines

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Architecture members and driver members really have different tastes, they are different roles. It really need additional discussion.

For me, I only want to change devm_io*map*, not touch so much.

Welcome any other members' idea or suggestions.

Quoted 6 lines

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

In latest gcc and binutils, can compile score cross compiler successfully for building kernel (but I am not quite sure whether the compiling result are really OK, but I guess so).

And next (maybe after finish allmodconfig for microblaze), I shall try to let uml pass allmodconfig for linux-next tree.

Quoted 9 lines · On Thursday 17 July 2014 17:29:31 Chen Gang wrote:

Quoted 8 lines

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Quoted 4 lines

Architecture members and driver members really have different tastes, they are different roles. It really need additional discussion.

For me, I only want to change devm_io*map*, not touch so much.

But what do you gain from that? All drivers that need these functions should already 'depends on HAS_IOMEM' and if they don't, we should fix /that/ instead. I don't see this dependency as any different from a lot of others (PCI, DMAENGINE, HAVE_CLK, ...) that we use to intentionally annotate drivers that need a particular feature to be present for compilation. Do you want to do the same hack to those?

Quoted 9 lines

Welcome any other members' idea or suggestions.

Quoted 6 lines

Note that s390 no has gained support for IOMEM, tile has it most of the time (when PCI is enabled, so you get it in half the test builds already), score should set HAS_IOMEM and doesn't even have public compilers, and uml doesn't even compile in latest mainline. Nothing else ever sets NO_IOMEM.

Quoted 3 lines

In latest gcc and binutils, can compile score cross compiler successfully for building kernel (but I am not quite sure whether the compiling result are really OK, but I guess so).

Ok. Would you mind sending a patch that enables HAS_IOMEM on score?

Quoted 2 lines

And next (maybe after finish allmodconfig for microblaze), I shall try to let uml pass allmodconfig for linux-next tree.

That is a fair goal, but it seems better to do that by ensuring we don't build any code that tries to call the MMIO functions rather than trying to make them build.

score should set HAS_IOMEM and doesn't
even have public compilers

On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
[...]

Quoted 2 lines

score should set HAS_IOMEM and doesn't
even have public compilers

This begs an interesting question. Should it be made a requirement to have publicly available compilers for new architectures so that they can at least be compile-tested? Preferably this would of course be in source form so that there aren't any dependencies on the distribution.

Quoted 9 lines · On Thursday 17 July 2014 11:56:58 Thierry Reding wrote:

On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
[...]

Quoted 2 lines

score should set HAS_IOMEM and doesn't
even have public compilers

This begs an interesting question. Should it be made a requirement to have publicly available compilers for new architectures so that they can at least be compile-tested? Preferably this would of course be in source form so that there aren't any dependencies on the distribution.

The question has come up a few times. I wouldn't mandate that the port has an upstream gcc (you've got to start mainlining one of them first after all), but having compilers available for download should probably be required. It's hard to ask for a particular quality of that gcc port though, or to expect it to stay available online.

Where did you find the gcc port for score?

Quoted 17 lines · Arnd Bergmann

Quoted 9 lines · On Thursday 17 July 2014 11:56:58 Thierry Reding wrote:

On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
[...]

Quoted 2 lines

score should set HAS_IOMEM and doesn't
even have public compilers

This begs an interesting question. Should it be made a requirement to have publicly available compilers for new architectures so that they can at least be compile-tested? Preferably this would of course be in source form so that there aren't any dependencies on the distribution.

The question has come up a few times. I wouldn't mandate that the port has an upstream gcc (you've got to start mainlining one of them first after all), but having compilers available for download should probably be required. It's hard to ask for a particular quality of that gcc port though, or to expect it to stay available online.

Quoted 1 line

Where did you find the gcc port for score?

It's upstream, though marked obsolete and to be removed in the next release... =)

Quoted 5 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

                                          gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
  void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
  /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Quoted 20 lines · Arnd Bergmann

Quoted 5 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

                                          gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
  void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
  /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

Quoted 6 lines

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

The point of this exercise is that we do not have to replace a good chunk of 'depends on COMPILE_TEST' with 'depends on COMPILE_TEST && HAS_IOMEM'

E.g. the typical Kconfig entry for your random SoC peripheral driver looks like

config ARCH_FOOBAR_DRIVER

        depends on ARCH_FOOBAR || COMPILE_TEST
        ...

Now when COMPILE_TEST is not set there is a implicit dependency on HAS_IOMEM since the architecture will provide it. If COMPILE_TEST is selected the driver will also be build-able on architectures that do no have HAS_IOMEM and hence linking the driver fails. One way to fix this is of course to replace the COMPILE_TEST with (COMPILE_TEST && HAS_IOMEM). But this is very often overlooked and only noticed later on when somebody actually builds a allyesconfig on an architecture that does not provide HAS_IOMEM. To avoid these kinds of build errors and tedious fixup patches the idea is to provide a stub function when HAS_IOMEM is not enabled, but COMPILE_TEST is enabled.

Quoted 28 lines · On Thursday 17 July 2014 12:40:25 Lars-Peter Clausen wrote:

Quoted 20 lines · Arnd Bergmann

Quoted 5 lines · On Thursday 17 July 2014 09:27:58 Chen Gang wrote:

                                          gfp_t gfp_mask, unsigned int order);

extern void devm_free_pages(struct device *dev, unsigned long addr);

include/linux/device.h +1 -0

+#ifdef CONFIG_HAS_IOMEM
  void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

include/linux/device.h extern unsigned long devm_get_free_pages(struct device *dev, · line 644

Quoted 10 lines

include/linux/device.h +8 -0

+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+                                               struct resource *res)
+{
+       pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+       return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
 
  /* allows to add/remove a custom action to devres stack */

To be honest, I think it's a bad idea to introduce wrappers functions that are only available when CONFIG_COMPILE_TEST is set.

Quoted 6 lines

COMPILE_TEST is a great tool in general, but it has its limits. In particular, the case for !CONFIG_IOMEM is completely obscure and we won't find any bugs by allowing more drivers to be built in those configurations, but attempting to do it would cause endless churn by changing each instance of 'depends on HAS_IOMEM' to 'depends on HAS_IOMEM || COMPILE_TEST'.

Quoted 2 lines

The point of this exercise is that we do not have to replace a good chunk of 'depends on COMPILE_TEST' with 'depends on COMPILE_TEST && HAS_IOMEM'

Ok, I see.

Quoted 6 lines

E.g. the typical Kconfig entry for your random SoC peripheral driver looks like

config ARCH_FOOBAR_DRIVER

        depends on ARCH_FOOBAR || COMPILE_TEST
        ...

Quoted 9 lines

Now when COMPILE_TEST is not set there is a implicit dependency on HAS_IOMEM since the architecture will provide it. If COMPILE_TEST is selected the driver will also be build-able on architectures that do no have HAS_IOMEM and hence linking the driver fails. One way to fix this is of course to replace the COMPILE_TEST with (COMPILE_TEST && HAS_IOMEM). But this is very often overlooked and only noticed later on when somebody actually builds a allyesconfig on an architecture that does not provide HAS_IOMEM. To avoid these kinds of build errors and tedious fixup patches the idea is to provide a stub function when HAS_IOMEM is not enabled, but COMPILE_TEST is enabled.

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

Quoted 5 lines · Arnd Bergmann

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

According to current source code, tile still has chance to choose NO_IOMEM, for me, welcome the tile's maintainer's ideas or suggestions.

Quoted 8 lines · Chen Gang

Quoted 5 lines · Arnd Bergmann

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

According to current source code, tile still has chance to choose NO_IOMEM, for me, welcome the tile's maintainer's ideas or suggestions.

I'm not really sure. It's true that on tile, if you don't enable PCI support there's no other I/O memory (or I/O port) space you can use. We pretty much always enable PCI support in our kernel, though. I'm kind of surprised that other architectures don't also have the model that IOMEM requires PCI, but perhaps most architectures just don't encode that in the Kconfig file?

My observation is just that if I remove the "NO_IOMEM if !PCI" from arch/tile/Kconfig, my build fails with ioremap() undefined. No doubt I could work around that, but my assumption was that NO_IOMEM was exactly the right thing to express the fact that without PCI there is no I/O memory

Quoted 10 lines · On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:

Quoted 8 lines · Chen Gang

Quoted 5 lines · Arnd Bergmann

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

According to current source code, tile still has chance to choose NO_IOMEM, for me, welcome the tile's maintainer's ideas or suggestions.

Quoted 6 lines

I'm not really sure. It's true that on tile, if you don't enable PCI support there's no other I/O memory (or I/O port) space you can use. We pretty much always enable PCI support in our kernel, though. I'm kind of surprised that other architectures don't also have the model that IOMEM requires PCI, but perhaps most architectures just don't encode that in the Kconfig file?

Only s390 as far as I know. Most architectures have integrated peripherals that use MMIO without PCI.

Quoted 4 lines

My observation is just that if I remove the "NO_IOMEM if !PCI" from arch/tile/Kconfig, my build fails with ioremap() undefined. No doubt I could work around that, but my assumption was that NO_IOMEM was exactly the right thing to express the fact that without PCI there is no I/O memory

Your assumption is correct.

For tile by itself it would certainly be best to leave this dependency, it makes no sense to enable IOMEM without PCI.

That doesn't solve the problem of COMPILE_TEST enabling drivers that require IOMEM though. An easy hack for that would be to make COMPILE_TEST depend on HAS_IOMEM, but it gets into hacky territory there, and it's not clear if this is any better than the original patch to provide fallbacks for ioremap and friends. Definitely simpler though.

Quoted 3 lines · On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:

Quoted 2 lines · Chen Gang

According to current source code, tile still has chance to choose NO_IOMEM, for me, welcome the tile's maintainer's ideas or suggestions.

Quoted 6 lines

I'm not really sure. It's true that on tile, if you don't enable PCI support there's no other I/O memory (or I/O port) space you can use. We pretty much always enable PCI support in our kernel, though. I'm kind of surprised that other architectures don't also have the model that IOMEM requires PCI, but perhaps most architectures just don't encode that in the Kconfig file?

Only s390 as far as I know. Most architectures have integrated peripherals that use MMIO without PCI.

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 6 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

Quoted 3 lines

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

Thanks,
//richard

Score can provide dummy functions if HAS_IOMEM and NO_IOMEM will be removed, even if we indeed have no IOMEM.

2014-07-18 18:51 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 40 lines

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

Quoted 41 lines

2014-07-18 18:51 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 40 lines

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

That will let UML itself against COMPILE_TEST (but all the other architectures not).

And if let COMPILE_TEST depend on !UML, can we still remove all HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

If we can remove them, we can send related patch firstly -- that will let current discussion be in UML architecture wide instead of kernel wide.

Quoted 48 lines

Quoted 41 lines

2014-07-18 18:51 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 40 lines

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

That will let UML itself against COMPILE_TEST (but all the other architectures not).

And if let COMPILE_TEST depend on !UML, can we still remove all HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

Quoted 4 lines

If we can remove them, we can send related patch firstly -- that will let current discussion be in UML architecture wide instead of kernel wide.

Next, I shall:

- Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

- Try to make dummy IOMEM functions for score architecture.

- Continue discussing with UML for it.

Am 20.07.2014 10:38, schrieb Chen Gang:

Quoted 54 lines · Chen Gang

Quoted 52 lines

Quoted 41 lines

2014-07-18 18:51 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 40 lines

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

That will let UML itself against COMPILE_TEST (but all the other architectures not).

And if let COMPILE_TEST depend on !UML, can we still remove all HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

If we can remove them, we can send related patch firstly -- that will let current discussion be in UML architecture wide instead of kernel wide.

Quoted 3 lines

Next, I shall:

- Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

This needs to be last, otherwise lot's of stuff will break.

Quoted 3 lines

- Try to make dummy IOMEM functions for score architecture.

- Continue discussing with UML for it.

If you find sane dummy functions for both UML and score I'm fine with it.

Quoted 57 lines · Richard Weinberger

Am 20.07.2014 10:38, schrieb Chen Gang:

Quoted 54 lines · Chen Gang

Quoted 52 lines

Quoted 41 lines

2014-07-18 18:51 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 40 lines

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

That will let UML itself against COMPILE_TEST (but all the other architectures not).

And if let COMPILE_TEST depend on !UML, can we still remove all HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

If we can remove them, we can send related patch firstly -- that will let current discussion be in UML architecture wide instead of kernel wide.

Quoted 6 lines

Quoted 3 lines

Next, I shall:

- Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

This needs to be last, otherwise lot's of stuff will break.

OK, thanks, that sounds reasonable to me.

Quoted 6 lines

Quoted 3 lines

- Try to make dummy IOMEM functions for score architecture.

- Continue discussing with UML for it.

If you find sane dummy functions for both UML and score I'm fine with it.

For me, what you said is necessary, tile and s390 also need dummy IOMEM when !PCI.

So for me, I shall implement them in "include/asm-generic", and let uml, score, tile and s390 use dummy IOMEM when they need.

Welcome any other members ideas, suggestions and completions.

Quoted 45 lines · Chen Gang

Quoted 41 lines

2014-07-18 18:51 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 40 lines

Am 18.07.2014 12:44, schrieb Chen Gang:

Quoted 26 lines · Richard Weinberger

Quoted 13 lines

Am 18.07.2014 02:36, schrieb Chen Gang:

Quoted 12 lines · Richard Weinberger

Quoted 9 lines

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

Quoted 4 lines

AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff to build on UML seems pointless to me and we special-case it in a number of places already.

If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-)

Quoted 7 lines

Quoted 3 lines

For me, if only uml left, I suggest to implement dummy functions within uml instead of let CONFIG_UML appear in generic include directory. And then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

COMPILE_TEST is none-architecture specific, but UML is. So in generic include folder, if we're focusing on choosing whether COMPILE_TEST or UML, for me, I will choose COMPILE_TEST.

Quoted 5 lines

If we're not only focusing on COMPILE_TEST, for me, if something only depend on one architecture, I'd like to put them under "arch/*/" folder.

Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody has to think of them again. :-)

And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap...

I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

That will let UML itself against COMPILE_TEST (but all the other architectures not).

Quoted 7 lines

And if let COMPILE_TEST depend on !UML, can we still remove all HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

If we can remove them, we can send related patch firstly -- that will let current discussion be in UML architecture wide instead of kernel wide.

Next, I shall:

- Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

- Try to make dummy IOMEM functions for score architecture.

- Continue discussing with UML for it.

By the way: how about HAS_DMA? can we treat it as HAS_IOMEM (remove it from kernel)? (for me, I guess we can not).

At present, I shall finish sending patch for removing IOMEM today, and continue to welcome any ideas, suggestions or completions for IOMEM or DMA.

Quoted 7 lines

Next, I shall:

- Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

- Try to make dummy IOMEM functions for score architecture.

Quoted 2 lines

- Continue discussing with UML for it.

Oh, sorry, I forgot, after remove IOMEM from kernel, also s390 and tile need implement dummy IOMEM if !PCI.

If possible, I shall try to implement the dummy IOMEM in 'asm-generic', and let uml, score, s390 and tile use them when they need.

Quoted 7 lines · On Sunday 20 July 2014 17:45:40 Chen Gang wrote:

Quoted 7 lines

Next, I shall:

- Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

- Try to make dummy IOMEM functions for score architecture.

Quoted 8 lines

Quoted 2 lines

- Continue discussing with UML for it.

Oh, sorry, I forgot, after remove IOMEM from kernel, also s390 and tile need implement dummy IOMEM if !PCI.

If possible, I shall try to implement the dummy IOMEM in 'asm-generic', and let uml, score, s390 and tile use them when they need.

Sorry for going round in circles, but looking back at the original patches, adding the extra 'depends on HAS_IOMEM' does seem much better than the other suggestions that came afterwards.

In particular, removing HAS_IOMEM and NO_IOMEM sounds like an awful idea to me. I'd rather add a HAS_IOPORT in addition to also catch architectures that have no support for PC-style PIO.

Quoted 12 lines · 在 2014年7月14日，下午4:57，Richard Weinberger <richard-/[email protected]>…

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:

Quoted 11 lines · Richard Weinberger

Quoted 9 lines

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:

Quoted 5 lines · Richard Weinberger

Quoted 2 lines

Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports...

What kind of bug report are you going to get?

User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :)

Quoted 6 lines

Quoted 3 lines

These drivers are typically drivers for some SoC peripheral and the device will simply physically not exist on a platform that does not provide HAS_IOMEM. This is not really any different from making the driver selectable via COMPILE_TEST for any other platform. To hit the issue you'd have to instantiate a device driver instance for a device that physically does not exist. This will always result in a failure.

Okay, you have convinced me. :)

OK, thank all of you, and I shall send the related patch for it.

I will try to finish it within this week.

Quoted 26 lines · Lars-Peter Clausen

Quoted 17 lines · Richard Weinberger

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:

Quoted 16 lines · Richard Weinberger

Quoted 14 lines

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:

Quoted 10 lines · Richard Weinberger

Quoted 5 lines

Am 13.07.2014 11:27, schrieb Lennox Wu:

Quoted 1 line

As I said before, some configurations don't make sense.

If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem.

Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled to avoid these linker errors. That's in my opinion better than turning most of the 'depends on COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up quite a lot and it is often overlooked when adding a driver that can be build when COMPILE_TEST is enabled.

And what should this stub do?
Except calling BUG()...

Quoted 7 lines

Quoted 3 lines

return NULL;

It's for compile testing, it's not meant to work at runtime.

Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think?

Quoted 10 lines

The kernel will still be working fine and you can run it on a system. The drivers which use ioremap() or similar are probably not instantiated on a system that does not provide HAS_IOMEM. But even if it was the driver should handle ioremap() returning NULL gracefully and abort the driver probe. That said you'll probably not run a kernel that was built with COMPILE_TEST on your real hardware since it contains so many drivers that are completely useless on your hardware. The idea of COMPILE_TEST is to have as much compile test exposure as possible to the code that is enabled by COMPILE_TEST. Stubbing out ioremap() and friends when HAS_IOMEM is not set and COMPILE_TEST is set makes it easier to get there.

I run my kernels with COMPILE_TEST enabled as I need to build test things that I don't happen to use.

I like the 'return NULL' option for this, it hits us all the time, might as well fix it properly like this so that we don't have to deal with Kconfig changes everywhere.

Also put a big "This platform does not support IOMEM" error printk in there, so that people have a chance to figure out what is going on if they happen to run such a driver on a platform that can't support it.