On Sun, 21 Sep 2014, Rafael J. Wysocki wrote:

On Tuesday, September 16, 2014 02:52:31 PM Mika Westerberg wrote:

quoted

This is a second revision of the patches first submitted here [1].

The recent publication of the ACPI 5.1 specification [2] adds a reserved name
for Device Specific Data (_DSD, Section 6.2.5). This mechanism allows for
passing arbitrary hardware description data to the OS. The exact format of the
_DSD data is specific to the UUID paired with it [3].   

An ACPI Device Properties UUID has been defined [4] to provide a format
compatible with existing device tree schemas. The purpose for this was to
allow for the reuse of the existing schemas and encourage the development
of firmware agnostic device drivers.

This series accomplishes the following (as well as some other dependencies):

 * Add _DSD support to the ACPI core
   This simply reads the UUID and the accompanying Package

 * Add ACPI Device Properties _DSD format support
   This understands the hierarchical key:value pair structure
   defined by the Device Properties UUID

 * Add a unified device properties API with ACPI and OF backends
   This provides for the firmware agnostic device properties
   Interface to be used by drivers

 * Provides 3 example drivers that were previously Device Tree aware that
   can now be used with either Device Tree or ACPI Device Properties. The
   drivers use "PRP0001" as their _HID which means that the match should be
   done using driver's .of_match_table instead.

The patch series has been tested on Minnoboard and Minnowboard MAX and the
relevant part of DSDTs are at the end of this cover letter.

This series does not provide for a means to append to a system DSDT. That
will ultimately be required to make the most effective use of the _DSD
mechanism. Work is underway on that as a separate effort.

Most important changes to the previous RFC version:

  * Added wrapper functions for most used property types
  * Return -EOVERFLOW in case integer would not fit to a type
  * Dropped dev_prop_ops
  * We now have dev_node_xxx() functions to access firmware node
    properties without dev pointer
  * The accessor function names try to be close to their corresponding of_*
    counterpart
  * Tried to have a bit better examples in the documentation patch
  * gpiolib got support for _DSD and also it now understand firmware node
    properties with dev_node_get_named_gpiod() that requests the GPIO
    properly.
  * Support for "PRP0001" _HID/_CID. This means that the match should be
    done using driver .of_match_table instead.
  * Add unified property support for at25 SPI eeprom driver as well.

[1] https://lkml.org/lkml/2014/8/17/10
[2] http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf
[3] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[4] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

Aaron Lu (2):
  input: gpio_keys_polled - Add support for GPIO descriptors
  input: gpio_keys_polled - Make use of device property API

Max Eliaser (2):
  leds: leds-gpio: Make use of device property API
  leds: leds-gpio: Add ACPI probing support

Mika Westerberg (11):
  ACPI: Add support for device specific properties
  ACPI: Allow drivers to match using Device Tree compatible property
  ACPI: Document ACPI device specific properties
  mfd: Add ACPI support
  gpio / ACPI: Add support for _DSD device properties
  gpio: Add support for unified device properties interface
  gpio: sch: Consolidate core and resume banks
  leds: leds-gpio: Add support for GPIO descriptors
  input: gpio_keys_polled - Add ACPI probing support
  misc: at25: Make use of device property API
  misc: at25: Add ACPI probing support

Given the ACKs that we've got already (the Greg's one in particular) and
the apparent lack of objections (or indeed any comments at all), I'm about
to queue this up for 3.18 next week.

I'd prefer to take the MFD patch through the MFD tree if that's
possible.  Are there any technical reasons why this would prove
difficult?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog