| Message ID | 53C1F7DE.3060102@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
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
>
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To unsubscribe from this list: send the line "unsubscribe linux-pwm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
在 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.-- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. >
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. >
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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
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(-)