[RFC PATCH 1/3] iio: accel: Add device tree probing for STMicro accelerometers

[Maxime Ripard]

Add the compatibles supported by the st_sensors library. This uses kind
of a hack, since the st_sensors core will actively check at probe time
that the device name matches the one reported when using old style i2c
probing, and that this name will be different with device tree.

Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/***@public.gmane.org>
---
.../devicetree/bindings/iio/accel/st_accel_i2c.txt | 22 +++++++++++++++
drivers/iio/accel/st_accel_i2c.c | 33 ++++++++++++++++++++++
2 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt

diff --git a/Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt b/Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt
new file mode 100644
index 000000000000..4a1efdf1775f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt
@@ -0,0 +1,22 @@
+* ST Micro accelerometer sensors
+
+Required properties:
+ - compatible : should be either:
+ * "st,lis3dh"
+ * "st,lis331dlh"
+ * "st,lsm303dl-accel"
+ * "st,lsm303dlh-accel"
+ * "st,lsm303dlhc-accel"
+ * "st,lsm303dlm-accel"
+ * "st,lsm330-accel"
+ * "st,lsm330d-accel"
+ * "st,lsm330dl-accel"
+ * "st,lsm330dlc-accel"
+ - reg : the I2C address of the sensor
+
+Example:
+
+accel: ***@19 {
+ compatible = "st,lsm330dlc-accel";
+ reg = <0x19>;
+};
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index d7bedbdfc81d..de2bf76378d8 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -13,11 +13,27 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/iio/iio.h>
+#include <linux/of_device.h>

#include <linux/iio/common/st_sensors.h>
#include <linux/iio/common/st_sensors_i2c.h>
#include "st_accel.h"

+static const struct of_device_id st_accel_of_table[] = {
+ { .compatible = "st,lis3dh", .data = LIS3DH_ACCEL_DEV_NAME },
+ { .compatible = "st,lis331dlh", .data = LIS331DLH_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dl-accel", .data = LSM303DL_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dlh-accel", .data = LSM303DLH_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dlhc-accel", .data = LSM303DLHC_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dlm-accel", .data = LSM303DLM_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330-accel", .data = LSM330_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330d-accel", .data = LSM330D_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330dl-accel", .data = LSM330DL_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330dlc-accel", .data = LSM330DLC_ACCEL_DEV_NAME },
+ {},
+};
+MODULE_DEVICE_TABLE(of, st_accel_of_table);
+
static int st_accel_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -34,6 +50,22 @@ static int st_accel_i2c_probe(struct i2c_client *client,

st_sensors_i2c_configure(indio_dev, client, adata);

+ /*
+ * If we are probed through DT, st_sensors_i2c_configure will
+ * fill the indio_dev->name string with the client->name,
+ * which is the compatible without the vendor prefix. Since
+ * compatibles separators are usually "-", and that the
+ * convention in this driver is using "_", we obviously have a
+ * problem when the st-sensors core checks that the two
+ * strings matches. We need to set again the indio_dev->name
+ * string to the real value used by the core later on.
+ */
+ if (client->dev.of_node) {
+ const struct of_device_id *device;
+ device = of_match_device(st_accel_of_table, &client->dev);
+ indio_dev->name = device->data;
+ }
+
err = st_accel_common_probe(indio_dev, client->dev.platform_data);
if (err < 0)
return err;
@@ -67,6 +99,7 @@ static struct i2c_driver st_accel_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "st-accel-i2c",
+ .of_match_table = of_match_ptr(st_accel_of_table),
},
.probe = st_accel_i2c_probe,
.remove = st_accel_i2c_remove,

[Maxime Ripard]

Add the compatibles supported by the st_sensors library. This uses kind
of a hack, since the st_sensors core will actively check at probe time
that the device name matches the one reported when using old style i2c
probing, and that this name will be different with device tree.

Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/***@public.gmane.org>
---
.../devicetree/bindings/iio/gyro/st_gyro_i2c.txt | 20 ++++++++++++++
drivers/iio/gyro/st_gyro_i2c.c | 31 ++++++++++++++++++++++
2 files changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/gyro/st_gyro_i2c.txt

diff --git a/Documentation/devicetree/bindings/iio/gyro/st_gyro_i2c.txt b/Documentation/devicetree/bindings/iio/gyro/st_gyro_i2c.txt
new file mode 100644
index 000000000000..39e434c80771
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyro/st_gyro_i2c.txt
@@ -0,0 +1,20 @@
+* ST Micro gyroscopes sensors
+
+Required properties:
+ - compatible : should be either:
+ * "st,l3g4200d"
+ * "st,lsm330-gyro"
+ * "st,lsm330d-gyro"
+ * "st,lsm330dl-gyro"
+ * "st,lsm330dlc-gyro"
+ * "st,l3gd20"
+ * "st,l3gd20h"
+ * "st,l3g4is-ui"
+ - reg : the I2C address of the sensor
+
+Example:
+
+gyro: ***@6a {
+ compatible = "st,lsm330dlc-gyro";
+ reg = <0x6a>;
+};
diff --git a/drivers/iio/gyro/st_gyro_i2c.c b/drivers/iio/gyro/st_gyro_i2c.c
index 16b8b8d70bf1..f82c1d9c4be9 100644
--- a/drivers/iio/gyro/st_gyro_i2c.c
+++ b/drivers/iio/gyro/st_gyro_i2c.c
@@ -13,11 +13,25 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/iio/iio.h>
+#include <linux/of_device.h>

#include <linux/iio/common/st_sensors.h>
#include <linux/iio/common/st_sensors_i2c.h>
#include "st_gyro.h"

+static const struct of_device_id st_gyro_of_table[] = {
+ { .compatible = "st,l3g4200d", .data = L3G4200D_GYRO_DEV_NAME },
+ { .compatible = "st,lsm330-gyro", .data = LSM330_GYRO_DEV_NAME },
+ { .compatible = "st,lsm330d-gyro", .data = LSM330D_GYRO_DEV_NAME },
+ { .compatible = "st,lsm330dl-gyro", .data = LSM330DL_GYRO_DEV_NAME },
+ { .compatible = "st,lsm330dlc-gyro", .data = LSM330DLC_GYRO_DEV_NAME },
+ { .compatible = "st,l3gd20", .data = L3GD20_GYRO_DEV_NAME },
+ { .compatible = "st,l3gd20h", .data = L3GD20H_GYRO_DEV_NAME },
+ { .compatible = "st,l3g4is-ui", .data = L3G4IS_GYRO_DEV_NAME },
+ {},
+};
+MODULE_DEVICE_TABLE(of, st_gyro_of_table);
+
static int st_gyro_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -34,6 +48,22 @@ static int st_gyro_i2c_probe(struct i2c_client *client,

st_sensors_i2c_configure(indio_dev, client, gdata);

+ /*
+ * If we are probed through DT, st_sensors_i2c_configure will
+ * fill the indio_dev->name string with the client->name,
+ * which is the compatible without the vendor prefix. Since
+ * compatibles separators are usually "-", and that the
+ * convention in this driver is using "_", we obviously have a
+ * problem when the st-sensors core checks that the two
+ * strings matches. We need to set again the indio_dev->name
+ * string to the real value used by the core later on.
+ */
+ if (client->dev.of_node) {
+ const struct of_device_id *device;
+ device = of_match_device(st_gyro_of_table, &client->dev);
+ indio_dev->name = device->data;
+ }
+
err = st_gyro_common_probe(indio_dev,
(struct st_sensors_platform_data *)&gyro_pdata);
if (err < 0)
@@ -66,6 +96,7 @@ static struct i2c_driver st_gyro_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "st-gyro-i2c",
+ .of_match_table = of_match_ptr(st_gyro_of_table),
},
.probe = st_gyro_i2c_probe,
.remove = st_gyro_i2c_remove,

