linux-kernel - iio: dac: ad5624r_spi.c

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 for Android: free password hash cracker in your pocket

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

Message-ID: <3f5ff01b-8c32-423f-b3cc-a95399b69399@gmail.com>
Date: Wed, 18 Dec 2024 10:38:26 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 Matti Vaittinen <mazziesaccount@...il.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: iio: dac: ad5624r_spi.c - use of scan_type

Hi dee Ho peeps,

I started drafting a driver for a ROHM DAC. I took a quick look at the 
ad5624r_spi.c, and the use of the 'scan_type' -field in the struct 
iio_chan_spec puzzled me.

I think this field is used by the driver to convert the data from user 
to register format while performing the INDIO_DIRECT_MODE raw writes. I 
don't spot any buffer usage. Furthermore, as far as I can say the 'sign' 
and 'storagebits' are unused.

My understanding has been that the scan_type is only intended for 
parsing the buffered values, and usually when the data direction is from 
driver to user.

I suppose I shouldn't copy the ad5624r_spi.c use of scan_type to a new 
driver. I'm somewhat tempted to send a patch which drops the scan_type 
from the ad5624r_spi.c, and adds the 'realbits' and 'shift' to the 
driver's internal struct ad5624r_state. This, however, will change the 
interface to userland so maybe it's best to not do that.

I wonder if I am missing something? (That wouldn't be unheard of XD). If 
not, then at least a documentary patch with a comment "don't do this in 
new drivers" might be Ok, or how do you see this?

Yours,
	-- Matti