From: Jonathan Cameron <jic23@cam.ac.uk>
To: LKML <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: RFC: Merge strategy for Industrial I/O (staging?)
Date: Wed, 12 Aug 2009 09:27:05 +0000 [thread overview]
Message-ID: <4A828AE9.9090807@cam.ac.uk> (raw)
Dear All,
IIO is intended to be a subsystem for sensors such as ADCs, accelerometers,
gyros, light sensors and others that have reasonably high update rates and
typically are connected via i2c or spi busses.
The latest patch set posted to lkml was v4
http://thread.gmane.org/gmane.linux.kernel/860693
Tree at
http://git.kernel.org/?p=linux/kernel/git/jic23/iio_v4.git;a=summary
original discussion of the need for such a subsystem:
http://lkml.org/lkml/2008/5/20/135
The last couple of versions of IIO have recieved some useful feedback from
a number of people, and feedback from various users has led to a number
of recent bug fixes. Unfortunately, full reviews of any given element have
not be forthcoming. Several people who have in principle offered to help
haven't had the time as yet.
In the short term, the lack of review of the core (patch 1 of the above set)
leads to a stack of device drivers sitting in the git repository waiting on
the core being merged. Currently in the tree there are 3 acceleromters, an
adc and a light sensor. I also have an IMU driver (ADIS16350 family) that
needs a little more cleaning up and testing with latest IIO core.
Increasing numbers of drivers that would fall within the scope of IIO are
being submitted to various other subsystems (hwmon for example) and getting
bounced out as inappropriate for that subsystem. So, whilst I'd be reasonably
happy to maintain the subsystem out of kernel until interest in the devices
covered grows, or people have time to assist, I was wondering whether it
would be appropriate to submit the subsystem and the associated driver
set to staging.
Whilst some elements could definitely do with more work (for example the
use of rtc's to get periodic timers, is clunky at best), much of the core
and the actual device drivers are to my mind pretty clean. So the question
is, 'Is lack of reviewers a valid reason to submit to staging in the meantime?'
What do people think?
All offers of review or other suggestions on how to proceed also welcome!
Also I'm still not that keen on the name if anyone has a better idea.
Thanks
Jonathan
next reply other threads:[~2009-08-12 15:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-12 9:27 Jonathan Cameron [this message]
2009-08-12 15:51 ` RFC: Merge strategy for Industrial I/O (staging?) Greg KH
2009-08-12 10:09 ` Jonathan Cameron
2009-08-12 21:10 ` Robert Schwebel
2009-08-13 5:45 ` Jonathan Cameron
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=4A828AE9.9090807@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/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