On 4/24/15, 21:28, "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> wrote: >On Friday, April 24, 2015 04:08:31 PM Suravee Suthikulpanit wrote: >> On 4/16/15 20:45, Zheng, Lv wrote: >> > Before back porting this to ACPICA, let me ask one simple question. >> > According to the spec, the _CLS is optional and PCI specific. >> > So why should we implement it in ACPICA core not OSPM specific >>modules? >> > If this need to be implemented in ACPICA, then what about the >>following device identification objects? >> > _DDN, _HRV, _MLS, _PLD, _STR, _SUN >> > >> > Thanks and best regards >> > -Lv >> >> Hi, >> >> Sorry for late reply. As for the justification for introducing the _CLS >> support in the ACPICA, this is mainly because ACPI does not currently >> define _CID for certain device classes, which used to mostly be PCI >> devices. Instead, ACPI spec mentioned that _CLS can be used for loading >> generic drivers on hardware that is compatible with PCI-defined device >> classes, but that is not implemented on the PCI bus (and is therefore >> enumerated by ACPI.) > >I think it would be good to point to the particular part of the spec >making that provision. In what section is that mentioned, exactly? Here is the copied from section 6.1.3 _CLS (Class Code) from ACPI 5.1 spec: "This object is used to supply OSPM with the PCI-defined class, subclass and programming interface for a device. This object is optional but may be useful for generic drivers written for PCI devices that move off of PCI and are enumerated by ACPI.² Otherwise, if the community think it¹s better to not putting the _CLS the _CLS parsing code in ACPICA since, I can try looking into pulling the code out of ACPICA. I also noticed a little issue in the patch series where the ACPI_VALID_CLS is used in the patch 1 but defined in patch 2. I can send out v9 with the fix once we agree on the _CLS parsing. Thanks, Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
