Re: [PATCH 1/3] staging: iio: Fix typos in documentation

[Jonathan Cameron <jic23@cam.ac.uk>]

All look good to me.  Thanks,

Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> Spell-check wouln't catch these :)
> 
> Signed-off-by: Amit Kucheria <amit.kucheria@verdurent.com>
> Cc: Jonathan Cameron <jic23@cam.ac.uk>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> ---
>  drivers/staging/iio/Documentation/device.txt   |    4 ++--
>  drivers/staging/iio/Documentation/overview.txt |    9 +++++----
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/iio/Documentation/device.txt b/drivers/staging/iio/Documentation/device.txt
> index 6916cd3..69d9570 100644
> --- a/drivers/staging/iio/Documentation/device.txt
> +++ b/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.
> diff --git a/drivers/staging/iio/Documentation/overview.txt b/drivers/staging/iio/Documentation/overview.txt
> index 64584ad..e39dfc1 100644
> --- a/drivers/staging/iio/Documentation/overview.txt
> +++ b/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