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&gt; wrote: >Hi Rafael > >Thanks for sending this out. A lot of work has gone into this. >I have some comments below. > >Cheers > >Charles 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" <rafael.j.wysocki(a)intel.com&gt; >wrote: ... >> 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 >>associated >> with it. That can be a PNP or ACPI device ID, a device ID that >>can >> 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 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. 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. Thanks! -- Darren Hart Intel Open Source Technology Center

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&gt; wrote: >Hi Rafael > >Thanks for sending this out. A lot of work has gone into this. >I have some comments below. > >Cheers > >Charles 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" <rafael.j.wysocki(a)intel.com&gt; >wrote: ... >> 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 >>associated >> with it. That can be a PNP or ACPI device ID, a device ID that >>can >> 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 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.

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. Thanks!

-- Darren Hart Intel Open Source Technology Center

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&gt; wrote: >On 12/11/15, 9:22 AM, "DSD on behalf of Charles Garcia-Tobin" &gt;&lt;dsd-bounces(a)acpica.org on behalf of charles.garcia-tobin(a)arm.com&gt; wrote: > >>Hi Rafael >> >>Thanks for sending this out. A lot of work has gone into this. >>I have some comments below. >> >>Cheers >> >>Charles > >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" <rafael.j.wysocki(a)intel.com&gt; >>wrote: >... >>> 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 >>>associated >>> with it. That can be a PNP or ACPI device ID, a device ID that >>>can >>> 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. 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. Got it. > >>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. Agreed > >>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. > >Thanks! Cheers Charles > >-- >Darren Hart >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.

Hi Darren On 12/01/2016 23:24, "Hart, Darren" <darren.hart(a)intel.com&gt; wrote: > On 1/6/16, 2:13 PM, "Charles Garcia-Tobin" <charles.garcia-tobin(a)arm.com&gt; > wrote: > > >> 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 way? I am definitely agreed with scope :-) What I was really trying to request in section 3.2 is that instead of saying: "… That can be a PNP or ACPI device ID, a device ID that can 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 …" The txt read: "… That can be a PNP or ACPI device ID, a device ID that can be returned by the ACPI _CID object, a PCI Class Code that can be returned by the ACPI _CLS object, or generally any *ACPI compliant device identification method* that can be used by the Operating System to find a matching driver for the device …"

This however is all motivated by the PRP0001 issue. So we probably ought to get to the bottom of that. What would be a good forum to discuss that? Is worth organising a call? Other than that, my original reply to the posting had some very minor suggestions including: 1. An example of a property with it’s full path. This is just because the reading of the directory structure is long, as it’s a deep one, and so an example would help beat confusion. 2. nit: s/“slash”/“forward slash”/ 3. I suggested slightly clearly language around abstract property sets. Have a good one Charles > -- > Darren > >> On 16/12/2015 23:32, "Hart, Darren" <darren.hart(a)intel.com&gt; 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&gt; >>> wrote: >>> >>>> Hi Rafael >>>> >>>> Thanks for sending this out. A lot of work has gone into this. >>>> I have some comments below. >>>> >>>> Cheers >>>> >>>> Charles >>> 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" <rafael.j.wysocki(a)intel.com&gt; >>>> wrote: >>> ... >>>>> 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 >>>>> associated >>>>> with it. That can be a PNP or ACPI device ID, a device ID >>>>> that >>>>> can >>>>> 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. >> 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. >> Got it. >> >>>> 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. >> Agreed >> >>>> 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. >>> >>> Thanks! >> Cheers >> >> Charles >> >> >>> -- >>> Darren Hart >>> 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. >> 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.

Hi Rafael On 13/01/2016 23:32, "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com&gt; wrote: > On 1/13/2016 5:42 PM, Charles Garcia-Tobin wrote: >> Hi Darren >> >> On 12/01/2016 23:24, "Hart, Darren" <darren.hart(a)intel.com&gt; wrote: >> >>> On 1/6/16, 2:13 PM, "Charles Garcia-Tobin" >>> <charles.garcia-tobin(a)arm.com&gt; >>> wrote: >>> >>> >>>> 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 way? >> I am definitely agreed with scope :-) >> >> What I was really trying to request in section 3.2 is that instead of >> saying: >> >> "… That can be a PNP or ACPI device ID, a device ID that can 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 …" >> >> The txt read: >> >> "… That can be a PNP or ACPI device ID, a device ID that can be returned >> by the ACPI _CID object, a PCI Class Code that can be >> returned by the ACPI _CLS object, or generally any *ACPI compliant >> device >> identification method* that can be used by the Operating System to find >> a >> matching driver for the device …" > So question here: Are PCI device IDs regarded as an "ACPI compliant > device identification method"? Or USB device IDs? Or device IDs in any > other bus that ACPI may be used with for that matter? > > The original language may be a bit ambiguous, though, when I'm thinking > about it now. > > Maybe something like "a device ID sufficient for finding a matching > driver for the device by an Operating System" would be better? [Note > that the "an" is on purpose, as it shouldn't matter which OS this is > referring to.] The PCI thing is fair point, the “an” thing helps too. Any thoughts on where we should discuss the PRP thing? That’s the big one. Would a call make sense?

>> This however is all motivated by the PRP0001 issue. So we probably ought >> to get to the bottom of that. What would be a good forum to discuss >> that? >> Is worth organising a call? >> >> Other than that, my original reply to the posting had some very minor >> suggestions including: >> >> >> 1. An example of a property with it’s full path. This is just because >> the >> reading of the directory structure is long, as it’s a deep one, and so >> an >> example would help beat confusion. >> 2. nit: s/“slash”/“forward slash”/ >> 3. I suggested slightly clearly language around abstract property sets. >> >> Have a good one >> >> Charles >> >> >>> -- >>> Darren >>> >>>> On 16/12/2015 23:32, "Hart, Darren" <darren.hart(a)intel.com&gt; 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&gt; >>>>> wrote: >>>>> >>>>>> Hi Rafael >>>>>> >>>>>> Thanks for sending this out. A lot of work has gone into this. >>>>>> I have some comments below. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Charles >>>>> 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" >>>>>> <rafael.j.wysocki(a)intel.com&gt; >>>>>> wrote: >>>>> ... >>>>>>> 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 >>>>>>> associated >>>>>>> with it. That can be a PNP or ACPI device ID, a device ID >>>>>>> that >>>>>>> can >>>>>>> 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. >>>> 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. >>>> Got it. >>>> >>>>>> 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. >>>> Agreed >>>> >>>>>> 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. >>>>> >>>>> Thanks! >>>> Cheers >>>> >>>> Charles >>>> >>>> >>>>> -- >>>>> Darren Hart >>>>> 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. >>>> >> 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. >> 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.