diff mbox series

[RFC,2/2] iio: st-accel: Add support for Silan SC7A20 and SC7A30E

Message ID 20200811134846.3981475-3-daniel@0x0f.com
State New
Headers show
Series iio: st-accel: Add support for Silan clones | expand

Commit Message

Daniel Palmer Aug. 11, 2020, 1:48 p.m. UTC
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.
---
 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(-)

Comments

Jonathan Cameron Aug. 16, 2020, 8:52 a.m. UTC | #1
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);
Daniel Palmer Aug. 16, 2020, 9:27 a.m. UTC | #2
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
Jonathan Cameron Aug. 16, 2020, 9:40 a.m. UTC | #3
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
Andy Shevchenko Aug. 16, 2020, 9:55 a.m. UTC | #4
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?
Daniel Palmer Aug. 16, 2020, 11:59 a.m. UTC | #5
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
Denis CIOCCA Aug. 19, 2020, 6:19 p.m. UTC | #6
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
Jonathan Cameron Aug. 20, 2020, 9:01 a.m. UTC | #7
+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
Greg Kroah-Hartman Aug. 20, 2020, 9:17 a.m. UTC | #8
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
Daniel Palmer Aug. 20, 2020, 12:27 p.m. UTC | #9
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
Andy Shevchenko Aug. 20, 2020, 12:34 p.m. UTC | #10
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
Andy Shevchenko Aug. 20, 2020, 12:56 p.m. UTC | #11
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 mbox series

Patch

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);