linux-kernel - RFC: Merge strategy for Industrial I/O (staging?)

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-next>] [day] [month] [year] [list]

Date:	Wed, 12 Aug 2009 09:27:05 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	LKML <linux-kernel@...r.kernel.org>, Greg KH <greg@...ah.com>
Subject: RFC: Merge strategy for Industrial I/O (staging?)

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/