From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
To: Saalim Quadri <danascape@gmail.com>
Cc: jic23@kernel.org, lars@metafoo.de, Michael.Hennerich@analog.com,
gregkh@linuxfoundation.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev
Subject: Re: [RFC]: Getting ADIS16203 out of staging
Date: Fri, 7 Mar 2025 00:32:30 -0300 [thread overview]
Message-ID: <Z8pozuvS1a3sa039@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20250306002645.1555569-1-danascape@gmail.com>
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
>
next prev parent reply other threads:[~2025-03-07 3:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 0:26 [RFC]: Getting ADIS16203 out of staging Saalim Quadri
2025-03-07 3:32 ` Marcelo Schmitt [this message]
2025-03-08 14:42 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8pozuvS1a3sa039@debian-BULLSEYE-live-builder-AMD64 \
--to=marcelo.schmitt1@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=danascape@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox