Re: [PATCH/RFC] iio: hi8435: do not enable all events by default

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 29 May 2017 08:40:26 +0300
Nikita Yushchenko <nikita.yoush@cogentembedded.com> wrote:

> >> Still, isn't there subsystem-level default that all events are disabled
> >> by default?  If such, then current hi8435 state breaks subsystem-level
> >> rules, which is a [userspace-visible] bug.  I'm not sure how far should
> >> we go in bug compatibility.  
> >
> > It is indeed the subsystem default (as much as we have one)
> > 
> > This is a moderately obscure chip for linux systems, do we have a good handle
> > on where it is being used - i.e. are most of the devices under control of
> > people we can discuss this with?  
> 
> Company I work with, uses this chip in several boards; what they need is
> a service that monitors all connected chip's outputs and detects
> changes.  They originally wanted gpio-style access to use with userspace
> polling, and were not pleased with entire IIO thing. However it's
> important for them to minimize required kernel patches against mainline,
> thus if mainline supports this chip as IIO device that's ok for them.
Was always an odd corner case - and I'll admit it wasn't one that made
me very comfortable either. One option would be to put a GPIO bridge
driver in place so that both interfaces are available.  I know this is
something Linus and I have thought about in the past for various
use cases.
> 
> Questions like default event enable state has little practical impact.
> It's more about keeping architecture clean.
I'm going to go with not changing this, even though it matters little to
either of you.  Simply because we clearly do have a non trivial number of
users and this would be ABI breakage.

Jonathan

> 
> Nikita
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html