linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).