| Message ID | 1393899345-7397-2-git-send-email-graeme.gregory@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| 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>
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>
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
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.
On Tue, Mar 04, 2014 at 10:23:16AM +0000, Catalin Marinas 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? > Hi Catalin would changing the title to ACPI ARM64 Core Support be better in your mind. I do intend for the maintainership to cover just the plat/arm-core.c file. Graeme > > +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. > > -- > Catalin > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 04, 2014 at 06:59:46PM +0800, 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. > > 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. > Ok, I will update the commit decision when we add this patch to the current upstreaming series. I would like if Rafael/Len are happy with the that the plat/arm-core.c file is handled via their linux-pm tree. Catalini/Will would obviously still maintain control over changes in arch/arm64 and I think it would be good if they were willing to also Ack changes to plat/arm-core.c The individual driver changes would be like they are for DT be pushed through the appropriate subsystem, or with appropriate Acks if this is not possible in combined patchsets. > > > >> +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). > We have absolutely no intention of pushing patches that arm64 maintainers are unhappy with. As Grant says this is purely to indicate who people should come and talk to. We really appreciate the feedback given on patches so far and wish to continue with this process. Graeme
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).
On Tue, Mar 04, 2014 at 07:03:18PM +0000, Graeme Gregory wrote: > On Tue, Mar 04, 2014 at 10:23:16AM +0000, Catalin Marinas 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? > > > Hi Catalin would changing the title to ACPI ARM64 Core Support be better > in your mind. I do intend for the maintainership to cover just the > plat/arm-core.c file. See my reply to Grant. If that's the only thing you guys are aiming for, who's in charge of the other bits? Face-to-face meeting in 3 hours anyway, so we can get back here with the conclusion.
On Tue, 4 Mar 2014 23:50:44 +0000, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Tue, Mar 04, 2014 at 07:03:18PM +0000, Graeme Gregory wrote: > > On Tue, Mar 04, 2014 at 10:23:16AM +0000, Catalin Marinas 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? > > > > > Hi Catalin would changing the title to ACPI ARM64 Core Support be better > > in your mind. I do intend for the maintainership to cover just the > > plat/arm-core.c file. > > See my reply to Grant. If that's the only thing you guys are aiming for, > who's in charge of the other bits? Face-to-face meeting in 3 hours > anyway, so we can get back here with the conclusion. Update for the benefit of those who weren't at Connect. I really think Hanjun and Graeme can do an excellent job here, but I appreciate that they are new to maintainership. To help them along, I'll mentor them in the maintainer process. I'm encouraging them to take the lead, but I'll be reading all the patches and I'll jump into the conversation if I think it is going off the rails. I'll also ack patches when I think they are in good shape and there is it is well defined what the boundaries need to be. We all agree that the current patches are not ready to be merged and there is feedback to be addressed before the next merge request. We will not attempt to merge without acks from Catalin. Also missing is a clear statement of how ACPI works on ARM. There needs to be a straight forward description of how ACPI PM works and how it is different from using FDT. That document will be written in short order and posted for review. g.
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(+)