Re: [PATCH] ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64

[Mark Brown <broonie@kernel.org>]

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

On Thu, Mar 31, 2016 at 04:48:44PM +0200, Ard Biesheuvel wrote:
> On 31 March 2016 at 15:38, Will Deacon <will.deacon@arm.com> wrote:

> > I'd really like to get away from the concept of ACPI-only systems. Would
> > we reject a .dtb contribution for such a machine?

> Absolutely not, and I expect such contributions will appear sooner
> rather than later.

> But the point of ACPI is the abstraction, and the ridiculous churn in
> DTB's carried in mainline clearly shows the need for that*. So there
> will be ACPI-only systems because the drivers are coded against the
> abstracted interface, and DT is simply not a drop-in replacement in
> that case.

It's also worth remembering that just because we have a DT in tree that
doesn't mean that people running actual systems are going to use it.
For some systems there will be a user community that wants to do that
but that won't be universal, there are going to be people who just use
the default firmware.

> > I understand that, but I still think that removing the dependency on
> > EXPERT is indicative of saying "this stuff is good to be used by the
> > masses", irrespective of a cmdline option. Maybe that's true, but it's
> > not immediately obvious to me, with all the patches in flight.

> Well, we are not cc'ing to stable, are we? Or do you think the current
> stuff is so broken that we should even protect users of the upstream
> HEAD branch against it?

Like I said in the other mail I'm also just not sure that this is
something that people deciding what firmware to ship on their systems
are paying much attention to.  People are coming to their own assessment
based on their own testing and other factors.  Where I see this having
an impact is more on having the rest of the upstream community keeping
an eye on what the ACPI people are doing.

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