[PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

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 <gang.chen.5i5j@gmail.com>
---
 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(-)

diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index bc2d474..449d45f 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -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.
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4ad7b89..2faf5ce 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -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.
 
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index b87e382..4e927d2 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -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
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..0e4abb2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -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
-- 
1.7.11.7

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

After this last patch, score architecture can pass allmodconfig. :-)

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

Thanks.

On 07/13/2014 11:07 AM, Chen Gang wrote:
> 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 <gang.chen.5i5j@gmail.com>
> ---
>  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(-)
> 
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index bc2d474..449d45f 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -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.
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 4ad7b89..2faf5ce 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -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.
>  
> diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
> index b87e382..4e927d2 100644
> --- a/drivers/staging/iio/adc/Kconfig
> +++ b/drivers/staging/iio/adc/Kconfig
> @@ -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
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 76dd541..0e4abb2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -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
> 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Marek Vasut]

On Sunday, July 13, 2014 at 05:07:10 AM, Chen Gang wrote:
> 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!

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lennox Wu]

As I said before, some configurations don't make sense.
I don't think all of the patches are necessary.

Best,
Lennox

2014-07-13 11:45 GMT+08:00 Marek Vasut <marex@denx.de>:
> On Sunday, July 13, 2014 at 05:07:10 AM, Chen Gang wrote:
>> 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!
>
> 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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 13.07.2014 11:27, schrieb Lennox Wu:
> 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.

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/13/2014 05:45 PM, Richard Weinberger wrote:
> Am 13.07.2014 11:27, schrieb Lennox Wu:
>> 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.
>

OK, thanks. And I shall split them into several patches, although we can
understand that score may not need them.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lars-Peter Clausen]

On 07/13/2014 11:45 AM, Richard Weinberger wrote:
> Am 13.07.2014 11:27, schrieb Lennox Wu:
>> 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.

- Lars

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
>> Am 13.07.2014 11:27, schrieb Lennox Wu:
>>> 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()...

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lars-Peter Clausen]

On 07/13/2014 03:40 PM, Richard Weinberger wrote:
> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
>> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
>>> Am 13.07.2014 11:27, schrieb Lennox Wu:
>>>> 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()...

return NULL;

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

- Lars

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
> On 07/13/2014 03:40 PM, Richard Weinberger wrote:
>> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
>>> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
>>>> Am 13.07.2014 11:27, schrieb Lennox Wu:
>>>>> 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()...
> 
> 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?

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lars-Peter Clausen]

On 07/13/2014 04:03 PM, Richard Weinberger wrote:
> Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
>> On 07/13/2014 03:40 PM, Richard Weinberger wrote:
>>> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
>>>> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
>>>>> Am 13.07.2014 11:27, schrieb Lennox Wu:
>>>>>> 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()...
>>
>> 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.

- Lars

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/13/2014 11:14 AM, Chen Gang wrote:
[...]
> 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
> 

Oh, sorry, after check related details, this is still a kernel issue,
'die' is a macro which defined by most of architectures, so can not
use this common name as a declaration in any other area.

I shall send related patch for it.

Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/13/2014 10:25 PM, Lars-Peter Clausen wrote:
> On 07/13/2014 04:03 PM, Richard Weinberger wrote:
>> Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
>>> On 07/13/2014 03:40 PM, Richard Weinberger wrote:
>>>> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
>>>>> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
>>>>>> Am 13.07.2014 11:27, schrieb Lennox Wu:
>>>>>>> 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()...
>>>
>>> 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.
> 

For me, welcome Greg's idea or suggestion for it.

And also if the reply contents are wrapped (e.g. within 80 or less), that
will generate a better display under other members' email clients.


Thanks
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Greg Kroah-Hartman]

On Sun, Jul 13, 2014 at 04:25:06PM +0200, Lars-Peter Clausen wrote:
> On 07/13/2014 04:03 PM, Richard Weinberger wrote:
> >Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
> >>On 07/13/2014 03:40 PM, Richard Weinberger wrote:
> >>>Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
> >>>>On 07/13/2014 11:45 AM, Richard Weinberger wrote:
> >>>>>Am 13.07.2014 11:27, schrieb Lennox Wu:
> >>>>>>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()...
> >>
> >>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.

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.

