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

On 07/20/2014 05:51 PM, Chen Gang wrote:

On 07/20/2014 05:45 PM, Richard Weinberger wrote:

quoted

Am 20.07.2014 10:38, schrieb Chen Gang:

quoted

On 07/19/2014 02:02 AM, Chen Gang wrote:

quoted

quoted

2014-07-18 18:51 GMT+08:00 Richard Weinberger [off-list ref]:

quoted

Am 18.07.2014 12:44, schrieb Chen Gang:

quoted

On 07/18/2014 03:35 PM, Richard Weinberger wrote:

quoted

Am 18.07.2014 02:36, schrieb Chen Gang:

quoted

On 07/18/2014 02:09 AM, Richard Weinberger wrote:

quoted

Am 17.07.2014 12:48, schrieb Arnd Bergmann:

quoted

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.

quoted

quoted

 - 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