Skip to contentSkip to conversation

Match i2c_device_id when using DT ids through ACPI

RFC In review Crestez Dan Leonard 3 participants 9 messages Jun 9, 2016 – Jun 13, 2016

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

v2 cover Match i2c_device_id when using DT ids through ACPI

Linux supports instantiating devices using devicetree ids from ACPI by setting the id to PRP0001 and adding the devicetree compatible string in _DSD properties. This is described in Documentation/acpi/enumeration.txt.

I've tried to use this feature using custom ACPI tables and one issue I encountered is that a lot of i2c device drivers are written for DT only and expect a valid i2c_device_id *id parameter to their probe function but this is always NULL for the PRP0001 case. Others call of_match_device in order to determine their exact model number and that will also fail.

Drivers normally do this in order to differentiate between minor model numbers supported by the same driver, for example hmc5883 versus hmc5983.

For ACPI it is common to add calls to acpi_match_device in order to do such differentiation. It might make sense to call some form of acpi_of_match_device except no such function is currently exported. I think it makes a lot of sense to refactor the current acpi_of_match_device to return the of_device_id and export it.

This is in PATCH 1. After exposing this function it could be called from each driver that needs to support multiple models through PRP0001. I guess the alternative to exposing acpi_of_match_device would be for driver code to poke at acpi_device->data.of_compatible?

Going further it might make sense to attempt to fetch the i2c_device_id when instantiating through PRP0001. This already happens automatically for devicetree and it makes a lot of sense it would work through ACPI with DT ids. Patch 2 hacks an additional search in i2c register code. This makes some drivers "just work" without manually handling the "ACPI with DT ids" case.

For P1 it might make sense to change the parameters around so that acpi_of_match_device will have the same signature as of_match_device.

The purpose of these changes would be to make more drivers easier to instantiate through ACPI firmware.

v2 fixes the code to actually work correctly. Hopefully the patches will also be sent to the correct addresses this time.

Crestez Dan Leonard (2):
acpi: Expose acpi_of_match_device
i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

 drivers/acpi/bus.c     | 13 +++++++------
 drivers/i2c/i2c-core.c | 30 ++++++++++++++++++++++++++----
 include/linux/acpi.h   |  8 ++++++++
 3 files changed, 41 insertions(+), 10 deletions(-)
Signature · 1 line
2.5.5
#1 lore raw

RFC v2 1/2 acpi: Expose acpi_of_match_device

This can be used by device drivers as the equivalent of of_match_device when they are instantiated through ACPI using devicetree IDs. This is described in Documentation/acpi/enumeration.txt

---
 drivers/acpi/bus.c   | 13 +++++++------
 include/linux/acpi.h |  8 ++++++++
 2 files changed, 15 insertions(+), 6 deletions(-)
drivers/acpi/bus.c +7 -6
index 27367d4..b366bb2 100644
@@ -574,18 +574,18 @@ struct acpi_device *acpi_companion_match(const struct device *dev)
  * identifiers and a _DSD object with the "compatible" property, use that
  * property to match against the given list of identifiers.
  */
-static bool acpi_of_match_device(struct acpi_device *adev,
-				 const struct of_device_id *of_match_table)
+const struct of_device_id* acpi_of_match_device(const struct acpi_device *adev,
+						const struct of_device_id *of_match_table)
 {
 	const union acpi_object *of_compatible, *obj;
 	int i, nval;
 
 	if (!adev)
-		return false;
+		return NULL;
 
 	of_compatible = adev->data.of_compatible;
 	if (!of_match_table || !of_compatible)
-		return false;
+		return NULL;
 
 	if (of_compatible->type == ACPI_TYPE_PACKAGE) {
 		nval = of_compatible->package.count;
@@ -600,11 +600,12 @@ static bool acpi_of_match_device(struct acpi_device *adev,
 
 		for (id = of_match_table; id->compatible[0]; id++)
 			if (!strcasecmp(obj->string.pointer, id->compatible))
-				return true;
+				return id;
 	}
 
-	return false;
+	return NULL;
 }
+EXPORT_SYMBOL(acpi_of_match_device);
 
 static bool __acpi_match_device_cls(const struct acpi_device_id *id,
 				    struct acpi_hardware_id *hwid)
include/linux/acpi.h +8 -0
index d4a3cb2..0810001 100644
@@ -524,6 +524,8 @@ extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
 
 const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
 					       const struct device *dev);
