[PATCH] MAINTAINERS: add maintainers for arm64 acpi

[Catalin Marinas]

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 at 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 at linaro.org>
> >> +M:   Graeme Gregory <graeme.gregory at linaro.org>
> >> +S:   Supported
> >> +L:   linux-acpi at 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).

-- 
Catalin