public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Steve Capper <steve.capper@linaro.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64
Date: Thu, 31 Mar 2016 08:28:54 -0700	[thread overview]
Message-ID: <20160331152854.GA2350@sirena.org.uk> (raw)
In-Reply-To: <20160331123649.GE18910@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On Thu, Mar 31, 2016 at 01:36:50PM +0100, Will Deacon wrote:

> I'm unsure about whether or not we want 'default y' here, but I'd like

I can easily do followup patches which change that to be "default y if
!ARM64" (or default y if $OTHER_ARCHES) and adding CONFIG_ACPI to
defconfig (for the test coverage) if that helps?  I think that's
perfectly reasonable.  As Ard says if both DT and ACPI are built in then
the kernel will continue to prefer DT if it finds one.

> to wait for Catalin to come back from his 2-week holiday before going
> anywhere with this patch. It's only fair that his opinion should be
> taken into account, and there's not a huge rush for this. I do consider

It definitely makes sense to get Catalin's input.  I do think that this
is something we don't want to defer indefinitely though, I think we're
hurting ourselves more than we're helping.

> "ACPI-only platforms" as simply "platforms without a .dtb" (modulo
> any significant AML code) and therefore don't view this as a blocking
> issue.

I think people with a system with no DT provided might disagree on that
one, and that this isn't really about end users or even distros but
rather about the people working upstream and especially doing test and
QA work upstream.

> We should also take into account the large amount of ongoing ACPI work
> (e.g. the DSD and PRP0001 saga, PCI and IORT support, virtualisation work,
> etc), and decide whether or not that's currently in a state where we want
> to encourage people to start using this in their arm64 kernels.

My perception is that the EXPERT dependency is not having a meaningful
impact on people who want to use ACPI, they're just going ahead and
doing it anyway and expecting that distros will ship kernels which
enable ACPI (which realistically the ones that don't currently are going
to do as they start encountering these platforms).  There doesn't seem
to be much sign that decisions about shipping systems are being guided
by this and the work that's happening on ACPI is going on regardless,
some of it x86 focused.

The kernel will still continue to prefer DT on arm64 systems so it's
still the default upstream.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2016-03-31 15:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 17:58 [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64 Mark Brown
2016-03-30 18:02 ` G Gregory
2016-03-30 19:25 ` Ard Biesheuvel
2016-03-30 19:35 ` Al Stone
2016-03-31  3:44 ` Hanjun Guo
2016-03-31 12:04   ` Rafael J. Wysocki
2016-03-31 12:36     ` Will Deacon
2016-03-31 12:47       ` Rafael J. Wysocki
2016-03-31 13:20       ` Ard Biesheuvel
2016-03-31 13:38         ` Will Deacon
2016-03-31 14:48           ` Ard Biesheuvel
2016-03-31 16:39             ` Mark Brown
2016-03-31 15:28       ` Mark Brown [this message]
2016-04-12 17:23 ` Catalin Marinas
2016-04-13  5:25   ` Mark Brown
2016-04-13  8:51     ` Catalin Marinas
2016-04-13 12:49       ` Mark Brown
2016-04-14 18:02   ` Olof Johansson
2016-04-14 18:25     ` Mark Brown
2016-04-14 18:49       ` Olof Johansson
2016-04-14 18:56         ` Mark Brown

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=20160331152854.GA2350@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=graeme.gregory@linaro.org \
    --cc=guohanjun@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=steve.capper@linaro.org \
    --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