| Message ID | 1393899345-7397-2-git-send-email-graeme.gregory@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Tue, 2014-03-04 at 10:15 +0800, Graeme Gregory wrote: > Add maintainers for the arm-core file for arm64 ACPI support Shouldn't something have to be in the kernel tree before there's a MAINTAINERS entry? > diff --git a/MAINTAINERS b/MAINTAINERS > index c6d0e93..c770d3a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -259,6 +259,13 @@ F: drivers/pci/*/*acpi* > F: drivers/pci/*/*/*acpi* > F: tools/power/acpi > > +ACPI ARM64 > +M: Hanjun Guo <hanjun.guo@linaro.org> > +M: Graeme Gregory <graeme.gregory@linaro.org> > +S: Supported > +L: linux-acpi@vger.kernel.org > +F: drivers/acpi/plat/arm-core.c > + > ACPI COMPONENT ARCHITECTURE (ACPICA) > M: Robert Moore <robert.moore@intel.com> > M: Lv Zheng <lv.zheng@intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/03/2014 06:21 PM, Joe Perches wrote: > On Tue, 2014-03-04 at 10:15 +0800, Graeme Gregory wrote: >> Add maintainers for the arm-core file for arm64 ACPI support > > Shouldn't something have to be in the kernel > tree before there's a MAINTAINERS entry? or in linux-next and the patch can be added to linux-next (some git tree). >> diff --git a/MAINTAINERS b/MAINTAINERS >> index c6d0e93..c770d3a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -259,6 +259,13 @@ F: drivers/pci/*/*acpi* >> F: drivers/pci/*/*/*acpi* >> F: tools/power/acpi >> >> +ACPI ARM64 >> +M: Hanjun Guo <hanjun.guo@linaro.org> >> +M: Graeme Gregory <graeme.gregory@linaro.org> >> +S: Supported >> +L: linux-acpi@vger.kernel.org >> +F: drivers/acpi/plat/arm-core.c >> + >> ACPI COMPONENT ARCHITECTURE (ACPICA) >> M: Robert Moore <robert.moore@intel.com> >> M: Lv Zheng <lv.zheng@intel.com>
On Tue, Mar 04, 2014 at 02:15:45AM +0000, Graeme Gregory wrote: > +ACPI ARM64 That's a pretty broad statement for a single file. Is it core support, architected peripherals, SoC? > +M: Hanjun Guo <hanjun.guo@linaro.org> > +M: Graeme Gregory <graeme.gregory@linaro.org> > +S: Supported > +L: linux-acpi@vger.kernel.org > +F: drivers/acpi/plat/arm-core.c This patch should be part of the series introducing the arm-core.c file and it will be ACKed (or NAKed) following review. We can't really commit maintainers to a file which does not exist in mainline and while there is still feedback to be addressed. It's like a blank cheque.
On Tue, Mar 4, 2014 at 10:28 AM, Randy Dunlap <rdunlap@infradead.org> wrote: > On 03/03/2014 06:21 PM, Joe Perches wrote: >> On Tue, 2014-03-04 at 10:15 +0800, Graeme Gregory wrote: >>> Add maintainers for the arm-core file for arm64 ACPI support >> >> Shouldn't something have to be in the kernel >> tree before there's a MAINTAINERS entry? > > or in linux-next and the patch can be added to linux-next (some git tree). Sure, it makes sense to merge this file along with the rest of the series, but I certainly appreciate that Graeme and Hanjun are willing to volunteer to do this work. On Tue, Mar 4, 2014 at 6:23 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Tue, Mar 04, 2014 at 02:15:45AM +0000, Graeme Gregory wrote: >> +ACPI ARM64 > > That's a pretty broad statement for a single file. Is it core support, > architected peripherals, SoC? That's a good point. Graeme, it would be good if you could put some text in the patch describing how you propose the maintainership to work. Unfortunately the maintainers file doesn't have any kind of comments field, otherwise I'd suggest you make those comments directly there. Given that ACPI can touch a lot of subsystems I would expect you and Hanjun not to be merging much code directly, but being listed in maintainers means that you will be kept in the loop when it comes to merging ARM ACPI changes. I would also expect that anything that does go through you (instead of merely acked) would be merged via Rafael and Len's tree. > >> +M: Hanjun Guo <hanjun.guo@linaro.org> >> +M: Graeme Gregory <graeme.gregory@linaro.org> >> +S: Supported >> +L: linux-acpi@vger.kernel.org >> +F: drivers/acpi/plat/arm-core.c > > This patch should be part of the series introducing the arm-core.c file > and it will be ACKed (or NAKed) following review. We can't really commit > maintainers to a file which does not exist in mainline and while there is > still feedback to be addressed. It's like a blank cheque. I agree with merging it with the rest of the series, but comparing it to a blank cheque is not appropriate. Merely having an entry in MAINTAINERS doesn't immediately confer trust or ability to merge code, but it does tell people who to talk to when looking at ACPI on ARM. You can bet that neither Linus, Len or Rafael will merge ARM ACPI trees from them if you disagree. (And even if they did, you would yell, and Linus would revert it). > > -- > Catalin Graeme, you can add my a-b line: Acked-by: Grant Likely <grant.likely@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 04, 2014 at 10:59:46AM +0000, Grant Likely wrote: > On Tue, Mar 4, 2014 at 10:28 AM, Randy Dunlap <rdunlap@infradead.org> wrote: > > On 03/03/2014 06:21 PM, Joe Perches wrote: > >> On Tue, 2014-03-04 at 10:15 +0800, Graeme Gregory wrote: > >>> Add maintainers for the arm-core file for arm64 ACPI support > >> > >> Shouldn't something have to be in the kernel > >> tree before there's a MAINTAINERS entry? > > > > or in linux-next and the patch can be added to linux-next (some git tree). > > Sure, it makes sense to merge this file along with the rest of the > series, but I certainly appreciate that Graeme and Hanjun are willing > to volunteer to do this work. Well, to put it another way, it makes no sense at all to merge this patch independently. > On Tue, Mar 4, 2014 at 6:23 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Tue, Mar 04, 2014 at 02:15:45AM +0000, Graeme Gregory wrote: > >> +ACPI ARM64 > > > > That's a pretty broad statement for a single file. Is it core support, > > architected peripherals, SoC? > > That's a good point. Graeme, it would be good if you could put some > text in the patch describing how you propose the maintainership to > work. Unfortunately the maintainers file doesn't have any kind of > comments field, otherwise I'd suggest you make those comments directly > there. > > Given that ACPI can touch a lot of subsystems I would expect you and > Hanjun not to be merging much code directly, but being listed in > maintainers means that you will be kept in the loop when it comes to > merging ARM ACPI changes. I would also expect that anything that does > go through you (instead of merely acked) would be merged via Rafael > and Len's tree. > > > > >> +M: Hanjun Guo <hanjun.guo@linaro.org> > >> +M: Graeme Gregory <graeme.gregory@linaro.org> > >> +S: Supported > >> +L: linux-acpi@vger.kernel.org > >> +F: drivers/acpi/plat/arm-core.c > > > > This patch should be part of the series introducing the arm-core.c file > > and it will be ACKed (or NAKed) following review. We can't really commit > > maintainers to a file which does not exist in mainline and while there is > > still feedback to be addressed. It's like a blank cheque. > > I agree with merging it with the rest of the series, but comparing it > to a blank cheque is not appropriate. Merely having an entry in > MAINTAINERS doesn't immediately confer trust or ability to merge code, > but it does tell people who to talk to when looking at ACPI on ARM. > You can bet that neither Linus, Len or Rafael will merge ARM ACPI > trees from them if you disagree. (And even if they did, you would > yell, and Linus would revert it). If you want to know who to talk to regarding a subsystem then you use get_maintainer.pl and/or git blame. Regardless of this patch, neither of those tools will identify Graeme or Hanjun as the contacts for ACPI on ARM. I think we're in agreement, but just to spell it out: this patch should be included at the end of a series adding the files which will be maintained. Will -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 4, 2014 at 7:15 PM, Will Deacon <will.deacon@arm.com> wrote: > On Tue, Mar 04, 2014 at 10:59:46AM +0000, Grant Likely wrote: >> I agree with merging it with the rest of the series, but comparing it >> to a blank cheque is not appropriate. Merely having an entry in >> MAINTAINERS doesn't immediately confer trust or ability to merge code, >> but it does tell people who to talk to when looking at ACPI on ARM. >> You can bet that neither Linus, Len or Rafael will merge ARM ACPI >> trees from them if you disagree. (And even if they did, you would >> yell, and Linus would revert it). > > If you want to know who to talk to regarding a subsystem then you use > get_maintainer.pl and/or git blame. Regardless of this patch, neither of > those tools will identify Graeme or Hanjun as the contacts for ACPI on ARM. > > I think we're in agreement, but just to spell it out: this patch should be > included at the end of a series adding the files which will be maintained. Yes, agreed. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tue, Mar 04, 2014 at 10:59:46AM +0000, Grant Likely wrote: > On Tue, Mar 4, 2014 at 6:23 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Tue, Mar 04, 2014 at 02:15:45AM +0000, Graeme Gregory wrote: > >> +ACPI ARM64 > > > > That's a pretty broad statement for a single file. Is it core support, > > architected peripherals, SoC? > > That's a good point. Graeme, it would be good if you could put some > text in the patch describing how you propose the maintainership to > work. Unfortunately the maintainers file doesn't have any kind of > comments field, otherwise I'd suggest you make those comments directly > there. I would actually go for something that can be used as a reference like Documentation/arm64/acpi.txt. This will be a document that evolves in time but pretty much sets the direction for what it means to support ACPI on the arm64 kernel. Yesterday's talk at Linaro Connect about clocks and voltage regulators on ACPI platforms is a clear example that needs to be captured in a kernel document. For DT we have documented bindings and I was too lazy for a broader arm64 soc.txt document but I plan send an RFC across the lines of https://plus.google.com/103785593327310749350/posts/dZF3zf7z2v4 (unless the arm-soc guys beat me to it ;)). I really don't see much point in an ACPI ARM64 maintainers entry that only covers a 200 lines long file without guidelines on what else is going into other parts of the kernel related to ARM ACPI. > Given that ACPI can touch a lot of subsystems I would expect you and > Hanjun not to be merging much code directly, but being listed in > maintainers means that you will be kept in the loop when it comes to > merging ARM ACPI changes. I would also expect that anything that does > go through you (instead of merely acked) would be merged via Rafael > and Len's tree. No issues here. > >> +M: Hanjun Guo <hanjun.guo@linaro.org> > >> +M: Graeme Gregory <graeme.gregory@linaro.org> > >> +S: Supported > >> +L: linux-acpi@vger.kernel.org > >> +F: drivers/acpi/plat/arm-core.c > > > > This patch should be part of the series introducing the arm-core.c file > > and it will be ACKed (or NAKed) following review. We can't really commit > > maintainers to a file which does not exist in mainline and while there is > > still feedback to be addressed. It's like a blank cheque. > > I agree with merging it with the rest of the series, but comparing it > to a blank cheque is not appropriate. Merely having an entry in > MAINTAINERS doesn't immediately confer trust or ability to merge code, > but it does tell people who to talk to when looking at ACPI on ARM. > You can bet that neither Linus, Len or Rafael will merge ARM ACPI > trees from them if you disagree. (And even if they did, you would > yell, and Linus would revert it). The point is that I don't have to follow all the developments closely and feel the need to yell, so I have to rely on (trust) the newly appointed maintainers to do the right thing. The recent example with me asking Rafael to drop the GIC patch shouldn't have really happened. It's not for Rafael to decide on how many acks to be on a patch before being merged (absolutely no complaints to Rafael here) but rather for the patch contributors to reach out to relevant kernel developers and ask for review/ack before sending the patch upstream (especially when there is an ongoing conversation). As I already stated, I'm not bothered with the ACPI clean-up patches, that's up to Rafael/Len to merge. But those involving the ARM IP like GIC and timers need wider review before going upstream. For something of such importance to us like ARM ACPI, I really feel uneasy about patches going into mainline with just a Signed-off-by (hint: your ack adds significant weight to a patch ;)). Who/how many acks, I leave it to the ARM64 ACPI maintainers to figure out but it must be non-zero to be able to build up trust over time. And there is the wider issue of which platforms go for ACPI and which stay with DT. Here the key agreement should come from the arm64 and arm-soc maintainers and captured in a kernel document. That's a kernel decision based on technical merits and *not* driven by "artificial" distro policies (sorry jcm).
diff --git a/MAINTAINERS b/MAINTAINERS index c6d0e93..c770d3a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -259,6 +259,13 @@ F: drivers/pci/*/*acpi* F: drivers/pci/*/*/*acpi* F: tools/power/acpi +ACPI ARM64 +M: Hanjun Guo <hanjun.guo@linaro.org> +M: Graeme Gregory <graeme.gregory@linaro.org> +S: Supported +L: linux-acpi@vger.kernel.org +F: drivers/acpi/plat/arm-core.c + ACPI COMPONENT ARCHITECTURE (ACPICA) M: Robert Moore <robert.moore@intel.com> M: Lv Zheng <lv.zheng@intel.com>
Add maintainers for the arm-core file for arm64 ACPI support Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> --- MAINTAINERS | 7 +++++++ 1 file changed, 7 insertions(+)