On 04/27/2015 03:38 PM, Rafael J. Wysocki wrote:
On Sunday, April 26, 2015 10:45:29 PM Suthikulpanit, Suravee wrote:
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."
OK, so the "move off of PCI" part should be understood as "something that
used to be on the PCI bus, but now may be included into an SoC directly
in which case it won't be a PCI device any more", right?
That's right. For example, the SATA controller is a good example for
this case. On most x86 platforms, they are often enumerated as PCI
devices. However, in the ARM64 SOC (e.g. on AMD Seattle), it could be
enumerated as non-PCI device.
Thanks,
Suravee
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.
To me that pretty much depends on the answer to the above question.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
