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

[Mark Brown <broonie@kernel.org>]

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

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:

> > 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.

> Which people do you mean?

Systems integrators in the embedded space, I'm mostly thinking from the
perspective of people who make consumer electronics but the issues apply
in other embedded sitautions.

> It is clear that for ACPI to be a viable mechanism in the embedded
> space, we need the ability to add additional device descriptions beyond
> what ships in the firmware on the board. We could stick with the old
> monolithic model by enabling people to easily rebuild the firmware
> (something I personally think we need to do anyway), but just because
> people *can* rebuild the firmware, doesn't mean they are going to want
> to! Alternatively, tooling could be provided to modify these tables

Right, and there are frequently process issues which make it difficult
to do this - in larger organisations the firmware may well be maintained
by a different team to the kernel team which can make getting changes
done harder for non-technical resons.

> > 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.

> We can determine which method is used based on which device struct
> pointers are populated.

Not at present - we can tell if we are running on ACPI but that's not
the issue.

> > 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.

> From the ACPI side of things at least, we've definitely been thinking
> more broadly than that. In fact the kernel interface, like the one Arnd
> mentioned which happens to be the same thing Rafael and I have
> suggested, is intended to solve a problem we are seeing in industry
> where we can't reuse drivers on ACPI platforms without a lot of driver
> development. The new API is intended to minimize that effort.

I'm surprised it's a *lot* of development TBH - or rather that the hard
bit is not mostly putting new back ends on existing APIs.

> There's more... but rather than just dump here... could you elaborate on
> your concerns here? Are there some specific things we might be
> overlooking - would like to hear your thoughts as I agree, this is
> bigger than the kernel changes.

The most immediate thing is if the tooling around ACPI based systems is
going to be able to support people providing configuration to the system
without undule pain, otherwise it becomes more likely that people won't
use the new infrastructure.

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.  This may end up being
nothing to worry about, hopefully it is, but right now as a driver
author I'd expect to approach things differently with a different
firmware.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]