Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support

[Guenter Roeck <linux@roeck-us.net>]

On Wed, Jun 15, 2016 at 05:31:10PM +0100, Jonathan Cameron wrote:
> 
> 
> On 15 June 2016 05:18:05 BST, Guenter Roeck <linux@roeck-us.net> wrote:
> >On 06/14/2016 12:01 PM, Matt Ranostay wrote:
> >> Hello Guenter et al,
> >>
> >> So seems I wrote an iio driver for the SHT31 chipset about the same
> >> David Frey had his merged into hwmon tree. So was wondering per
> >> Jonathan's comments what your input on this would be.
> >>
> >>>From what I can see the additional functionality of the hrtimer
> >> trigger + rather fast update/integration time that a case could be
> >> made because of the triggered buffer.
> >>
> >> Now there is some functionality missing from my iio driver than
> >exists
> >> in the hwmon.. like the thermal and humidity trip points (but that
> >can
> >> be handled in a userspace HAL anyway), and the non-clock skewing
> >> read/write functionality (this can be easily added).
> >>
> >
> >I am quite sure that we had this discussion about this very driver
> >before.
> >One of the key reasons for going with hwmon was limit register support.
> >
> >Guess you claim that is no longer relevant since it can be handled in
> >user space ?
> >If so, I would disagree; it seems to be difficult to generate an alert
> >signal
> >from user space.
> Agreed
> >
> >I don't mind if you folks want drivers for chips like like this (ie
> >chips supporting
> >limits, or in other words typical hardware monitoring chips) in iio,
> >but I would
> >kindly ask to enhance the iio subsystem to support limits.
> 
> It has done since day one via event chardev. Limitations are :
> * One per channel per type per direction. (Didn't seem necessary at the time)
> This obviously matters for hwmon chips.
> * No in kernel interface yet so not pushed on to iio-hwmon bridge.
> * Intended for interrupt type limits which do not always correspond to how all 
> devices do it... there are ways around it but only indirectly.
> 
> All fixable and not actually directly relevant for this part (possibly the inkern
>  interface is...)

Sure, all is fixable. Not that it will help here.

If you plan to accept this driver, please let me and David know, and I'll drop
the hwmon driver. It means we'll both have wasted our time, but it does not make
sense to keep two drivers for this chip around.

On another side note, I don't really believe that it makes much sense to add all
this functionality to iio to start with. I'd rather fix the hwmon registration
API and create a hwmon->iio bridge.

Guenter