Input: edt-ft5x06 - fix an i2c write for M09 support

The driver sends 3 bytes instead of 2 when accessing a register on the M09
firmware, so writing to gain seems to overflow into the offset register.

Signed-off-by: Robert Woerle <robert@linuxdevelopment.de>
Acked-By: Simon Budig <simon.budig@kernelconcepts.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: elantech - deal with clickpads reporting right button events

At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom area:

https://bugzilla.redhat.com/show_bug.cgi?id=1103528

This is different from how (elantech) clickpads normally operate, normally
no matter where the user clicks on the pad the pad always reports a left
button event, since there is only 1 hardware button beneath the path.

It looks like Dell has put 2 buttons under the pad, one under each bottom
corner, causing this.

Since this however still clearly is a real clickpad hardware-wise, we still
want to report it as such to userspace, so that things like finger movement
in the bottom area can be properly ignored as it should be on clickpads.

So deal with this weirdness by simply mapping a right click to a left click
on elantech clickpads. As an added advantage this is something which we can
simply do on all elantech clickpads, so no need to add special quirks for
this weird model.

Reported-and-tested-by: Elder Marco <eldermarco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set

The touchpad on the GIGABYTE U2442 not only stops communicating when we try
to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS
versions also when we set bit 1 (enable two finger mode auto correct).

I've asked the original reporter of:
https://bugzilla.kernel.org/show_bug.cgi?id=61151

To check that not setting bit 1 does not lead to any adverse effects on his
model / BIOS revision, and it does not, so this commit fixes the touchpad
not working on these versions by simply never setting bit 1 for laptop
models with the no_hw_res quirk.

Reported-and-tested-by: James Lademann <jwlademann@gmail.com>
Tested-by: Philipp Wolfer <ph.wolfer@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: max8997_haptic - add error handling for regulator and pwm

Let's start checking return value of regulator_enable and pwm_enable to
avoid errors. Fixes the following warning:

drivers/input/misc/max8997_haptic.c:185:19: warning: ignoring return value of ‘regulator_enable’, declared with attribute warn_unused_result [-Wunused-result]

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: atmel_mxt_ts - fix invalid return from mxt_get_bootloader_version

The patch e57a66aa8534: "Input: atmel_mxt_ts - read and report
bootloader version" from May 18, 2014, leads to the following static
checker warning:

	drivers/input/touchscreen/atmel_mxt_ts.c:437 mxt_get_bootloader_version()
	warn: signedness bug returning '(-5)'

drivers/input/touchscreen/atmel_mxt_ts.c
   429  static u8 mxt_get_bootloader_version(struct mxt_data *data, u8 val)
   430  {
   431          struct device *dev = &data->client->dev;
   432          u8 buf[3];
   433
   434          if (val & MXT_BOOT_EXTENDED_ID) {
   435                  if (mxt_bootloader_read(data, &buf[0], 3) != 0) {
   436                          dev_err(dev, "%s: i2c failure\n", __func__);
   437                          return -EIO;
                                       ^^^^
This gets truncated into a number from 0-255 and anyway the caller
doesn't check for errors.

(reported by Dan Carpenter)

Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>