[PATCH v2 0/8] Support ROHM KX134ACR-LBZ

[PATCH v2 0/8] Support ROHM KX134ACR-LBZ

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

This patch series introduces support for ROHM KX134ACR-LBZ and
KX134-1211 accelerometers.

The KX134ACR-LBZ is almost identical to the KX132ACR-LBZ. Similarly the
KX134-1211 is almost identical to the KX132-1211. The differencies
visible to the driver are different g-ranges and the "Who am I"
-identification register's values.

This series does also convert parts of the GTS helpers and the kx022a
driver to use __cleanup - based scoped free/unlock operations, and fixes
the value of required wait time after sensor reset. The wait time value
fixup is cosmetic/documentational, as the time that has been slept has
likely been larger than required due to the msleep() implementation.

Revision history:
v1 => v2:
 - Rebased on iio-fixes to avoid conflicts with queued fixes.
 - Added the reset delay change to the series to avoid conflicts. Was
   previously sent as an individual patch:
   https://lore.kernel.org/all/ZzWfXbjaDkFnu_Jg@mva-rohm/
 - Added support for kx134-1211

The v1 can be found from:
https://lore.kernel.org/all/cover.1731495937.git.mazziesaccount@gmail.com/


The patch 1/8 is the delay fixup mentioned above.

The patch 2/8 contains GTS helper change, which is independent from the
rest of the series. It can be applied/rejected independently.

Patch 3/8 changes kx022a to use scoped mutexes. It can also be applied
as an independent improvement even if the kx134acr-lbz support was not
added.

Patch 4/8 adds mechanisms for supporting sensors with different
g-ranges in the kx022a driver.

5-8/8 add support for new hardware, kx134acr-lbz and kx134-1211.

---

Matti Vaittinen (8):
  iio: accel: kx022a: Improve reset delay
  iio: gts: Simplify using __free
  iio: accel: kx022a: Use cleanup.h helpers
  iio: accel: kx022a: Support ICs with different G-ranges
  dt-bindings: ROHM KX134ACR-LBZ
  iio: kx022a: Support ROHM KX134ACR-LBZ
  dt-bindings: iio: kx022a: Support KX134-1211
  iio: accel: kx022a: Support KX134-1211

 .../bindings/iio/accel/kionix,kx022a.yaml     |  11 +-
 drivers/iio/accel/kionix-kx022a-i2c.c         |   4 +
 drivers/iio/accel/kionix-kx022a-spi.c         |   4 +
 drivers/iio/accel/kionix-kx022a.c             | 170 ++++++++++++------
 drivers/iio/accel/kionix-kx022a.h             |   6 +
 drivers/iio/industrialio-gts-helper.c         |  19 +-
 6 files changed, 147 insertions(+), 67 deletions(-)

-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 1/8] iio: accel: kx022a: Improve reset delay

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]

All the sensors supported by kx022a driver seemed to require some delay
after software reset to be operational again. More or less a random
msleep(1) was added to cause the driver to go to sleep so the sensor has
time to become operational again.

Now we have official docuumentation available:
https://fscdn.rohm.com/kionix/en/document/AN010_KX022ACR-Z_Power-on_Procedure_E.pdf
https://fscdn.rohm.com/kionix/en/document/TN027-Power-On-Procedure.pdf
https://fscdn.rohm.com/kionix/en/document/AN011_KX134ACR-LBZ_Power-on_Procedure_E.pdf

stating the required time is 2 ms.

Due to the nature of the current msleep implementation, the msleep(1) is
likely to be sleeping more than 2ms already - but the value "1" is
misleading in case someone needs to optimize the start time and change
the msleep to a more accurate delay. Hence it is better for
"documentation" purposes to use value which actually reflects the
specified 2ms wait time.

Change the value of delay after software reset to match the
specifications and add links to the power-on procedure specifications.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:
  - Included in the series of improvements (was a separate patch)
  - rebased on iio/testing to avoid conflicts with queued fixes
---
 drivers/iio/accel/kionix-kx022a.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
index 53261e1d5d1f..b6664299e0d5 100644
--- a/drivers/iio/accel/kionix-kx022a.c
+++ b/drivers/iio/accel/kionix-kx022a.c
@@ -1121,10 +1121,15 @@ static int kx022a_chip_init(struct kx022a_data *data)
 		return ret;
 
 	/*
-	 * I've seen I2C read failures if we poll too fast after the sensor
-	 * reset. Slight delay gives I2C block the time to recover.
+	 * According to the power-on procedure documents, there is (at least)
+	 * 2ms delay required after the software reset. This should be same for
+	 * all, KX022ACR-Z, KX132-1211, KX132ACR-LBZ and KX134ACR-LBZ.
+	 *
+	 * https://fscdn.rohm.com/kionix/en/document/AN010_KX022ACR-Z_Power-on_Procedure_E.pdf
+	 * https://fscdn.rohm.com/kionix/en/document/TN027-Power-On-Procedure.pdf
+	 * https://fscdn.rohm.com/kionix/en/document/AN011_KX134ACR-LBZ_Power-on_Procedure_E.pdf
 	 */
-	msleep(1);
+	msleep(2);
 
 	ret = regmap_read_poll_timeout(data->regmap, data->chip_info->cntl2, val,
 				       !(val & KX022A_MASK_SRST),
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/8] iio: accel: kx022a: Improve reset delay

[Jonathan Cameron]

On Thu, 21 Nov 2024 10:19:50 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> All the sensors supported by kx022a driver seemed to require some delay
> after software reset to be operational again. More or less a random
> msleep(1) was added to cause the driver to go to sleep so the sensor has
> time to become operational again.
> 
> Now we have official docuumentation available:
> https://fscdn.rohm.com/kionix/en/document/AN010_KX022ACR-Z_Power-on_Procedure_E.pdf
> https://fscdn.rohm.com/kionix/en/document/TN027-Power-On-Procedure.pdf
> https://fscdn.rohm.com/kionix/en/document/AN011_KX134ACR-LBZ_Power-on_Procedure_E.pdf
> 
> stating the required time is 2 ms.
> 
> Due to the nature of the current msleep implementation, the msleep(1) is
> likely to be sleeping more than 2ms already - but the value "1" is
> misleading in case someone needs to optimize the start time and change
> the msleep to a more accurate delay. Hence it is better for
> "documentation" purposes to use value which actually reflects the
> specified 2ms wait time.
> 
> Change the value of delay after software reset to match the
> specifications and add links to the power-on procedure specifications.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Stands fine on it's own so applied (before I've even read the rest of the series).

Jonathan

[PATCH v2 2/8] iio: gts: Simplify using __free

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

The error path in the gain_to_scaletables() uses goto for unwinding an
allocation on failure. This can be slightly simplified by using the
automated free when exiting the scope.

Use __free(kfree) and drop the goto based error handling.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:
  - patch number changed because a change was added to the series.
  - rebased on iio/testing to avoid conflicts with queued fixes
---
 drivers/iio/industrialio-gts-helper.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/industrialio-gts-helper.c b/drivers/iio/industrialio-gts-helper.c
index 291c0fc332c9..602d3d338e66 100644
--- a/drivers/iio/industrialio-gts-helper.c
+++ b/drivers/iio/industrialio-gts-helper.c
@@ -4,6 +4,7 @@
  * Copyright (c) 2023 Matti Vaittinen <mazziesaccount@gmail.com>
  */
 
+#include <linux/cleanup.h>
 #include <linux/device.h>
 #include <linux/errno.h>
 #include <linux/export.h>