[Maxime Ripard]

The CFA-10057 has an embedded ST Micro LSM330 DLC accelerometer and
gyroscope wired on the the i2c0 bus. Add those to the DT.

Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/***@public.gmane.org>
---
arch/arm/boot/dts/imx28-cfa10057.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-cfa10057.dts b/arch/arm/boot/dts/imx28-cfa10057.dts
index 0333c0532f28..fc289465c30f 100644
--- a/arch/arm/boot/dts/imx28-cfa10057.dts
+++ b/arch/arm/boot/dts/imx28-cfa10057.dts
@@ -119,6 +119,19 @@
status = "okay";
};

+ i2c0: ***@80058000 {
+ accel: ***@19 {
+ compatible = "st,lsm330dlc-accel";
+ reg = <0x19>;
+ };
+
+ gyro: ***@6a {
+ compatible = "st,lsm330dlc-gyro";
+ reg = <0x6a>;
+ };
+ };
+
+
i2c1: ***@8005a000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;

[Denis CIOCCA]

Hi Maxime, everyone,

only one point: it's possible to use the same names with DT? (using _
instead of -)
Why only for i2c?

Thanks,
Denis

Hi everyone,
This is an attempt at adding the DT probing to the st_sensors
accelerometers and gyroscopes.
It's somewhat hackish, because the core actively checks for the value
of the device at probe time, and DT probing generates a quite
different name.
I first tried to turn the function st_sensors_check_device_support the
other way around, with the "leaf" providing the sensor structure, and
the function checking that it's consistent with the WAI stored in the
sensor. However, it turned to be a quite intrusive change, so I'm
sending the easiest one, to try to get some feedback :)
Thanks!
Maxime
iio: accel: Add device tree probing for STMicro accelerometers
iio: accel: Add device tree probing for STMicro gyroscopes
ARM: cfa10057: Add the accelerometer and gyroscope to the device tree
.../devicetree/bindings/iio/accel/st_accel_i2c.txt | 22 +++++++++++++++
.../devicetree/bindings/iio/gyro/st_gyro_i2c.txt | 20 +++++++++++++
arch/arm/boot/dts/imx28-cfa10057.dts | 13 +++++++++
drivers/iio/accel/st_accel_i2c.c | 33 ++++++++++++++++++++++
drivers/iio/gyro/st_gyro_i2c.c | 31 ++++++++++++++++++++
5 files changed, 119 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt
create mode 100644 Documentation/devicetree/bindings/iio/gyro/st_gyro_i2c.txt

[Maxime Ripard]

Hi Denis,

Post by Denis CIOCCA
only one point: it's possible to use the same names with DT? (using _
instead of -)

Yes, it is, but only for i2c as far as I'm aware, and usually the DT
compatibles are with - as a separator (I looked into the ePAPR, but
couldn't get any explanations or requirements on this, even though
it's used in all of their examples)

Post by Denis CIOCCA
Why only for i2c?

Because I was only interested in i2c :)

Maxime

[Jonathan Cameron]

Post by Maxime Ripard
Hi Denis,

only one point: it's possible to use the same names with DT? (using _ instead of -)

Yes, it is, but only for i2c as far as I'm aware, and usually the DT compatibles are with - as a separator (I
looked into the ePAPR, but couldn't get any explanations or requirements on this, even though it's used in all of
their examples)

In other discussions, where the defacto i2c device tree bindings have
been followed, the conclusion has been that to change to a - from _
would result in userspace ABI changes, so whilst no one wants _
the discussion has concluded we can't really avoid it.

Post by Maxime Ripard

Why only for i2c?

Because I was only interested in i2c :)
Maxime

[Denis CIOCCA]

Hi Jonathan,

Post by Jonathan Cameron

Post by Maxime Ripard
Yes, it is, but only for i2c as far as I'm aware, and usually the DT compatibles are with - as a separator (I
looked into the ePAPR, but couldn't get any explanations or requirements on this, even though it's used in all of
their examples)

In other discussions, where the defacto i2c device tree bindings have
been followed, the conclusion has been that to change to a - from _
would result in userspace ABI changes, so whilst no one wants _
the discussion has concluded we can't really avoid it.

Ok, I understood the point. Thanks,

Denis--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Maxime Ripard]

Hi Jonathan,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Maxime Ripard
Hi Denis,

only one point: it's possible to use the same names with DT? (using _ instead of -)

Yes, it is, but only for i2c as far as I'm aware, and usually the
DT compatibles are with - as a separator (I looked into the ePAPR,
but couldn't get any explanations or requirements on this, even
though it's used in all of their examples)

In other discussions, where the defacto i2c device tree bindings have
been followed, the conclusion has been that to change to a - from _
would result in userspace ABI changes, so whilst no one wants _
the discussion has concluded we can't really avoid it.

What kind of userspace ABI changes are we talking about?

Maxime

[Jonathan Cameron]

Post by Denis CIOCCA
Hi Jonathan,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Post by Maxime Ripard
Hi Denis,

only one point: it's possible to use the same names with DT? (using _ instead of -)

Yes, it is, but only for i2c as far as I'm aware, and usually the DT compatibles are with - as a separator (I
looked into the ePAPR, but couldn't get any explanations or requirements on this, even though it's used in all
of their examples)

In other discussions, where the defacto i2c device tree bindings have been followed, the conclusion has been that
to change to a - from _ would result in userspace ABI changes, so whilst no one wants _ the discussion has
concluded we can't really avoid it.

What kind of userspace ABI changes are we talking about?

IIRC:

i2c has a generic binding that matches to the name bit of the i2c_device_id
array. That is then exported in sysfs. There are quite a lot of instances
of underscores out there in these names. Thus unforutnately they can't
be changed without possibly breaking userspace. Typically those same names
are also output by IIO though obviously we could keep that the same whilst
changing the dt binding.

Also the i2c binding allows binding after dropping the vendor prefix which
is even more 'interesting'. See of_modialias_node in drivers/of/base.c

I'd therefore argue in favour of just leaving the underscores in existing
drivers as a nasty bit of legacy and doing our best to not introduce any
new ones!

Jonathan

[Jean Delvare]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Denis CIOCCA
Hi Jonathan,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Post by Maxime Ripard
Hi Denis,

only one point: it's possible to use the same names with DT? (using _ instead of -)

Yes, it is, but only for i2c as far as I'm aware, and usually the DT compatibles are with - as a separator (I
looked into the ePAPR, but couldn't get any explanations or requirements on this, even though it's used in all
of their examples)

In other discussions, where the defacto i2c device tree bindings have been followed, the conclusion has been that
to change to a - from _ would result in userspace ABI changes, so whilst no one wants _ the discussion has
concluded we can't really avoid it.

What kind of userspace ABI changes are we talking about?

i2c has a generic binding that matches to the name bit of the i2c_device_id
array. That is then exported in sysfs. There are quite a lot of instances
of underscores out there in these names. Thus unforutnately they can't
be changed without possibly breaking userspace. Typically those same names
are also output by IIO though obviously we could keep that the same whilst
changing the dt binding.
Also the i2c binding allows binding after dropping the vendor prefix which
is even more 'interesting'. See of_modialias_node in drivers/of/base.c
I'd therefore argue in favour of just leaving the underscores in existing
drivers as a nasty bit of legacy and doing our best to not introduce any
new ones!

I don't know what is the problem with underscores, but please note that
hwmon i2c devices are NOT allowed to have dashes in their name because
that would break libsensors.

[Maxime Ripard]

Hi Jean,

Post by Jean Delvare

Post by Jonathan Cameron
i2c has a generic binding that matches to the name bit of the
i2c_device_id array. That is then exported in sysfs. There are
quite a lot of instances of underscores out there in these names.
Thus unforutnately they can't be changed without possibly breaking
userspace. Typically those same names are also output by IIO
though obviously we could keep that the same whilst changing the
dt binding.
Also the i2c binding allows binding after dropping the vendor
prefix which is even more 'interesting'. See of_modialias_node in
drivers/of/base.c
I'd therefore argue in favour of just leaving the underscores in
existing drivers as a nasty bit of legacy and doing our best to
not introduce any new ones!

I don't know what is the problem with underscores, but please note
that hwmon i2c devices are NOT allowed to have dashes in their name
because that would break libsensors.

As far as I remember, hwmon doesn't handle the accelerometers or
gyroscopes, does it?

Thanks,
Maxime

[Jean Delvare]

Post by Maxime Ripard
Hi Jean,

Post by Jean Delvare

Post by Jonathan Cameron
i2c has a generic binding that matches to the name bit of the
i2c_device_id array. That is then exported in sysfs. There are
quite a lot of instances of underscores out there in these names.
Thus unforutnately they can't be changed without possibly breaking
userspace. Typically those same names are also output by IIO
though obviously we could keep that the same whilst changing the
dt binding.
Also the i2c binding allows binding after dropping the vendor
prefix which is even more 'interesting'. See of_modialias_node in
drivers/of/base.c
I'd therefore argue in favour of just leaving the underscores in
existing drivers as a nasty bit of legacy and doing our best to
not introduce any new ones!

I don't know what is the problem with underscores, but please note
that hwmon i2c devices are NOT allowed to have dashes in their name
because that would break libsensors.

As far as I remember, hwmon doesn't handle the accelerometers or
gyroscopes, does it?

You remember correctly, it does not and never will.

[Maxime Ripard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Denis CIOCCA
Hi Jonathan,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Post by Maxime Ripard
Hi Denis,

only one point: it's possible to use the same names with DT? (using _ instead of -)

Yes, it is, but only for i2c as far as I'm aware, and usually the DT compatibles are with - as a separator (I
looked into the ePAPR, but couldn't get any explanations or requirements on this, even though it's used in all
of their examples)

In other discussions, where the defacto i2c device tree bindings have been followed, the conclusion has been that
to change to a - from _ would result in userspace ABI changes, so whilst no one wants _ the discussion has
concluded we can't really avoid it.

What kind of userspace ABI changes are we talking about?

i2c has a generic binding that matches to the name bit of the i2c_device_id
array. That is then exported in sysfs. There are quite a lot of instances
of underscores out there in these names. Thus unforutnately they can't
be changed without possibly breaking userspace. Typically those same names
are also output by IIO though obviously we could keep that the same whilst
changing the dt binding.
Also the i2c binding allows binding after dropping the vendor prefix which
is even more 'interesting'. See of_modialias_node in drivers/of/base.c
I'd therefore argue in favour of just leaving the underscores in existing
drivers as a nasty bit of legacy and doing our best to not introduce any
new ones!

Except I'm not removing anything, just adding new stuff. Therefore,
I'm not breaking anything. The existing users of the underscore stuff
in DT will still work, (if some ever exist, last time I checked, it
wasn't the case) just like they used to.

If we have the occasion of having the thing done like it's done
anywhere else, at no cost, I don't get what the issue is.

Especially since these devices are also usable on other buses than
i2c, which make it quite inconsistent from one bus to another.

Maxime

[Jonathan Cameron]

Post by Maxime Ripard
Add the compatibles supported by the st_sensors library. This uses kind
of a hack, since the st_sensors core will actively check at probe time
that the device name matches the one reported when using old style i2c
probing, and that this name will be different with device tree.

Note that this is unnecessary give core i2c matching, until we have some
more elements in the binding. I'd certainly expect the interrupts
on the relevant devices to be in the binding...

Post by Maxime Ripard
---
.../devicetree/bindings/iio/accel/st_accel_i2c.txt | 22 +++++++++++++++
drivers/iio/accel/st_accel_i2c.c | 33 ++++++++++++++++++++++
2 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt
diff --git a/Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt b/Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt
new file mode 100644
index 000000000000..4a1efdf1775f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/st_accel_i2c.txt
@@ -0,0 +1,22 @@
+* ST Micro accelerometer sensors
+
+ * "st,lis3dh"
+ * "st,lis331dlh"
+ * "st,lsm303dl-accel"
+ * "st,lsm303dlh-accel"
+ * "st,lsm303dlhc-accel"
+ * "st,lsm303dlm-accel"
+ * "st,lsm330-accel"
+ * "st,lsm330d-accel"
+ * "st,lsm330dl-accel"
+ * "st,lsm330dlc-accel"
+ - reg : the I2C address of the sensor
+
+
+ compatible = "st,lsm330dlc-accel";
+ reg = <0x19>;
+};
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index d7bedbdfc81d..de2bf76378d8 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -13,11 +13,27 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/iio/iio.h>
+#include <linux/of_device.h>
#include <linux/iio/common/st_sensors.h>
#include <linux/iio/common/st_sensors_i2c.h>
#include "st_accel.h"
+static const struct of_device_id st_accel_of_table[] = {
+ { .compatible = "st,lis3dh", .data = LIS3DH_ACCEL_DEV_NAME },
+ { .compatible = "st,lis331dlh", .data = LIS331DLH_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dl-accel", .data = LSM303DL_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dlh-accel", .data = LSM303DLH_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dlhc-accel", .data = LSM303DLHC_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm303dlm-accel", .data = LSM303DLM_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330-accel", .data = LSM330_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330d-accel", .data = LSM330D_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330dl-accel", .data = LSM330DL_ACCEL_DEV_NAME },
+ { .compatible = "st,lsm330dlc-accel", .data = LSM330DLC_ACCEL_DEV_NAME },
+ {},
+};
+MODULE_DEVICE_TABLE(of, st_accel_of_table);
+
static int st_accel_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -34,6 +50,22 @@ static int st_accel_i2c_probe(struct i2c_client *client,
st_sensors_i2c_configure(indio_dev, client, adata);
+ /*
+ * If we are probed through DT, st_sensors_i2c_configure will
+ * fill the indio_dev->name string with the client->name,
+ * which is the compatible without the vendor prefix. Since
+ * compatibles separators are usually "-", and that the
+ * convention in this driver is using "_", we obviously have a
+ * problem when the st-sensors core checks that the two
+ * strings matches. We need to set again the indio_dev->name
+ * string to the real value used by the core later on.
+ */
+ if (client->dev.of_node) {
+ const struct of_device_id *device;
+ device = of_match_device(st_accel_of_table, &client->dev);
+ indio_dev->name = device->data;
+ }
+
err = st_accel_common_probe(indio_dev, client->dev.platform_data);
if (err < 0)
return err;
@@ -67,6 +99,7 @@ static struct i2c_driver st_accel_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "st-accel-i2c",
+ .of_match_table = of_match_ptr(st_accel_of_table),
},
.probe = st_accel_i2c_probe,
.remove = st_accel_i2c_remove,

[Maxime Ripard]

Post by Jonathan Cameron

Post by Maxime Ripard
Add the compatibles supported by the st_sensors library. This uses kind
of a hack, since the st_sensors core will actively check at probe time
that the device name matches the one reported when using old style i2c
probing, and that this name will be different with device tree.

Note that this is unnecessary give core i2c matching, until we have some
more elements in the binding. I'd certainly expect the interrupts
on the relevant devices to be in the binding...

This interrupt DT thing has been stalled for monthes, I don't have any
hardware to test the interrupts, maybe we can just move forward and
wait for someone that have the need for the interrupts to do the work?

Maxime