This patch series introduce ACPI support for non-PCI AHCI platform driver.
Existing ACPI support for AHCI assumes the device controller is a PCI device.
Also, since there is no ACPI _HID/_CID for generic AHCI controller, the driver
could not use them for matching devices. Therefore, this patch introduces
a mechanism for drivers to match devices using ACPI _CLS method.
This patch series is rebased from and tested with:
http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v8
This topic was discussed earlier here (as part of introducing support for
AMD Seattle SATA controller):
http://marc.info/?l=linux-arm-kernel&m=141083492521584&w=2
Changes from V2 (https://lkml.org/lkml/2015/1/5/662)
* Update with review comment from Rafael in patch 1/2
* Rebased and tested with acpi-5.1-v8
Changes from V1 (https://lkml.org/lkml/2014/12/19/345)
* Rebased to 3.19.0-rc2
* Change from acpi_cls in device_driver to acpi_match_cls (Hanjun comment)
* Change the matching logic in acpi_driver_match_device() due to the new
special PRP0001 _HID.
* Simplify the return type of acpi_match_device_cls() to boolean.
Changes from RFC (https://lkml.org/lkml/2014/12/17/446)
* Remove #ifdef and make non-ACPI version of the acpi_match_device_cls
as inline. (per Arnd)
* Simplify logic to retrieve and evaluate _CLS handle. (per Hanjun)
Suravee Suthikulpanit (2):
ACPI / scan: Add support for ACPI _CLS device matching
ata: ahci_platform: Add ACPI _CLS matching
drivers/acpi/scan.c | 75 +++++++++++++++++++++++++++++++++++++++--
drivers/ata/Kconfig | 2 +-
drivers/ata/ahci_platform.c | 3 ++
include/acpi/acnames.h | 1 +
include/linux/acpi.h | 10 ++++++
include/linux/device.h | 1 +
include/linux/mod_devicetable.h | 6 ++++
7 files changed, 94 insertions(+), 4 deletions(-)
--
2.1.0
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
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
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.
Signed-off-by: Suravee Suthikulpanit <[email protected]>
---
drivers/acpi/scan.c | 75 +++++++++++++++++++++++++++++++++++++++--
include/acpi/acnames.h | 1 +
include/linux/acpi.h | 10 ++++++
include/linux/device.h | 1 +
include/linux/mod_devicetable.h | 6 ++++
5 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index dc4d896..0579395 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -987,13 +987,82 @@ static bool acpi_of_driver_match_device(struct device *dev,
bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv)
{
- if (!drv->acpi_match_table)
- return acpi_of_driver_match_device(dev, drv);
+ bool ret = false;
- return !!acpi_match_device(drv->acpi_match_table, dev);
+ if (drv->acpi_match_table)
+ ret = !!acpi_match_device(drv->acpi_match_table, dev);
+
+ /* Next, try to match with special "PRP0001" _HID */
+ if (!ret && drv->of_match_table)
+ ret = acpi_of_driver_match_device(dev, drv);
+
+ /* Next, try to match with PCI-defined class-code */
+ if (!ret && drv->acpi_match_cls)
+ ret = acpi_match_device_cls(drv->acpi_match_cls, dev);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(acpi_driver_match_device);
+/**
+ * acpi_match_device_cls - Match a struct device against a ACPI _CLS method
+ * @dev_cls: A pointer to struct acpi_device_cls object to match against.
+ * @dev: The ACPI device structure to match.
+ *
+ * Check if @dev has a valid ACPI and _CLS handle. If there is a
+ * struct acpi_device_cls object for that handle, use that object to match
+ * against the given struct acpi_device_cls object.
+ *
+ * Return true on success or false on failure.
+ */
+bool acpi_match_device_cls(const struct acpi_device_cls *dev_cls,
+ const struct device *dev)
+{
+ acpi_status status;
+ union acpi_object *pkg;
+ struct acpi_device_cls cls;
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer format = { sizeof("NNN"), "NNN" };
+ struct acpi_buffer state = { 0, NULL };
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+
+ if (!adev || !adev->status.present || !dev_cls)
+ return false;
+
+ status = acpi_evaluate_object(adev->handle, METHOD_NAME__CLS,
+ NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ /**
+ * Note:
+ * ACPIv5.1 defines the package to contain 3 integers for
+ * Base-Class code, Sub-Class code, and Programming Interface code.
+ */
+ pkg = buffer.pointer;
+ if (!pkg ||
+ (pkg->type != ACPI_TYPE_PACKAGE) ||
+ (pkg->package.count != 3)) {
+ dev_dbg(&adev->dev, "Invalid _CLS data\n");
+ goto out;
+ }
+
+ state.length = sizeof(struct acpi_device_cls);
+ state.pointer = &cls;
+
+ status = acpi_extract_package(pkg, &format, &state);
+ if (ACPI_FAILURE(status))
+ goto out;
+
+ return (dev_cls->base_class == cls.base_class &&
+ dev_cls->sub_class == cls.sub_class &&
+ dev_cls->prog_interface == cls.prog_interface);
+out:
+ kfree(pkg);
+ return false;
+}
+EXPORT_SYMBOL_GPL(acpi_match_device_cls);
+
static void acpi_free_power_resources_lists(struct acpi_device *device)
{
int i;
diff --git a/include/acpi/acnames.h b/include/acpi/acnames.h
index 7461327..22332a6 100644
--- a/include/acpi/acnames.h
+++ b/include/acpi/acnames.h
@@ -51,6 +51,7 @@
#define METHOD_NAME__BBN "_BBN"
#define METHOD_NAME__CBA "_CBA"
#define METHOD_NAME__CID "_CID"
+#define METHOD_NAME__CLS "_CLS"
#define METHOD_NAME__CRS "_CRS"
#define METHOD_NAME__DDN "_DDN"
#define METHOD_NAME__HID "_HID"
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 536991b..9a01d5d 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -442,6 +442,10 @@ const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
extern bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv);
+
+bool acpi_match_device_cls(const struct acpi_device_cls *dev_cls,
+ const struct device *dev);
+
int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
int acpi_device_modalias(struct device *, char *, int);
void acpi_walk_dep_device_list(acpi_handle handle);
@@ -542,6 +546,12 @@ static inline const struct acpi_device_id *acpi_match_device(
return NULL;
}
+static inline bool acpi_match_device_cls(const struct acpi_device_cls *dev_cls,
+ const struct device *dev)
+{
+ return false;
+}
+
static inline bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv)
{
diff --git a/include/linux/device.h b/include/linux/device.h
index fb50673..8e259c5c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -237,6 +237,7 @@ struct device_driver {
const struct of_device_id *of_match_table;
const struct acpi_device_id *acpi_match_table;
+ const struct acpi_device_cls *acpi_match_cls;
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 745def8..cf0e0d198 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -191,6 +191,12 @@ struct acpi_device_id {
kernel_ulong_t driver_data;
};
+struct acpi_device_cls {
+ kernel_ulong_t base_class;
+ kernel_ulong_t sub_class;
+ kernel_ulong_t prog_interface;
+};
+
#define PNP_ID_LEN 8
#define PNP_MAX_DEVICES 8
--
2.1.0
This patch adds ACPI supports for AHCI platform driver, which uses _CLS
method to match the device.
The following is an example of ASL structure in DSDT for a SATA controller,
which contains _CLS package to be matched by the ahci_platform driver:
Device (AHC0) // AHCI Controller
{
Name(_HID, "AMDI0600")
Name (_CCA, 1)
Name (_CLS, Package (3)
{
0x01, // Base Class: Mass Storage
0x06, // Sub-Class: serial ATA
0x01, // Interface: AHCI
})
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite, 0xE0300000, 0x00010000)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,,,) { 387 }
})
}
Also, since ATA driver should not require PCI support for ATA_ACPI,
this patch removes dependency in the driver/ata/Kconfig.
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Suravee Suthikulpanit <[email protected]>
---
drivers/ata/Kconfig | 2 +-
drivers/ata/ahci_platform.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 5f60155..50305e3 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -48,7 +48,7 @@ config ATA_VERBOSE_ERROR
config ATA_ACPI
bool "ATA ACPI Support"
- depends on ACPI && PCI
+ depends on ACPI
default y
help
This option adds support for ATA-related ACPI objects.
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 18d5398..ae66974 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -71,12 +71,15 @@ static const struct of_device_id ahci_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
+static const struct acpi_device_cls ahci_cls = {0x01, 0x06, 0x01};
+
static struct platform_driver ahci_driver = {
.probe = ahci_probe,
.remove = ata_platform_remove_one,
.driver = {
.name = "ahci",
.of_match_table = ahci_of_match,
+ .acpi_match_cls = &ahci_cls,
.pm = &ahci_pm_ops,
},
};
--
2.1.0
On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:
> Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
> 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
> 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.
>
> Signed-off-by: Suravee Suthikulpanit <[email protected]>
Greg, Mika, any problems with this?
> ---
> drivers/acpi/scan.c | 75 +++++++++++++++++++++++++++++++++++++++--
> include/acpi/acnames.h | 1 +
> include/linux/acpi.h | 10 ++++++
> include/linux/device.h | 1 +
> include/linux/mod_devicetable.h | 6 ++++
> 5 files changed, 90 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index dc4d896..0579395 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -987,13 +987,82 @@ static bool acpi_of_driver_match_device(struct device *dev,
> bool acpi_driver_match_device(struct device *dev,
> const struct device_driver *drv)
> {
> - if (!drv->acpi_match_table)
> - return acpi_of_driver_match_device(dev, drv);
> + bool ret = false;
>
> - return !!acpi_match_device(drv->acpi_match_table, dev);
> + if (drv->acpi_match_table)
> + ret = !!acpi_match_device(drv->acpi_match_table, dev);
> +
> + /* Next, try to match with special "PRP0001" _HID */
> + if (!ret && drv->of_match_table)
> + ret = acpi_of_driver_match_device(dev, drv);
> +
> + /* Next, try to match with PCI-defined class-code */
> + if (!ret && drv->acpi_match_cls)
> + ret = acpi_match_device_cls(drv->acpi_match_cls, dev);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(acpi_driver_match_device);
>
> +/**
> + * acpi_match_device_cls - Match a struct device against a ACPI _CLS method
> + * @dev_cls: A pointer to struct acpi_device_cls object to match against.
> + * @dev: The ACPI device structure to match.
> + *
> + * Check if @dev has a valid ACPI and _CLS handle. If there is a
> + * struct acpi_device_cls object for that handle, use that object to match
> + * against the given struct acpi_device_cls object.
> + *
> + * Return true on success or false on failure.
> + */
> +bool acpi_match_device_cls(const struct acpi_device_cls *dev_cls,
> + const struct device *dev)
> +{
> + acpi_status status;
> + union acpi_object *pkg;
> + struct acpi_device_cls cls;
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + struct acpi_buffer format = { sizeof("NNN"), "NNN" };
> + struct acpi_buffer state = { 0, NULL };
> + struct acpi_device *adev = ACPI_COMPANION(dev);
> +
> + if (!adev || !adev->status.present || !dev_cls)
> + return false;
> +
> + status = acpi_evaluate_object(adev->handle, METHOD_NAME__CLS,
> + NULL, &buffer);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + /**
> + * Note:
> + * ACPIv5.1 defines the package to contain 3 integers for
> + * Base-Class code, Sub-Class code, and Programming Interface code.
> + */
> + pkg = buffer.pointer;
> + if (!pkg ||
> + (pkg->type != ACPI_TYPE_PACKAGE) ||
> + (pkg->package.count != 3)) {
> + dev_dbg(&adev->dev, "Invalid _CLS data\n");
> + goto out;
> + }
> +
> + state.length = sizeof(struct acpi_device_cls);
> + state.pointer = &cls;
> +
> + status = acpi_extract_package(pkg, &format, &state);
> + if (ACPI_FAILURE(status))
> + goto out;
> +
> + return (dev_cls->base_class == cls.base_class &&
> + dev_cls->sub_class == cls.sub_class &&
> + dev_cls->prog_interface == cls.prog_interface);
> +out:
> + kfree(pkg);
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(acpi_match_device_cls);
> +
> static void acpi_free_power_resources_lists(struct acpi_device *device)
> {
> int i;
> diff --git a/include/acpi/acnames.h b/include/acpi/acnames.h
> index 7461327..22332a6 100644
> --- a/include/acpi/acnames.h
> +++ b/include/acpi/acnames.h
> @@ -51,6 +51,7 @@
> #define METHOD_NAME__BBN "_BBN"
> #define METHOD_NAME__CBA "_CBA"
> #define METHOD_NAME__CID "_CID"
> +#define METHOD_NAME__CLS "_CLS"
> #define METHOD_NAME__CRS "_CRS"
> #define METHOD_NAME__DDN "_DDN"
> #define METHOD_NAME__HID "_HID"
Shouldn't this change go through ACPICA?
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 536991b..9a01d5d 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -442,6 +442,10 @@ const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
>
> extern bool acpi_driver_match_device(struct device *dev,
> const struct device_driver *drv);
> +
> +bool acpi_match_device_cls(const struct acpi_device_cls *dev_cls,
> + const struct device *dev);
> +
> int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
> int acpi_device_modalias(struct device *, char *, int);
> void acpi_walk_dep_device_list(acpi_handle handle);
> @@ -542,6 +546,12 @@ static inline const struct acpi_device_id *acpi_match_device(
> return NULL;
> }
>
> +static inline bool acpi_match_device_cls(const struct acpi_device_cls *dev_cls,
> + const struct device *dev)
> +{
> + return false;
> +}
> +
> static inline bool acpi_driver_match_device(struct device *dev,
> const struct device_driver *drv)
> {
> diff --git a/include/linux/device.h b/include/linux/device.h
> index fb50673..8e259c5c 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -237,6 +237,7 @@ struct device_driver {
>
> const struct of_device_id *of_match_table;
> const struct acpi_device_id *acpi_match_table;
> + const struct acpi_device_cls *acpi_match_cls;
>
> int (*probe) (struct device *dev);
> int (*remove) (struct device *dev);
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 745def8..cf0e0d198 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -191,6 +191,12 @@ struct acpi_device_id {
> kernel_ulong_t driver_data;
> };
>
> +struct acpi_device_cls {
> + kernel_ulong_t base_class;
> + kernel_ulong_t sub_class;
> + kernel_ulong_t prog_interface;
> +};
> +
> #define PNP_ID_LEN 8
> #define PNP_MAX_DEVICES 8
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:
> On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:
> > Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
> > 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
> > 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.
> >
> > Signed-off-by: Suravee Suthikulpanit <[email protected]>
>
> Greg, Mika, any problems with this?
None from me:
Acked-by: Greg Kroah-Hartman <[email protected]>
On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:
> On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:
> > Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
> > 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
> > 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.
> >
> > Signed-off-by: Suravee Suthikulpanit <[email protected]>
>
> 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.
On 2/9/15, 19:15, "Mika Westerberg" <[email protected]>
wrote:
>On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:
>> On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:
>> > Device drivers typically use ACPI _HIDs/_CIDs listed in struct
>>device_driver
>> > 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
>> > 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.
>> >
>> > Signed-off-by: Suravee Suthikulpanit <[email protected]>
>>
>> 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.
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.
Thanks,
Suravee
On Mon, Feb 09, 2015 at 09:02:11PM +0000, Suthikulpanit, Suravee wrote:
> On 2/9/15, 19:15, "Mika Westerberg" <[email protected]>
> wrote:
>
> >On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:
> >> On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:
> >> > Device drivers typically use ACPI _HIDs/_CIDs listed in struct
> >>device_driver
> >> > 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
> >> > 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.
> >> >
> >> > Signed-off-by: Suravee Suthikulpanit <[email protected]>
> >>
> >> 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 :)
> 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. Besides, how do you
support modules with this? Or did I miss something?
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:
> > On 2/9/15, 19:15, "Mika Westerberg" <[email protected]>
> > wrote:
> >
> > >On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:
> > >> On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit wrote:
> > >> > Device drivers typically use ACPI _HIDs/_CIDs listed in struct
> > >>device_driver
> > >> > 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
> > >> > 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.
> > >> >
> > >> > Signed-off-by: Suravee Suthikulpanit <[email protected]>
> > >>
> > >> 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 :)
>
> > 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.
On 2/10/15, 23:07, "Rafael J. Wysocki" <[email protected]> wrote:
>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:
>> > On 2/9/15, 19:15, "Mika Westerberg" <[email protected]>
>> > wrote:
>> >
>> > >On Mon, Feb 09, 2015 at 12:02:43AM +0100, Rafael J. Wysocki wrote:
>> > >> On Monday, February 09, 2015 12:20:03 AM Suravee Suthikulpanit
>>wrote:
>> > >> > Device drivers typically use ACPI _HIDs/_CIDs listed in struct
>> > >>device_driver
>> > >> > 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
>> > >> > 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.
>> > >> >
>> > >> > Signed-off-by: Suravee Suthikulpanit
>><[email protected]>
>> > >>
>> > >> 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 :)
>>
>> > 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.
Ok, let me reimplement this part to put "u32 cls" in the struct
acpi_device_id, and use that for matching then.
>
>> Besides, how do you support modules with this? Or did I miss something?
>
>Good question.
Ah. I didn?t think about this part earlier.
IIUC, the current ACPI driver would create modules.alias entry with format:
acpi:<HID>:<CID>
What do you think if we append the _CLS of the device using the following
format:
acpi:<HID>:<CID>:<CLS>
In case of PCI_CLASS_STORAGE_SATA_AHCI, this would become:
acpi:::0x10601
Thanks,
Suravee
On Wed, Feb 11, 2015 at 10:35:25PM +0000, Suthikulpanit, Suravee wrote:
> >> Besides, how do you support modules with this? Or did I miss something?
> >
> >Good question.
>
> Ah. I didn?t think about this part earlier.
>
> IIUC, the current ACPI driver would create modules.alias entry with format:
> acpi:<HID>:<CID>
>
> What do you think if we append the _CLS of the device using the following
> format:
> acpi:<HID>:<CID>:<CLS>
>
> In case of PCI_CLASS_STORAGE_SATA_AHCI, this would become:
> acpi:::0x10601
Note, that you can have multiple _CIDs, in other words it may look like:
acpi:<HID>:<CID0>:<CID1>:<CLS>
In which case I'm not sure how to match the class. Perhaps use something
else than ':' as a separator for class?
BTW, should we add class_mask as well (like PCI does) so that drivers
can match part of the class id?