[Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Arnd Bergmann]

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:
> >> On Monday, May 05, 2014 06:45:28 PM Benjamin Herrenschmidt wrote:
> >>> On Sun, 2014-05-04 at 14:28 +0200, Rafael J. Wysocki wrote:
> >>> Only for standardized resource types, such as mmio ranges or interrupts.
> >>> Anything else is absolutely in the domain of competence of the driver
> >>> and I would argue *only* in the domain of competence of the driver.
> >>
> >> But why can't we treat DT bindings as a standard?
> >
> > 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.

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.

	Arnd