public inbox for linux-kernel-mentees@lists.linux-foundation.org
 help / color / mirror / Atom feed
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(-)
> 


  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