lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 5 Mar 2014 03:16:13 +0800
From:	Graeme Gregory <graeme@...a.org.uk>
To:	Grant Likely <grant.likely@...aro.org>
Cc:	Randy Dunlap <rdunlap@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Graeme Gregory <graeme.gregory@...aro.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI Devel Mailing List <linux-acpi@...r.kernel.org>,
	Joe Perches <joe@...ches.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] MAINTAINERS: add maintainers for arm64 acpi

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@...radead.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@....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@...aro.org>
> >> +M:   Graeme Gregory <graeme.gregory@...aro.org>
> >> +S:   Supported
> >> +L:   linux-acpi@...r.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