linux-kernel - Re: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240224192535.237933de@jic23-huawei>
Date: Sat, 24 Feb 2024 19:25:35 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Quentin Schulz <foss+kernel@...il.net>, Lars-Peter Clausen
 <lars@...afoo.de>, Heiko Stuebner <heiko@...ech.de>, AngeloGioacchino Del
 Regno <angelogioacchino.delregno@...labora.com>, Shreeya Patel
 <shreeya.patel@...labora.com>, Simon Xue <xxm@...k-chips.com>, Philipp
 Zabel <p.zabel@...gutronix.de>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, linux-iio@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Quentin Schulz
 <quentin.schulz@...obroma-systems.com>
Subject: Re: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and
 remove custom logic for getting reset

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

> On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@...ilnet> 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@...il.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