---

yaml
---
r: 175230
b: refs/heads/master
c: 51bf00a
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 727acb4fb2143ac7228b9a49f9e2f73f71e748d9
+refs/heads/master: 51bf00aef02d410bf74afb31ec2d5dbcedb1a52f

trunk/drivers/staging/iio/Documentation/device.txt

@@ -10,7 +10,7 @@ First allocate one using:
 
 struct iio_dev *indio_dev = iio_allocate_device();
 
-The fill in the following.
+Then fill in the following:
 
 indio_dev->dev.parent
   the struct device associated with the underlying hardware.
@@ -45,5 +45,5 @@ allocated prior to registering the device with the iio-core, but must
 be registered afterwards (otherwise the whole parentage of devices
 gets confused)
 
-On remove iio_device_unregister(indio_dev) will remove the device from
+On remove, iio_device_unregister(indio_dev) will remove the device from
 the core, and iio_free_device will clean up.

trunk/drivers/staging/iio/Documentation/overview.txt

@@ -24,11 +24,12 @@ hwmon with simple polled access to device channels via sysfs.
 * Event chrdevs.  These are similar to input in that they provide a
 route to user space for hardware triggered events. Such events include
 threshold detectors, free-fall detectors and more complex action
-detection.  They events themselves are currently very simple with
+detection.  The events themselves are currently very simple with
 merely an event code and a timestamp.  Any data associated with the
-event must be accessed via polling. Note a given device may have one
-or more event channel.  These events are turned on or off (if possible)
-via sysfs interfaces.
+event must be accessed via polling.
+
+Note: A given device may have one or more event channel.  These events are
+turned on or off (if possible) via sysfs interfaces.
 
 * Hardware ring buffer support.  Some recent sensors have included
 fifo / ring buffers on the sensor chip.  These greatly reduce the load