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
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
<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" <rafael.j.wysocki(a)intel.com>
>> 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
"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.