public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Quentin Schulz <foss+kernel@0leil.net>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Heiko Stuebner <heiko@sntech.de>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Shreeya Patel <shreeya.patel@collabora.com>,
	Simon Xue <xxm@rock-chips.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	Quentin Schulz <quentin.schulz@theobroma-systems.com>
Subject: Re: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset
Date: Sat, 24 Feb 2024 19:25:35 +0000	[thread overview]
Message-ID: <20240224192535.237933de@jic23-huawei> (raw)
In-Reply-To: <CAHp75VfmsDeTP97srRJU09gA988xw68+ZHsXvXT3W_wv1HEauA@mail.gmail.com>

On Fri, 23 Feb 2024 15:01:30 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
> >
> > The mask for the channel selection is incorrect as it's specified to be
> > 16b wide by is actually only 4.
> >
> > Also, the 16 lower bits in the SARADC_CONV_CON register are write
> > protected. Whatever their value is can only be written to the hardware
> > block if their associated bit in the higher 16 bits is set. Considering
> > that the channel bitmask is 4b wide but that we can write e.g. 0 in
> > there, we shouldn't use the value shifted by 16 as a mask but rather the
> > bitmask for that value shifted by 16. This is currently NOT an issue
> > because the only SoC with SARADCv2 IP is the RK3588 which has a reset
> > defined in the SoC DTSI. When that is the case, the reset is asserted
> > before every channel conversion is started. This means the registers are
> > reset so effectively, we do not need to write zeros so the wrong mask
> > still works because where we should be writing zeroes, there are already
> > zeroes. However, let's fix this in case there comes a day there's an SoC
> > which doesn't require to reset the controller before every channel
> > conversion is started.
> >
> > Lastly, let's use the appropriate function from the reset subsystem
> > for getting an optional exclusive reset instead of rolling out our own
> > logic.
> >
> > Those three patches should not be changing any behavior.  
> 
> Nice series, I have the comments in patch 3, but no need to resend
> until Jonathan asks for. He might address that whilst applying.
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> 

I've take the series through the togreg branch as we are so near the
merge windows.  Note (despite Linus not liking it :)) I use links
in my git tags so anyone really searching for Quentin can find
the discussion.

I'm usually a bit lazy on cleaning out what I would consider unnecessary
CC tags but given Andy comment on these I've dropped the extra
one.

Patches 1 and 2 marked for stable.

Jonathan

      reply	other threads:[~2024-02-24 19:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 12:45 [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset Quentin Schulz
2024-02-23 12:45 ` [PATCH 1/3] iio: adc: rockchip_saradc: fix bitmask for channels on SARADCv2 Quentin Schulz
2024-02-23 13:40   ` Heiko Stübner
2024-02-23 12:45 ` [PATCH 2/3] iio: adc: rockchip_saradc: use mask for write_enable bitfield Quentin Schulz
2024-02-23 13:43   ` Heiko Stübner
2024-02-23 12:45 ` [PATCH 3/3] iio: adc: rockchip_saradc: replace custom logic with devm_reset_control_get_optional_exclusive Quentin Schulz
2024-02-23 13:00   ` Andy Shevchenko
2024-02-23 13:10     ` Quentin Schulz
2024-02-23 14:39       ` Andy Shevchenko
2024-02-26 20:31         ` Dragan Simic
2024-02-27 12:48           ` Andy Shevchenko
2024-02-27 14:55             ` Dragan Simic
2024-02-23 13:44   ` Heiko Stübner
2024-02-23 13:01 ` [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset Andy Shevchenko
2024-02-24 19:25   ` Jonathan Cameron [this message]

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=20240224192535.237933de@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=foss+kernel@0leil.net \
    --cc=heiko@sntech.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=p.zabel@pengutronix.de \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=shreeya.patel@collabora.com \
    --cc=xxm@rock-chips.com \
    /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