Arnd Bergmann [off-list ref] wrote:

On Tuesday 17 January 2012, AnilKumar, Chimata wrote:

quoted

Hi All,

Recalling the patch, provide the comments if there are any if not

please include

quoted

this patch to v3.3 kernel.

As Mark and Greg said, 3.4 would be appropriate.

quoted

+static ssize_t lis3lv02d_range_set(struct device *dev,
+				struct device_attribute *attr, const char *buf,
+				size_t count)
+{
+	unsigned long range;
+
+	if (strict_strtoul(buf, 0, &range))
+		return -EINVAL;
+
+	lis3_dev.g_range = range;
+	lis3lv02d_update_g_range(&lis3_dev);
+
+	return count;
+}
+
 static DEVICE_ATTR(selftest, S_IRUSR, lis3lv02d_selftest_show,

NULL);

quoted

 static DEVICE_ATTR(position, S_IRUGO, lis3lv02d_position_show,

NULL);

quoted

 static DEVICE_ATTR(rate, S_IRUGO | S_IWUSR, lis3lv02d_rate_show,
 					    lis3lv02d_rate_set);
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, lis3lv02d_range_show,
+					    lis3lv02d_range_set);

I think you need to document this new attribute in the Documentation
directory, unless I missed the other patch doing this.

On a more general topic, do we have a kernel-wide policy for
accelerometer
drivers? AFAICT, we currently have three subsystems that contain 
accelerometer drivers, plus a few ad-hoc ones like this, which is a
rather unpleasant situation. What I found are these:

$ git grep -l accelerometer drivers/ | manual_grep
drivers/hwmon/applesmc.c
  (one hwmon sysfs attribute for x/y/z)
drivers/input/misc/adxl34x.c
  (lots of sysfs attributes, input_report_key)
drivers/input/misc/cma3000_d0x.c
  (input_report_abs)
drivers/input/misc/kxtj9.c
  (input_report_abs, plus one aux sysfs attribute)
drivers/macintosh/ams/ams-core.c
  (one sysfs attribute for x/y/z)
drivers/misc/lis3lv02d/
  (multiple sysfs attributes)
drivers/platform/x86/hdaps.c
  (multiple sysfs attributes, only x/y)
drivers/platform/x86/hp_accel.c
  (hooks into drivers/misc/lis3lv02d/)
drivers/staging/iio/accel/kxsd9.c
  (iio)
drivers/staging/iio/accel/sca3000_core.c
  (iio plus extra attributes)

For what it is worth there are a total of nine iio acceleration drivers. Some are special purpose though.

While I'm not blaming you for the current situation, but I think the
situation is no longer sustainable and we need to decide on one place
and interface for these to go in the long run so we don't grow even
more nonstandard interfaces.

Any opinions where they should live? input, iio or a new subsystem?

Personal thought is that straight 3d devices very directed at input should go there. Iio has a few wrinkles left for the in kernel interfaces needed for a bridge to input. For starters the pull and push data interfaces have not merged yet (in staging) and we have not started on in kernel acess to non data events yet(thresholds).  Still happy to take them when we can support usecases fully. 
Of course any help getting there would be most welcome!

Jonathan

Arnd

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.