thanks,

greg k-h

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 13.07.2014 21:22, schrieb Greg Kroah-Hartman:
> On Sun, Jul 13, 2014 at 04:25:06PM +0200, Lars-Peter Clausen wrote:
>> On 07/13/2014 04:03 PM, Richard Weinberger wrote:
>>> Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
>>>> On 07/13/2014 03:40 PM, Richard Weinberger wrote:
>>>>> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
>>>>>> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
>>>>>>> Am 13.07.2014 11:27, schrieb Lennox Wu:
>>>>>>>> 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()...
>>>>
>>>> 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.
> 
> 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.

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

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Greg Kroah-Hartman]

On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
> Am 13.07.2014 21:22, schrieb Greg Kroah-Hartman:
> > On Sun, Jul 13, 2014 at 04:25:06PM +0200, Lars-Peter Clausen wrote:
> >> On 07/13/2014 04:03 PM, Richard Weinberger wrote:
> >>> Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
> >>>> On 07/13/2014 03:40 PM, Richard Weinberger wrote:
> >>>>> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
> >>>>>> On 07/13/2014 11:45 AM, Richard Weinberger wrote:
> >>>>>>> Am 13.07.2014 11:27, schrieb Lennox Wu:
> >>>>>>>> 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()...
> >>>>
> >>>> 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.
> > 
> > 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.
> 
> 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?

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Thierry Reding]

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

On Sun, Jul 13, 2014 at 12:22:02PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Jul 13, 2014 at 04:25:06PM +0200, Lars-Peter Clausen wrote:
> > On 07/13/2014 04:03 PM, Richard Weinberger wrote:
> > >Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
> > >>On 07/13/2014 03:40 PM, Richard Weinberger wrote:
> > >>>Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
> > >>>>On 07/13/2014 11:45 AM, Richard Weinberger wrote:
> > >>>>>Am 13.07.2014 11:27, schrieb Lennox Wu:
> > >>>>>>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()...
> > >>
> > >>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.
> 
> 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.

I agree. One nit, though: devm_ioremap_resource() returns an ERR_PTR()-
encoded error code, so the dummy should probably be returning something
like ERR_PTR(-ENOSYS) instead of NULL.

> 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.

Yes, that sounds like a very good idea and should be indication enough
of what exactly has gone wrong.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>> 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. :)

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lars-Peter Clausen]

On 07/14/2014 10:31 AM, Richard Weinberger wrote:
> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>> 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.

- Lars

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>> 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.

Okay, you have convinced me. :)

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：

> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>> 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.
> 
> 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.

Thanks.
—
Chen Gang
Open, share, and attitude like air, water, and life which God blessed.

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/14/2014 05:22 PM, Chen Gang wrote:
> 
> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
> 
>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>> 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.
>>
>> 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.

Thanks.

> 
> OK, thank all of you, and I shall send the related patch for it. 
> 
> I will try to finish it within this week.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/14/2014 05:22 PM, Chen Gang wrote:
> 
> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
> 
>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>> 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.
>>
>> 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.

Thanks.

> 
> OK, thank all of you, and I shall send the related patch for it. 
> 
> I will try to finish it within this week.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Guenter Roeck]

On 07/14/2014 05:34 PM, Chen Gang wrote:
> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>
>> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
>>
>>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>>> 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.
>>>
>>> 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.
>

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.

Guenter

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/15/2014 08:53 AM, Guenter Roeck wrote:
> On 07/14/2014 05:34 PM, Chen Gang wrote:
>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>
>>> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
>>>
>>>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>>>> 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.
>>>>
>>>> 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.
>>
> 
> 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.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/15/2014 09:11 AM, Chen Gang wrote:
> 
> 
> On 07/15/2014 08:53 AM, Guenter Roeck wrote:
>> On 07/14/2014 05:34 PM, Chen Gang wrote:
>>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>>
>>>> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
>>>>
>>>>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>>>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>
>> 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.
> 

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.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/15/2014 10:38 PM, Chen Gang wrote:
> On 07/15/2014 09:11 AM, Chen Gang wrote:
>>
>>
>> On 07/15/2014 08:53 AM, Guenter Roeck wrote:
>>> On 07/14/2014 05:34 PM, Chen Gang wrote:
>>>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>>>
>>>>> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
>>>>>
>>>>>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>>>>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>>>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> 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 <gang.chen.5i5j@gmail.com>
---
 include/linux/device.h |  9 +++++++++
 include/linux/io.h     | 30 +++++++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index c2421e0..a7500c3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -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);
 
+#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");
+	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);
diff --git a/include/linux/io.h b/include/linux/io.h
index b76e6e5..59128aa 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -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,
 			    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)
+{
+	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;
+}
+
+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.
-- 
1.9.2.459.g68773ac

>>
>> 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.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Guenter Roeck]

On 07/16/2014 06:27 PM, Chen Gang wrote:
>
>
> On 07/15/2014 10:38 PM, Chen Gang wrote:
>> On 07/15/2014 09:11 AM, Chen Gang wrote:
>>>
>>>
>>> On 07/15/2014 08:53 AM, Guenter Roeck wrote:
>>>> On 07/14/2014 05:34 PM, Chen Gang wrote:
>>>>> On 07/14/2014 05:22 PM, Chen Gang wrote:
>>>>>>
>>>>>> 在 2014年7月14日，下午4:57，Richard Weinberger <richard@nod.at> 写道：
>>>>>>
>>>>>>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>>>>>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
>>>>>>>>> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
>>>>>>>>>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>>>>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>
>>>> 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 <gang.chen.5i5j@gmail.com>
> ---
>   include/linux/device.h |  9 +++++++++
>   include/linux/io.h     | 30 +++++++++++++++++++++++++++++-
>   2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c2421e0..a7500c3 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -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);
>
> +#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

> +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

> +	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);
> diff --git a/include/linux/io.h b/include/linux/io.h
> index b76e6e5..59128aa 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -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,
>   			    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)
> +

Same as above - I would suggest to use #else.

> +static inline void __iomem *devm_ioremap(struct device *dev,
> +				resource_size_t offset, unsigned long size)
> +{
> +	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");

dev_warn

Guenter

> +	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.
>

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Thierry Reding]

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

On Thu, Jul 17, 2014 at 09:27:58AM +0800, Chen Gang wrote:
[...]
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c2421e0..a7500c3 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -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);
>  
> +#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.

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

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

> +}
> +#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);
> diff --git a/include/linux/io.h b/include/linux/io.h
> index b76e6e5..59128aa 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -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,
>  			    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)

> +{
> +	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

?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 04:37 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 09:27:58AM +0800, Chen Gang wrote:
> [...]
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index c2421e0..a7500c3 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -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);
>>  
>> +#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.
> 

OK, thanks. I will use the comments which you provide.

And also use #else instead of #elif, use 'dev_warn' instead of 'pr_warn'
which Guenter suggests.

>> +	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.

>> +}
>> +#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);
>> diff --git a/include/linux/io.h b/include/linux/io.h
>> index b76e6e5..59128aa 100644
>> --- a/include/linux/io.h
>> +++ b/include/linux/io.h
>> @@ -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,
>>  			    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)
> 

That sounds fine to me, thanks.

>> +{
>> +	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
> 

That sounds fine to me, thanks.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Dan Carpenter]

On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
> >> +	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.

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

regards,
dan carpenter

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 05:16 PM, Dan Carpenter wrote:
> On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
>>>> +	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.
> 
> 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.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

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);
>  
> +#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");
> +       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.

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 17.07.2014 11:20, schrieb Arnd Bergmann:
> 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);
>>  
>> +#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");
>> +       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.

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

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 05:20 PM, Arnd Bergmann wrote:
> 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);
>>  
>> +#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");
>> +       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'.
>

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.

> 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.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Thierry Reding]

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

On Thu, Jul 17, 2014 at 05:29:31PM +0800, Chen Gang wrote:
> 
> 
> On 07/17/2014 05:20 PM, Arnd Bergmann wrote:
> > 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);
> >>  
> >> +#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");
> >> +       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'.
> >
> 
> 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.
> 
> > 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).

I was only able to ever build a partial bare-metal toolchain for score.
There's no uClibc, glibc or newlib support, so it becomes rather useless
as a Linux architecture.

Also when I run the cross-compiler on a score defconfig build, I get a
bunch of these:

	score-unknown-elf-gcc-4.9.0: internal compiler error: Segmentation fault (program as)

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Thierry Reding]

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

On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
[...]
>                       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.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:
> Am 17.07.2014 11:20, schrieb Arnd Bergmann:
> > 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);
> >>  
> >> +#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");
> >> +       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.
> 
> 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);


	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 11:56:58 Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
> [...]
> >                       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?

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 17:29:31 Chen Gang wrote:
> > 
> > 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.

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?

> Welcome any other members' idea or suggestions.

> > 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).

Ok. Would you mind sending a patch that enables HAS_IOMEM on
score?
 
> 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.

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lars-Peter Clausen]

On 07/17/2014 11:20 AM, Arnd Bergmann wrote:
> 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);
>>
>> +#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");
>> +       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'.

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.

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 12:40:25 Lars-Peter Clausen wrote:
> On 07/17/2014 11:20 AM, Arnd Bergmann wrote:
> > 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);
> >>
> >> +#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");
> >> +       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'.
> 
> 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.

> 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.

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.

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Thierry Reding]

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

On Thu, Jul 17, 2014 at 12:33:32PM +0200, Arnd Bergmann wrote:
> On Thursday 17 July 2014 11:56:58 Thierry Reding wrote:
> > On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
> > [...]
> > >                       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?

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

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 17.07.2014 12:28, schrieb Arnd Bergmann:
> On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:
>> Am 17.07.2014 11:20, schrieb Arnd Bergmann:
>>> 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);
>>>>  
>>>> +#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");
>>>> +       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.
>>
>> 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);

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)

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 06:55 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 12:33:32PM +0200, Arnd Bergmann wrote:
>> On Thursday 17 July 2014 11:56:58 Thierry Reding wrote:
>>> On Thu, Jul 17, 2014 at 11:20:36AM +0200, Arnd Bergmann wrote:
>>> [...]
>>>>                       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?
> 
> It's upstream, though marked obsolete and to be removed in the next
> release... =)
> 

For me, I get the latest gcc version and binutils source code, and fix 2
bugs (one for gas, which always generate core dump, the other for gcc
c-decl, fix it together with the other gcc members).

And I only finish compiling raw cross-compiler (--without-headers),
after make some patches, can let score pass allmodconfig.

At present, it seems the score cross-compiler still contents some issue
which I shall try to analyse (it is about link symbols), and maybe need
communicate with gcc/binutils members.


At present, the related score maintainers are still active in upstream
kernel, so we also need the related maintainers' ideas and suggestions.


Thanks
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 12:58:55 Richard Weinberger wrote:
> > 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.

Sorry, nevermind. I had a workaround for a gcc-4.9 bug applied that
turned off optimization for uid16.c, which fixed the build for ARM for
me but happened to break x86 including uml.

Without that patch, I don't see this problem.

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 12:40:25 Lars-Peter Clausen wrote:
>> On 07/17/2014 11:20 AM, Arnd Bergmann wrote:
>>> 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);
>>>>
>>>> +#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");
>>>> +       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'.
>>
>> 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.
> 
>> 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.
> 
> 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.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 06:58 PM, Richard Weinberger wrote:
> Am 17.07.2014 12:28, schrieb Arnd Bergmann:
>> On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:
>>> Am 17.07.2014 11:20, schrieb Arnd Bergmann:
>>>> 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);
>>>>>  
>>>>> +#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");
>>>>> +       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.
>>>
>>> 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);
> 
> 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)
> 

