Thread (70 messages) 70 messages, 11 authors, 2014-07-31

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2014-07-13 20:13:42
Also in: linux-iio, linux-pwm, linux-watchdog, lkml

On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
Am 13.07.2014 21:22, schrieb Greg Kroah-Hartman:
quoted
On Sun, Jul 13, 2014 at 04:25:06PM +0200, Lars-Peter Clausen wrote:
quoted
On 07/13/2014 04:03 PM, Richard Weinberger wrote:
quoted
Am 13.07.2014 15:56, schrieb Lars-Peter Clausen:
quoted
On 07/13/2014 03:40 PM, Richard Weinberger wrote:
quoted
Am 13.07.2014 15:26, schrieb Lars-Peter Clausen:
quoted
On 07/13/2014 11:45 AM, Richard Weinberger wrote:
quoted
Am 13.07.2014 11:27, schrieb Lennox Wu:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help