On Tue, 21 Jun 2022 14:18:55 +0200 Stefan Lengfeld <stefan.lengfeld@xxxxxxxxx> wrote: > Hi all, Hi Stefan, > > I'm currently working on a linux kernel driver for a new sensor design. It's a > special kind of light sensor that measures the reflection of emitted light. > > I'm trying to fit this type of sensor into the IIO subsystem but I hit some > issues. > > > Question 1: > > The sensor measures the absorbance[1] of a material. It's the negative > logarithmic quotient of the received and emitted light. It's a unit-less value. > > As far as I can see there is currently no predefined IIO type in the kernel for > this. I have search the list [2], but nothing matches. > > Do I overlook something or what channel type should I use for this sensor > measurement value? So the closest we've seen to this is some of the health sensors (pulse oximeter targeting devices) but in that case the processing is done with a custom userspace library so we just pass values on in fixed point. So probably needs a new channel type. > > > Question 2: > > The sensor effectively returns a float value of the measurement. I grepped trough > the existing IIO drivers, but there seems only one driver that deals with float > values. The sps30 driver[3] gets a float from the device, but converts it to a > integer value before passing it to the IIO subsystem. > > I know that it's possible to provide a 'scale' attribute per channel to > userspace[4], which can be a float point number. More fixed point - though we have a couple of precision options. The aim there is to ensure we only need a few bits of custom code to consume these values in kernel. Raw value can also be fixed point. > So effectively the result of a > measurement can be a float-point value after it's computed in userspace. > > Are floats really not supported as channel values? What is the recommend > approach to deal with these measurement values? So, in kernel we basically can't do floats (not quite true, but near enough that it doesn't matter). Given IIO can have in kernel consumers, that more or less rules out true floating point handling. We have in the past discussed simply passing them on to userspace (and hence ruling out any interpretation of the value) but so far no one has added the necessary support. I'm not against adding that support, but I would want to see the code / docs to fully understand why we are doing it. It will be a special case in various code paths hence the extra consideration needed. > > > Question 3: > > Is there another kernel subsystem/UAPI that fits this type of sensor > better? (My guess would be: No, IIO is the correct subsystem.) Based on your description, IIO is the best option. Jonathan > > > Thanks a lot for answering my question. > > > Kind regards, > Stefan > > [1]: https://en.wikipedia.org/wiki/Absorbance > [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/iio/types.h#n14 > [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/chemical/sps30.c#n39 > [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/dummy/iio_simple_dummy.c#n122