@@ -167,8 +168,8 @@ static int iio_gts_gain_cmp(const void *a, const void *b)
 
 static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
 {
-	int i, j, new_idx, time_idx, ret = 0;
-	int *all_gains;
+	int ret, i, j, new_idx, time_idx;
+	int *all_gains __free(kfree) = NULL;
 	size_t gain_bytes;
 
 	for (i = 0; i < gts->num_itime; i++) {
@@ -232,10 +233,9 @@ static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
 
 	gts->avail_all_scales_table = kcalloc(new_idx, 2 * sizeof(int),
 					      GFP_KERNEL);
-	if (!gts->avail_all_scales_table) {
-		ret = -ENOMEM;
-		goto free_out;
-	}
+	if (!gts->avail_all_scales_table)
+		return -ENOMEM;
+
 	gts->num_avail_all_scales = new_idx;
 
 	for (i = 0; i < gts->num_avail_all_scales; i++) {
@@ -246,14 +246,11 @@ static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
 		if (ret) {
 			kfree(gts->avail_all_scales_table);
 			gts->num_avail_all_scales = 0;
-			goto free_out;
+			return ret;
 		}
 	}
 
-free_out:
-	kfree(all_gains);
-
-	return ret;
+	return 0;
 }
 
 /**
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 2/8] iio: gts: Simplify using __free

[Jonathan Cameron]

On Thu, 21 Nov 2024 10:20:07 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> The error path in the gain_to_scaletables() uses goto for unwinding an
> allocation on failure. This can be slightly simplified by using the
> automated free when exiting the scope.
> 
> Use __free(kfree) and drop the goto based error handling.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> 
> ---
> 
> Revision history:
>   v1 => v2:
>   - patch number changed because a change was added to the series.
>   - rebased on iio/testing to avoid conflicts with queued fixes
> ---
>  drivers/iio/industrialio-gts-helper.c | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/iio/industrialio-gts-helper.c b/drivers/iio/industrialio-gts-helper.c
> index 291c0fc332c9..602d3d338e66 100644
> --- a/drivers/iio/industrialio-gts-helper.c
> +++ b/drivers/iio/industrialio-gts-helper.c
> @@ -4,6 +4,7 @@
>   * Copyright (c) 2023 Matti Vaittinen <mazziesaccount@gmail.com>
>   */
>  
> +#include <linux/cleanup.h>
>  #include <linux/device.h>
>  #include <linux/errno.h>
>  #include <linux/export.h>
> @@ -167,8 +168,8 @@ static int iio_gts_gain_cmp(const void *a, const void *b)
>  
>  static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
>  {
> -	int i, j, new_idx, time_idx, ret = 0;
> -	int *all_gains;
> +	int ret, i, j, new_idx, time_idx;
> +	int *all_gains __free(kfree) = NULL;
See the docs in cleanup.h (added recently).

Constructor and destructor should go together.   Dan wrote good docs on this
(which are now in cleanup.h) so I'll not go into why!

Upshot is this goes where you do the kcalloc, not up here.

>  	size_t gain_bytes;
>  
>  	for (i = 0; i < gts->num_itime; i++) {
> @@ -232,10 +233,9 @@ static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
>  
>  	gts->avail_all_scales_table = kcalloc(new_idx, 2 * sizeof(int),
>  					      GFP_KERNEL);
> -	if (!gts->avail_all_scales_table) {
> -		ret = -ENOMEM;
> -		goto free_out;
> -	}
> +	if (!gts->avail_all_scales_table)
> +		return -ENOMEM;
> +
>  	gts->num_avail_all_scales = new_idx;
>  
>  	for (i = 0; i < gts->num_avail_all_scales; i++) {
> @@ -246,14 +246,11 @@ static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
>  		if (ret) {
>  			kfree(gts->avail_all_scales_table);
>  			gts->num_avail_all_scales = 0;
> -			goto free_out;
> +			return ret;
>  		}
>  	}
>  
> -free_out:
> -	kfree(all_gains);
> -
> -	return ret;
> +	return 0;
>  }
>  
>  /**

Re: [PATCH v2 2/8] iio: gts: Simplify using __free

[Matti Vaittinen]

Hi Jonathan,

Thanks once again for the review :)

On 23/11/2024 18:37, Jonathan Cameron wrote:
> On Thu, 21 Nov 2024 10:20:07 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> The error path in the gain_to_scaletables() uses goto for unwinding an
>> allocation on failure. This can be slightly simplified by using the
>> automated free when exiting the scope.
>>
>> Use __free(kfree) and drop the goto based error handling.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---
>>
>> Revision history:
>>    v1 => v2:
>>    - patch number changed because a change was added to the series.
>>    - rebased on iio/testing to avoid conflicts with queued fixes
>> ---
>>   drivers/iio/industrialio-gts-helper.c | 19 ++++++++-----------
>>   1 file changed, 8 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iio/industrialio-gts-helper.c b/drivers/iio/industrialio-gts-helper.c
>> index 291c0fc332c9..602d3d338e66 100644
>> --- a/drivers/iio/industrialio-gts-helper.c
>> +++ b/drivers/iio/industrialio-gts-helper.c
>> @@ -4,6 +4,7 @@
>>    * Copyright (c) 2023 Matti Vaittinen <mazziesaccount@gmail.com>
>>    */
>>   
>> +#include <linux/cleanup.h>
>>   #include <linux/device.h>
>>   #include <linux/errno.h>
>>   #include <linux/export.h>
>> @@ -167,8 +168,8 @@ static int iio_gts_gain_cmp(const void *a, const void *b)
>>   
>>   static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
>>   {
>> -	int i, j, new_idx, time_idx, ret = 0;
>> -	int *all_gains;
>> +	int ret, i, j, new_idx, time_idx;
>> +	int *all_gains __free(kfree) = NULL;
> See the docs in cleanup.h (added recently).
> 
> Constructor and destructor should go together.   Dan wrote good docs on this
> (which are now in cleanup.h) so I'll not go into why!

I went through the cleanup.h, and noticed the nice explanation for the 
pitfall where we have multiple "scoped operations" with specific 
ordering required. I didn't see other reasoning beyond that - I do hope 
I didn't miss anything.

I find introducing variables mid-function very confusing. Only exception 
for this has been introducing temporary variables at the start of a 
block, to reduce the scope. I would still like to avoid this when it 
isn't absolutely necessary, as it bleeds my eyes :)

I really don't see why we would have other cleanups which required 
specific ordering with the allocated "all_gains".

Anyways, if you think we really have a problem here, would it then 
suffice if I moved the:

         gain_bytes = array_size(gts->num_hwgain, sizeof(int));
         all_gains = kcalloc(gts->num_itime, gain_bytes, GFP_KERNEL);
         if (!all_gains)
                 return -ENOMEM;

to the beginning of the function, and the "int *all_gains __free(kfree) 
= NULL;" as last variable declaration?

(This is not optimal as we will then do the allocation even if 
converting gains to scales failed - but I don't think this is a real 
problem as this should never happen after the driver is proven working 
for the first time).

> Upshot is this goes where you do the kcalloc, not up here.

*whining* "but, but, but ... it is ugly..." :)

Yours,
	-- Matti

Re: [PATCH v2 2/8] iio: gts: Simplify using __free

[Jonathan Cameron]

On Mon, 25 Nov 2024 11:16:22 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> Hi Jonathan,
> 
> Thanks once again for the review :)
> 
> On 23/11/2024 18:37, Jonathan Cameron wrote:
> > On Thu, 21 Nov 2024 10:20:07 +0200
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >   
> >> The error path in the gain_to_scaletables() uses goto for unwinding an
> >> allocation on failure. This can be slightly simplified by using the
> >> automated free when exiting the scope.
> >>
> >> Use __free(kfree) and drop the goto based error handling.
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >>
> >> ---
> >>
> >> Revision history:
> >>    v1 => v2:
> >>    - patch number changed because a change was added to the series.
> >>    - rebased on iio/testing to avoid conflicts with queued fixes
> >> ---
> >>   drivers/iio/industrialio-gts-helper.c | 19 ++++++++-----------
> >>   1 file changed, 8 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/iio/industrialio-gts-helper.c b/drivers/iio/industrialio-gts-helper.c
> >> index 291c0fc332c9..602d3d338e66 100644
> >> --- a/drivers/iio/industrialio-gts-helper.c
> >> +++ b/drivers/iio/industrialio-gts-helper.c
> >> @@ -4,6 +4,7 @@
> >>    * Copyright (c) 2023 Matti Vaittinen <mazziesaccount@gmail.com>
> >>    */
> >>   
> >> +#include <linux/cleanup.h>
> >>   #include <linux/device.h>
> >>   #include <linux/errno.h>
> >>   #include <linux/export.h>
> >> @@ -167,8 +168,8 @@ static int iio_gts_gain_cmp(const void *a, const void *b)
> >>   
> >>   static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
> >>   {
> >> -	int i, j, new_idx, time_idx, ret = 0;
> >> -	int *all_gains;
> >> +	int ret, i, j, new_idx, time_idx;
> >> +	int *all_gains __free(kfree) = NULL;  
> > See the docs in cleanup.h (added recently).
> > 
> > Constructor and destructor should go together.   Dan wrote good docs on this
> > (which are now in cleanup.h) so I'll not go into why!  
> 
> I went through the cleanup.h, and noticed the nice explanation for the 
> pitfall where we have multiple "scoped operations" with specific 
> ordering required. I didn't see other reasoning beyond that - I do hope 
> I didn't miss anything.
> 
> I find introducing variables mid-function very confusing. Only exception 
> for this has been introducing temporary variables at the start of a 
> block, to reduce the scope. I would still like to avoid this when it 
> isn't absolutely necessary, as it bleeds my eyes :)
> 
> I really don't see why we would have other cleanups which required 
> specific ordering with the allocated "all_gains".
> 
> Anyways, if you think we really have a problem here, would it then 
> suffice if I moved the:
> 
>          gain_bytes = array_size(gts->num_hwgain, sizeof(int));
>          all_gains = kcalloc(gts->num_itime, gain_bytes, GFP_KERNEL);
>          if (!all_gains)
>                  return -ENOMEM;
> 
> to the beginning of the function, and the "int *all_gains __free(kfree) 
> = NULL;" as last variable declaration?
> 

No.  You need to follow the standard way. It is something we are
all getting used to, but all use of cleanup.h needs to follow same rules
so that reviewers find it easy to review once they are seeing lots of
instances of it.

Many indeed find this ugly but reality is it's happening all over the place
just usually hidden in a macro.  From cleanup.h look at how
guard() works for instance.


Jonathan

> (This is not optimal as we will then do the allocation even if 
> converting gains to scales failed - but I don't think this is a real 
> problem as this should never happen after the driver is proven working 
> for the first time).
> 
> > Upshot is this goes where you do the kcalloc, not up here.  
> 
> *whining* "but, but, but ... it is ugly..." :)

:)  It won't look ugly after a few years!
> 
> Yours,
> 	-- Matti

