From: Mark Brown <broonie@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
linaro-kernel@lists.linaro.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
patches@linaro.org, Olof Johansson <olof@lixom.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Linus Walleij <linus.walleij@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
linaro-acpi@lists.linaro.org, linux-acpi@vger.kernel.org,
Hanjun Guo <hanjun.guo@linaro.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Jon Masters <jonathan@jonmasters.org>,
Rob Herring <rob.herring@calxeda.com>,
Grant Likely <grant.likely@linaro.org>
Subject: Re: [RFC part1 PATCH 0/7] Make ACPI core running on ARM64
Date: Sun, 8 Dec 2013 19:40:40 +0000 [thread overview]
Message-ID: <20131208194040.GN29268@sirena.org.uk> (raw)
In-Reply-To: <201312080344.56317.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]
On Sun, Dec 08, 2013 at 03:44:56AM +0100, Arnd Bergmann wrote:
> On Friday 06 December 2013, Mark Brown wrote:
> > OTOH if it's well encapsulated, is going to be required for any kind of
> > ACPI use and gets to the point where people are OK with it by itself
> > then I'm not sure what we'd gain by keeping it out of tree - it'd make
> > the real system patch sets bigger and harder to review.
> I'd agree as soon as someone can convince me that we actually want ACPI
> support in the kernel for ARM64 servers. As far as I'm concerned it's quite
> possible that the people who have worked on this for the past couple of
> years behind closed doors know what they are doing and it will all be
> good, but it's also possible that it turns into a huge trainwreck once
> we see multiple implementations that have fundamentally incompatible
> requirements regarding what they want from ACPI and we end up not doing
> it at all. I just don't have enough information at this point to know which
> of the two is true and I'd like to ensure that accepting the patches
> that meet your criteria above would not be seen as an endorsement to do
> crazy stuff later.
I do share all your concerns about the closed door stuff, and I'm also
not convinced that they'll be able to control the things people try to
do with it if it does become at all successful.
That said I don't think anyone could be in any reasonable doubt as to
the concerns that people have at this point and I do worry that keeping
everything out of tree will both increase reviwer fatigue if it does end
up getting merged and increase the chances that we end up with a
deployed fiat accomplait being submitted. We can always add dire
warnings and so on to the code and Kconfig to try to remind people but
so long as it's neither getting in the way of anything else nor making
any real decisions (as opposed to basics for the core spec) I'm not sure
how much we gain, if it never goes anywhere it can just sit and rot
quietly in a corner until it gets in the way.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-12-08 19:41 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 16:36 Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI " Hanjun Guo
2013-12-03 16:41 ` Matthew Garrett
2013-12-04 14:08 ` Hanjun Guo
2013-12-05 22:04 ` Arnd Bergmann
2013-12-06 15:04 ` [Linaro-acpi] " Tomasz Nowicki
2013-12-06 17:23 ` Arnd Bergmann
2013-12-09 4:12 ` Hanjun Guo
2013-12-09 11:50 ` Catalin Marinas
2013-12-09 13:05 ` Hanjun Guo
2013-12-09 16:35 ` Arnd Bergmann
2013-12-09 16:55 ` Catalin Marinas
2013-12-09 17:20 ` Arnd Bergmann
2013-12-09 18:01 ` Catalin Marinas
2013-12-16 20:51 ` Graeme Gregory
2013-12-17 11:29 ` Catalin Marinas
2013-12-19 11:30 ` Graeme Gregory
2013-12-19 14:01 ` Arnd Bergmann
2013-12-19 15:43 ` Catalin Marinas
2013-12-20 19:55 ` Mark Brown
2013-12-10 2:53 ` Hanjun Guo
2013-12-09 17:06 ` Matthew Garrett
2013-12-10 1:52 ` Hanjun Guo
2013-12-10 3:28 ` Arnd Bergmann
2013-12-10 19:22 ` Mark Brown
2013-12-10 20:00 ` Arnd Bergmann
2013-12-10 20:23 ` Mark Brown
2013-12-11 3:07 ` Arnd Bergmann
2013-12-11 11:02 ` Mark Brown
2013-12-10 9:56 ` Linus Walleij
2013-12-09 23:34 ` Rob Herring
2013-12-03 16:47 ` One Thousand Gnomes
2013-12-04 14:15 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 2/7] ARM64 : Add dummy asm/cpu.h Hanjun Guo
2013-12-03 17:13 ` Mark Rutland
2013-12-04 15:00 ` Hanjun Guo
2013-12-03 17:59 ` Mark Brown
2013-12-03 16:36 ` [RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent Hanjun Guo
2013-12-03 16:46 ` Matthew Garrett
2013-12-04 14:11 ` Hanjun Guo
2013-12-03 16:51 ` One Thousand Gnomes
2013-12-03 17:02 ` Matthew Garrett
2013-12-04 14:16 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64 Hanjun Guo
2013-12-03 16:53 ` One Thousand Gnomes
2013-12-04 14:17 ` Hanjun Guo
2013-12-03 17:12 ` Rob Herring
2013-12-04 14:30 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file Hanjun Guo
2013-12-03 18:03 ` Mark Rutland
2013-12-04 15:48 ` Hanjun Guo
2013-12-04 5:46 ` Zheng, Lv
2013-12-04 15:53 ` Hanjun Guo
2013-12-04 19:47 ` Al Stone
2013-12-05 3:38 ` Arnd Bergmann
2013-12-05 13:51 ` Hanjun Guo
2013-12-05 20:40 ` Arnd Bergmann
2013-12-05 14:09 ` Rob Herring
2013-12-05 14:27 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 6/7] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 7/7] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2013-12-04 10:10 ` Graeme Gregory
2013-12-04 15:55 ` Hanjun Guo
2013-12-05 22:25 ` [RFC part1 PATCH 0/7] Make ACPI core running on ARM64 Arnd Bergmann
2013-12-06 13:58 ` Mark Brown
2013-12-08 2:44 ` Arnd Bergmann
2013-12-08 19:40 ` Mark Brown [this message]
2013-12-10 9:45 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131208194040.GN29268@sirena.org.uk \
--to=broonie@kernel.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=jonathan@jonmasters.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mjg59@srcf.ucam.org \
--cc=olof@lixom.net \
--cc=patches@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=rob.herring@calxeda.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®