Yeah, and I have notified to ext4 related maintainer, yesterday, and he
has already send fix patch for it, I guess it will be integrated into
main line soon.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 06:38 PM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 17:29:31 Chen Gang wrote:
>>>
>>> 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.
> 
> 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?
> 
>> Welcome any other members' idea or suggestions.
> 
>>> 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.
>>>
>>

I guess, we are just discussing about them in another threads, so I skip
them. If it is still necessary to reply (e.g. I misunderstand), please
let me know, thanks.

>> 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?
>  

For me, welcome the score related maintainers' idea and suggestions.

>> 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.
> 

When I am performing uml, I will try and also communicate with the
related maintainers for it (their suggestions and ideas are valuable).

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 17.07.2014 12:48, schrieb 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.

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

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chris Metcalf]

On 7/17/2014 7:28 AM, Chen Gang wrote:
> On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
>> 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 :-)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:
> On 7/17/2014 7:28 AM, Chen Gang wrote:
> > On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
> >> 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?

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

> 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.

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/18/2014 05:05 AM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:
>> On 7/17/2014 7:28 AM, Chen Gang wrote:
>>> On 07/17/2014 06:48 PM, Arnd Bergmann wrote:
>>>> 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?
> 
> Only s390 as far as I know. Most architectures have integrated
> peripherals that use MMIO without PCI.
> 
>> 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.
> 

OK, thank all of you, tile just likes most of architectures to support
IOMEM, and at present, we can focus score and uml only.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/18/2014 02:09 AM, Richard Weinberger wrote:
> Am 17.07.2014 12:48, schrieb 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.
> 
> 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.

If score sticks to NO_IOMEM, and can not remove score from kernel only
because of this reason. I also suggest implement dummy functions within
score itself.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 18.07.2014 02:36, schrieb Chen Gang:
> 
> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>> Am 17.07.2014 12:48, schrieb 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.
>>
>> 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.

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

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/18/2014 03:35 PM, Richard Weinberger wrote:
> Am 18.07.2014 02:36, schrieb Chen Gang:
>>
>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>> Am 17.07.2014 12:48, schrieb 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.
>>>
>>> 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.
> 
> 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. :-)


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 18.07.2014 12:44, schrieb Chen Gang:
> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>
>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>
>>>> 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.
>>
>> 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. :-)

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Lennox Wu]

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

Best,
Lennox

2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
> Am 18.07.2014 12:44, schrieb Chen Gang:
>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>
>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>
>>>>> 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.
>>>
>>> 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. :-)
>
> 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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/18/2014 11:37 PM, Lennox Wu wrote:
> Score can provide dummy functions if HAS_IOMEM  and NO_IOMEM will be
> removed, even if we indeed have no IOMEM.
> 

Thank you for your reply, for score, your ideas is OK to me.


And for the COMPILE_TEST needs still discussing below:

> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>
>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>>
>>>>>> 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.
>>>>
>>>> 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. :-)
>>
>> 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.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/19/2014 02:02 AM, Chen Gang wrote:
>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>>
>>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> 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. :-)
>>>
>>> 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.
> 

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.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 20.07.2014 10:38, schrieb Chen Gang:
> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
>>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>>>
>>>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>> 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. :-)
>>>>
>>>> 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.
>>
> 
> Next, I shall:
> 
>  - Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

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

>  - 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.

Thanks,
//richard

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/20/2014 04:38 PM, Chen Gang wrote:
> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
>>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>>>
>>>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>> 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. :-)
>>>>
>>>> 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.
>>
> 
> 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.
>
 
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.

> 
> 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.
> 
> 

Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/20/2014 05:45 PM, Richard Weinberger wrote:
> 
> 
> Am 20.07.2014 10:38, schrieb Chen Gang:
>> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
>>>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>>>>
>>>>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>
>>>>>>> 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. :-)
>>>>>
>>>>> 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.
>>>
>>
>> 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.

