From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Sanchayan Maity <maitysanchayan@gmail.com>,
Gregor Boirie <gregor.boirie@parrot.com>,
Matt Ranostay <mranostay@gmail.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
Chris Healy <Chris.Healy@zii.aero>,
Jeff White <Jeff.White@zii.aero>,
Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Subject: Re: [PATCH/RFC] iio: hi8435: do not enable all events by default
Date: Mon, 29 May 2017 08:40:26 +0300 [thread overview]
Message-ID: <b47aa21c-925d-7a83-7bd0-0d9d73f79017@cogentembedded.com> (raw)
In-Reply-To: <20170528164846.3fa3d4d8@kernel.org>
>> 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.
Questions like default event enable state has little practical impact.
It's more about keeping architecture clean.
Nikita
next prev parent reply other threads:[~2017-05-29 5:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 8:08 [PATCH/RFC] iio: hi8435: do not enable all events by default Nikita Yushchenko
2017-05-24 19:27 ` Jonathan Cameron
2017-05-25 5:47 ` Nikita Yushchenko
2017-05-28 15:48 ` Jonathan Cameron
[not found] ` <CY4PR12MB12549ADA207663849E8DBE8583F20@CY4PR12MB1254.namprd12.prod.outlook.com>
2017-05-28 17:00 ` Fw: " Chris Healy
2017-05-29 5:40 ` Nikita Yushchenko [this message]
2017-06-03 9:07 ` Jonathan Cameron
2017-06-09 9:17 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b47aa21c-925d-7a83-7bd0-0d9d73f79017@cogentembedded.com \
--to=nikita.yoush@cogentembedded.com \
--cc=Chris.Healy@zii.aero \
--cc=Jeff.White@zii.aero \
--cc=gregor.boirie@parrot.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maitysanchayan@gmail.com \
--cc=mranostay@gmail.com \
--cc=pmeerw@pmeerw.net \
--cc=vladimir.barinov@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).