On 1/6/16, 2:13 PM, "Charles Garcia-Tobin" <charles.garcia-tobin(a)arm.com>
Hi Darren et al
Sorry also for delay, just getting back from Xmas hiatus and still have
much to catch up with.
Here are some thoughts on your comments
Thank you Charles!
It sounds like we are in mutual agreement on the scope of this document. I understand you
have reservations about PRP0001, but considering that to be a separate topic, is there any
specific point or concern with this document that you would like to see changed in some
On 16/12/2015 23:32, "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 charles.garcia-tobin(a)arm.com> wrote:
>>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
>>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
>>> returned by the ACPI _CLS object, or generally a device ID that
>>> can be used by an Operating System to find a matching driver
>>> 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.
I guess my concern with PRP0001 is that AFAIKS it has never been formally
agreed, and therefore exists as concept in one kernel only and is not a
standard thing. But perhaps that’s discussion we could have elsewhere.
>>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 change.
>>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 OS driver.
>>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.
OK I wasn’t at the summit, but I’ll chat with other folk in ARM to see the
feeling here. However to date when we have talked about it, PRP00001 has
caused a lot of concern precisely because of the concern stated above.
>All that said, PRP0001 is a separate issue from the database.
Agreed. Happy to discuss elsewhere
>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
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may
also be privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.