[fw-summit] Firmware Mini-Summit Minutes from 2015-09-22
ahs3 at redhat.com
Mon Oct 5 21:04:13 UTC 2015
ARM/ACPI Firmware Mini-Summit
Linaro Connect SFO15, Burlingame, CA, USA
22 Sept 2015
It was a short session, really. Holding this via Linaro Connect does present
some limitations, which held some of the attendance down (my apologies for the
lack of outside connectivity -- I did not plan for it properly). On the other
hand, it can be done inexpensively; until there is a better way, or some
funding organization, this will likely be what we can afford to do -- sporadic
gatherings when critical mass is attending the same event.
Current State of ACPI on ARMv8
The current state of ACPI on ARMv8 is reasonably good. Core support was first
upstreamed in Linux 4.1, with minor updates in 4.2. In order to round out and
mostly complete ACPI basics , the following features are in progress:
-- Hanjun, Suravee and Marc Z are working on getting GICv2m/GICv3 support,
which requires getting reworking irqdomain support, and self-probing for
irqchips and clocksources. There are a lot of moving pieces in flight
for these functions.
-- Lorenzo, Hanjun and Tomasz are working on the ACPI-based PCU support for
arm64, but first need to resolve how to handle mmconfig
For next steps, Ashwin will be looking at cpufreq, building on the work that
Sudeep has already started for cpuidle. Support for APEI  and IORT  will
also be forthcoming.
At that point, there's not much left to do. Obviously, kernel maintenance will
take time and effort; that is assumed. However, adding much ACPI functionality
beyond the items above requires feedback from Linaro members and the community
For example, the ACPI spec does a pretty decent job with thermal management.
It is not clear that anyone uses it; on the x86 side, this all seems to be
handled in SMM or other firmware. Is any ARM vendor interested in this?
Similarly for ECs (Embedded Controllers). Again, there is no requirement to
use the ACPI tables involved. On the x86 side, though, this functionality is
actively being used and improved. From a basic review of the code, there is
no reason it shouldn't just work on arm64, but does anyone care?
So, please tell Linaro if there is something needed from the ACPI spec. Call,
write or send carrier pigeons, just let us know.
_DSD and Device Properties
There is still a lot of discussion around using device properties properly.
And, some things that were supposed to happen did not. However, due to recent
LKML submissions, and efforts by Rafael, Charles and myself, we're trying to
get things in order.
The concrete work done so far is:
-- a mailing list, dsd at acpica.org, which we have started to use, and which
should be used for detailed discussions in the future
-- a small repository of documentation on _how_ to submit, approve, and use
device properties in a community approved manner (please see the files in
We do have clear agreement on the boundaries between the ASWG and the creators
and users of device properties. The bottom line is that ASWG has defined the
form of _DSD and device properties, but does not control their content. This
is where the community must step in.
For us, as the community, we need to define:
-- *what* is to be submitted,
-- *when* it is to be submitted,
-- *how* we are to approve or disapprove of what is submitted,
-- *who* approves or disapproves of what is submitted,
-- and *where* does one submit things?
For *where*, please use the dsd at acpica.org mailing list. That's why it was
For *when*, please submit device property descriptions before trying to put
them in a driver. We can make accommodations for descriptions discovered in
the wild, but we would rather have them up front.
A discussion has been started on *what*, *how* and *who* on dsd at acpica.org.
Updates are forthcoming. This author is trying to develop a formalism for
describing (and maintaining) device property descriptions, and Charles is
trying to document the processes for ACKs/NAKs, and both of us are getting
excellent feedback and contributions from Rafael. More voices are needed.
Other observations brought up during the discussion on this topic:
-- __DSD should *only* be used for specific devices, and never for general
frameworks (per Rafael at LinuxCon, but the majority agrees with this,
-- Even if properties are "non-standard", it's better that they are in
firmware than in .INF files, so they can be shared across OSs.
-- Perhaps the same sort of thing needs to be done for _DSM and _OSC;
there was debate on whether or not it's simply too late for these or
if there was value is capturing what we could now that the horse has
-- A logo program of some sort is probably the best way to get people to
do the right thing with _DSD device properties. The question is: who
would run this? how would it work?
-- One camp would like us to just re-use all of the DT bindings as is; the
other camp is just as adamantly opposed to re-use this way. Stay tuned.
Film at 11.
The IORT spec has been updated to SMMUv3. However, it still needs an update
to deal with NUMA systems. This will be worked on and released as soon as
SMMUv2 patches are currently under development and being verified on the
Thunder-X platform. ITS (for PCI MSI) patches are on-going and being updated
in accordance with Marc Z's irqdomain (domain token) support; the older version
has been tested on Thunder-X and is known to work.
We will continue to run sessions at each forthcoming Linaro Connect; if there
is interest (and travel budget), we may try to do something at either a UEFI
plugfest or Linux Plumbers, if the opportunity presents itself.
Dong Wei discussed some of the IP issues involved with the UEFI Forum providing
a mailing list and bugzilla instance for the group. Essentially, the question
is: does a BZ indicate any sort of liability, and if so, for whom? On the other
hand, a mailing list is probably sufficient for the near term. So, Dong will
see about setting that up and the fw-summit at l.l.o will likely migrate to a UEFI
provided public firmware mailing list.
Matthew Garret was kind enough to send out his promised document on Secure Boot:
Please review and comment.
Other TODO List Items
-- LuvOS is up and working for arm64; Linaro will be looking at developing more
testing specifically around SBSA/SBBR. Wiki pages at wiki.linaro.org have
 I.e., functionality common to all platforms, as differs from functionality
for a specific device.
 Current APEI can only be used and tested with correctable errors using GPIO
signalled events. Uncorrectable errors will require something similar to an
NMI (currently being worked on in ARM, with details likely later this year).
ACPI spec changes in 6.1 may allow us to simplify this functionality, also.
 IORT spec is available, and is currently undergoing an update to be released
Red Hat, Inc.
ahs3 at redhat.com
More information about the fw-summit