On Tuesday, February 10, 2015 11:59:32 AM Mika Westerberg wrote:

On Mon, Feb 09, 2015 at 09:02:11PM +0000, Suthikulpanit, Suravee wrote:

quoted

On 2/9/15, 19:15, "Mika Westerberg" [off-list ref]
wrote:

quoted

On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:

quoted

On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:

quoted

Device drivers typically use ACPI _HIDs/_CIDs listed in struct

device_driver

quoted

acpi_match_table to match devices. However, for generic drivers, we do
not want to list _HID for all supported devices, and some device

classes

quoted

do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface).

This patch adds support for matching ACPI devices using the _CLS

method.

quoted

Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>

Greg, Mika, any problems with this?

Is there some specific reason why this cannot be done in similar way
than PCI already does?

In other words, stuff _CLS fields to struct acpi_device_id and make
match functions match against those if they are != 0.

That was my original thought. Then I realized that the acpi_device_id is
used
to create the device matching table, in which could contain several
_HID/_CID.
However, most of the added _CLS field would likely ended up being unused
and
taking up space.

Well, PCI is doing that already :)

quoted

In contrast to _HID/_CID, a driver is likely to match just a single _CLS.
So, I think it is cleaner to have just a dedicate struct acpi_device_cls,
and 
a matching function for it.

IMHO cleaner version is the one following PCI.

I agree.

Besides, how do you support modules with this? Or did I miss something?

Good question.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.