+const struct of_device_id *acpi_of_match_device(const struct acpi_device *dev,
+						const struct of_device_id *ids);
 
 extern bool acpi_driver_match_device(struct device *dev,
 				     const struct device_driver *drv);
@@ -649,6 +651,12 @@ static inline const struct acpi_device_id *acpi_match_device(
 	return NULL;
 }
 
+const struct of_device_id *acpi_of_match_device(const struct acpi_device *dev,
+						const struct acpi_device_id *ids)
+{
+	return NULL;
+}
+
 static inline bool acpi_driver_match_device(struct device *dev,
 					    const struct device_driver *drv)
 {
Signature · 1 line
2.5.5
#2 lore raw

RFC v2 2/2 i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

In reply to Crestez Dan Leonard

When devices are instatiated through devicetree the i2c_client->name is set to the compatible string with company name stripped out. This is then matched to the i2c_device_id table to pass the device_id to the probe function. This id parameter is used by some device drivers to differentiate between model numbers.

When using ACPI this id parameter is NULL and the driver usually needs to do ACPI-specific differentiation.

This patch attempts to find a valid i2c_device_id when using ACPI with DT-like compatible strings.

---
 drivers/i2c/i2c-core.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)
drivers/i2c/i2c-core.c +26 -4
index 3ffeb6c..911052d 100644
@@ -581,17 +581,23 @@ static inline int acpi_i2c_install_space_handler(struct i2c_adapter *adapter)
 
 /* ------------------------------------------------------------------------- */
 
-static const struct i2c_device_id *i2c_match_id(const struct i2c_device_id *id,
-						const struct i2c_client *client)
+static const struct i2c_device_id *i2c_match_id_name(const struct i2c_device_id *id,
+						     const char *id_name)
 {
 	while (id->name[0]) {
-		if (strcmp(client->name, id->name) == 0)
+		if (strcmp(id_name, id->name) == 0)
 			return id;
 		id++;
 	}
 	return NULL;
 }
 
