Hi Jonathan, On Sun May 16, 2021 at 5:06 AM EDT, Jonathan Cameron wrote: > On Sun, 16 May 2021 00:43:13 -0400 > Liam Beguin <liambeguin@xxxxxxxxx> wrote: > > > Add a devicetree binding to optionally force a different IIO channel > > type. > > > > This is useful in cases where ADC channels are connected to a circuit > > that represent another unit such as a temperature or a current. > > > > `channel-types` was chosen instead of `io-channel-types` as this is not > > part of the iio consumer bindings. > > > > In the current form, this patch does what it's intended to do: > > change the unit displayed by `sensors`, but feels like the wrong way to > > address the problem. > > > > Would it be possible to force the type of different IIO channels for > > this kind of use case with a devicetree binding from the IIO subsystem? > > > > It would be convenient to do it within the IIO subsystem to have the > > right unit there too. > > > > Thanks for your time, > > Liam > > Hi Liam, > > +CC Peter for AFE part. > > It's an interesting approach, but I would suggest we think about this > a different way. > > Whenever a channel is being used to measure something 'different' from > what it actually measures (e.g. a voltage ADC measuring a current) that > reflects their being some analog component involved. > If you look at drivers/iio/afe/iio-rescale.c you can see the approach > we currently use to handle this. Many thanks for pointing out the AFE code. That look like what I was hoping to accomplish, but in a much better way. > > Effectively what you add to devicetree is a consumer of the ADC channel > which in turn provides services to other devices. For this current case > it would be either a current-sense-amplifier or a current-sense-shunt > depending on what the analog front end looks like. We have to describe > the characteristics of that front end which isn't something that can > be done via a simple channel type. > Understood. My original intention was to use sensors.conf to do the conversions and take into accounts those parameters. > That afe consumer device can then provide services to another consumer > (e.g. iio-hwmon) which work for your usecase. > > The main limitation of this approach currently is you end up with > one device per channel. That could be improved upon if you have a > usecase > where it matters. > > I don't think we currently have an equivalent for temperature sensing > but it would be easy enough to do something similar. Wonderful, thanks again for pointing out the AFE! Liam > > Jonathan > > > > > > Liam Beguin (2): > > hwmon: (iio_hwmon) optionally force iio channel type > > dt-bindings: hwmon: add iio-hwmon bindings > > > > .../devicetree/bindings/hwmon/iio-hwmon.yaml | 41 +++++++++++++++++++ > > drivers/hwmon/iio_hwmon.c | 2 + > > 2 files changed, 43 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml > > > > > > base-commit: 9f4ad9e425a1d3b6a34617b8ea226d56a119a717