Re: [PATCH v2 2/8] iio: gts: Simplify using __free

[Matti Vaittinen]

Hi & Thanks Jonathan,

On 26/11/2024 19:52, Jonathan Cameron wrote:
> On Mon, 25 Nov 2024 11:16:22 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> Hi Jonathan,
>>
>> Thanks once again for the review :)
>>
>> On 23/11/2024 18:37, Jonathan Cameron wrote:
>>> On Thu, 21 Nov 2024 10:20:07 +0200
>>> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>>>    
>>>> The error path in the gain_to_scaletables() uses goto for unwinding an
>>>> allocation on failure. This can be slightly simplified by using the
>>>> automated free when exiting the scope.
>>>>
>>>> Use __free(kfree) and drop the goto based error handling.
>>>>
>>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>>>
>>>> ---
>>>>
>>>> Revision history:
>>>>     v1 => v2:
>>>>     - patch number changed because a change was added to the series.
>>>>     - rebased on iio/testing to avoid conflicts with queued fixes
>>>> ---
>>>>    drivers/iio/industrialio-gts-helper.c | 19 ++++++++-----------
>>>>    1 file changed, 8 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/iio/industrialio-gts-helper.c b/drivers/iio/industrialio-gts-helper.c
>>>> index 291c0fc332c9..602d3d338e66 100644
>>>> --- a/drivers/iio/industrialio-gts-helper.c
>>>> +++ b/drivers/iio/industrialio-gts-helper.c
>>>> @@ -4,6 +4,7 @@
>>>>     * Copyright (c) 2023 Matti Vaittinen <mazziesaccount@gmail.com>
>>>>     */
>>>>    
>>>> +#include <linux/cleanup.h>
>>>>    #include <linux/device.h>
>>>>    #include <linux/errno.h>
>>>>    #include <linux/export.h>
>>>> @@ -167,8 +168,8 @@ static int iio_gts_gain_cmp(const void *a, const void *b)
>>>>    
>>>>    static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
>>>>    {
>>>> -	int i, j, new_idx, time_idx, ret = 0;
>>>> -	int *all_gains;
>>>> +	int ret, i, j, new_idx, time_idx;
>>>> +	int *all_gains __free(kfree) = NULL;
>>> See the docs in cleanup.h (added recently).
>>>
>>> Constructor and destructor should go together.   Dan wrote good docs on this
>>> (which are now in cleanup.h) so I'll not go into why!
>>
>> I went through the cleanup.h, and noticed the nice explanation for the
>> pitfall where we have multiple "scoped operations" with specific
>> ordering required. I didn't see other reasoning beyond that - I do hope
>> I didn't miss anything.
>>
>> I find introducing variables mid-function very confusing. Only exception
>> for this has been introducing temporary variables at the start of a
>> block, to reduce the scope. I would still like to avoid this when it
>> isn't absolutely necessary, as it bleeds my eyes :)
>>
>> I really don't see why we would have other cleanups which required
>> specific ordering with the allocated "all_gains".
>>
>> Anyways, if you think we really have a problem here, would it then
>> suffice if I moved the:
>>
>>           gain_bytes = array_size(gts->num_hwgain, sizeof(int));
>>           all_gains = kcalloc(gts->num_itime, gain_bytes, GFP_KERNEL);
>>           if (!all_gains)
>>                   return -ENOMEM;
>>
>> to the beginning of the function, and the "int *all_gains __free(kfree)
>> = NULL;" as last variable declaration?
>>
> 
> No.  You need to follow the standard way. It is something we are
> all getting used to, but all use of cleanup.h needs to follow same rules
> so that reviewers find it easy to review once they are seeing lots of
> instances of it.
> 
> Many indeed find this ugly but reality is it's happening all over the place
> just usually hidden in a macro.  From cleanup.h look at how
> guard() works for instance.

Well, those macros are better in that the variables they internally 
declare aren't visible in the outside code. The 'all_gains' pointer is 
used throughout the function, and I really dislike having local 
variables which aren't declared at the beginning of a function/block 
emerge out of nowhere. Makes me think: "why this terribly named global?".

Well, maybe I really just need to try to adapt these things but I will 
drop this one out of the series for now. TBH, I don't really like how 
this table building function looks like. It's too long and confusing. I 
will see if there is a sane way to split it, and maybe get the __free() 
pointers to the beginning of a function as well ;)

>> (This is not optimal as we will then do the allocation even if
>> converting gains to scales failed - but I don't think this is a real
>> problem as this should never happen after the driver is proven working
>> for the first time).
>>
>>> Upshot is this goes where you do the kcalloc, not up here.
>>
>> *whining* "but, but, but ... it is ugly..." :)
> 
> :)  It won't look ugly after a few years!

Could be. But now I am in the middle of "everything used to be better in 
the good old day" -crisis. Playing 8-bit NES games and wondering if I 
could fix my old C64 ^_^;

In any case, thanks for the guidance (and optimism!) XD

Yours,
	-- Matti

[PATCH v2 3/8] iio: accel: kx022a: Use cleanup.h helpers

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5233 bytes --]

A few functions in KX022A need to use mutex for protecting the
enabling/disabling of the measurement while configurations are being
made. Some of the functions can be slightly simplified by using the
__cleanup based scoped mutexes, which allows dropping the goto based
unlocking at error path.

Simplify error paths using guard(mutex).

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:
  - patch number changed because a change was added to the series.
  - rebased on iio/testing to avoid conflicts with queued fixes
---
 drivers/iio/accel/kionix-kx022a.c | 61 ++++++++++++-------------------
 1 file changed, 23 insertions(+), 38 deletions(-)

diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
index b6664299e0d5..98953178a580 100644
--- a/drivers/iio/accel/kionix-kx022a.c
+++ b/drivers/iio/accel/kionix-kx022a.c
@@ -5,6 +5,7 @@
  * ROHM/KIONIX accelerometer driver
  */
 
+#include <linux/cleanup.h>
 #include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/interrupt.h>
@@ -448,7 +449,7 @@ static void kx022a_reg2scale(unsigned int val, unsigned int *val1,
 	*val2 = kx022a_scale_table[val][1];
 }
 
