From: Jonathan Cameron <jic23@kernel.org>
To: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Cc: gregkh@linuxfoundation.org, lars@metafoo.de,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-staging@lists.linux.dev, Michael.Hennerich@analog.com,
sonic.zhang@analog.com, vapier@gentoo.org,
skhan@linuxfoundation.org, linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor
Date: Mon, 21 Apr 2025 12:31:27 +0100 [thread overview]
Message-ID: <20250421123127.3a5a7d65@jic23-huawei> (raw)
In-Reply-To: <20250420014910.849934-1-gshahrouzi@gmail.com>
On Sat, 19 Apr 2025 21:49:05 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
> The original patch combined a functional fix (allowing channel 7) with
> several refactoring steps (introducing chip_info, renaming structs,
> improving validation). As requested, these have now been separated.
>
> The series proceeds as follows:
> 1. Fix: Allow diagnostic channel 7 for all device variants.
> 2. Refactor: Rename the main state structure for clarity before introducing
> the new chip_info struct.
> 3. Refactor: Introduce struct ad7816_chip_info to hold static per-variant
> data, update ID tables to store pointers, and switch to using
> device_get_match_data() for firmware-independent identification.
> This removes the old enum/id mechanism.
> 4. Refactor: Add has_busy_pin to chip_info and use this flag to
> determine BUSY pin handling, replacing pointer comparisons.
> 5. Refactor: Simplify channel validation logic using
> chip_info->max_channels, removing strcmp() checks.
>
> Regarding the 'fixes' tag: I've applied it only to the first commit
> containing the core fix, primarily to make backporting easier. Is this
> the standard practice, or should the tag typically be applied to
> subsequent commits that build upon or are related to the fix as well?
>
> Changes in v5:
> - Use correct patch version.
Generally I wouldn't resend for this. Instead a single email in
reply to the messed up version saying it is infact v4 would have
done the job.
Alternatively a quick reply to that thread to say it was messed
up and please look for v5 would have worked to make a reader
move on directly to the newer version
Jonathan
> Changes in v4:
> - Include missing bracket for condtional statement.
> Chainges in v3:
> - Split the patch into smaller patches. Make the fix first
> followed by clean up.
> - Include missing channel for channel selection.
> - Address specific feedback regarding enums vs. chip_info data.
> - Use device_get_match_data() for device identification.
> - Move BUSY pin capability check into chip_info data.
> - Simplify channel validation using chip_info data.
> Changes in v2:
> - Refactor by adding chip_info struct which simplifies
> conditional logic.
>
> Gabriel Shahrouzi (5):
> staging: iio: adc: ad7816: Allow channel 7 for all devices
> staging: iio: adc: ad7816: Rename state structure
> staging: iio: adc: ad7816: Introduce chip_info and use pointer
> matching
> staging: iio: adc: ad7816: Use chip_info for device capabilities
> staging: iio: adc: ad7816: Simplify channel validation using chip_info
>
> drivers/staging/iio/adc/ad7816.c | 94 ++++++++++++++++++--------------
> 1 file changed, 54 insertions(+), 40 deletions(-)
>
next prev parent reply other threads:[~2025-04-21 11:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
2025-04-21 12:29 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 2/5] staging: iio: adc: ad7816: Rename state structure Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
2025-04-21 12:34 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
2025-04-21 12:35 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
2025-04-21 12:37 ` Jonathan Cameron
2025-04-21 11:31 ` Jonathan Cameron [this message]
2025-04-21 13:49 ` [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
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=20250421123127.3a5a7d65@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshahrouzi@gmail.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=sonic.zhang@analog.com \
--cc=vapier@gentoo.org \
/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