On Fri, May 16, 2014 at 11:52:22PM -0700, Darren Vincent Hart wrote:
> On Sat, 2014-05-17 at 14:09 +0100, Mark Brown wrote:
> > On Fri, May 16, 2014 at 08:57:59PM -0700, Darren Vincent Hart wrote:
> > > On Tue, 2014-05-13 at 13:11 +0100, Mark Brown wrote:

> Can you elaborate on the issues you're trying to call out regarding
> active versus passive ACPI?

As far as I can tell a big part of what people see themselves getting
from ACPI is the ability to use the executable methods to handle
hardware updates without software updates, including things you can't do
by just changing the data you supply to the system.  Device drivers can
do things to play nicely with this, such as assuming that configuration
in the device when they start is sane and should be preserved unless
they know what they're doing, but in a data only model it's generally
safer to just discard any such configuration and get the hardware into a
known good state by resetting it or similar (this is the most common
pattern that has a practical impact which I'm aware of).  Things like
configuring the features on a new variant of a device for example, or
turning on a previously unsupported feature.

In the embedded case it's generally relatively straightforward to add a
new property, add the code to handle it and rebuild the world.  If
updating the OS isn't an option that gets a lot more tricky and doing
things via firmware methods more sensible.

> At the individual driver level, it is trivial. However, there are
> thousands of drivers, and as we discussed above, many of the integrators
> of these things don't do any driver development. Making those drivers
> available to ACPI based platforms then becomes a large task in
> aggregate.

> The property abstraction layer being discussed is aimed at making that
> aggregate task as small as possible - partly via new backends as you
> describe.

OK, but then can't ACPI just present via the OF APIs rather than
requiring us to go and search and replace all the property parsing code?

> > The thing I'm less clear on is if there are going to be problems down
> > the line with people trying to do things that they currently do with
> > ACPI like hide details of new board versions causing conflicts with code
> > that assumes the firmware is just providing data.

> OK, this goes back to your concerns on active/passive ACPI I guess?

Yes.

> I believe our best weapon against (new) nasty firmware hacks is to
> provide a flexible mechanism with excellent documentation and examples
> that make it easier to follow them than to contrive some gross
> workaround.

> In the past, this is something that ACPI has been lacking. When I first
> started looking into this, I kept asking for a Manual, and all I would
> get was a Specification.

> As part of the ACPI properties update to the specification, we are also
> preparing independent documentation for how to use it.

That should help, though obviously documentation is not always consulted
with the frequency and dilligency that one may desire (and to be fair
it's not always very discoverable).  However a part of my worry is that
given what at least some people are trying to achieve the things they
get up to aren't that tasteless, they just happen to have different aims
and use cases to the embedded one.