Merge branch 'poll' into staging/for_v3.4

* poll: (5970 commits)
  poll: add poll_requested_events() and poll_does_not_wait() functions
  crc32: select an algorithm via Kconfig
  crc32: add self-test code for crc32c
  crypto: crc32c should use library implementation
  crc32: bolt on crc32c
  crc32: add note about this patchset to crc32.c
  crc32: optimize loop counter for x86
  crc32: add slice-by-8 algorithm to existing code
  crc32: make CRC_*_BITS definition correspond to actual bit counts
  crc32: fix mixing of endian-specific types
  crc32: miscellaneous cleanups
  crc32: simplify unit test code
  crc32: move long comment about crc32 fundamentals to Documentation/
  crc32: remove two instances of trailing whitespaces
  checkpatch: check for quoted strings broken across lines
  checkpatch: whitespace - add/remove blank lines
  checkpatch: warn on use of yield()
  checkpatch: add --strict tests for braces, comments and casts
  checkpatch: add [] to type extensions
  checkpatch: high precedence operators do not require additional parentheses in #defines
  ...

1 files changed, 58 insertions, 0 deletions

diff --git a/drivers/staging/iio/Documentation/inkernel.txt b/drivers/staging/iio/Documentation/inkernel.txt
new file mode 100644
index 0000000..a05823e
--- /dev/null
+++ b/drivers/staging/iio/Documentation/inkernel.txt
@@ -0,0 +1,58 @@
+Industrial I/O Subsystem in kernel consumers.
+
+The IIO subsystem can act as a layer under other elements of the kernel
+providing a means of obtaining ADC type readings or of driving DAC type
+signals.  The functionality supported will grow as use cases arise.
+
+Describing the channel mapping (iio/machine.h)
+
+Channel associations are described using:
+
+struct iio_map {
+	const char *adc_channel_label;
+	const char *consumer_dev_name;
+	const char *consumer_channel;
+};
+
+adc_channel_label identifies the channel on the IIO device by being
+matched against the datasheet_name field of the iio_chan_spec.
+
+consumer_dev_name allows identification of the consumer device.
+This are then used to find the channel mapping from the consumer device (see
+below).
+
+Finally consumer_channel is a string identifying the channel to the consumer.
+(Perhaps 'battery_voltage' or similar).
+
+An array of these structures is then passed to the IIO driver.
+
+Supporting in kernel interfaces in the driver (driver.h)
+
+The driver must provide datasheet_name values for its channels and
+must pass the iio_map structures and a pointer to its own iio_dev structure
+ on to the core via a call to iio_map_array_register.  On removal,
+iio_map_array_unregister reverses this process.
+
+The result of this is that the IIO core now has all the information needed
+to associate a given channel with the consumer requesting it.
+
+Acting as an IIO consumer (consumer.h)
+
+The consumer first has to obtain an iio_channel structure from the core
+by calling iio_channel_get().  The correct channel is identified by:
+
+* matching dev or dev_name against consumer_dev and consumer_dev_name
+* matching consumer_channel against consumer_channel in the map
+
+There are then a number of functions that can be used to get information
+about this channel such as it's current reading.
+
+e.g.
+iio_st_read_channel_raw() - get a reading
+iio_st_read_channel_type() - get the type of channel
+
+There is also provision for retrieving all of the channels associated
+with a given consumer.  This is useful for generic drivers such as
+iio_hwmon where the number and naming of channels is not known by the
+consumer driver.  To do this, use iio_st_channel_get_all.
+