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-next>] [day] [month] [year] [list]
Date: Fri, 23 Feb 2024 13:45:20 +0100
From: Quentin Schulz <foss+kernel@...il.net>
To: Jonathan Cameron <jic23@...nel.org>, 
 Lars-Peter Clausen <lars@...afoo.de>, Heiko Stuebner <heiko@...ech.de>, 
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, 
 Andy Shevchenko <andy.shevchenko@...il.com>, 
 Shreeya Patel <shreeya.patel@...labora.com>, Simon Xue <xxm@...k-chips.com>, 
 Philipp Zabel <p.zabel@...gutronix.de>
Cc: 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>, 
 Quentin Schulz <foss+kernel@...il.net>
Subject: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove
 custom logic for getting reset

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.

Signed-off-by: Quentin Schulz <quentin.schulz@...obroma-systems.com>
---
Quentin Schulz (3):
      iio: adc: rockchip_saradc: fix bitmask for channels on SARADCv2
      iio: adc: rockchip_saradc: use mask for write_enable bitfield
      iio: adc: rockchip_saradc: replace custom logic with devm_reset_control_get_optional_exclusive

 drivers/iio/adc/rockchip_saradc.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)
---
base-commit: 39133352cbed6626956d38ed72012f49b0421e7b
change-id: 20240222-saradcv2-chan-mask-593585865256

Best regards,
-- 
Quentin Schulz <quentin.schulz@...obroma-systems.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