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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170603100758.6164e219@kernel.org>
Date:   Sat, 3 Jun 2017 10:07:58 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc:     Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Sanchayan Maity <maitysanchayan@...il.com>,
        Gregor Boirie <gregor.boirie@...rot.com>,
        Matt Ranostay <mranostay@...il.com>, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org, Chris Healy <Chris.Healy@....aero>,
        Jeff White <Jeff.White@....aero>,
        Vladimir Barinov <vladimir.barinov@...entembedded.com>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH/RFC] iio: hi8435: do not enable all events by default

On Mon, 29 May 2017 08:40:26 +0300
Nikita Yushchenko <nikita.yoush@...entembedded.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html