| Message ID | 20200811134846.3981475-3-daniel@0x0f.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iio: st-accel: Add support for Silan clones | expand |
On Tue, 11 Aug 2020 22:48:46 +0900 Daniel Palmer <daniel@0x0f.com> wrote: > This chips are not from ST but seem to be clones of the ST parts. > The register and bit settings in the datasheets match those in the > LIS2DH datasheet. Same issue with sign off. + Needs to be added to the device tree documentation in Documentation/devicetree/bindings/iio/st-sensors.txt Thanks, Jonathan > --- > drivers/iio/accel/st_accel.h | 4 + > drivers/iio/accel/st_accel_core.c | 159 +++++++++++++++++++++++++++++- > drivers/iio/accel/st_accel_i2c.c | 10 ++ > 3 files changed, 172 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h > index 5d356288e001..784c2df83dde 100644 > --- a/drivers/iio/accel/st_accel.h > +++ b/drivers/iio/accel/st_accel.h > @@ -36,6 +36,8 @@ enum st_accel_type { > LIS3DHH, > LIS2DE12, > LIS2HH12, > + SC7A20, > + SC7A30E, > ST_ACCEL_MAX, > }; > > @@ -61,6 +63,8 @@ enum st_accel_type { > #define LIS3DE_ACCEL_DEV_NAME "lis3de" > #define LIS2DE12_ACCEL_DEV_NAME "lis2de12" > #define LIS2HH12_ACCEL_DEV_NAME "lis2hh12" > +#define SC7A20_ACCEL_DEV_NAME "sc7a20" > +#define SC7A30E_ACCEL_DEV_NAME "sc7a30e" > > /** > * struct st_sensors_platform_data - default accel platform data > diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c > index 43c50167d220..23fdbf27d44c 100644 > --- a/drivers/iio/accel/st_accel_core.c > +++ b/drivers/iio/accel/st_accel_core.c > @@ -980,7 +980,164 @@ static const struct st_sensor_settings st_accel_sensors_settings[] = { > .multi_read_bit = true, > .bootime = 2, > }, > - > + { > + .wai = 0x11, > + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS, > + .sensors_supported = { > + [0] = SC7A20_ACCEL_DEV_NAME, > + }, > + .ch = (struct iio_chan_spec *)st_accel_12bit_channels, > + .odr = { > + .addr = 0x20, > + .mask = 0xf0, > + .odr_avl = { > + { .hz = 1, .value = 0x01, }, > + { .hz = 10, .value = 0x02, }, > + { .hz = 25, .value = 0x03, }, > + { .hz = 50, .value = 0x04, }, > + { .hz = 100, .value = 0x05, }, > + { .hz = 200, .value = 0x06, }, > + { .hz = 400, .value = 0x07, }, > + { .hz = 1600, .value = 0x08, }, > + }, > + }, > + .pw = { > + .addr = 0x20, > + .mask = 0xf0, > + .value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE, > + }, > + .enable_axis = { > + .addr = ST_SENSORS_DEFAULT_AXIS_ADDR, > + .mask = ST_SENSORS_DEFAULT_AXIS_MASK, > + }, > + .fs = { > + .addr = 0x23, > + .mask = 0x30, > + .fs_avl = { > + [0] = { > + .num = ST_ACCEL_FS_AVL_2G, > + .value = 0x00, > + .gain = IIO_G_TO_M_S_2(1000), > + }, > + [1] = { > + .num = ST_ACCEL_FS_AVL_4G, > + .value = 0x01, > + .gain = IIO_G_TO_M_S_2(2000), > + }, > + [2] = { > + .num = ST_ACCEL_FS_AVL_8G, > + .value = 0x02, > + .gain = IIO_G_TO_M_S_2(4000), > + }, > + [3] = { > + .num = ST_ACCEL_FS_AVL_16G, > + .value = 0x03, > + .gain = IIO_G_TO_M_S_2(12000), > + }, > + }, > + }, > + .bdu = { > + .addr = 0x23, > + .mask = 0x80, > + }, > + .drdy_irq = { > + .int1 = { > + .addr = 0x22, > + .mask = 0x10, > + }, > + .addr_ihl = 0x25, > + .mask_ihl = 0x02, > + .stat_drdy = { > + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, > + .mask = 0x07, > + }, > + }, > + .sim = { > + .addr = 0x23, > + .value = BIT(0), > + }, > + .multi_read_bit = true, > + .bootime = 2, > + }, > + { > + .wai = 0x33, > + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS, > + .sensors_supported = { > + [0] = SC7A30E_ACCEL_DEV_NAME, > + }, > + .ch = (struct iio_chan_spec *)st_accel_12bit_channels, > + .odr = { > + .addr = 0x20, > + .mask = 0xf0, > + .odr_avl = { > + { .hz = 1, .value = 0x01, }, > + { .hz = 10, .value = 0x02, }, > + { .hz = 25, .value = 0x03, }, > + { .hz = 50, .value = 0x04, }, > + { .hz = 100, .value = 0x05, }, > + { .hz = 200, .value = 0x06, }, > + { .hz = 400, .value = 0x07, }, > + { .hz = 1600, .value = 0x08, }, > + }, > + }, > + .pw = { > + .addr = 0x20, > + .mask = 0xf0, > + .value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE, > + }, > + .enable_axis = { > + .addr = ST_SENSORS_DEFAULT_AXIS_ADDR, > + .mask = ST_SENSORS_DEFAULT_AXIS_MASK, > + }, > + .fs = { > + .addr = 0x23, > + .mask = 0x30, > + .fs_avl = { > + [0] = { > + .num = ST_ACCEL_FS_AVL_2G, > + .value = 0x00, > + .gain = IIO_G_TO_M_S_2(1000), > + }, > + [1] = { > + .num = ST_ACCEL_FS_AVL_4G, > + .value = 0x01, > + .gain = IIO_G_TO_M_S_2(2000), > + }, > + [2] = { > + .num = ST_ACCEL_FS_AVL_8G, > + .value = 0x02, > + .gain = IIO_G_TO_M_S_2(4000), > + }, > + [3] = { > + .num = ST_ACCEL_FS_AVL_16G, > + .value = 0x03, > + .gain = IIO_G_TO_M_S_2(12000), > + }, > + }, > + }, > + .bdu = { > + .addr = 0x23, > + .mask = 0x80, > + }, > + .drdy_irq = { > + .int1 = { > + .addr = 0x22, > + .mask = 0x10, > + }, > + .addr_ihl = 0x25, > + .mask_ihl = 0x02, > + .stat_drdy = { > + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, > + .mask = 0x07, > + }, > + }, > + .sim = { > + .addr = 0x23, > + .value = BIT(0), > + }, > + .multi_read_bit = true, > + .bootime = 2, > + }, > }; > > static int st_accel_read_raw(struct iio_dev *indio_dev, > diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c > index 360e16f2cadb..2c9e91ef5e19 100644 > --- a/drivers/iio/accel/st_accel_i2c.c > +++ b/drivers/iio/accel/st_accel_i2c.c > @@ -108,6 +108,14 @@ static const struct of_device_id st_accel_of_match[] = { > .compatible = "st,lis2hh12", > .data = LIS2HH12_ACCEL_DEV_NAME, > }, > + { > + .compatible = "silan,sc7a20-accel", > + .data = SC7A20_ACCEL_DEV_NAME, > + }, > + { > + .compatible = "silan,sc7a30e-accel", > + .data = SC7A30E_ACCEL_DEV_NAME, > + }, > {}, > }; > MODULE_DEVICE_TABLE(of, st_accel_of_match); > @@ -143,6 +151,8 @@ static const struct i2c_device_id st_accel_id_table[] = { > { LIS3DE_ACCEL_DEV_NAME }, > { LIS2DE12_ACCEL_DEV_NAME }, > { LIS2HH12_ACCEL_DEV_NAME }, > + { SC7A20_ACCEL_DEV_NAME }, > + { SC7A30E_ACCEL_DEV_NAME }, > {}, > }; > MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
Hi Jonathan, On Sun, 16 Aug 2020 at 17:52, Jonathan Cameron <jic23@kernel.org> wrote: > Same issue with sign off. I didn't think that was needed for an RFC. I'll add the sign off to the v1. > + Needs to be added to the device tree documentation in > Documentation/devicetree/bindings/iio/st-sensors.txt I'll add that in. Other than that was the change OK? I wasn't sure a massive copy/paste would be acceptable. Thanks, Daniel
On Sun, 16 Aug 2020 18:27:03 +0900 Daniel Palmer <daniel@0x0f.com> wrote: > Hi Jonathan, > > On Sun, 16 Aug 2020 at 17:52, Jonathan Cameron <jic23@kernel.org> wrote: > > Same issue with sign off. > > I didn't think that was needed for an RFC. I'll add the sign off to the v1. I'd always put them in anyway as RFCs sometimes get picked up if the comments are all positive! > > > + Needs to be added to the device tree documentation in > > Documentation/devicetree/bindings/iio/st-sensors.txt > > I'll add that in. Other than that was the change OK? I wasn't sure a > massive copy/paste > would be acceptable. It's always a trade off with cases like this on whether we want to add complexity to the code to handle different WAI values, or just have a bit more constant data and replicate stuff. I'm fine with the replicating options, but of course others may not be. Jonathan > > Thanks, > > Daniel
On Tue, Aug 11, 2020 at 4:51 PM Daniel Palmer <daniel@0x0f.com> wrote: > > This chips are not from ST but seem to be clones of the ST parts. > The register and bit settings in the datasheets match those in the > LIS2DH datasheet. No SoB tag?! Hint: `git commit -a -s --amend` would fix this if you have properly configured Git. On top of that, can you add Datasheet: tag with links to the actual component datasheets?
Hi Andy, On Sun, 16 Aug 2020 at 18:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > No SoB tag?! Hint: `git commit -a -s --amend` would fix this if you > have properly configured Git. > Sorry I wasn't aware it was needed for an RFC. > On top of that, can you add Datasheet: tag with links to the actual > component datasheets? I will do that for the v1 of the patch series. All of the datasheets I've found so far are mostly Chinese but the register tables are in English. I've collected them together here: http://linux-chenxing.org/silan/index.html Cheers, Daniel
Hi Jonathan, I strongly disagree that these parts will be supported by STMicroelectronics driver. We DO NOT want to find out one day that we need to modify our structure in order to support competition. If they need to support this chip, please provide a new driver for that part leaving STMicroelectronics driver managing our parts. Thanks & Br, Denis > -----Original Message----- > From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org> > On Behalf Of Daniel Palmer > Sent: Sunday, August 16, 2020 5:00 AM > To: Andy Shevchenko <andy.shevchenko@gmail.com> > Cc: linux-iio <linux-iio@vger.kernel.org>; Jonathan Cameron > <jic23@kernel.org> > Subject: Re: [RFC PATCH 2/2] iio: st-accel: Add support for Silan SC7A20 and > SC7A30E > > Hi Andy, > > On Sun, 16 Aug 2020 at 18:55, Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > No SoB tag?! Hint: `git commit -a -s --amend` would fix this if you > > have properly configured Git. > > > > Sorry I wasn't aware it was needed for an RFC. > > > On top of that, can you add Datasheet: tag with links to the actual > > component datasheets? > > I will do that for the v1 of the patch series. All of the datasheets I've found so > far are mostly Chinese but the register tables are in English. I've collected > them together > here: http://linux-chenxing.org/silan/index.html > > Cheers, > > Daniel
+CC: GregKH as this will pass through his tree. As a quick summary, it seems we have some cloned parts that appear to be compatible with certain ST micro parts, but have different whoami address values. Entirely reasonably, Denis is not happy to have them added to the ST maintained driver given the potential for future incompatibilities. I don't particularly mind a separate driver, though I would ask that we remove a lot of the abstractions from the ST driver as they won't be necessary given the much more restricted parts being supported, Greg, I'm guessing this is far from the first time this has happened. Any advise? Jonathan On Wed, 19 Aug 2020 18:19:21 +0000 Denis CIOCCA <denis.ciocca@st.com> wrote: > Hi Jonathan, > > I strongly disagree that these parts will be supported by STMicroelectronics driver. > We DO NOT want to find out one day that we need to modify our structure in order to support competition. If they need to support this chip, please provide a new driver for that part leaving STMicroelectronics driver managing our parts. > > Thanks & Br, > Denis > > > > > -----Original Message----- > > From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org> > > On Behalf Of Daniel Palmer > > Sent: Sunday, August 16, 2020 5:00 AM > > To: Andy Shevchenko <andy.shevchenko@gmail.com> > > Cc: linux-iio <linux-iio@vger.kernel.org>; Jonathan Cameron > > <jic23@kernel.org> > > Subject: Re: [RFC PATCH 2/2] iio: st-accel: Add support for Silan SC7A20 and > > SC7A30E > > > > Hi Andy, > > > > On Sun, 16 Aug 2020 at 18:55, Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > No SoB tag?! Hint: `git commit -a -s --amend` would fix this if you > > > have properly configured Git. > > > > > > > Sorry I wasn't aware it was needed for an RFC. > > > > > On top of that, can you add Datasheet: tag with links to the actual > > > component datasheets? > > > > I will do that for the v1 of the patch series. All of the datasheets I've found so > > far are mostly Chinese but the register tables are in English. I've collected > > them together > > here: http://linux-chenxing.org/silan/index.html > > > > Cheers, > > > > Daniel
On Thu, Aug 20, 2020 at 10:01:00AM +0100, Jonathan Cameron wrote: > > +CC: GregKH as this will pass through his tree. > > As a quick summary, it seems we have some cloned parts that appear to be compatible > with certain ST micro parts, but have different whoami address values. > > Entirely reasonably, Denis is not happy to have them added to the ST maintained driver > given the potential for future incompatibilities. > > I don't particularly mind a separate driver, though I would ask that we remove > a lot of the abstractions from the ST driver as they won't be necessary given > the much more restricted parts being supported, > > Greg, I'm guessing this is far from the first time this has happened. > Any advise? Yes, this happens all the time. Do not create a whole new driver if at all possible, that way lies duplicated work and madness. Just add the new ids or whatever to the existing driver and have everyone work with it together. "future incompatibilities" are never something to plan for, we can deal with that when/if that ever happens. thanks, greg k-h
Hi Denis, On Thu, 20 Aug 2020 at 03:19, Denis CIOCCA <denis.ciocca@st.com> wrote: > I strongly disagree that these parts will be supported by STMicroelectronics driver. The alternative seems to be write a totally new driver that does exactly the same thing, use a lot of people's time to get it ready to go into the kernel etc when we could come up with a way to allow the driver to accept a different WAI register value in a non-intrusive way that can go in the bin at a later date if it turns out supporting these chips is too much hassle. > We DO NOT want to find out one day that we need to modify our structure in order to support competition. I think Jonathan suggested adding me as a reviewer for these parts thus making me responsible for them. I'm fine with that. If it comes to the point where the driver changes so much that it's not possible to keep them working then you'd have my blessing to just remove support for them. That said I'm not going to force this on anyone. This patch was a spin-off of a personal project to try to make cheap Linux capable SoCs available to makers[0]. One of the devices I used to reverse engineer that hardware had one of these Silan parts, I noticed the registers looked exactly the same as ST parts supported in the kernel already and upon testing they worked so I thought it was worth throwing this out there. If you guys don't want to deal with it I'll just leave it in my tree. >If they need to support this chip, please provide a new driver for that part leaving STMicroelectronics driver managing our parts. To be clear I'm not working for Silan and I doubt they have any interest in supporting these parts. There are hacky drivers for them in 3.x kernels that some vendors are still using and that's probably as much as they care. Thanks, Daniel [0] - https://github.com/breadbee/breadbee
On Wed, Aug 19, 2020 at 9:19 PM Denis CIOCCA <denis.ciocca@st.com> wrote: > > Hi Jonathan, > > I strongly disagree that these parts will be supported by STMicroelectronics driver. > We DO NOT want to find out one day that we need to modify our structure in order to support competition. If they need to support this chip, please provide a new driver for that part leaving STMicroelectronics driver managing our parts. I'm not sure I understand this passage. Are you telling we have to have Amount_of_Vendors * cloned_component drivers? This is NOT how Linux kernel works, really. Look at the pca953x GPIO expander driver, for example. It has tons of clones supported and no-one died. > > On Sun, 16 Aug 2020 at 18:55, Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > No SoB tag?! Hint: `git commit -a -s --amend` would fix this if you > > > have properly configured Git. > > > > > > > Sorry I wasn't aware it was needed for an RFC. > > > > > On top of that, can you add Datasheet: tag with links to the actual > > > component datasheets? > > > > I will do that for the v1 of the patch series. All of the datasheets I've found so > > far are mostly Chinese but the register tables are in English. I've collected > > them together > > here: http://linux-chenxing.org/silan/index.html
On Thu, Aug 20, 2020 at 3:27 PM Daniel Palmer <daniel@0x0f.com> wrote: > On Thu, 20 Aug 2020 at 03:19, Denis CIOCCA <denis.ciocca@st.com> wrote: > > > I strongly disagree that these parts will be supported by STMicroelectronics driver. > > The alternative seems to be write a totally new driver that does > exactly the same thing, use a lot of people's time to get it ready to > go into the kernel etc when we could come up with a way to allow the > driver to accept a different WAI register value in a non-intrusive way > that can go in the bin at a later date if it turns out supporting > these chips is too much hassle. Which is fine with me, I mean adding an ID is a common practice for competing hardware clones. > > We DO NOT want to find out one day that we need to modify our structure in order to support competition. > > I think Jonathan suggested adding me as a reviewer for these parts > thus making me responsible for them. > I'm fine with that. If it comes to the point where the driver changes > so much that it's not possible to keep them working then you'd have my > blessing to just remove support for them. I encourage you to do this. I guess it's much better if we have someone, than orphaned code in the kernel. > That said I'm not going to force this on anyone. > This patch was a spin-off of a personal project to try to make cheap > Linux capable SoCs available to makers[0]. And again full support from me here. It's a really very strange position of STMicro here. I as a maintainer / reviewer / supporter of a lot of hardware have a good example of collaboration with contributors from other companies when they do improve our drivers. And I have been doing the same for others, for example Synopsys DesignWare SATA driver which had been found on PPC44x platform. > One of the devices I used > to reverse engineer that hardware had one of these Silan parts, I > noticed the registers looked exactly the same as ST parts supported in > the kernel already and upon testing they worked so I thought it was > worth throwing this out there. If you guys don't want to deal with it > I'll just leave it in my tree. > [0] - https://github.com/breadbee/breadbee
diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h index 5d356288e001..784c2df83dde 100644 --- a/drivers/iio/accel/st_accel.h +++ b/drivers/iio/accel/st_accel.h @@ -36,6 +36,8 @@ enum st_accel_type { LIS3DHH, LIS2DE12, LIS2HH12, + SC7A20, + SC7A30E, ST_ACCEL_MAX, }; @@ -61,6 +63,8 @@ enum st_accel_type { #define LIS3DE_ACCEL_DEV_NAME "lis3de" #define LIS2DE12_ACCEL_DEV_NAME "lis2de12" #define LIS2HH12_ACCEL_DEV_NAME "lis2hh12" +#define SC7A20_ACCEL_DEV_NAME "sc7a20" +#define SC7A30E_ACCEL_DEV_NAME "sc7a30e" /** * struct st_sensors_platform_data - default accel platform data diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c index 43c50167d220..23fdbf27d44c 100644 --- a/drivers/iio/accel/st_accel_core.c +++ b/drivers/iio/accel/st_accel_core.c @@ -980,7 +980,164 @@ static const struct st_sensor_settings st_accel_sensors_settings[] = { .multi_read_bit = true, .bootime = 2, }, - + { + .wai = 0x11, + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS, + .sensors_supported = { + [0] = SC7A20_ACCEL_DEV_NAME, + }, + .ch = (struct iio_chan_spec *)st_accel_12bit_channels, + .odr = { + .addr = 0x20, + .mask = 0xf0, + .odr_avl = { + { .hz = 1, .value = 0x01, }, + { .hz = 10, .value = 0x02, }, + { .hz = 25, .value = 0x03, }, + { .hz = 50, .value = 0x04, }, + { .hz = 100, .value = 0x05, }, + { .hz = 200, .value = 0x06, }, + { .hz = 400, .value = 0x07, }, + { .hz = 1600, .value = 0x08, }, + }, + }, + .pw = { + .addr = 0x20, + .mask = 0xf0, + .value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE, + }, + .enable_axis = { + .addr = ST_SENSORS_DEFAULT_AXIS_ADDR, + .mask = ST_SENSORS_DEFAULT_AXIS_MASK, + }, + .fs = { + .addr = 0x23, + .mask = 0x30, + .fs_avl = { + [0] = { + .num = ST_ACCEL_FS_AVL_2G, + .value = 0x00, + .gain = IIO_G_TO_M_S_2(1000), + }, + [1] = { + .num = ST_ACCEL_FS_AVL_4G, + .value = 0x01, + .gain = IIO_G_TO_M_S_2(2000), + }, + [2] = { + .num = ST_ACCEL_FS_AVL_8G, + .value = 0x02, + .gain = IIO_G_TO_M_S_2(4000), + }, + [3] = { + .num = ST_ACCEL_FS_AVL_16G, + .value = 0x03, + .gain = IIO_G_TO_M_S_2(12000), + }, + }, + }, + .bdu = { + .addr = 0x23, + .mask = 0x80, + }, + .drdy_irq = { + .int1 = { + .addr = 0x22, + .mask = 0x10, + }, + .addr_ihl = 0x25, + .mask_ihl = 0x02, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, + }, + .sim = { + .addr = 0x23, + .value = BIT(0), + }, + .multi_read_bit = true, + .bootime = 2, + }, + { + .wai = 0x33, + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS, + .sensors_supported = { + [0] = SC7A30E_ACCEL_DEV_NAME, + }, + .ch = (struct iio_chan_spec *)st_accel_12bit_channels, + .odr = { + .addr = 0x20, + .mask = 0xf0, + .odr_avl = { + { .hz = 1, .value = 0x01, }, + { .hz = 10, .value = 0x02, }, + { .hz = 25, .value = 0x03, }, + { .hz = 50, .value = 0x04, }, + { .hz = 100, .value = 0x05, }, + { .hz = 200, .value = 0x06, }, + { .hz = 400, .value = 0x07, }, + { .hz = 1600, .value = 0x08, }, + }, + }, + .pw = { + .addr = 0x20, + .mask = 0xf0, + .value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE, + }, + .enable_axis = { + .addr = ST_SENSORS_DEFAULT_AXIS_ADDR, + .mask = ST_SENSORS_DEFAULT_AXIS_MASK, + }, + .fs = { + .addr = 0x23, + .mask = 0x30, + .fs_avl = { + [0] = { + .num = ST_ACCEL_FS_AVL_2G, + .value = 0x00, + .gain = IIO_G_TO_M_S_2(1000), + }, + [1] = { + .num = ST_ACCEL_FS_AVL_4G, + .value = 0x01, + .gain = IIO_G_TO_M_S_2(2000), + }, + [2] = { + .num = ST_ACCEL_FS_AVL_8G, + .value = 0x02, + .gain = IIO_G_TO_M_S_2(4000), + }, + [3] = { + .num = ST_ACCEL_FS_AVL_16G, + .value = 0x03, + .gain = IIO_G_TO_M_S_2(12000), + }, + }, + }, + .bdu = { + .addr = 0x23, + .mask = 0x80, + }, + .drdy_irq = { + .int1 = { + .addr = 0x22, + .mask = 0x10, + }, + .addr_ihl = 0x25, + .mask_ihl = 0x02, + .stat_drdy = { + .addr = ST_SENSORS_DEFAULT_STAT_ADDR, + .mask = 0x07, + }, + }, + .sim = { + .addr = 0x23, + .value = BIT(0), + }, + .multi_read_bit = true, + .bootime = 2, + }, }; static int st_accel_read_raw(struct iio_dev *indio_dev, diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c index 360e16f2cadb..2c9e91ef5e19 100644 --- a/drivers/iio/accel/st_accel_i2c.c +++ b/drivers/iio/accel/st_accel_i2c.c @@ -108,6 +108,14 @@ static const struct of_device_id st_accel_of_match[] = { .compatible = "st,lis2hh12", .data = LIS2HH12_ACCEL_DEV_NAME, }, + { + .compatible = "silan,sc7a20-accel", + .data = SC7A20_ACCEL_DEV_NAME, + }, + { + .compatible = "silan,sc7a30e-accel", + .data = SC7A30E_ACCEL_DEV_NAME, + }, {}, }; MODULE_DEVICE_TABLE(of, st_accel_of_match); @@ -143,6 +151,8 @@ static const struct i2c_device_id st_accel_id_table[] = { { LIS3DE_ACCEL_DEV_NAME }, { LIS2DE12_ACCEL_DEV_NAME }, { LIS2HH12_ACCEL_DEV_NAME }, + { SC7A20_ACCEL_DEV_NAME }, + { SC7A30E_ACCEL_DEV_NAME }, {}, }; MODULE_DEVICE_TABLE(i2c, st_accel_id_table);