From: Richard Weinberger <richard@nod.at>
To: Chen Gang <gang.chen.5i5j@gmail.com>, Lennox Wu <lennox.wu@gmail.com>
Cc: linux-iio@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Tom Gundersen <teg@jklm.no>,
Thierry Reding <thierry.reding@gmail.com>,
Marek Vasut <marex@denx.de>, Liqin Chen <liqin.linux@gmail.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
msalter@redhat.com, Guenter Roeck <linux@roeck-us.net>,
linux-pwm@vger.kernel.org, devel@driverdev.osuosl.org,
linux-watchdog@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
linux-input@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
knaack.h@gmx.de, Martin Schwidefsky <schwidefsky@de.ibm.com>,
Mischa.Jonker@synopsys.com, jic23@kernel.org
Subject: Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Date: Sun, 20 Jul 2014 11:45:35 +0200 [thread overview]
Message-ID: <53CB8FBF.2070206@nod.at> (raw)
In-Reply-To: <53CB801D.1030603@gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Chen Gang <gang.chen.5i5j@gmail.com>, Lennox Wu <lennox.wu@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Guenter Roeck <linux@roeck-us.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-iio@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Tom Gundersen <teg@jklm.no>,
Thierry Reding <thierry.reding@gmail.com>,
Marek Vasut <marex@denx.de>, Liqin Chen <liqin.linux@gmail.com>,
msalter@redhat.com, linux-pwm@vger.kernel.org,
devel@driverdev.osuosl.org, linux-watchdog@vger.kernel.org,
linux-input@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
knaack.h@gmx.de, Martin Schwidefsky <schwidefsky@de.ibm.com>,
Mischa.Jonker@synopsys.com, jic23@kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Date: Sun, 20 Jul 2014 11:45:35 +0200 [thread overview]
Message-ID: <53CB8FBF.2070206@nod.at> (raw)
In-Reply-To: <53CB801D.1030603@gmail.com>
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
next prev parent reply other threads:[~2014-07-20 9:45 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-13 3:07 [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource' Chen Gang
2014-07-13 3:07 ` Chen Gang
2014-07-13 3:14 ` Chen Gang
2014-07-13 14:28 ` Chen Gang
2014-07-13 14:28 ` Chen Gang
[not found] ` <53C1F7DE.3060102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-13 3:45 ` Marek Vasut
2014-07-13 3:45 ` Marek Vasut
2014-07-13 9:27 ` Lennox Wu
2014-07-13 9:27 ` Lennox Wu
2014-07-13 9:45 ` Richard Weinberger
2014-07-13 9:45 ` Richard Weinberger
2014-07-13 10:06 ` Chen Gang
2014-07-13 10:06 ` Chen Gang
2014-07-13 13:26 ` Lars-Peter Clausen
[not found] ` <53C288F0.3070001-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2014-07-13 13:40 ` Richard Weinberger
2014-07-13 13:40 ` Richard Weinberger
2014-07-13 13:56 ` Lars-Peter Clausen
2014-07-13 14:03 ` Richard Weinberger
2014-07-13 14:25 ` Lars-Peter Clausen
2014-07-13 14:25 ` Lars-Peter Clausen
2014-07-13 15:02 ` Chen Gang
2014-07-13 15:02 ` Chen Gang
2014-07-13 19:22 ` Greg Kroah-Hartman
2014-07-13 19:22 ` Greg Kroah-Hartman
2014-07-13 19:33 ` Richard Weinberger
2014-07-13 20:17 ` Greg Kroah-Hartman
2014-07-13 20:17 ` Greg Kroah-Hartman
[not found] ` <20140713201753.GA29955-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-07-14 8:31 ` Richard Weinberger
2014-07-14 8:31 ` Richard Weinberger
2014-07-14 8:48 ` Lars-Peter Clausen
2014-07-14 8:48 ` Lars-Peter Clausen
2014-07-14 8:57 ` Richard Weinberger
2014-07-14 8:57 ` Richard Weinberger
[not found] ` <53C39B66.4060500-/L3Ra7n9ekc@public.gmane.org>
2014-07-14 9:22 ` Chen Gang
2014-07-14 9:22 ` Chen Gang
2014-07-14 9:22 ` Chen Gang
2014-07-14 9:22 ` Chen Gang
[not found] ` <5A40E1FC-CA61-4AFF-B205-4BAC175AA7AC-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-15 0:34 ` Chen Gang
2014-07-15 0:34 ` Chen Gang
2014-07-15 0:34 ` Chen Gang
2014-07-15 0:53 ` Guenter Roeck
2014-07-15 0:53 ` Guenter Roeck
2014-07-15 1:11 ` Chen Gang
2014-07-15 1:11 ` Chen Gang
2014-07-15 14:38 ` Chen Gang
2014-07-15 14:38 ` Chen Gang
2014-07-15 14:38 ` Chen Gang
[not found] ` <53C53CE1.4090803-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-17 1:27 ` Chen Gang
2014-07-17 1:27 ` Chen Gang
2014-07-17 1:27 ` Chen Gang
2014-07-17 1:58 ` Guenter Roeck
2014-07-17 1:58 ` Guenter Roeck
2014-07-17 2:11 ` Chen Gang
2014-07-17 8:37 ` Thierry Reding
2014-07-17 8:37 ` Thierry Reding
2014-07-17 8:59 ` Chen Gang
2014-07-17 8:59 ` Chen Gang
2014-07-17 9:16 ` Dan Carpenter
2014-07-17 9:16 ` Dan Carpenter
2014-07-17 9:19 ` Chen Gang
2014-07-23 11:09 ` Chen Gang
2014-07-23 11:30 ` Dan Carpenter
2014-07-23 11:37 ` Chen Gang
2014-07-17 9:20 ` Arnd Bergmann
2014-07-17 9:26 ` Richard Weinberger
2014-07-17 9:26 ` Richard Weinberger
2014-07-17 10:28 ` Arnd Bergmann
2014-07-17 10:28 ` Arnd Bergmann
2014-07-17 10:58 ` Richard Weinberger
2014-07-17 10:58 ` Richard Weinberger
2014-07-17 11:24 ` Arnd Bergmann
2014-07-17 11:24 ` Arnd Bergmann
2014-07-17 11:32 ` Chen Gang
2014-07-17 11:32 ` Chen Gang
2014-07-17 11:32 ` Chen Gang
2014-07-17 9:29 ` Chen Gang
2014-07-17 9:29 ` Chen Gang
2014-07-17 9:51 ` Thierry Reding
2014-07-17 10:38 ` Arnd Bergmann
2014-07-17 10:38 ` Arnd Bergmann
2014-07-17 11:46 ` Chen Gang
2014-07-17 11:46 ` Chen Gang
2014-07-17 9:56 ` Thierry Reding
2014-07-17 9:56 ` Thierry Reding
2014-07-17 10:33 ` Arnd Bergmann
2014-07-17 10:55 ` Thierry Reding
2014-07-17 10:55 ` Thierry Reding
2014-07-17 11:20 ` Chen Gang
2014-07-17 11:20 ` Chen Gang
2014-07-17 10:40 ` Lars-Peter Clausen
2014-07-17 10:40 ` Lars-Peter Clausen
2014-07-17 10:48 ` Arnd Bergmann
2014-07-17 11:28 ` Chen Gang
2014-07-17 20:41 ` Chris Metcalf
2014-07-17 20:41 ` Chris Metcalf
2014-07-17 21:05 ` Arnd Bergmann
2014-07-17 21:05 ` Arnd Bergmann
2014-07-18 0:26 ` Chen Gang
2014-07-31 20:09 ` Chris Metcalf
2014-07-31 20:09 ` Chris Metcalf
2014-07-17 18:09 ` Richard Weinberger
2014-07-17 18:09 ` Richard Weinberger
2014-07-18 0:36 ` Chen Gang
2014-07-18 7:35 ` Richard Weinberger
2014-07-18 7:35 ` Richard Weinberger
2014-07-18 10:44 ` Chen Gang
2014-07-18 10:51 ` Richard Weinberger
2014-07-18 15:37 ` Lennox Wu
2014-07-18 15:37 ` Lennox Wu
2014-07-18 18:02 ` Chen Gang
2014-07-20 8:38 ` Chen Gang
2014-07-20 8:38 ` Chen Gang
2014-07-20 9:45 ` Richard Weinberger [this message]
2014-07-20 9:45 ` Richard Weinberger
[not found] ` <53CB8FBF.2070206-/L3Ra7n9ekc@public.gmane.org>
2014-07-20 9:51 ` Chen Gang
2014-07-20 9:51 ` Chen Gang
2014-07-20 9:56 ` Chen Gang
2014-07-20 9:56 ` Chen Gang
2014-07-20 9:45 ` Chen Gang
2014-07-20 9:45 ` Chen Gang
2014-07-22 10:32 ` Arnd Bergmann
2014-07-22 11:29 ` Chen Gang
2014-07-22 11:29 ` Chen Gang
2014-07-15 0:35 ` Chen Gang
2014-07-15 0:35 ` Chen Gang
2014-07-15 0:35 ` Chen Gang
2014-07-14 8:18 ` Thierry Reding
2014-07-14 8:18 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53CB8FBF.2070206@nod.at \
--to=richard@nod.at \
--cc=Mischa.Jonker@synopsys.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=devel@driverdev.osuosl.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gang.chen.5i5j@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=lennox.wu@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=liqin.linux@gmail.com \
--cc=marex@denx.de \
--cc=msalter@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=teg@jklm.no \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.