public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
* [RFC]: Getting ADIS16203 out of staging
@ 2025-03-06  0:26 Saalim Quadri
  2025-03-07  3:32 ` Marcelo Schmitt
  0 siblings, 1 reply; 3+ messages in thread
From: Saalim Quadri @ 2025-03-06  0:26 UTC (permalink / raw)
  To: jic23
  Cc: lars, Michael.Hennerich, gregkh, linux-iio, linux-kernel,
	linux-staging

ADIS16203 and ADIS16201 are very similar in functionality whilst the
major difference between the accuracy in ADIS16201, I wonder if they
can be merged together into single driver, whilst also implementing
platform_device support in them.

I want to work on this, provided some opinions for me to work with
or to have a separate driver for both of them.

I see that there has been some discussion regarding the same at [1].

[1]: https://lore.kernel.org/linux-iio/20230124094450.0000272b@Huawei.com

Sincerely,
Saalim Quadri

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC]: Getting ADIS16203 out of staging
  2025-03-06  0:26 [RFC]: Getting ADIS16203 out of staging Saalim Quadri
@ 2025-03-07  3:32 ` Marcelo Schmitt
  2025-03-08 14:42   ` Jonathan Cameron
  0 siblings, 1 reply; 3+ messages in thread
From: Marcelo Schmitt @ 2025-03-07  3:32 UTC (permalink / raw)
  To: Saalim Quadri
  Cc: jic23, lars, Michael.Hennerich, gregkh, linux-iio, linux-kernel,
	linux-staging

Hi Saalim,

On 03/06, Saalim Quadri wrote:
> ADIS16203 and ADIS16201 are very similar in functionality whilst the
> major difference between the accuracy in ADIS16201, I wonder if they
> can be merged together into single driver, whilst also implementing
> platform_device support in them.
> 
From quick datasheet comparison, yes, I think the drivers could be merged.

> I want to work on this, provided some opinions for me to work with
> or to have a separate driver for both of them.

I often look at two things when assessing if two or more devices can be
supported by the same driver, the protocol and internal register structure. For
IIO devices, the protocol is usually I2C or SPI. Though, even between devices of
same protocol, there may be differences on how the data is structured in
read/write commands. Also, if internal registers have very different addresses
or meanings, it makes it harder to reuse code because the configuration
procedure for each distinct design/device will tend to require specific
handling.

That said, ADIS16201 and ADIS16203 SPI read/write commands seem to be the same,
and ADIS16203 registers seem to be a subset of ADIS16201's. That's why I think
it may be worth merging the drivers. I didn't read the datasheets thoroughly,
though.

> 
> I see that there has been some discussion regarding the same at [1].
> 
> [1]: https://lore.kernel.org/linux-iio/20230124094450.0000272b@Huawei.com

Git tends to rename/move files when we move a file from one directory to another.
IIRC, Jonathan prefers the drivers to be completely removed from staging to then
be added under iio directory to sort of make it clearer that something is
being added to official (not staging) IIO drivers. To accomplish that, we
use --no-renames flag (e.g. git format-patch --no-renames ...).

> 
> Sincerely,
> Saalim Quadri
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC]: Getting ADIS16203 out of staging
  2025-03-07  3:32 ` Marcelo Schmitt
@ 2025-03-08 14:42   ` Jonathan Cameron
  0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Cameron @ 2025-03-08 14:42 UTC (permalink / raw)
  To: Marcelo Schmitt
  Cc: Saalim Quadri, lars, Michael.Hennerich, gregkh, linux-iio,
	linux-kernel, linux-staging

On Fri, 7 Mar 2025 00:32:30 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> Hi Saalim,
> 
> On 03/06, Saalim Quadri wrote:
> > ADIS16203 and ADIS16201 are very similar in functionality whilst the
> > major difference between the accuracy in ADIS16201, I wonder if they
> > can be merged together into single driver, whilst also implementing
> > platform_device support in them.
> >   
> From quick datasheet comparison, yes, I think the drivers could be merged.
> 
> > I want to work on this, provided some opinions for me to work with
> > or to have a separate driver for both of them.  
> 
> I often look at two things when assessing if two or more devices can be
> supported by the same driver, the protocol and internal register structure. For
> IIO devices, the protocol is usually I2C or SPI. Though, even between devices of
> same protocol, there may be differences on how the data is structured in
> read/write commands. Also, if internal registers have very different addresses
> or meanings, it makes it harder to reuse code because the configuration
> procedure for each distinct design/device will tend to require specific
> handling.
> 
> That said, ADIS16201 and ADIS16203 SPI read/write commands seem to be the same,
> and ADIS16203 registers seem to be a subset of ADIS16201's. That's why I think
> it may be worth merging the drivers. I didn't read the datasheets thoroughly,
> though.

> 
> > 
> > I see that there has been some discussion regarding the same at [1].
> > 
> > [1]: https://lore.kernel.org/linux-iio/20230124094450.0000272b@Huawei.com  
> 
Yes.  I never did get around to merging them after that was pretty much the conclusion
of the reviews of that attempt to get the driver out of staging.

So if you are willing go ahead.  One challenge is testing where you need one of:
1. Test devices.
2. Someone willing to test who has them.
3. Emulation of enough to verify that nothing broke.  Assumption more or less
   being that current driver is 'correct' so it's a case of emulating the
   device then tracking forwards that it continues to function as you modify
   the driver.
4. Really simple changes where we rely on review alone.

Jonathan


> Git tends to rename/move files when we move a file from one directory to another.
> IIRC, Jonathan prefers the drivers to be completely removed from staging to then
> be added under iio directory to sort of make it clearer that something is
> being added to official (not staging) IIO drivers. To accomplish that, we
> use --no-renames flag (e.g. git format-patch --no-renames ...).

Kind of more about providing a convenient place to check that we are happy with
the state of the driver as part of the series that moves it.  That move patch
results in a full driver review, similar to what we'd do for a new driver.
Good to point this out though, thanks

Jonathan


> 
> > 
> > Sincerely,
> > Saalim Quadri
> >   


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-03-08 14:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-06  0:26 [RFC]: Getting ADIS16203 out of staging Saalim Quadri
2025-03-07  3:32 ` Marcelo Schmitt
2025-03-08 14:42   ` Jonathan Cameron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox