[V3 PATCH 0/2] Introduce ACPI support for ahci_platform driver

[V3 PATCH 0/2] Introduce ACPI support for ahci_platform driver

[Suravee Suthikulpanit]

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

[V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Suravee Suthikulpanit]

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 <Suravee.Suthikulpanit@amd.com>
---
 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

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Rafael J. Wysocki]

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 <Suravee.Suthikulpanit@amd.com>

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.

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Greg Kroah-Hartman]

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 <Suravee.Suthikulpanit@amd.com>
> 
> Greg, Mika, any problems with this?

None from me:

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Mika Westerberg]

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

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Suthikulpanit, Suravee]

On 2/9/15, 19:15, "Mika Westerberg" <mika.westerberg@linux.intel.com>
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 <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.

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

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Mika Westerberg]

On Mon, Feb 09, 2015 at 09:02:11PM +0000, Suthikulpanit, Suravee wrote:
> On 2/9/15, 19:15, "Mika Westerberg" <mika.westerberg@linux.intel.com>
> 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 <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 :)

> 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?

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Rafael J. Wysocki]

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" <mika.westerberg@linux.intel.com>
> > 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 <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 :)
> 
> > 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.

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Suthikulpanit, Suravee]

On 2/10/15, 23:07, "Rafael J. Wysocki" <rjw@rjwysocki.net> 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" <mika.westerberg@linux.intel.com>
>> > 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
>><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 :)
>> 
>> > 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

Re: [V3 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Mika Westerberg]

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?

[V3 PATCH 2/2] ata: ahci_platform: Add ACPI _CLS matching

[Suravee Suthikulpanit]

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 <tj@kernel.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
 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