Happy New Year!
The end of December likely wasn't the most optimal time to solicit feedback and get a
discussion going :-)
Please allow me to bring this discussion back to your attention. Please review my response
below and let's see if we can pick up where we left off.
Intel Open Source Technology Center
On 12/16/15, 3:32 PM, "Hart, Darren" <darren.hart(a)intel.com> wrote:
On 12/11/15, 9:22 AM, "DSD on behalf of Charles
Garcia-Tobin" <dsd-bounces(a)acpica.org on behalf of
>Thanks for sending this out. A lot of work has gone into this.
>I have some comments below.
Hi Charles. Apologies for the delay. I wanted to comment on the Device ID requirement
specifically, inline below, and will respond to the other comments separately.
>On 08/12/2015 23:19, "Rafael J. Wysocki"
>> 3.2. Device ID Requirement
>> For every property set in the database, with the exception of
>> property sets created for the sole purpose of inheritance (see
>> Section 8.2 below), there must be at least one Device ID
>> with it. That can be a PNP or ACPI device ID, a device ID that
>> be returned by the ACPI _CID object, a PCI Class Code that can be
>> returned by the ACPI _CLS object, or generally a device ID that
>> can be used by an Operating System to find a matching driver for
>> the device. In any case, it must be well defined in a way that
>> is not OS-specific.
>So here I have concern. My understanding per ACPI spec is that you¹d use
>_HID, _CID and _CLS for this method. I am wondering if this text is here
>to allow binding driver using device tree¹s ³compatible" string. I find
>this worrying because:
The language above was chosen to ensure we comply with the ACPI specification and
requirements for a device ID.
PRP0001, as a separate topic, was proposed to address the compatible style binding in a
way that met those same requirements.
>1. Above we state how properties are going to be assigned to one Device
One "Device ID", not each physical instantiation of a device (or each model/part
number). Properties, in general, are useful because they can describe multiple variants of
a given type of device without requiring a new Device ID for each and every solitary
>2. We don¹t want to do generic properties, instead if a generic property
>was found we should promote creation of that to the ACPI spec.
I suppose that line can be interpreted in a number of ways. While we argued against
defining "Ethernet_MAC" in the absence of a Device ID to which it pertained, I
would expect something like a Foo Networks line of Ethernet NICs to potentially all work
from a single FOOXXXX ID with a defined set of properties with which to parameterize the
>Yet the ³compatible² if used in this way would be an example of a generic
>property, in as much as it applies to many devices. The PRP00001 kind of
>hides this, but actually promotes the very behaviours we were trying to
>avoid in creating these rules. In particular we only want to use DSD for
>properties that are not covered by the spec in any other way. Using
>compatible would just encourage folk to pull in whole DTs which in turn
>could pull in properties that do overlap with ACPI.
I share the objection to pulling in entire DTs containing conflicting properties. We have
attempted to address this through language in the document (3.3 immediately below) about
specific things which should not be included in properties. It's also probably worth
noting that the most problematic examples wouldn't actually work anyway, which is a
far better deterrent than the language in 3.3 :-)
As to something like PRP0001+compatible. The goal for this has always been to enable the
use of drivers for leaf-node devices like sensors on non-enumerable busses, gpio connected
things, etc, which already exist today and for which there has been unanimous preference
voiced (Kernel Summit 2014, from various architecture representatives) to not generate
hundreds of ACPI Ids, but to rather make them available in a firmware implementation
agnostic way. This is what drove the new device_properties API within the Linux kernel.
All that said, PRP0001 is a separate issue from the database. At most, I would expect to
see an entry for PRP0001 with a single entry "compatible=<matchterm>" in
the database, with a reference to known documentation for the matchterm sources, such as
the Linux DT documentation, with caveats for use as described above. This is not intended
to document best practice, but instead to be a practical approach to enabling that will
result in more consistent usage via a prescribed path than if we were to ignore this
reality and leave everyone to fend for themselves.
I'll respond to the organization topic separately.
Intel Open Source Technology Center