-static int kx022a_turn_on_off_unlocked(struct kx022a_data *data, bool on)
+static int __kx022a_turn_on_off(struct kx022a_data *data, bool on)
 {
 	int ret;
 
@@ -469,7 +470,7 @@ static int kx022a_turn_off_lock(struct kx022a_data *data)
 	int ret;
 
 	mutex_lock(&data->mutex);
-	ret = kx022a_turn_on_off_unlocked(data, false);
+	ret = __kx022a_turn_on_off(data, false);
 	if (ret)
 		mutex_unlock(&data->mutex);
 
@@ -480,7 +481,7 @@ static int kx022a_turn_on_unlock(struct kx022a_data *data)
 {
 	int ret;
 
-	ret = kx022a_turn_on_off_unlocked(data, true);
+	ret = __kx022a_turn_on_off(data, true);
 	mutex_unlock(&data->mutex);
 
 	return ret;
@@ -912,18 +913,19 @@ static int kx022a_fifo_disable(struct kx022a_data *data)
 {
 	int ret = 0;
 
-	ret = kx022a_turn_off_lock(data);
+	guard(mutex)(&data->mutex);
+	ret = __kx022a_turn_on_off(data, false);
 	if (ret)
 		return ret;
 
 	ret = regmap_clear_bits(data->regmap, data->ien_reg, KX022A_MASK_WMI);
 	if (ret)
-		goto unlock_out;
+		return ret;
 
 	ret = regmap_clear_bits(data->regmap, data->chip_info->buf_cntl2,
 				KX022A_MASK_BUF_EN);
 	if (ret)
-		goto unlock_out;
+		return ret;
 
 	data->state &= ~KX022A_STATE_FIFO;
 
@@ -931,12 +933,7 @@ static int kx022a_fifo_disable(struct kx022a_data *data)
 
 	kfree(data->fifo_buffer);
 
-	return kx022a_turn_on_unlock(data);
-
-unlock_out:
-	mutex_unlock(&data->mutex);
-
-	return ret;
+	return __kx022a_turn_on_off(data, true);
 }
 
 static int kx022a_buffer_predisable(struct iio_dev *idev)
@@ -959,33 +956,29 @@ static int kx022a_fifo_enable(struct kx022a_data *data)
 	if (!data->fifo_buffer)
 		return -ENOMEM;
 
-	ret = kx022a_turn_off_lock(data);
+	guard(mutex)(&data->mutex);
+	ret = __kx022a_turn_on_off(data, false);
 	if (ret)
 		return ret;
 
 	/* Update watermark to HW */
 	ret = kx022a_fifo_set_wmi(data);
 	if (ret)
-		goto unlock_out;
+		return ret;
 
 	/* Enable buffer */
 	ret = regmap_set_bits(data->regmap, data->chip_info->buf_cntl2,
 			      KX022A_MASK_BUF_EN);
 	if (ret)
-		goto unlock_out;
+		return ret;
 
 	data->state |= KX022A_STATE_FIFO;
 	ret = regmap_set_bits(data->regmap, data->ien_reg,
 			      KX022A_MASK_WMI);
 	if (ret)
-		goto unlock_out;
-
-	return kx022a_turn_on_unlock(data);
-
-unlock_out:
-	mutex_unlock(&data->mutex);
+		return ret;
 
-	return ret;
+	return __kx022a_turn_on_off(data, true);
 }
 
 static int kx022a_buffer_postenable(struct iio_dev *idev)
@@ -1053,7 +1046,7 @@ static irqreturn_t kx022a_irq_thread_handler(int irq, void *private)
 	struct kx022a_data *data = iio_priv(idev);
 	irqreturn_t ret = IRQ_NONE;
 
-	mutex_lock(&data->mutex);
+	guard(mutex)(&data->mutex);
 
 	if (data->trigger_enabled) {
 		iio_trigger_poll_nested(data->trig);
@@ -1068,8 +1061,6 @@ static irqreturn_t kx022a_irq_thread_handler(int irq, void *private)
 			ret = IRQ_HANDLED;
 	}
 
-	mutex_unlock(&data->mutex);
-
 	return ret;
 }
 
@@ -1079,32 +1070,26 @@ static int kx022a_trigger_set_state(struct iio_trigger *trig,
 	struct kx022a_data *data = iio_trigger_get_drvdata(trig);
 	int ret = 0;
 
-	mutex_lock(&data->mutex);
+	guard(mutex)(&data->mutex);
 
 	if (data->trigger_enabled == state)
-		goto unlock_out;
+		return 0;
 
 	if (data->state & KX022A_STATE_FIFO) {
 		dev_warn(data->dev, "Can't set trigger when FIFO enabled\n");
-		ret = -EBUSY;
-		goto unlock_out;
+		return -EBUSY;
 	}
 
-	ret = kx022a_turn_on_off_unlocked(data, false);
+	ret = __kx022a_turn_on_off(data, false);
 	if (ret)
-		goto unlock_out;
+		return ret;
 
 	data->trigger_enabled = state;
 	ret = kx022a_set_drdy_irq(data, state);
 	if (ret)
-		goto unlock_out;
-
-	ret = kx022a_turn_on_off_unlocked(data, true);
-
-unlock_out:
-	mutex_unlock(&data->mutex);
+		return ret;
 
-	return ret;
+	return __kx022a_turn_on_off(data, true);
 }
 
 static const struct iio_trigger_ops kx022a_trigger_ops = {
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 3/8] iio: accel: kx022a: Use cleanup.h helpers

[Jonathan Cameron]

On Thu, 21 Nov 2024 10:20:23 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> A few functions in KX022A need to use mutex for protecting the
> enabling/disabling of the measurement while configurations are being
> made. Some of the functions can be slightly simplified by using the
> __cleanup based scoped mutexes, which allows dropping the goto based
> unlocking at error path.
> 
> Simplify error paths using guard(mutex).
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Now we have guard(), the main reason (I think) for the
combined on + lock and off + unlock paths is gone. So can
we just flatten those and do the locking at caller.

After this patch there are only 4 more users anyway and the
ones in the switch statement can be easily done with {}
and guard.

The ones in probe() can be done with a scoped_guard()

Jonathan


> ---
> 
> Revision history:
>   v1 => v2:
>   - patch number changed because a change was added to the series.
>   - rebased on iio/testing to avoid conflicts with queued fixes
> ---
>  drivers/iio/accel/kionix-kx022a.c | 61 ++++++++++++-------------------
>  1 file changed, 23 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
> index b6664299e0d5..98953178a580 100644
> --- a/drivers/iio/accel/kionix-kx022a.c
> +++ b/drivers/iio/accel/kionix-kx022a.c
> @@ -5,6 +5,7 @@
>   * ROHM/KIONIX accelerometer driver
>   */
>  
> +#include <linux/cleanup.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
>  #include <linux/interrupt.h>
> @@ -448,7 +449,7 @@ static void kx022a_reg2scale(unsigned int val, unsigned int *val1,
>  	*val2 = kx022a_scale_table[val][1];
>  }
>  
> -static int kx022a_turn_on_off_unlocked(struct kx022a_data *data, bool on)
> +static int __kx022a_turn_on_off(struct kx022a_data *data, bool on)
>  {
>  	int ret;
>  
> @@ -469,7 +470,7 @@ static int kx022a_turn_off_lock(struct kx022a_data *data)
>  	int ret;
>  
>  	mutex_lock(&data->mutex);
> -	ret = kx022a_turn_on_off_unlocked(data, false);
> +	ret = __kx022a_turn_on_off(data, false);
>  	if (ret)
>  		mutex_unlock(&data->mutex);
>  
> @@ -480,7 +481,7 @@ static int kx022a_turn_on_unlock(struct kx022a_data *data)
>  {
>  	int ret;
>  
> -	ret = kx022a_turn_on_off_unlocked(data, true);
> +	ret = __kx022a_turn_on_off(data, true);
>  	mutex_unlock(&data->mutex);
>  
>  	return ret;
> @@ -912,18 +913,19 @@ static int kx022a_fifo_disable(struct kx022a_data *data)
>  {
>  	int ret = 0;
>  
> -	ret = kx022a_turn_off_lock(data);
> +	guard(mutex)(&data->mutex);
> +	ret = __kx022a_turn_on_off(data, false);
>  	if (ret)
>  		return ret;
>  
>  	ret = regmap_clear_bits(data->regmap, data->ien_reg, KX022A_MASK_WMI);
>  	if (ret)
> -		goto unlock_out;
> +		return ret;
>  
>  	ret = regmap_clear_bits(data->regmap, data->chip_info->buf_cntl2,
>  				KX022A_MASK_BUF_EN);
>  	if (ret)
> -		goto unlock_out;
> +		return ret;
>  
>  	data->state &= ~KX022A_STATE_FIFO;
>  
> @@ -931,12 +933,7 @@ static int kx022a_fifo_disable(struct kx022a_data *data)
>  
>  	kfree(data->fifo_buffer);
>  
> -	return kx022a_turn_on_unlock(data);
> -
> -unlock_out:
> -	mutex_unlock(&data->mutex);
> -
> -	return ret;
> +	return __kx022a_turn_on_off(data, true);
>  }
>  
>  static int kx022a_buffer_predisable(struct iio_dev *idev)
> @@ -959,33 +956,29 @@ static int kx022a_fifo_enable(struct kx022a_data *data)
>  	if (!data->fifo_buffer)
>  		return -ENOMEM;
>  
> -	ret = kx022a_turn_off_lock(data);
> +	guard(mutex)(&data->mutex);
> +	ret = __kx022a_turn_on_off(data, false);
>  	if (ret)
>  		return ret;
>  
>  	/* Update watermark to HW */
>  	ret = kx022a_fifo_set_wmi(data);
>  	if (ret)
> -		goto unlock_out;
> +		return ret;
>  
>  	/* Enable buffer */
>  	ret = regmap_set_bits(data->regmap, data->chip_info->buf_cntl2,
>  			      KX022A_MASK_BUF_EN);
>  	if (ret)
> -		goto unlock_out;
> +		return ret;
>  
>  	data->state |= KX022A_STATE_FIFO;
>  	ret = regmap_set_bits(data->regmap, data->ien_reg,
>  			      KX022A_MASK_WMI);
>  	if (ret)
> -		goto unlock_out;
> -
> -	return kx022a_turn_on_unlock(data);
> -
> -unlock_out:
> -	mutex_unlock(&data->mutex);
> +		return ret;
>  
> -	return ret;
> +	return __kx022a_turn_on_off(data, true);
>  }
>  
>  static int kx022a_buffer_postenable(struct iio_dev *idev)
> @@ -1053,7 +1046,7 @@ static irqreturn_t kx022a_irq_thread_handler(int irq, void *private)
>  	struct kx022a_data *data = iio_priv(idev);
>  	irqreturn_t ret = IRQ_NONE;
>  
> -	mutex_lock(&data->mutex);
> +	guard(mutex)(&data->mutex);
>  
>  	if (data->trigger_enabled) {
>  		iio_trigger_poll_nested(data->trig);
> @@ -1068,8 +1061,6 @@ static irqreturn_t kx022a_irq_thread_handler(int irq, void *private)
>  			ret = IRQ_HANDLED;
>  	}
>  
> -	mutex_unlock(&data->mutex);
> -
>  	return ret;
>  }
>  
> @@ -1079,32 +1070,26 @@ static int kx022a_trigger_set_state(struct iio_trigger *trig,
>  	struct kx022a_data *data = iio_trigger_get_drvdata(trig);
>  	int ret = 0;
>  
> -	mutex_lock(&data->mutex);
> +	guard(mutex)(&data->mutex);
>  
>  	if (data->trigger_enabled == state)
> -		goto unlock_out;
> +		return 0;
>  
>  	if (data->state & KX022A_STATE_FIFO) {
>  		dev_warn(data->dev, "Can't set trigger when FIFO enabled\n");
> -		ret = -EBUSY;
> -		goto unlock_out;
> +		return -EBUSY;
>  	}
>  
> -	ret = kx022a_turn_on_off_unlocked(data, false);
> +	ret = __kx022a_turn_on_off(data, false);
>  	if (ret)
> -		goto unlock_out;
> +		return ret;
>  
>  	data->trigger_enabled = state;
>  	ret = kx022a_set_drdy_irq(data, state);
>  	if (ret)
> -		goto unlock_out;
> -
> -	ret = kx022a_turn_on_off_unlocked(data, true);
> -
> -unlock_out:
> -	mutex_unlock(&data->mutex);
> +		return ret;
>  
> -	return ret;
> +	return __kx022a_turn_on_off(data, true);
>  }
>  
>  static const struct iio_trigger_ops kx022a_trigger_ops = {

Re: [PATCH v2 3/8] iio: accel: kx022a: Use cleanup.h helpers

[Matti Vaittinen]

Hello Jonathan,

Thanks again!

On 23/11/2024 18:42, Jonathan Cameron wrote:
> On Thu, 21 Nov 2024 10:20:23 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> A few functions in KX022A need to use mutex for protecting the
>> enabling/disabling of the measurement while configurations are being
>> made. Some of the functions can be slightly simplified by using the
>> __cleanup based scoped mutexes, which allows dropping the goto based
>> unlocking at error path.
>>
>> Simplify error paths using guard(mutex).
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Now we have guard(), the main reason (I think) for the
> combined on + lock and off + unlock paths is gone. So can
> we just flatten those and do the locking at caller.

I did consider this too :)

Why I decided to keep it as it is, (even though we need the extra 
mutex_unlock() at certain error path) is because I kind of like the 
lock+off and unlock+on functions. This locking does not protect data, 
but really a sequence of operations that needs to be done while sensor 
is OFF state. It's almost like a doc saying that "please, ensure the 
sensor is OFF for the following operations" :)

(Another thing is that we do claim the direct mode in write_raw, and 
goto is still handy for releasing it. Scoped guards won't play nicely 
with goto. Yes, we could probably use the __cleanup for direct mode, but 
I still like the lock+off, unlock+on for the reason above)

Yours,
	-- Matti

Re: [PATCH v2 3/8] iio: accel: kx022a: Use cleanup.h helpers

[Jonathan Cameron]

On Mon, 25 Nov 2024 11:34:36 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> Hello Jonathan,
> 
> Thanks again!
> 
> On 23/11/2024 18:42, Jonathan Cameron wrote:
> > On Thu, 21 Nov 2024 10:20:23 +0200
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >   
> >> A few functions in KX022A need to use mutex for protecting the
> >> enabling/disabling of the measurement while configurations are being
> >> made. Some of the functions can be slightly simplified by using the
> >> __cleanup based scoped mutexes, which allows dropping the goto based
> >> unlocking at error path.
> >>
> >> Simplify error paths using guard(mutex).
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>  
> > Now we have guard(), the main reason (I think) for the
> > combined on + lock and off + unlock paths is gone. So can
> > we just flatten those and do the locking at caller.  
> 
> I did consider this too :)
> 
> Why I decided to keep it as it is, (even though we need the extra 
> mutex_unlock() at certain error path) is because I kind of like the 
> lock+off and unlock+on functions. This locking does not protect data, 
> but really a sequence of operations that needs to be done while sensor 
> is OFF state. It's almost like a doc saying that "please, ensure the 
> sensor is OFF for the following operations" :)

hmm.  I really don't like them because they are 'unusual'  :)

I'd argue they just ensure a sequence of writes go in as an atomic thing.
Two of those writes happen to be turn it off and turn it on.

So the data the are protecting is the device internal state data.

> 
> (Another thing is that we do claim the direct mode in write_raw, and 
> goto is still handy for releasing it. Scoped guards won't play nicely 
> with goto. Yes, we could probably use the __cleanup for direct mode, but 
> I still like the lock+off, unlock+on for the reason above)
There is a nice new cleanup that David did to make the direct mode
handling much cleaner.

	if_not_cond_guard(iio_claim_direct_try, indio_dev)
		return -EBUSY;


> 
> Yours,
> 	-- Matti
> 

Re: [PATCH v2 3/8] iio: accel: kx022a: Use cleanup.h helpers

[Matti Vaittinen]

On 26/11/2024 19:55, Jonathan Cameron wrote:
> On Mon, 25 Nov 2024 11:34:36 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> Hello Jonathan,
>>
>> Thanks again!
>>
>> On 23/11/2024 18:42, Jonathan Cameron wrote:
>>> On Thu, 21 Nov 2024 10:20:23 +0200
>>> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>>>    
>>>> A few functions in KX022A need to use mutex for protecting the
>>>> enabling/disabling of the measurement while configurations are being
>>>> made. Some of the functions can be slightly simplified by using the
>>>> __cleanup based scoped mutexes, which allows dropping the goto based
>>>> unlocking at error path.
>>>>
>>>> Simplify error paths using guard(mutex).
>>>>
>>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>> Now we have guard(), the main reason (I think) for the
>>> combined on + lock and off + unlock paths is gone. So can
>>> we just flatten those and do the locking at caller.
>>
>> I did consider this too :)
>>
>> Why I decided to keep it as it is, (even though we need the extra
>> mutex_unlock() at certain error path) is because I kind of like the
>> lock+off and unlock+on functions. This locking does not protect data,
>> but really a sequence of operations that needs to be done while sensor
>> is OFF state. It's almost like a doc saying that "please, ensure the
>> sensor is OFF for the following operations" :)
> 
> hmm.  I really don't like them because they are 'unusual'  :)

I could argue these aren't totally unusual, perhaps unusual in IIO. I 
fell in love with this type of functions when Guenter suggested this 
approach for me in the wdg. Well, IIO is your territory so I'll mutilate 
this file accordingly.

> I'd argue they just ensure a sequence of writes go in as an atomic thing.
> Two of those writes happen to be turn it off and turn it on.

Well, the data-sheet is very clear what comes to clearing the PC1 bit 
when the various CNTL register are touched:
https://fscdn.rohm.com/kionix/en/datasheet/kx022acr-z-e.pdf
(at the beginning of various CNTL register descriptions). So, the on/off 
thing is not something that just happens - and this is what these 
functions did try to underline :)

> So the data the are protecting is the device internal state data.
> 
>>
>> (Another thing is that we do claim the direct mode in write_raw, and
>> goto is still handy for releasing it. Scoped guards won't play nicely
>> with goto. Yes, we could probably use the __cleanup for direct mode, but
>> I still like the lock+off, unlock+on for the reason above)
> There is a nice new cleanup that David did to make the direct mode
> handling much cleaner.
> 
> 	if_not_cond_guard(iio_claim_direct_try, indio_dev)
> 		return -EBUSY;

Ah. Nice. This is not yet in the iio_testing though. I'll add this 'drop 
the off+lock, on+unlock -functions change as an individual patch. It'll 
depend on the if_not_cond_guard() while the rest of the patches should 
have no dependencies to any "not yet in iio_testing" stuff.

I do have the patches ready for sending but I don't have sensors to test 
this at home. I'll give this a try at the office tomorrow and send it 
out then.

Yours,
     -- Matti

[PATCH v2 4/8] iio: accel: kx022a: Support ICs with different G-ranges

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5131 bytes --]

The register interface of the ROHM KX134ACR-LBZ accelerometer is almost
identical to the KX132ACR-LBZ. Main difference between these
accelerometers is that the KX134ACR-LBZ supports G-ranges +/- 8, 16,
32 and 64G. All the other sensors supported by the kx022a driver can
measure +/- 2, 4, 8 and 16G.

Prepare supporting the KX134ACR-LBZ with different G-ranges by storing
a pointer to the scale tables in IC specific structure.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:
  - patch number changed because a change was added to the series.
  - rebased on iio/testing to avoid conflicts with queued fixes
---
 drivers/iio/accel/kionix-kx022a.c | 32 ++++++++++++++++++++-----------
 drivers/iio/accel/kionix-kx022a.h |  2 ++
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
index 98953178a580..b23a27623a46 100644
--- a/drivers/iio/accel/kionix-kx022a.c
+++ b/drivers/iio/accel/kionix-kx022a.c
@@ -413,6 +413,8 @@ static int kx022a_read_avail(struct iio_dev *indio_dev,
 			     const int **vals, int *type, int *length,
 			     long mask)
 {
+	struct kx022a_data *data = iio_priv(indio_dev);
+
 	switch (mask) {
 	case IIO_CHAN_INFO_SAMP_FREQ:
 		*vals = (const int *)kx022a_accel_samp_freq_table;
@@ -421,9 +423,8 @@ static int kx022a_read_avail(struct iio_dev *indio_dev,
 		*type = IIO_VAL_INT_PLUS_MICRO;
 		return IIO_AVAIL_LIST;
 	case IIO_CHAN_INFO_SCALE:
-		*vals = (const int *)kx022a_scale_table;
-		*length = ARRAY_SIZE(kx022a_scale_table) *
-			  ARRAY_SIZE(kx022a_scale_table[0]);
+		*vals = (const int *)data->chip_info->scale_table;
+		*length = data->chip_info->scale_table_size;
 		*type = IIO_VAL_INT_PLUS_NANO;
 		return IIO_AVAIL_LIST;
 	default:
@@ -439,14 +440,14 @@ static void kx022a_reg2freq(unsigned int val,  int *val1, int *val2)
 	*val2 = kx022a_accel_samp_freq_table[val & KX022A_MASK_ODR][1];
 }
 
-static void kx022a_reg2scale(unsigned int val, unsigned int *val1,
-			     unsigned int *val2)
+static void kx022a_reg2scale(struct kx022a_data *data, unsigned int val,
+			     unsigned int *val1, unsigned int *val2)
 {
 	val &= KX022A_MASK_GSEL;
 	val >>= KX022A_GSEL_SHIFT;
 
-	*val1 = kx022a_scale_table[val][0];
-	*val2 = kx022a_scale_table[val][1];
+	*val1 = data->chip_info->scale_table[val][0];
+	*val2 = data->chip_info->scale_table[val][1];
 }
 
 static int __kx022a_turn_on_off(struct kx022a_data *data, bool on)
@@ -544,11 +545,11 @@ static int kx022a_write_raw(struct iio_dev *idev,
 		kx022a_turn_on_unlock(data);
 		break;
 	case IIO_CHAN_INFO_SCALE:
-		n = ARRAY_SIZE(kx022a_scale_table);
+		n = data->chip_info->scale_table_size / 2;
 
 		while (n-- > 0)
-			if (val == kx022a_scale_table[n][0] &&
-			    val2 == kx022a_scale_table[n][1])
+			if (val == data->chip_info->scale_table[n][0] &&
+			    val2 == data->chip_info->scale_table[n][1])
 				break;
 		if (n < 0) {
 			ret = -EINVAL;
@@ -643,7 +644,7 @@ static int kx022a_read_raw(struct iio_dev *idev,
 		if (ret < 0)
 			return ret;
 
-		kx022a_reg2scale(regval, val, val2);
+		kx022a_reg2scale(data, regval, val, val2);
 
 		return IIO_VAL_INT_PLUS_NANO;
 	}
@@ -1148,6 +1149,9 @@ const struct kx022a_chip_info kx022a_chip_info = {
 	.regmap_config			= &kx022a_regmap_config,
 	.channels			= kx022a_channels,
 	.num_channels			= ARRAY_SIZE(kx022a_channels),
+	.scale_table			= kx022a_scale_table,
+	.scale_table_size		= ARRAY_SIZE(kx022a_scale_table) *
+					  ARRAY_SIZE(kx022a_scale_table[0]),
 	.fifo_length			= KX022A_FIFO_LENGTH,
 	.who				= KX022A_REG_WHO,
 	.id				= KX022A_ID,
@@ -1173,6 +1177,9 @@ const struct kx022a_chip_info kx132_chip_info = {
 	.regmap_config		  = &kx132_regmap_config,
 	.channels		  = kx132_channels,
 	.num_channels		  = ARRAY_SIZE(kx132_channels),
+	.scale_table			= kx022a_scale_table,
+	.scale_table_size		= ARRAY_SIZE(kx022a_scale_table) *
+					  ARRAY_SIZE(kx022a_scale_table[0]),
 	.fifo_length		  = KX132_FIFO_LENGTH,
 	.who			  = KX132_REG_WHO,
 	.id			  = KX132_ID,
@@ -1206,6 +1213,9 @@ const struct kx022a_chip_info kx132acr_chip_info = {
 	.regmap_config			= &kx022a_regmap_config,
 	.channels			= kx022a_channels,
 	.num_channels			= ARRAY_SIZE(kx022a_channels),
+	.scale_table			= kx022a_scale_table,
+	.scale_table_size		= ARRAY_SIZE(kx022a_scale_table) *
+					  ARRAY_SIZE(kx022a_scale_table[0]),
 	.fifo_length			= KX022A_FIFO_LENGTH,
 	.who				= KX022A_REG_WHO,
 	.id				= KX132ACR_LBZ_ID,
diff --git a/drivers/iio/accel/kionix-kx022a.h b/drivers/iio/accel/kionix-kx022a.h
index 7060438ad88c..36e9d9de8c13 100644
--- a/drivers/iio/accel/kionix-kx022a.h
+++ b/drivers/iio/accel/kionix-kx022a.h
@@ -161,6 +161,8 @@ struct kx022a_data;
 struct kx022a_chip_info {
 	const char *name;
 	const struct regmap_config *regmap_config;
+	const int (*scale_table)[2];
+	const int scale_table_size;
 	const struct iio_chan_spec *channels;
 	unsigned int num_channels;
 	unsigned int fifo_length;
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 5/8] dt-bindings: ROHM KX134ACR-LBZ

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

From the software point of view, the KX134ACR-LBZ is almost identical to
the KX132ACR-LBZ. They, however, have different g ranges and ID register
values which makes them incompatible.

Add compatible and information for ROHM KX134ACR-LBZ accelerometer.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>

---

Revision history:
  v1 => v2:
  - Improve commit message by explaining why compatible is needed.
  - patch number changed because a change was added to the series.
  - rebased on iio/testing to avoid conflicts with queued fixes
---
 .../devicetree/bindings/iio/accel/kionix,kx022a.yaml          | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
index 66ea894dbe55..c973f4941a6d 100644
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
@@ -11,7 +11,8 @@ maintainers:
 
 description: |
   KX022A, KX132ACR-LBZ and KX132-1211 are 3-axis accelerometers supporting
-  +/- 2G, 4G, 8G and 16G ranges, variable output data-rates and a
+  +/- 2G, 4G, 8G and 16G ranges. The KX134ACR-LBZ supports +/- 8G, 16G,
+  32G and 64G. All the sensors also have variable output data-rates and a
   hardware-fifo buffering. These accelerometers can be accessed either
   via I2C or SPI.
 
@@ -21,6 +22,7 @@ properties:
       - kionix,kx022a
       - kionix,kx132-1211
       - rohm,kx132acr-lbz
+      - rohm,kx134acr-lbz
 
   reg:
     maxItems: 1
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 6/8] iio: kx022a: Support ROHM KX134ACR-LBZ

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5805 bytes --]

The register interface of the ROHM KX134ACR-LBZ accelerometer is
almost identical to the KX132ACR-LBZ. The main difference between these
accelerometers is that the KX134ACR-LBZ supports different G-ranges. The
driver can model this by informing different scale to users. Also, the
content of the "who_am_I" register is different.

Add an ID and scales for the KX134ACR-LBZ.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:.
  - patch number changed because a change was added to the series.
  - rebased on iio/testing to avoid conflicts with queued fixes
---
 drivers/iio/accel/kionix-kx022a-i2c.c |  2 ++
 drivers/iio/accel/kionix-kx022a-spi.c |  2 ++
 drivers/iio/accel/kionix-kx022a.c     | 36 +++++++++++++++++++++++++++
 drivers/iio/accel/kionix-kx022a.h     |  2 ++
 4 files changed, 42 insertions(+)

diff --git a/drivers/iio/accel/kionix-kx022a-i2c.c b/drivers/iio/accel/kionix-kx022a-i2c.c
index 8a1d4fc28ddd..9fd049c2b62e 100644
--- a/drivers/iio/accel/kionix-kx022a-i2c.c
+++ b/drivers/iio/accel/kionix-kx022a-i2c.c
@@ -39,6 +39,7 @@ static const struct i2c_device_id kx022a_i2c_id[] = {
 	{ .name = "kx022a", .driver_data = (kernel_ulong_t)&kx022a_chip_info },
 	{ .name = "kx132-1211", .driver_data = (kernel_ulong_t)&kx132_chip_info },
 	{ .name = "kx132acr-lbz", .driver_data = (kernel_ulong_t)&kx132acr_chip_info },
+	{ .name = "kx134acr-lbz", .driver_data = (kernel_ulong_t)&kx134acr_chip_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, kx022a_i2c_id);
@@ -47,6 +48,7 @@ static const struct of_device_id kx022a_of_match[] = {
 	{ .compatible = "kionix,kx022a", .data = &kx022a_chip_info },
 	{ .compatible = "kionix,kx132-1211", .data = &kx132_chip_info },
 	{ .compatible = "rohm,kx132acr-lbz", .data = &kx132acr_chip_info },
+	{ .compatible = "rohm,kx134acr-lbz", .data = &kx134acr_chip_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, kx022a_of_match);
diff --git a/drivers/iio/accel/kionix-kx022a-spi.c b/drivers/iio/accel/kionix-kx022a-spi.c
index f798b964d0b5..b20978afc565 100644
--- a/drivers/iio/accel/kionix-kx022a-spi.c
+++ b/drivers/iio/accel/kionix-kx022a-spi.c
@@ -39,6 +39,7 @@ static const struct spi_device_id kx022a_id[] = {
 	{ .name = "kx022a", .driver_data = (kernel_ulong_t)&kx022a_chip_info },
 	{ .name = "kx132-1211", .driver_data = (kernel_ulong_t)&kx132_chip_info },
 	{ .name = "kx132acr-lbz", .driver_data = (kernel_ulong_t)&kx132acr_chip_info },
+	{ .name = "kx134acr-lbz", .driver_data = (kernel_ulong_t)&kx134acr_chip_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(spi, kx022a_id);
@@ -47,6 +48,7 @@ static const struct of_device_id kx022a_of_match[] = {
 	{ .compatible = "kionix,kx022a", .data = &kx022a_chip_info },
 	{ .compatible = "kionix,kx132-1211", .data = &kx132_chip_info },
 	{ .compatible = "rohm,kx132acr-lbz", .data = &kx132acr_chip_info },
+	{ .compatible = "rohm,kx134acr-lbz", .data = &kx134acr_chip_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, kx022a_of_match);
diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
index b23a27623a46..9fe16802c125 100644
--- a/drivers/iio/accel/kionix-kx022a.c
+++ b/drivers/iio/accel/kionix-kx022a.c
@@ -408,6 +408,14 @@ static const int kx022a_scale_table[][2] = {
 	{ 0, 4788403 },
 };
 
+/* KX134ACR-LBZ ranges are (+/-) 8, 16, 32, 64 G */
+static const int kx134acr_lbz_scale_table[][2] = {
+	{ 0, 2394202 },
+	{ 0, 4788403 },
+	{ 0, 9576807 },
+	{ 0, 19153613 },
+};
+
 static int kx022a_read_avail(struct iio_dev *indio_dev,
 			     struct iio_chan_spec const *chan,
 			     const int **vals, int *type, int *length,
@@ -1236,6 +1244,34 @@ const struct kx022a_chip_info kx132acr_chip_info = {
 };
 EXPORT_SYMBOL_NS_GPL(kx132acr_chip_info, IIO_KX022A);
 
+const struct kx022a_chip_info kx134acr_chip_info = {
+	.name				= "kx134acr-lbz",
+	.regmap_config			= &kx022a_regmap_config,
+	.channels			= kx022a_channels,
+	.num_channels			= ARRAY_SIZE(kx022a_channels),
+	.scale_table			= kx134acr_lbz_scale_table,
+	.scale_table_size		= ARRAY_SIZE(kx134acr_lbz_scale_table) *
+					  ARRAY_SIZE(kx134acr_lbz_scale_table[0]),
+	.fifo_length			= KX022A_FIFO_LENGTH,
+	.who				= KX022A_REG_WHO,
+	.id				= KX134ACR_LBZ_ID,
+	.cntl				= KX022A_REG_CNTL,
+	.cntl2				= KX022A_REG_CNTL2,
+	.odcntl				= KX022A_REG_ODCNTL,
+	.buf_cntl1			= KX022A_REG_BUF_CNTL1,
+	.buf_cntl2			= KX022A_REG_BUF_CNTL2,
+	.buf_clear			= KX022A_REG_BUF_CLEAR,
+	.buf_status1			= KX022A_REG_BUF_STATUS_1,
+	.buf_read			= KX022A_REG_BUF_READ,
+	.inc1				= KX022A_REG_INC1,
+	.inc4				= KX022A_REG_INC4,
+	.inc5				= KX022A_REG_INC5,
+	.inc6				= KX022A_REG_INC6,
+	.xout_l				= KX022A_REG_XOUT_L,
+	.get_fifo_bytes_available	= kx022a_get_fifo_bytes_available,
+};
+EXPORT_SYMBOL_NS_GPL(kx134acr_chip_info, IIO_KX022A);
+
 int kx022a_probe_internal(struct device *dev, const struct kx022a_chip_info *chip_info)
 {
 	static const char * const regulator_names[] = {"io-vdd", "vdd"};
diff --git a/drivers/iio/accel/kionix-kx022a.h b/drivers/iio/accel/kionix-kx022a.h
index 36e9d9de8c13..ea32fd252a38 100644
--- a/drivers/iio/accel/kionix-kx022a.h
+++ b/drivers/iio/accel/kionix-kx022a.h
@@ -14,6 +14,7 @@
 #define KX022A_REG_WHO		0x0f
 #define KX022A_ID		0xc8
 #define KX132ACR_LBZ_ID		0xd8
+#define KX134ACR_LBZ_ID		0xcc
 
 #define KX022A_REG_CNTL2	0x19
 #define KX022A_MASK_SRST	BIT(7)
@@ -190,5 +191,6 @@ int kx022a_probe_internal(struct device *dev, const struct kx022a_chip_info *chi
 extern const struct kx022a_chip_info kx022a_chip_info;
 extern const struct kx022a_chip_info kx132_chip_info;
 extern const struct kx022a_chip_info kx132acr_chip_info;
+extern const struct kx022a_chip_info kx134acr_chip_info;
 
 #endif
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 7/8] dt-bindings: iio: kx022a: Support KX134-1211

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

The ROHM KX134-1211 is very similar to KX132-1211. The main difference is
supported g-ranges. The KX132-1211 can measure ranges from +/- 2g to
+/-16g where the KX134-1211 supports measuring ranges +/- 8g to +/- 64g.

Support the ROHM KX134-1211.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:
  - new patch
---
 .../devicetree/bindings/iio/accel/kionix,kx022a.yaml  | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
index c973f4941a6d..f07c70e51c45 100644
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
@@ -4,23 +4,24 @@
 $id: http://devicetree.org/schemas/iio/accel/kionix,kx022a.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: ROHM/Kionix KX022A, KX132-1211 and KX132ACR-LBZ Accelerometers
+title: ROHM/Kionix KX022A, KX132/134-1211 and KX132/134ACR-LBZ Accelerometers
 
 maintainers:
   - Matti Vaittinen <mazziesaccount@gmail.com>
 
 description: |
   KX022A, KX132ACR-LBZ and KX132-1211 are 3-axis accelerometers supporting
-  +/- 2G, 4G, 8G and 16G ranges. The KX134ACR-LBZ supports +/- 8G, 16G,
-  32G and 64G. All the sensors also have variable output data-rates and a
-  hardware-fifo buffering. These accelerometers can be accessed either
-  via I2C or SPI.
+  +/- 2G, 4G, 8G and 16G ranges. The KX134ACR-LBZ and KX134-1211 support
+  +/- 8G, 16G, 32G and 64G. All the sensors also have variable output
+  data-rates and a hardware-fifo buffering. These accelerometers can be
+  accessed either via I2C or SPI.
 
 properties:
   compatible:
     enum:
       - kionix,kx022a
       - kionix,kx132-1211
+      - kionix,kx134-1211
       - rohm,kx132acr-lbz
       - rohm,kx134acr-lbz
 
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 7/8] dt-bindings: iio: kx022a: Support KX134-1211

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Thu, Nov 21, 2024 at 10:21:30AM +0200, Matti Vaittinen wrote:
> The ROHM KX134-1211 is very similar to KX132-1211. The main difference is
> supported g-ranges. The KX132-1211 can measure ranges from +/- 2g to
> +/-16g where the KX134-1211 supports measuring ranges +/- 8g to +/- 64g.
> 
> Support the ROHM KX134-1211.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v2 8/8] iio: accel: kx022a: Support KX134-1211

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 5515 bytes --]

The ROHM KX134-1211 has very similar register interface as KX132-1211
does. The main differencies are the content of the "Who am I"
identification register and different g-ranges. The KX132-1211 can
measure ranges from +/- 2g to +/-16g where the KX134-1211 supports
measuring ranges +/- 8g to +/- 64g.

Support the ROHM KX134-1211.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

Revision history:
  v1 => v2:
  - new patch
---
 drivers/iio/accel/kionix-kx022a-i2c.c |  2 ++
 drivers/iio/accel/kionix-kx022a-spi.c |  2 ++
 drivers/iio/accel/kionix-kx022a.c     | 30 +++++++++++++++++++++++++++
 drivers/iio/accel/kionix-kx022a.h     |  2 ++
 4 files changed, 36 insertions(+)

diff --git a/drivers/iio/accel/kionix-kx022a-i2c.c b/drivers/iio/accel/kionix-kx022a-i2c.c
index 9fd049c2b62e..7359073ae0c0 100644
--- a/drivers/iio/accel/kionix-kx022a-i2c.c
+++ b/drivers/iio/accel/kionix-kx022a-i2c.c
@@ -38,6 +38,7 @@ static int kx022a_i2c_probe(struct i2c_client *i2c)
 static const struct i2c_device_id kx022a_i2c_id[] = {
 	{ .name = "kx022a", .driver_data = (kernel_ulong_t)&kx022a_chip_info },
 	{ .name = "kx132-1211", .driver_data = (kernel_ulong_t)&kx132_chip_info },
+	{ .name = "kx134-1211", .driver_data = (kernel_ulong_t)&kx134_chip_info },
 	{ .name = "kx132acr-lbz", .driver_data = (kernel_ulong_t)&kx132acr_chip_info },
 	{ .name = "kx134acr-lbz", .driver_data = (kernel_ulong_t)&kx134acr_chip_info },
 	{ }
@@ -47,6 +48,7 @@ MODULE_DEVICE_TABLE(i2c, kx022a_i2c_id);
 static const struct of_device_id kx022a_of_match[] = {
 	{ .compatible = "kionix,kx022a", .data = &kx022a_chip_info },
 	{ .compatible = "kionix,kx132-1211", .data = &kx132_chip_info },
+	{ .compatible = "kionix,kx134-1211", .data = &kx134_chip_info },
 	{ .compatible = "rohm,kx132acr-lbz", .data = &kx132acr_chip_info },
 	{ .compatible = "rohm,kx134acr-lbz", .data = &kx134acr_chip_info },
 	{ }
diff --git a/drivers/iio/accel/kionix-kx022a-spi.c b/drivers/iio/accel/kionix-kx022a-spi.c
index b20978afc565..50aeaafc56ec 100644
--- a/drivers/iio/accel/kionix-kx022a-spi.c
+++ b/drivers/iio/accel/kionix-kx022a-spi.c
@@ -38,6 +38,7 @@ static int kx022a_spi_probe(struct spi_device *spi)
 static const struct spi_device_id kx022a_id[] = {
 	{ .name = "kx022a", .driver_data = (kernel_ulong_t)&kx022a_chip_info },
 	{ .name = "kx132-1211", .driver_data = (kernel_ulong_t)&kx132_chip_info },
+	{ .name = "kx134-1211", .driver_data = (kernel_ulong_t)&kx134_chip_info },
 	{ .name = "kx132acr-lbz", .driver_data = (kernel_ulong_t)&kx132acr_chip_info },
 	{ .name = "kx134acr-lbz", .driver_data = (kernel_ulong_t)&kx134acr_chip_info },
 	{ }
@@ -47,6 +48,7 @@ MODULE_DEVICE_TABLE(spi, kx022a_id);
 static const struct of_device_id kx022a_of_match[] = {
 	{ .compatible = "kionix,kx022a", .data = &kx022a_chip_info },
 	{ .compatible = "kionix,kx132-1211", .data = &kx132_chip_info },
+	{ .compatible = "kionix,kx134-1211", .data = &kx134_chip_info },
 	{ .compatible = "rohm,kx132acr-lbz", .data = &kx132acr_chip_info },
 	{ .compatible = "rohm,kx134acr-lbz", .data = &kx134acr_chip_info },
 	{ }
diff --git a/drivers/iio/accel/kionix-kx022a.c b/drivers/iio/accel/kionix-kx022a.c
index 9fe16802c125..e3986dd65337 100644
--- a/drivers/iio/accel/kionix-kx022a.c
+++ b/drivers/iio/accel/kionix-kx022a.c
@@ -1209,6 +1209,36 @@ const struct kx022a_chip_info kx132_chip_info = {
 };
 EXPORT_SYMBOL_NS_GPL(kx132_chip_info, IIO_KX022A);
 
+const struct kx022a_chip_info kx134_chip_info = {
+	.name			  = "kx134-1211",
+	.regmap_config		  = &kx132_regmap_config,
+	.channels		  = kx132_channels,
+	.num_channels		  = ARRAY_SIZE(kx132_channels),
+	.scale_table			= kx134acr_lbz_scale_table,
+	.scale_table_size		= ARRAY_SIZE(kx134acr_lbz_scale_table) *
+					  ARRAY_SIZE(kx134acr_lbz_scale_table[0]),
+	.fifo_length		  = KX132_FIFO_LENGTH,
+	.who			  = KX132_REG_WHO,
+	.id			  = KX134_1211_ID,
+	.cntl			  = KX132_REG_CNTL,
+	.cntl2			  = KX132_REG_CNTL2,
+	.odcntl			  = KX132_REG_ODCNTL,
+	.buf_cntl1		  = KX132_REG_BUF_CNTL1,
+	.buf_cntl2		  = KX132_REG_BUF_CNTL2,
+	.buf_clear		  = KX132_REG_BUF_CLEAR,
+	.buf_status1		  = KX132_REG_BUF_STATUS_1,
+	.buf_smp_lvl_mask	  = KX132_MASK_BUF_SMP_LVL,
+	.buf_read		  = KX132_REG_BUF_READ,
+	.inc1			  = KX132_REG_INC1,
+	.inc4			  = KX132_REG_INC4,
+	.inc5			  = KX132_REG_INC5,
+	.inc6			  = KX132_REG_INC6,
+	.xout_l			  = KX132_REG_XOUT_L,
+	.get_fifo_bytes_available = kx132_get_fifo_bytes_available,
+};
+EXPORT_SYMBOL_NS_GPL(kx134_chip_info, IIO_KX022A);
+
+
 /*
  * Despite the naming, KX132ACR-LBZ is not similar to KX132-1211 but it is
  * exact subset of KX022A. KX132ACR-LBZ is meant to be used for industrial
diff --git a/drivers/iio/accel/kionix-kx022a.h b/drivers/iio/accel/kionix-kx022a.h
index ea32fd252a38..142652ff4b22 100644
--- a/drivers/iio/accel/kionix-kx022a.h
+++ b/drivers/iio/accel/kionix-kx022a.h
@@ -78,6 +78,7 @@
 
 #define KX132_REG_WHO		0x13
 #define KX132_ID		0x3d
+#define KX134_1211_ID		0x46
 
 #define KX132_FIFO_LENGTH	86
 
@@ -190,6 +191,7 @@ int kx022a_probe_internal(struct device *dev, const struct kx022a_chip_info *chi
 
 extern const struct kx022a_chip_info kx022a_chip_info;
 extern const struct kx022a_chip_info kx132_chip_info;
+extern const struct kx022a_chip_info kx134_chip_info;
 extern const struct kx022a_chip_info kx132acr_chip_info;
 extern const struct kx022a_chip_info kx134acr_chip_info;
 
-- 
2.47.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 8/8] iio: accel: kx022a: Support KX134-1211

[Jonathan Cameron]

On Thu, 21 Nov 2024 10:21:46 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> The ROHM KX134-1211 has very similar register interface as KX132-1211
> does. The main differencies are the content of the "Who am I"
> identification register and different g-ranges. The KX132-1211 can
> measure ranges from +/- 2g to +/-16g where the KX134-1211 supports
> measuring ranges +/- 8g to +/- 64g.
> 
> Support the ROHM KX134-1211.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> 
Reset of the series looks fine to me.