All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Greg KH <greg@kroah.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: RFC: Merge strategy for Industrial I/O (staging?)
Date: Wed, 12 Aug 2009 10:09:33 +0000	[thread overview]
Message-ID: <4A8294DD.3080205@cam.ac.uk> (raw)
In-Reply-To: <20090812155101.GA30629@kroah.com>

Greg KH wrote:
> On Wed, Aug 12, 2009 at 09:27:05AM +0000, Jonathan Cameron wrote:
>> 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 accelerometers, 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?'
> 
> Yes, I have no objection to taking these patches in staging for now, as
> long as you submit it with a TODO list of things left to be done to get
> it merged to the main portion of the kernel tree.
> 
> So, send me the patches!
Will do, thanks.

Jonathan


  reply	other threads:[~2009-08-12 16:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-12  9:27 RFC: Merge strategy for Industrial I/O (staging?) Jonathan Cameron
2009-08-12 15:51 ` Greg KH
2009-08-12 10:09   ` Jonathan Cameron [this message]
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=4A8294DD.3080205@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=akpm@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.