linux-kernel - Re: [RFC]: Getting ADIS16203 out of staging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250308144239.0442f1a7@jic23-huawei>
Date: Sat, 8 Mar 2025 14:42:39 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: Saalim Quadri <danascape@...il.com>, lars@...afoo.de,
 Michael.Hennerich@...log.com, gregkh@...uxfoundation.org,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-staging@...ts.linux.dev
Subject: Re: [RFC]: Getting ADIS16203 out of staging

On Fri, 7 Mar 2025 00:32:30 -0300
Marcelo Schmitt <marcelo.schmitt1@...il.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
> >