* [PATCH] cpuidle: add maintainer entry
2013-04-24 13:34 [PATCH] cpuidle: add maintainer entry Daniel Lezcano
@ 2013-04-24 13:55 ` Jason Cooper
2013-04-24 14:23 ` Andrew Lunn
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Jason Cooper @ 2013-04-24 13:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 24, 2013 at 03:34:23PM +0200, Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
>
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
>
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
>
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
>
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
>
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
>
> This organization will be the same than cpufreq.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> MAINTAINERS | 7 +++++++
> drivers/cpuidle/cpuidle-calxeda.c | 4 +++-
> drivers/cpuidle/cpuidle-kirkwood.c | 5 +++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
For the kirkwood bit:
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH] cpuidle: add maintainer entry
2013-04-24 13:34 [PATCH] cpuidle: add maintainer entry Daniel Lezcano
2013-04-24 13:55 ` Jason Cooper
@ 2013-04-24 14:23 ` Andrew Lunn
2013-04-24 16:55 ` Kevin Hilman
2013-04-24 17:50 ` Rob Herring
3 siblings, 0 replies; 14+ messages in thread
From: Andrew Lunn @ 2013-04-24 14:23 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 24, 2013 at 03:34:23PM +0200, Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
>
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
>
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
>
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
>
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
>
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
>
> This organization will be the same than cpufreq.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> MAINTAINERS | 7 +++++++
> drivers/cpuidle/cpuidle-calxeda.c | 4 +++-
> drivers/cpuidle/cpuidle-kirkwood.c | 5 +++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..effa0f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,13 @@ S: Maintained
> F: drivers/cpufreq/
> F: include/linux/cpufreq.h
>
> +CPUIDLE DRIVERS
> +M: Rafael J. Wysocki <rjw@sisk.pl>
> +L: linux-pm at vger.kernel.org
> +S: Maintained
> +F: drivers/cpuidle/*
> +F: include/linux/cpuidle.h
> +
> CPU FREQUENCY DRIVERS - ARM BIG LITTLE
> M: Viresh Kumar <viresh.kumar@linaro.org>
> M: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index e344b56..2378c39 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -1,7 +1,6 @@
> /*
> * Copyright 2012 Calxeda, Inc.
> *
> - * Based on arch/arm/plat-mxc/cpuidle.c:
> * Copyright 2012 Freescale Semiconductor, Inc.
> * Copyright 2012 Linaro Ltd.
> *
> @@ -16,6 +15,9 @@
> *
> * You should have received a copy of the GNU General Public License along with
> * this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Author : Rob Herring <rob.herring@calxeda.com>
> + * Maintainer: Rob Herring <rob.herring@calxeda.com>
> */
>
> #include <linux/cpuidle.h>
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 53290e1..521b0a7 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -1,6 +1,4 @@
> /*
> - * arch/arm/mach-kirkwood/cpuidle.c
> - *
> * CPU idle Marvell Kirkwood SoCs
> *
> * This file is licensed under the terms of the GNU General Public
> @@ -11,6 +9,9 @@
> * to implement two idle states -
> * #1 wait-for-interrupt
> * #2 wait-for-interrupt and DDR self refresh
> + *
> + * Maintainer: Jason Cooper <jason@lakedaemon.net>
> + * Maintainer: Andrew Lunn <andrew@lunn.ch>
> */
>
For the Kirkwood part
Acked-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-24 13:34 [PATCH] cpuidle: add maintainer entry Daniel Lezcano
2013-04-24 13:55 ` Jason Cooper
2013-04-24 14:23 ` Andrew Lunn
@ 2013-04-24 16:55 ` Kevin Hilman
2013-04-25 12:09 ` Linus Walleij
2013-04-24 17:50 ` Rob Herring
3 siblings, 1 reply; 14+ messages in thread
From: Kevin Hilman @ 2013-04-24 16:55 UTC (permalink / raw)
To: linux-arm-kernel
Rafael,
Daniel Lezcano <daniel.lezcano@linaro.org> writes:
[...]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..effa0f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,13 @@ S: Maintained
> F: drivers/cpufreq/
> F: include/linux/cpufreq.h
>
> +CPUIDLE DRIVERS
> +M: Rafael J. Wysocki <rjw@sisk.pl>
> +L: linux-pm at vger.kernel.org
> +S: Maintained
> +F: drivers/cpuidle/*
> +F: include/linux/cpuidle.h
What do you think about having Daniel listed here as a co-maintainer?
He has been driving a significant consolidation effort, and will
continue to do that, so I think he should help take care of this area
and ensure all drivers are moving in the right direction.
Kevin
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-24 16:55 ` Kevin Hilman
@ 2013-04-25 12:09 ` Linus Walleij
2013-04-25 18:27 ` Rafael J. Wysocki
0 siblings, 1 reply; 14+ messages in thread
From: Linus Walleij @ 2013-04-25 12:09 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Rafael,
>
> Daniel Lezcano <daniel.lezcano@linaro.org> writes:
>
> [...]
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 61677c3..effa0f3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2206,6 +2206,13 @@ S: Maintained
>> F: drivers/cpufreq/
>> F: include/linux/cpufreq.h
>>
>> +CPUIDLE DRIVERS
>> +M: Rafael J. Wysocki <rjw@sisk.pl>
>> +L: linux-pm at vger.kernel.org
>> +S: Maintained
>> +F: drivers/cpuidle/*
>> +F: include/linux/cpuidle.h
>
> What do you think about having Daniel listed here as a co-maintainer?
I second that. He will bring useful embedded knowledge to the
subsystem.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-25 12:09 ` Linus Walleij
@ 2013-04-25 18:27 ` Rafael J. Wysocki
2013-04-26 8:32 ` Linus Walleij
0 siblings, 1 reply; 14+ messages in thread
From: Rafael J. Wysocki @ 2013-04-25 18:27 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday, April 25, 2013 02:09:11 PM Linus Walleij wrote:
> On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman@linaro.org> wrote:
> > Rafael,
> >
> > Daniel Lezcano <daniel.lezcano@linaro.org> writes:
> >
> > [...]
> >
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 61677c3..effa0f3 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -2206,6 +2206,13 @@ S: Maintained
> >> F: drivers/cpufreq/
> >> F: include/linux/cpufreq.h
> >>
> >> +CPUIDLE DRIVERS
> >> +M: Rafael J. Wysocki <rjw@sisk.pl>
> >> +L: linux-pm at vger.kernel.org
> >> +S: Maintained
> >> +F: drivers/cpuidle/*
> >> +F: include/linux/cpuidle.h
> >
> > What do you think about having Daniel listed here as a co-maintainer?
>
> I second that. He will bring useful embedded knowledge to the
> subsystem.
I'd still like to have a say about the core, but if Daniel is willing to
maintain ARM cpuidle drivers and all of the relevant ARM people agree with
that, that'll be great.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-25 18:27 ` Rafael J. Wysocki
@ 2013-04-26 8:32 ` Linus Walleij
2013-04-26 10:53 ` Daniel Lezcano
0 siblings, 1 reply; 14+ messages in thread
From: Linus Walleij @ 2013-04-26 8:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 8:27 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, April 25, 2013 02:09:11 PM Linus Walleij wrote:
>> On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman@linaro.org> wrote:
>> > What do you think about having Daniel listed here as a co-maintainer?
>>
>> I second that. He will bring useful embedded knowledge to the
>> subsystem.
>
> I'd still like to have a say about the core, but if Daniel is willing to
> maintain ARM cpuidle drivers and all of the relevant ARM people agree with
> that, that'll be great.
OK Daniel can you post a v2 adding yourself as co-maintainer as well?
Add my Acked-by if you wish.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-26 8:32 ` Linus Walleij
@ 2013-04-26 10:53 ` Daniel Lezcano
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Lezcano @ 2013-04-26 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On 04/26/2013 10:32 AM, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 8:27 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Thursday, April 25, 2013 02:09:11 PM Linus Walleij wrote:
>>> On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman@linaro.org> wrote:
>
>>>> What do you think about having Daniel listed here as a co-maintainer?
>>>
>>> I second that. He will bring useful embedded knowledge to the
>>> subsystem.
>>
>> I'd still like to have a say about the core, but if Daniel is willing to
>> maintain ARM cpuidle drivers and all of the relevant ARM people agree with
>> that, that'll be great.
>
> OK Daniel can you post a v2 adding yourself as co-maintainer as well?
> Add my Acked-by if you wish.
Sure, I can help and ensure the drivers are going to the right
direction, especially the ARM drivers. I will add also Rafael's git tree
link.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-24 13:34 [PATCH] cpuidle: add maintainer entry Daniel Lezcano
` (2 preceding siblings ...)
2013-04-24 16:55 ` Kevin Hilman
@ 2013-04-24 17:50 ` Rob Herring
2013-04-25 6:45 ` Daniel Lezcano
3 siblings, 1 reply; 14+ messages in thread
From: Rob Herring @ 2013-04-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
On 04/24/2013 08:34 AM, Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
>
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
>
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
>
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
>
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
>
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
Shouldn't MAINTAINERS contain the driver maintainers too?
>
> This organization will be the same than cpufreq.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> MAINTAINERS | 7 +++++++
> drivers/cpuidle/cpuidle-calxeda.c | 4 +++-
> drivers/cpuidle/cpuidle-kirkwood.c | 5 +++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..effa0f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,13 @@ S: Maintained
> F: drivers/cpufreq/
> F: include/linux/cpufreq.h
>
> +CPUIDLE DRIVERS
> +M: Rafael J. Wysocki <rjw@sisk.pl>
> +L: linux-pm at vger.kernel.org
> +S: Maintained
> +F: drivers/cpuidle/*
> +F: include/linux/cpuidle.h
> +
> CPU FREQUENCY DRIVERS - ARM BIG LITTLE
> M: Viresh Kumar <viresh.kumar@linaro.org>
> M: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index e344b56..2378c39 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -1,7 +1,6 @@
> /*
> * Copyright 2012 Calxeda, Inc.
> *
> - * Based on arch/arm/plat-mxc/cpuidle.c:
This file may have moved, but it existed at the time this was committed.
So the comment still applies and documents what part of the file the FSL
and Linaro copyright applies to.
Of course most of what was copied here was the boilerplate which your
patch series removes. The heart of the functionality was developed by me.
> * Copyright 2012 Freescale Semiconductor, Inc.
> * Copyright 2012 Linaro Ltd.
> *
> @@ -16,6 +15,9 @@
> *
> * You should have received a copy of the GNU General Public License along with
> * this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Author : Rob Herring <rob.herring@calxeda.com>
> + * Maintainer: Rob Herring <rob.herring@calxeda.com>
As mentioned above, this doesn't seem right.
Rob
> */
>
> #include <linux/cpuidle.h>
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 53290e1..521b0a7 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -1,6 +1,4 @@
> /*
> - * arch/arm/mach-kirkwood/cpuidle.c
> - *
> * CPU idle Marvell Kirkwood SoCs
> *
> * This file is licensed under the terms of the GNU General Public
> @@ -11,6 +9,9 @@
> * to implement two idle states -
> * #1 wait-for-interrupt
> * #2 wait-for-interrupt and DDR self refresh
> + *
> + * Maintainer: Jason Cooper <jason@lakedaemon.net>
> + * Maintainer: Andrew Lunn <andrew@lunn.ch>
> */
>
> #include <linux/kernel.h>
>
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH] cpuidle: add maintainer entry
2013-04-24 17:50 ` Rob Herring
@ 2013-04-25 6:45 ` Daniel Lezcano
2013-04-25 6:49 ` Viresh Kumar
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Lezcano @ 2013-04-25 6:45 UTC (permalink / raw)
To: linux-arm-kernel
On 04/24/2013 07:50 PM, Rob Herring wrote:
> On 04/24/2013 08:34 AM, Daniel Lezcano wrote:
>> Currently the cpuidle drivers are spread across the different archs.
>>
>> The patch submission for cpuidle are following different path: the cpuidle core
>> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
>> tree, sh goes through sh arch tree, pseries goes through PowerPC and
>> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
>>
>> That makes difficult to consolidate the code and to propagate modifications
>> from the cpuidle core to the different drivers.
>>
>> Hopefully, a movement has initiated to put the cpuidle drivers into the
>> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
>>
>> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
>> and prevent new cpuidle drivers to goes to an arch directory.
>>
>> The upstreaming process is unchanged: Rafael takes the patches to merge them
>> into its tree but with the acked-by from the driver's maintainer. So the header
>> must contains the name of the maintainer.
>
> Shouldn't MAINTAINERS contain the driver maintainers too?
It should contains the upstream maintainer for the subsystem, and
optionally a co-maintainer.
The MAINTAINERS file gives informations about the patch submission path.
The file's header should contain the maintainer of the driver, so the
submitted patches will go to the subsystem maintainer for upstreaming
and to the driver maintainer for acked-by.
If you add an entry in MAINTAINERS like:
ARM/CALXEDA HIGHBANK ARCHITECTURE
M: Rob Herring <rob.herring@calxeda.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-highbank/
+F: drivers/cpuidle/cpuidle-calxeda.c
That will add confusion while we are trying to clarify the situation
with a single entry point for the patches submission. If someone wants
to submit a patch for this driver, it will look at the MAINTAINERS file
and won't know if it should send the patch against arm-soc or linux-pm.
At some exceptions, this is how is organized the different drivers, for
cpufreq, clocksource, ...
>> This organization will be the same than cpufreq.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>> MAINTAINERS | 7 +++++++
>> drivers/cpuidle/cpuidle-calxeda.c | 4 +++-
>> drivers/cpuidle/cpuidle-kirkwood.c | 5 +++--
>> 3 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 61677c3..effa0f3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2206,6 +2206,13 @@ S: Maintained
>> F: drivers/cpufreq/
>> F: include/linux/cpufreq.h
>>
>> +CPUIDLE DRIVERS
>> +M: Rafael J. Wysocki <rjw@sisk.pl>
>> +L: linux-pm at vger.kernel.org
>> +S: Maintained
>> +F: drivers/cpuidle/*
>> +F: include/linux/cpuidle.h
>> +
>> CPU FREQUENCY DRIVERS - ARM BIG LITTLE
>> M: Viresh Kumar <viresh.kumar@linaro.org>
>> M: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
>> index e344b56..2378c39 100644
>> --- a/drivers/cpuidle/cpuidle-calxeda.c
>> +++ b/drivers/cpuidle/cpuidle-calxeda.c
>> @@ -1,7 +1,6 @@
>> /*
>> * Copyright 2012 Calxeda, Inc.
>> *
>> - * Based on arch/arm/plat-mxc/cpuidle.c:
>
> This file may have moved, but it existed at the time this was committed.
> So the comment still applies and documents what part of the file the FSL
> and Linaro copyright applies to.
Ok. As this file moved to arch/arm/mach-imx and changed a lot, may be we
can add the tag #v3.7 in the comment...
> Of course most of what was copied here was the boilerplate which your
> patch series removes. The heart of the functionality was developed by me.
>
>> * Copyright 2012 Freescale Semiconductor, Inc.
>> * Copyright 2012 Linaro Ltd.
>> *
>> @@ -16,6 +15,9 @@
>> *
>> * You should have received a copy of the GNU General Public License along with
>> * this program. If not, see <http://www.gnu.org/licenses/>.
>> + *
>> + * Author : Rob Herring <rob.herring@calxeda.com>
>> + * Maintainer: Rob Herring <rob.herring@calxeda.com>
>
> As mentioned above, this doesn't seem right.
It is based on Robert Lee's cpuidle driver for imx, but you wrote this
driver, no ?
If I refer to commit be6a98d3f00c292d347465d96acbec9d8c2783cf, you are
author of this driver. Suffice to say the driver was initially based on
imx, which is the case in the top of the header.
I suggest to keep the Author and the Maintainer because if, in the
future, you don't want to maintain anymore the driver and someone wants
to know the initial author of the driver for any reasons, he can check
that in the file header without archaeological digs in the git history.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-25 6:45 ` Daniel Lezcano
@ 2013-04-25 6:49 ` Viresh Kumar
2013-04-25 7:06 ` Daniel Lezcano
0 siblings, 1 reply; 14+ messages in thread
From: Viresh Kumar @ 2013-04-25 6:49 UTC (permalink / raw)
To: linux-arm-kernel
On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 04/24/2013 07:50 PM, Rob Herring wrote:
>> Shouldn't MAINTAINERS contain the driver maintainers too?
>
> It should contains the upstream maintainer for the subsystem, and
> optionally a co-maintainer.
>
> The MAINTAINERS file gives informations about the patch submission path.
>
> The file's header should contain the maintainer of the driver, so the
> submitted patches will go to the subsystem maintainer for upstreaming
> and to the driver maintainer for acked-by.
>
> If you add an entry in MAINTAINERS like:
>
> ARM/CALXEDA HIGHBANK ARCHITECTURE
> M: Rob Herring <rob.herring@calxeda.com>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-highbank/
> +F: drivers/cpuidle/cpuidle-calxeda.c
>
> That will add confusion while we are trying to clarify the situation
> with a single entry point for the patches submission. If someone wants
> to submit a patch for this driver, it will look at the MAINTAINERS file
> and won't know if it should send the patch against arm-soc or linux-pm.
I though otherwise. We can add entry in MAINTAINERS for any module.
Module can be a framework/architecture or a single driver.
Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
wrong as it adds to confusion and so there should be a separate entry for
this driver rather than merging it with arch/ entries.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-25 6:49 ` Viresh Kumar
@ 2013-04-25 7:06 ` Daniel Lezcano
2013-04-25 15:50 ` Rob Herring
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Lezcano @ 2013-04-25 7:06 UTC (permalink / raw)
To: linux-arm-kernel
On 04/25/2013 08:49 AM, Viresh Kumar wrote:
> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>
>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>
>> It should contains the upstream maintainer for the subsystem, and
>> optionally a co-maintainer.
>>
>> The MAINTAINERS file gives informations about the patch submission path.
>>
>> The file's header should contain the maintainer of the driver, so the
>> submitted patches will go to the subsystem maintainer for upstreaming
>> and to the driver maintainer for acked-by.
>>
>> If you add an entry in MAINTAINERS like:
>>
>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>> M: Rob Herring <rob.herring@calxeda.com>
>> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> S: Maintained
>> F: arch/arm/mach-highbank/
>> +F: drivers/cpuidle/cpuidle-calxeda.c
>>
>> That will add confusion while we are trying to clarify the situation
>> with a single entry point for the patches submission. If someone wants
>> to submit a patch for this driver, it will look at the MAINTAINERS file
>> and won't know if it should send the patch against arm-soc or linux-pm.
>
> I though otherwise. We can add entry in MAINTAINERS for any module.
> Module can be a framework/architecture or a single driver.
IMO, there are too much drivers for that. It is simpler for someone to
read the MAINTAINERS file to find the cpuidle drivers goes through
linux-pm. I think we can trust Rafael to ask for the acked-by from the
maintainer of the driver before taking the patches.
> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
> wrong as it adds to confusion and so there should be a separate entry for
> this driver rather than merging it with arch/ entries.
Yes, actually it was an example to show the confusion we could be facing.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-25 7:06 ` Daniel Lezcano
@ 2013-04-25 15:50 ` Rob Herring
2013-04-25 16:32 ` Daniel Lezcano
0 siblings, 1 reply; 14+ messages in thread
From: Rob Herring @ 2013-04-25 15:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 2:06 AM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> On 04/25/2013 08:49 AM, Viresh Kumar wrote:
>> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>>
>>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>>
>>> It should contains the upstream maintainer for the subsystem, and
>>> optionally a co-maintainer.
>>>
>>> The MAINTAINERS file gives informations about the patch submission path.
>>>
>>> The file's header should contain the maintainer of the driver, so the
>>> submitted patches will go to the subsystem maintainer for upstreaming
>>> and to the driver maintainer for acked-by.
>>>
>>> If you add an entry in MAINTAINERS like:
>>>
>>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>>> M: Rob Herring <rob.herring@calxeda.com>
>>> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>> S: Maintained
>>> F: arch/arm/mach-highbank/
>>> +F: drivers/cpuidle/cpuidle-calxeda.c
>>>
>>> That will add confusion while we are trying to clarify the situation
>>> with a single entry point for the patches submission. If someone wants
>>> to submit a patch for this driver, it will look at the MAINTAINERS file
>>> and won't know if it should send the patch against arm-soc or linux-pm.
>>
>> I though otherwise. We can add entry in MAINTAINERS for any module.
>> Module can be a framework/architecture or a single driver.
>
> IMO, there are too much drivers for that. It is simpler for someone to
> read the MAINTAINERS file to find the cpuidle drivers goes through
> linux-pm. I think we can trust Rafael to ask for the acked-by from the
> maintainer of the driver before taking the patches.
It not a maintainer's job to solicit acks. It is the submitter's job
to Cc the correct people. The maintainer should only check for
necessary CC/acks and bitch at the submitter if they did not use
get_maintainers.pl.
Perhaps the MAINTAINERS file needs to be distributed to scale better
or we need a way to put the maintainer data into the source and be
usable by get_maintainers.pl.
>> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
>> wrong as it adds to confusion and so there should be a separate entry for
>> this driver rather than merging it with arch/ entries.
>
> Yes, actually it was an example to show the confusion we could be facing.
I'm confused about what is the confusion...
Rob
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] cpuidle: add maintainer entry
2013-04-25 15:50 ` Rob Herring
@ 2013-04-25 16:32 ` Daniel Lezcano
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Lezcano @ 2013-04-25 16:32 UTC (permalink / raw)
To: linux-arm-kernel
On 04/25/2013 05:50 PM, Rob Herring wrote:
> On Thu, Apr 25, 2013 at 2:06 AM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>> On 04/25/2013 08:49 AM, Viresh Kumar wrote:
>>> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>>>
>>>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>>>
>>>> It should contains the upstream maintainer for the subsystem, and
>>>> optionally a co-maintainer.
>>>>
>>>> The MAINTAINERS file gives informations about the patch submission path.
>>>>
>>>> The file's header should contain the maintainer of the driver, so the
>>>> submitted patches will go to the subsystem maintainer for upstreaming
>>>> and to the driver maintainer for acked-by.
>>>>
>>>> If you add an entry in MAINTAINERS like:
>>>>
>>>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>>>> M: Rob Herring <rob.herring@calxeda.com>
>>>> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>>> S: Maintained
>>>> F: arch/arm/mach-highbank/
>>>> +F: drivers/cpuidle/cpuidle-calxeda.c
>>>>
>>>> That will add confusion while we are trying to clarify the situation
>>>> with a single entry point for the patches submission. If someone wants
>>>> to submit a patch for this driver, it will look at the MAINTAINERS file
>>>> and won't know if it should send the patch against arm-soc or linux-pm.
>>>
>>> I though otherwise. We can add entry in MAINTAINERS for any module.
>>> Module can be a framework/architecture or a single driver.
>>
>> IMO, there are too much drivers for that. It is simpler for someone to
>> read the MAINTAINERS file to find the cpuidle drivers goes through
>> linux-pm. I think we can trust Rafael to ask for the acked-by from the
>> maintainer of the driver before taking the patches.
>
> It not a maintainer's job to solicit acks. It is the submitter's job
> to Cc the correct people. The maintainer should only check for
> necessary CC/acks and bitch at the submitter if they did not use
> get_maintainers.pl.
Ok, I was saying exactly the same, but it was misphrased.
I meant, we can be confident Rafael won't accept patches if they are not
acked by the correct people.
> Perhaps the MAINTAINERS file needs to be distributed to scale better
> or we need a way to put the maintainer data into the source and be
> usable by get_maintainers.pl.
Yep, the latter could be a good idea.
>>> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
>>> wrong as it adds to confusion and so there should be a separate entry for
>>> this driver rather than merging it with arch/ entries.
>>
>> Yes, actually it was an example to show the confusion we could be facing.
>
> I'm confused about what is the confusion...
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 14+ messages in thread