iio: dac: ad5624r_spi.c - use of scan_type
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: iio: dac: ad5624r_spi.c - use of scan_type
- From: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
- Date: Wed, 18 Dec 2024 10:38:26 +0200
- Cc: Lars-Peter Clausen <lars@xxxxxxxxxx>, Michael Hennerich <Michael.Hennerich@xxxxxxxxxx>, Jonathan Cameron <jic23@xxxxxxxxxx>, linux-iio@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
- User-agent: Mozilla Thunderbird
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
[Index of Archives]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Yosemite News]
[Linux Input]
[Linux Kernel]
[Linux SCSI]
[X.org]