From: Gabriel Shahrouzi <gshahrouzi@gmail.com>
To: gregkh@linuxfoundation.org, jic23@kernel.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
Cc: gshahrouzi@gmail.com, skhan@linuxfoundation.org,
linux-kernel-mentees@lists.linux.dev
Subject: [PATCH v3 0/5] staging: iio: adc: ad7816: Fix channel handling
Date: Fri, 18 Apr 2025 16:47:34 -0400 [thread overview]
Message-ID: <cover.1745007964.git.gshahrouzi@gmail.com> (raw)
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?
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(-)
--
2.43.0
next reply other threads:[~2025-04-18 20:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 20:47 Gabriel Shahrouzi [this message]
2025-04-18 20:47 ` [PATCH v3 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
2025-04-18 20:47 ` [PATCH v3 2/5] staging: iio: adc: ad7816: Rename state structure Gabriel Shahrouzi
2025-04-18 20:47 ` [PATCH v3 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
2025-04-18 20:47 ` [PATCH v3 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
2025-04-18 20:47 ` [PATCH v3 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
2025-04-19 12:19 ` kernel test robot
2025-04-19 13:11 ` kernel test robot
2025-04-21 11:29 ` [PATCH v3 0/5] staging: iio: adc: ad7816: Fix channel handling Jonathan Cameron
2025-04-21 13:44 ` 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=cover.1745007964.git.gshahrouzi@gmail.com \
--to=gshahrouzi@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--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