[v1] iio: accel: merge adis16203 into mainline adis16201 and remove from staging

[PATCH 0/3] iio: accel: merge adis16203 into mainline adis16201 and remove from staging

Posted by Shehryar Ahmad 3 weeks, 4 days ago

This series merges the adis16203 staging driver into the mainline
adis16201 driver and removes staging copy. Following discussion at [1].

Register addresses are identical between both parts (SUPPLY_OUT,
AUX_ADC, TEMP_OUT, inclination regs all match). Pin config is identical
too, all 16 pins, same names/types (Table 5, both datasheets). SPI
protocol is identical as well (Figure 3, both datasheets, Phase = 1,
Polarity = 1). adis16203's second (180-degree) inclination channel is
dropped, since userspace can trivially compute it from the first channel
anyway.[2]

Differences between chips selected per-device via a new struct
differ_info, picked in probe() off of_device_id match, same pattern as
adis16475.c, similar thing in adis16480 but different mechanism.

Don't have hardware for either part, only tested locally with KUnit that
the sign_extend32 and SCALE/OFFSET paths of real read_raw behave
correctly for both chips. Register read/write and probe aren't tested.

Patch 3's binding content is unchanged from [3].

If this isn't the right direction, guidance would be appreciated.

Link: https://lore.kernel.org/all/20250308144239.0442f1a7@jic23-huawei/
Link: https://lore.kernel.org/linux-iio/20180204163124.67234ae5@archlinux/
Link: https://lore.kernel.org/all/20260812043506.456ced6d@jic23-huawei/

Shehryar Ahmad (3):
  iio: accel: adis16201: merge adis16203 support from staging
  staging: iio: accel: remove adis16203, merged into mainline adis16201
    driver
  dt-bindings: iio: accel: adi,adis16201: add adis16203 compatible

 .../bindings/iio/accel/adi,adis16201.yaml     |   6 +-
 drivers/iio/accel/adis16201.c                 | 289 +++++++++-------
 drivers/staging/iio/Kconfig                   |   1 -
 drivers/staging/iio/Makefile                  |   1 -
 drivers/staging/iio/accel/Kconfig             |  19 --
 drivers/staging/iio/accel/Makefile            |   6 -
 drivers/staging/iio/accel/adis16203.c         | 315 ------------------
 7 files changed, 178 insertions(+), 459 deletions(-)
 delete mode 100644 drivers/staging/iio/accel/Kconfig
 delete mode 100644 drivers/staging/iio/accel/Makefile
 delete mode 100644 drivers/staging/iio/accel/adis16203.c

-- 
2.43.0

Re: [PATCH 0/3] iio: accel: merge adis16203 into mainline adis16201 and remove from staging

Posted by Andy Shevchenko 3 weeks, 4 days ago

On Mon, Aug 31, 2026 at 11:41:58PM +0500, Shehryar Ahmad wrote:
> This series merges the adis16203 staging driver into the mainline
> adis16201 driver and removes staging copy. Following discussion at [1].
> 
> Register addresses are identical between both parts (SUPPLY_OUT,
> AUX_ADC, TEMP_OUT, inclination regs all match). Pin config is identical
> too, all 16 pins, same names/types (Table 5, both datasheets). SPI
> protocol is identical as well (Figure 3, both datasheets, Phase = 1,
> Polarity = 1). adis16203's second (180-degree) inclination channel is
> dropped, since userspace can trivially compute it from the first channel
> anyway.[2]
> 
> Differences between chips selected per-device via a new struct
> differ_info, picked in probe() off of_device_id match, same pattern as
> adis16475.c, similar thing in adis16480 but different mechanism.
> 
> Don't have hardware for either part, only tested locally with KUnit that
> the sign_extend32 and SCALE/OFFSET paths of real read_raw behave
> correctly for both chips. Register read/write and probe aren't tested.
> 
> Patch 3's binding content is unchanged from [3].
> 
> If this isn't the right direction, guidance would be appreciated.
> 
> Link: https://lore.kernel.org/all/20250308144239.0442f1a7@jic23-huawei/
> Link: https://lore.kernel.org/linux-iio/20180204163124.67234ae5@archlinux/
> Link: https://lore.kernel.org/all/20260812043506.456ced6d@jic23-huawei/

Yeah, in the cover letter it's better to avoid Link tags unless you want
them to be present in the each of the patches (here I believe it's not
the case). Also you forgot the reference numbers. I assume you wanted
this:

 [1] https://lore.kernel.org/all/20250308144239.0442f1a7@jic23-huawei/
 [2] https://lore.kernel.org/linux-iio/20180204163124.67234ae5@archlinux/
 [3] https://lore.kernel.org/all/20260812043506.456ced6d@jic23-huawei/

-- 
With Best Regards,
Andy Shevchenko