On Tue, May 13, 2014 at 09:34:35AM +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 00:03:42 Rafael J. Wysocki wrote:
> > On 5/12/2014 11:59 PM, Mark Brown wrote:
> > > On Tue, May 06, 2014 at 02:22:15PM +0200, Rafael J. Wysocki wrote:

> > > Aside from the whole question of people bothering to pay attention to
> > > the specs when writing their BIOSs DTs (as used in modern systems) and
> > > ACPI have quite different models for what should be handled where - FDT
> > > is pure data and expects the kernel to do everything while ACPI expects
> > > to be used with active firmware.

> > While in practice ACPI is used on systems with active firmware usually, 
> > there's no expectation like this in ACPI itself in principle.

> Right. Open Firmware already has multiple ways of running code from the
> firmware (client calls, RTAS, FCODE, ...), which are used all the time,
> but we intentionally chose to not allow them for embedded systems with
> the FDT subset.

I wouldn't say they're used all the time these days - the platforms with
runtime OF aren't terribly active any more and don't have much overlap
with other systems.

> It should be entirely possible and reasonable to do the same thing for
> ACPI on embedded systems. I believe this is what SFI attempted to
> do, but that seems to have been discarded for some reason.

SFI didn't provide any way of giving data to devices other than
registering them which meant that it ended up with the pain of firmware
based device registration requring firmware updates to get the device
present being combined with the need for board files to actually get the
devices to do anything useful.  On the bright side this got around the
fact that in my experience the firmware was frequently not modifiable by
people directly working on Linux.

This might be another issue for the model where we treat ACPI as DT.
One of the things that makes the DT model workable in the embedded case
is that most of the time as far as the rest of the system is concerned
the DT is essentially part of the kernel - it's built from the same tree
and so on.  If ACPI goes the same way for embedded systems that'd work
just as well but that's obviously not how ACPI has historically been
done and if systems end up being built like they have been that might
not make people happy.  One of the things that active firmware is doing
is decoupling the firmware from the kernel which is a real and useful
benefit in many embedded situations, otherwise you just end up either
doing board quirks or just hacking things to be system specific in code.

There's also the possibility that the driver is going to have to figure
out at runtime if it's on a system with active ACPI or a system with
passsive ACPI, though I expect we can just do something like check what
properties are there for that assuming people don't end up doing
mix'n'match type things.  People are interested in ACPI for embedded
cases outside of x86 to a large extent so that they don't have to deal
with two different firmware interfaces if they also work on the server
cases.

I'm worried that there's more to the model for using a given firmware
interface than just the in kernel API but we're only thinking about
what's convenient in kernel here.