+static const struct i2c_device_id *i2c_match_id(const struct i2c_device_id *id,
+						const struct i2c_client *client)
+{
+	return i2c_match_id_name(id, client->name);
+}
+
 static int i2c_device_match(struct device *dev, struct device_driver *drv)
 {
 	struct i2c_client	*client = i2c_verify_client(dev);
@@ -767,6 +773,7 @@ static int i2c_device_probe(struct device *dev)
 {
 	struct i2c_client	*client = i2c_verify_client(dev);
 	struct i2c_driver	*driver;
+	const struct i2c_device_id *i2c_device_id;
 	int status;
 
 	if (!client)
@@ -826,7 +833,22 @@ static int i2c_device_probe(struct device *dev)
 	if (status == -EPROBE_DEFER)
 		goto err_clear_wakeup_irq;
 
-	status = driver->probe(client, i2c_match_id(driver->id_table, client));
+	i2c_device_id = i2c_match_id(driver->id_table, client);
+#ifdef CONFIG_ACPI
+	if (!i2c_device_id) {
+		const char *id_name;
+		const struct of_device_id *ofid;
+
+		ofid = acpi_of_match_device(ACPI_COMPANION(&client->dev),
+					    driver->driver.of_match_table);
+		if (ofid) {
+			id_name = strchr(ofid->compatible, ',');
+			id_name = id_name ? id_name + 1 : ofid->compatible;
+			i2c_device_id = i2c_match_id_name(driver->id_table, id_name);
+		}
+	}
+#endif
+	status = driver->probe(client, i2c_device_id);
 	if (status)
 		goto err_detach_pm_domain;
 
Signature · 1 line
2.5.5
#3 lore raw

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

Quoted 11 lines · Crestez Dan Leonard

When devices are instatiated through devicetree the i2c_client->name is set to the compatible string with company name stripped out. This is then matched to the i2c_device_id table to pass the device_id to the probe function. This id parameter is used by some device drivers to differentiate between model numbers.

When using ACPI this id parameter is NULL and the driver usually needs to do ACPI-specific differentiation.

This patch attempts to find a valid i2c_device_id when using ACPI with DT-like compatible strings.

So I don't really understand why it would be good idea to pass i2c_device_id for devices which are matched against their ACPI/DT tables. Apparently DT is already doing that so maybe there is some reason.

Anyway, why not fill in the device name when it is first enumerated if it uses DT compatible property? Just like DT does.

#4 lore raw

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

Quoted 13 lines · Mika Westerberg
Quoted 11 lines · Crestez Dan Leonard

When devices are instatiated through devicetree the i2c_client->name is set to the compatible string with company name stripped out. This is then matched to the i2c_device_id table to pass the device_id to the probe function. This id parameter is used by some device drivers to differentiate between model numbers.

When using ACPI this id parameter is NULL and the driver usually needs to do ACPI-specific differentiation.

This patch attempts to find a valid i2c_device_id when using ACPI with DT-like compatible strings.

Quoted 8 lines

So I don't really understand why it would be good idea to pass i2c_device_id for devices which are matched against their ACPI/DT tables. Apparently DT is already doing that so maybe there is some reason.

Anyway, why not fill in the device name when it is first enumerated if it uses DT compatible property? Just like DT does.

This automatic matching of i2c_device_id works for devicetree because of_i2c_register_device sets i2c_board_info.type to the compatible string with the vendor prefix removed. For I2C devices described via ACPI the i2c_board_info.type string is set to the ACPI device name. This ends up something like "PRP0001:00".

This could be changed in acpi_i2c_get_info to use the of_compatible string from DSD if present. Is that what you mean? That would work and it would be cleaner than my patch. Something like this:

i2c/i2c-core.c +2 -1
index 1e0ef9b..ba2fe7f 100644
@@ -181,7 +181,24 @@ static int acpi_i2c_get_info(struct acpi_device *adev,
 
        acpi_dev_free_resource_list(&resource_list);
 
-       strlcpy(info->type, dev_name(&adev->dev), sizeof(info->type));
+       /*
+        * If we have a DT id set info.type to the first compatible

string with
+ * the vendor prefix stripped. This is similar to of_modalias_node
+ */
+ if (adev->data.of_compatible) {
+ const union acpi_object *obj;
+ const char *str, *chr;
+
+ obj = adev->data.of_compatible;
+ if (obj->type == ACPI_TYPE_PACKAGE)
+ obj = obj->package.elements;

+               str = obj->string.pointer;
+               chr = strchr(str, ',');
+               if (chr)

+ str = chr + 1;
+ strlcpy(info->type, str, sizeof(info->type));
+ } else
+ strlcpy(info->type, dev_name(&adev->dev),
sizeof(info->type));

        return 0;

}

The biggest concern is that this would change the i2c device name between kernel versions. Is that acceptable?

#5 lore raw

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

Quoted 62 lines · Crestez Dan Leonard
Quoted 13 lines · Mika Westerberg
Quoted 11 lines · Crestez Dan Leonard

When devices are instatiated through devicetree the i2c_client->name is set to the compatible string with company name stripped out. This is then matched to the i2c_device_id table to pass the device_id to the probe function. This id parameter is used by some device drivers to differentiate between model numbers.

When using ACPI this id parameter is NULL and the driver usually needs to do ACPI-specific differentiation.

This patch attempts to find a valid i2c_device_id when using ACPI with DT-like compatible strings.

Quoted 8 lines

So I don't really understand why it would be good idea to pass i2c_device_id for devices which are matched against their ACPI/DT tables. Apparently DT is already doing that so maybe there is some reason.

Anyway, why not fill in the device name when it is first enumerated if it uses DT compatible property? Just like DT does.

This automatic matching of i2c_device_id works for devicetree because of_i2c_register_device sets i2c_board_info.type to the compatible string with the vendor prefix removed. For I2C devices described via ACPI the i2c_board_info.type string is set to the ACPI device name. This ends up something like "PRP0001:00".

This could be changed in acpi_i2c_get_info to use the of_compatible string from DSD if present. Is that what you mean? That would work and it would be cleaner than my patch. Something like this:

i2c/i2c-core.c +2 -1
index 1e0ef9b..ba2fe7f 100644
@@ -181,7 +181,24 @@ static int acpi_i2c_get_info(struct acpi_device *adev,
 
        acpi_dev_free_resource_list(&resource_list);
 
-       strlcpy(info->type, dev_name(&adev->dev), sizeof(info->type));
+       /*
+        * If we have a DT id set info.type to the first compatible

string with

i2c/i2c-core.c +16 -0
+        * the vendor prefix stripped. This is similar to of_modalias_node
+        */
+       if (adev->data.of_compatible) {
+               const union acpi_object *obj;
+               const char *str, *chr;
+
+               obj = adev->data.of_compatible;
+               if (obj->type == ACPI_TYPE_PACKAGE)
+                       obj = obj->package.elements;
+               str = obj->string.pointer;
+               chr = strchr(str, ',');
+               if (chr)
+                       str = chr + 1;
+               strlcpy(info->type, str, sizeof(info->type));
+       } else
+               strlcpy(info->type, dev_name(&adev->dev),

sizeof(info->type));

Quoted 2 lines
        return 0;

}

Yes, that's what I mean.

Quoted 2 lines

The biggest concern is that this would change the i2c device name between kernel versions. Is that acceptable?

I don't think that is a problem since I still have not seen a single system using ACPI _DSD so I would not expect anything to break.

However, I'm still not convinced it is good idea to return i2c_device_id from a completely different table if we match using ACPI/DT table.

#6 lore raw

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

In reply to Crestez Dan Leonard
Quoted 11 lines · Crestez Dan Leonard

When devices are instatiated through devicetree the i2c_client->name is set to the compatible string with company name stripped out. This is then matched to the i2c_device_id table to pass the device_id to the probe function. This id parameter is used by some device drivers to differentiate between model numbers.

When using ACPI this id parameter is NULL and the driver usually needs to do ACPI-specific differentiation.

This patch attempts to find a valid i2c_device_id when using ACPI with DT-like compatible strings.

Note that this DT behaviour is about to be dropped to match I2C with the "generic" behaviour".

https://lkml.org/lkml/2016/5/4/534

#7 lore raw

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

Quoted 10 lines · Wolfram Sang
Quoted 9 lines · Crestez Dan Leonard

When devices are instatiated through devicetree the i2c_client->name is set to the compatible string with company name stripped out. This is then matched to the i2c_device_id table to pass the device_id to the probe function. This id parameter is used by some device drivers to differentiate between model numbers.

When using ACPI this id parameter is NULL and the driver usually needs to do ACPI-specific differentiation.

Quoted 7 lines
Quoted 2 lines

This patch attempts to find a valid i2c_device_id when using ACPI with DT-like compatible strings.

Note that this DT behaviour is about to be dropped to match I2C with the "generic" behaviour".

https://lkml.org/lkml/2016/5/4/534

Looking at that series it seems that the intention is to eventually remove the i2c_device_id argument from probe completely? That would cause a lot of code churn. It would also require every driver that needs to differentiate between models to pretty much duplicate the matching logic performed by the core.

This does seem better than receiving an i2c_device_id parameter argument which may or may not be NULL. Still, in order to support multiple models using ACPI DT ids every driver would have to attempt some sort of acpi_of_match_device, right?

Have you considered adding .probe_of(dev, of_device_id) and .probe_acpi(dev, acpi_device_id) instead, with arguments which are always guaranteed to be non-NULL? The main advantage would be that drivers don't need to do their own matching and all rules are only present ever in the core. Then ACPI with DT ids could be made to "just work" without per-driver support.

Signature · 2 lines
Regards,
Leonard
#8 lore raw

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

Quoted 6 lines

Looking at that series it seems that the intention is to eventually remove the i2c_device_id argument from probe completely? That would cause a lot of code churn. It would also require every driver that needs to differentiate between models to pretty much duplicate the matching logic performed by the core.

I am with you on the "duplicated matching" issue which I personally don't like at all.

That being said, it is the de-facto standard way of doing it currently. If this is going to be changed, it should be done on a BIG SCALE.

Currently, I2C has a special way of passing matches. Because I see more important topics to work on, I personally could leave it as is. But if people want I2C to behave as the rest of the kernel, this is fine with me if they are committed to do it 100%. Replacing the current I2C special way with another I2C special way is no option. The correct path IMO is to bring I2C in line with the rest of the kernel and fix the kernel.