>>  - 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.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/20/2014 05:51 PM, Chen Gang wrote:
> On 07/20/2014 05:45 PM, Richard Weinberger wrote:
>>
>>
>> Am 20.07.2014 10:38, schrieb Chen Gang:
>>> On 07/19/2014 02:02 AM, Chen Gang wrote:
>>>>> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <richard@nod.at>:
>>>>>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>>>>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>>>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>>>>>>
>>>>>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>>>>>> Am 17.07.2014 12:48, schrieb 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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. :-)
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> 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.
> 
>>>  - 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.
> 
> 

And sorry, I can not finish this discussion and send patch for it within
this week, for it is really a long necessary discussion.

But, hope we can finish this discussion and send patch for it within
this month (but in current condition, I am not quite sure).

And after finish discussion, welcome any other members help sending
related patch for it (e.g. implement dummy IOMEM in "asm-generic",
remove all IOMEM in kernel wide).

Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Arnd Bergmann]

On Sunday 20 July 2014 17:45:40 Chen Gang wrote:
> > 
> > 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.
> >
>  
> 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.

	Arnd

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/22/2014 06:32 PM, Arnd Bergmann wrote:
> On Sunday 20 July 2014 17:45:40 Chen Gang wrote:
>>>
>>> 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.
>>>
>>  
>> 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.
> 

Welcome any other members (especially driver members) ideas and
suggestions -- driver members and architecture members have different
tastes and different roles.

For me, if no additional reply, I prefer to keep current status, and
still add 'depends on HAS_IOMEM' for each driver which need it, but I am
not sure whether driver members can bear it.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/17/2014 05:19 PM, Chen Gang wrote:
> 
> 
> On 07/17/2014 05:16 PM, Dan Carpenter wrote:
>> On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
>>>>> +	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.
>>
>> 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.

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

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Dan Carpenter]

On Wed, Jul 23, 2014 at 07:09:22PM +0800, Chen Gang wrote:
> 
> 
> On 07/17/2014 05:19 PM, Chen Gang wrote:
> > 
> > 
> > On 07/17/2014 05:16 PM, Dan Carpenter wrote:
> >> On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
> >>>>> +	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.
> >>
> >> 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.

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

regards,
dan carpenter

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

On 07/23/2014 07:30 PM, Dan Carpenter wrote:
> On Wed, Jul 23, 2014 at 07:09:22PM +0800, Chen Gang wrote:
>>
>>
>> On 07/17/2014 05:19 PM, Chen Gang wrote:
>>>
>>>
>>> On 07/17/2014 05:16 PM, Dan Carpenter wrote:
>>>> On Thu, Jul 17, 2014 at 04:59:09PM +0800, Chen Gang wrote:
>>>>>>> +	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.
>>>>
>>>> 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.
> 
> Matthias Brugger already moved it to include/linux/io.h on Friday.
> 

OK, thank you for your work.

And for me, this 'long discussion' can be finished now (keeping current
status no touch). But if any members have additional suggestions and
ideas, still welcome to reply directly.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chris Metcalf]

On 7/17/2014 5:05 PM, Arnd Bergmann wrote:
> On Thursday 17 July 2014 16:41:14 Chris Metcalf wrote:
>> On 7/17/2014 7:28 AM, Chen Gang wrote:
>>> 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?
> Only s390 as far as I know. Most architectures have integrated
> peripherals that use MMIO without PCI.

Yes, and tilegx has these too (quite a few of them).  The memory-mapped
devices are accessed by specifying a shim x,y coordinate in the high bits
of the physical address, in conjunction with an MMIO type in the TLB entry.
Various tilegx drivers set up these kinds of mappings in the page table.

The issue with ioremap() is that it takes a generic resource_size_t
"physical address", and we don't have any general-purpose layer that maps
particular PAs to shim coordinates, other than for TRIO (our PCI peripheral).
Right now we just check the PCI root complexes that we have configured in
the kernel, and if the pseudo physical address requested is in a range that
we're associating with one of the root complexes, we will use the appropriate
mapping against the appropriate TRIO shim to set up its x,y coordinate in
the page table.

So it makes some kind of sense to condition HAS_IOMEM on PCI, even though
naively it seems like it shouldn't be strictly related.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com