Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

Pull input subsystem updates from Dmitry Torokhov:
 "Just a swath of driver fixes and cleanups, no new drivers this time
  (although ALPS now supports one of the newer protocols, more to come)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (57 commits)
  Input: wacom - add support for DTU-1031
  Input: wacom - fix wacom->shared guards for dual input devices
  Input: edt_ft5x06 - use devm_* functions where appropriate
  Input: hyperv-keyboard - pass through 0xE1 prefix
  Input: logips2pp - fix spelling s/reciver/receiver/
  Input: delete non-required instances of include <linux/init.h>
  Input: twl4030-keypad - convert to using managed resources
  Input: twl6040-vibra - remove unneeded check for CONFIG_OF
  Input: twl4030-keypad - add device tree support
  Input: twl6040-vibra - add missing of_node_put
  Input: twl4030-vibra - add missing of_node_put
  Input: i8042 - cleanup SERIO_I8042 dependencies
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on x86
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on unicore32
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on sparc
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO for SH_CAYMAN
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on powerpc
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on mips
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on IA64
  Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on ARM/Footbridge
  ...

7 files changed, 128 insertions, 26 deletions

diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
new file mode 100644
index 000000000000..a5086e37fce6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-beeper.txt
@@ -0,0 +1,13 @@
+* GPIO beeper device tree bindings
+
+Register a beeper connected to GPIO pin.
+
+Required properties:
+- compatible:	Should be "gpio-beeper".
+- gpios:	From common gpio binding; gpio connection to beeper enable pin.
+
+Example:
+	beeper: beeper {
+		compatible = "gpio-beeper";
+		gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
+	};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
new file mode 100644
index 000000000000..ec365e172236
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -0,0 +1,41 @@
+* Texas Instruments tsc2007 touchscreen controller
+
+Required properties:
+- compatible: must be "ti,tsc2007".
+- reg: I2C address of the chip.
+- ti,x-plate-ohms: X-plate resistance in ohms.
+
+Optional properties:
+- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
+  The penirq pin goes to low when the panel is touched.
+  (see GPIO binding[1] for more details).
+- interrupt-parent: the phandle for the gpio controller
+  (see interrupt binding[0]).
+- interrupts: (gpio) interrupt to which the chip is connected
+  (see interrupt binding[0]).
+- ti,max-rt: maximum pressure.
+- ti,fuzzx: specifies the absolute input fuzz x value.
+  If set, it will permit noise in the data up to +- the value given to the fuzz
+  parameter, that is used to filter noise from the event stream.
+- ti,fuzzy: specifies the absolute input fuzz y value.
+- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,poll-period: how much time to wait (in milliseconds) before reading again the
+  values from the tsc2007.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+	&i2c1 {
+		/* ... */
+		tsc2007@49 {
+			compatible = "ti,tsc2007";
+			reg = <0x49>;
+			interrupt-parent = <&gpio4>;
+			interrupts = <0x0 0x8>;
+			gpios = <&gpio4 0 0>;
+			ti,x-plate-ohms = <180>;
+		};
+
+		/* ... */
+	};
diff --git a/Documentation/devicetree/bindings/input/twl4030-keypad.txt b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
new file mode 100644
index 000000000000..e4be2f76a717
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
@@ -0,0 +1,27 @@
+* TWL4030's Keypad Controller device tree bindings
+
+TWL4030's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+ * keypad,num-rows and keypad,num-columns are required.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+   - "ti,twl4030-keypad": For controllers compatible with twl4030 keypad
+      controller.
+- interrupt: should be one of the following
+   - <1>: For controllers compatible with twl4030 keypad controller.
+
+Example:
+	twl_keypad: keypad {
+		compatible = "ti,twl4030-keypad";
+		interrupts = <1>;
+		keypad,num-rows = <8>;
+		keypad,num-columns = <8>;
+	};
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
new file mode 100644
index 000000000000..c864a46cddcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
@@ -0,0 +1,21 @@
+Texas Instruments TWL family (twl4030) pwrbutton module
+
+This module is part of the TWL4030. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/twl-familly.txt.
+
+This module provides a simple power button event via an Interrupt.
+
+Required properties:
+- compatible: should be one of the following
+   - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
+- interrupts: should be one of the following
+   - <8>: For controllers compatible with twl4030
+
+Example:
+
+&twl {
+	twl_pwrbutton: pwrbutton {
+		compatible = "ti,twl4030-pwrbutton";
+		interrupts = <8>;
+	};
+};
diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 31bb6a4029ef..3f6d8a5e9cdc 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -68,7 +68,7 @@ features that you need, first. How each feature is mapped is described below.
 Legacy drivers often don't comply to these rules. As we cannot change them
 for backwards-compatibility reasons, you need to provide fixup mappings in
 user-space yourself. Some of them might also provide module-options that
-change the mappings so you can adivce users to set these.
+change the mappings so you can advise users to set these.
 
 All new gamepads are supposed to comply with this mapping. Please report any
 bugs, if they don't.
@@ -150,10 +150,10 @@ Menu-Pad:
                   BTN_START
   Many pads also have a third button which is branded or has a special symbol
   and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo
-  "HOME" button, the XBox "X"-button or Sony "P" button.
+  "HOME" button, the XBox "X"-button or Sony "PS" button.
 
 Rumble:
-  Rumble is adverticed as FF_RUMBLE.
+  Rumble is advertised as FF_RUMBLE.
 
 ----------------------------------------------------------------------------
   Written 2013 by David Herrmann <dh.herrmann@gmail.com>
diff --git a/Documentation/input/joystick-api.txt b/Documentation/input/joystick-api.txt
index c507330740cd..943b18eac918 100644
--- a/Documentation/input/joystick-api.txt
+++ b/Documentation/input/joystick-api.txt
@@ -16,14 +16,14 @@ joystick.
 
 By default, the device is opened in blocking mode.
 
-	int fd = open ("/dev/js0", O_RDONLY);
+	int fd = open ("/dev/input/js0", O_RDONLY);
 
 
 2. Event Reading
 ~~~~~~~~~~~~~~~~
 
 	struct js_event e;
-	read (fd, &e, sizeof(struct js_event));
+	read (fd, &e, sizeof(e));
 
 where js_event is defined as
 
@@ -34,8 +34,8 @@ where js_event is defined as
 		__u8 number;    /* axis/button number */
 	};
 
-If the read is successful, it will return sizeof(struct js_event), unless
-you wanted to read more than one event per read as described in section 3.1.
+If the read is successful, it will return sizeof(e), unless you wanted to read
+more than one event per read as described in section 3.1.
 
 
 2.1 js_event.type
@@ -99,9 +99,9 @@ may work well if you handle JS_EVENT_INIT events separately,
 
 	if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) {
 		if (js_event.value)
-	        	buttons_state |= (1 << js_event.number);
-	   	else
-	      		buttons_state &= ~(1 << js_event.number);
+			buttons_state |= (1 << js_event.number);
+		else
+			buttons_state &= ~(1 << js_event.number);
 	}
 
 is much safer since it can't lose sync with the driver. As you would
@@ -144,14 +144,14 @@ all events on the queue (that is, until you get a -1).
 For example,
 
 	while (1) {
-		while (read (fd, &e, sizeof(struct js_event)) > 0) {
-	        	process_event (e);
-	   	}
-	   	/* EAGAIN is returned when the queue is empty */
-	   	if (errno != EAGAIN) {
-	      		/* error */
-	   	}
-	   	/* do something interesting with processed events */
+		while (read (fd, &e, sizeof(e)) > 0) {
+			process_event (e);
+		}
+		/* EAGAIN is returned when the queue is empty */
+		if (errno != EAGAIN) {
+			/* error */
+		}
+		/* do something interesting with processed events */
 	}
 
 One reason for emptying the queue is that if it gets full you'll start
@@ -181,7 +181,7 @@ at a time using the typical read(2) functionality. For that, you would
 replace the read above with something like
 
 	struct js_event mybuffer[0xff];
-	int i = read (fd, mybuffer, sizeof(struct mybuffer));
+	int i = read (fd, mybuffer, sizeof(mybuffer));
 
 In this case, read would return -1 if the queue was empty, or some
 other value in which the number of events read would be i /
@@ -269,9 +269,9 @@ The driver offers backward compatibility, though. Here's a quick summary:
 	struct JS_DATA_TYPE js;
 	while (1) {
 		if (read (fd, &js, JS_RETURN) != JS_RETURN) {
-	      		/* error */
-	   	}
-	   	usleep (1000);
+			/* error */
+		}
+		usleep (1000);
 	}
 
 As you can figure out from the example, the read returns immediately,
diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt
index 304262bb661a..8d027dc86c1f 100644
--- a/Documentation/input/joystick.txt
+++ b/Documentation/input/joystick.txt
@@ -116,7 +116,7 @@ your needs:
   For testing the joystick driver functionality, there is the jstest
 program in the utilities package. You run it by typing:
 
-	jstest /dev/js0
+	jstest /dev/input/js0
 
   And it should show a line with the joystick values, which update as you
 move the stick, and press its buttons. The axes should all be zero when the
@@ -136,7 +136,7 @@ joystick should be autocalibrated by the driver automagically. However, with
 some analog joysticks, that either do not use linear resistors, or if you
 want better precision, you can use the jscal program
 
-	jscal -c /dev/js0
+	jscal -c /dev/input/js0
 
  included in the joystick package to set better correction coefficients than
 what the driver would choose itself.
@@ -145,7 +145,7 @@ what the driver would choose itself.
 calibration using the jstest command, and if you do, you then can save the
 correction coefficients into a file
 
-	jscal -p /dev/js0 > /etc/joystick.cal
+	jscal -p /dev/input/js0 > /etc/joystick.cal
 
   And add a line to your rc script executing that file
 
@@ -556,7 +556,7 @@ interface, and "old" for the "0.x" interface. You run it by typing:
 
 5. FAQ
 ~~~~~~
-Q: Running 'jstest /dev/js0' results in "File not found" error. What's the
+Q: Running 'jstest /dev/input/js0' results in "File not found" error. What's the
    cause?
 A: The device files don't exist. Create them (see section 2.2).