Re: [RFC PATCH v2 4/5] iio: accel: Support Kionix/ROHM KX022A accelerometer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/10/22 16:20, Vaittinen, Matti wrote:
On 10/10/22 14:58, Andy Shevchenko wrote:
On Mon, Oct 10, 2022 at 12:12:34PM +0300, Matti Vaittinen wrote:
...

+	ret = regmap_bulk_read(data->regmap, chan->address, &data->buffer,
+			       sizeof(s16));

No endianess awareness (sizeof __le16 / __be16)

+	if (ret)
+		return ret;
+
+	*val = data->buffer[0];

Ditto (get_unaligned_be16/le16 / le16/be16_to_cpup()).

I have probably misunderstood something but I don't see why we should use
'endianess awareness' in drivers? I thought the IIO framework code takes
care of the endianes conversions based on scan_type so each individual
driver does not need to do that. That however has been just my assumption. I
will need to check this. Thanks for pointing it out.

The IIO core uses endianness field only once in iio_show_fixed_type() AFAICS.

Following is some hand waving and speculation after my quick code read. So, I may be utterly wrong in which case please do correct me...

Anyways, it seems to me that you're correct. The endianness field is only used by the IIO to build the channel information for user-space so that applications reading data can parse it. As far as I understand, the driver does not need to do the conversions for user-space, but the user-space tools should inspect the type information and do the conversion. I think it makes sense as user-space applications may be better equipped to do some maths. It also may be some applications do not want to spend cycles doing the conversion but the conversions can be done later "offline" for the captured raw data. So omitting conversion in the IIO driver kind of makes sense to me.

I haven't thoroughly looked (and I have never used) the in-kernel IIO APIs for getting the data. A quick look at the include/linux/iio/consumer.h allows me to assume the iio_chan_spec can be obtained by the consumer drivers. This should make the endianess information available for the consumer drivers as well. So, again, consumer drivers can parse the raw-format data themself.

I have this far only used the sysfs and iio_generic_buffer on a little-endian machine so I have had no issues with the little-endian data and I have only observed the code. Hence I can not really say if my reasoning is correct - or if it is how IIO has been designed to operate. But based on my quick study I don't see a need for the IIO driver to do endianess conversion to any other format but what is indicated by scan_type. Specifically for KX022A, the data is already 16B LE when read from the sensor. This is also advertised by scan_type so no conversion should be needed (unless, of course, I am mistaken :]).

And it does nothing with it. Maybe Jonathan can shed a light what is it for
(I mean the field)?


I agree. It'd be great to listen to someone who actually knows what he is talking about and is not just guessing as I am ^_^;

Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux