The EETI touchscreen asserts its IRQ line as soon as it has data in its
internal buffers. The line is automatically deasserted once all data has
been read via I2C. Hence, the driver has to monitor the GPIO line and
cannot simply rely on the interrupt handler reception.

In the current implementation of the driver, irq_to_gpio() is used to
determine the GPIO number from the i2c_client's IRQ value.

As irq_to_gpio() is not available on all platforms, this patch changes
this and makes the driver ignore the passed in IRQ. Instead, a GPIO is
added to the platform_data struct and gpio_to_irq is used to derive the
IRQ from that GPIO. If this fails, bail out. The driver is only able to
work in environments where the touchscreen GPIO can be mapped to an
IRQ.

Without this patch, building raumfeld_defconfig results in:

drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active':
drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]

Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org (v3.2+)
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Sven Neumann <s.neumann@raumfeld.com>
Cc: linux-input@vger.kernel.org
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>

Pull random subsystem patches from Ted Ts'o:
 "This patch series contains a major revamp of how we collect entropy
  from interrupts for /dev/random and /dev/urandom.

  The goal is to addresses weaknesses discussed in the paper "Mining
  your Ps and Qs: Detection of Widespread Weak Keys in Network Devices",
  by Nadia Heninger, Zakir Durumeric, Eric Wustrow, J.  Alex Halderman,
  which will be published in the Proceedings of the 21st Usenix Security
  Symposium, August 2012.  (See https://factorable.net for more
  information and an extended version of the paper.)"

Fix up trivial conflicts due to nearby changes in
drivers/{mfd/ab3100-core.c, usb/gadget/omap_udc.c}

* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random: (33 commits)
  random: mix in architectural randomness in extract_buf()
  dmi: Feed DMI table to /dev/random driver
  random: Add comment to random_initialize()
  random: final removal of IRQF_SAMPLE_RANDOM
  um: remove IRQF_SAMPLE_RANDOM which is now a no-op
  sparc/ldc: remove IRQF_SAMPLE_RANDOM which is now a no-op
  [ARM] pxa: remove IRQF_SAMPLE_RANDOM which is now a no-op
  board-palmz71: remove IRQF_SAMPLE_RANDOM which is now a no-op
  isp1301_omap: remove IRQF_SAMPLE_RANDOM which is now a no-op
  pxa25x_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op
  omap_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op
  goku_udc: remove IRQF_SAMPLE_RANDOM which was commented out
  uartlite: remove IRQF_SAMPLE_RANDOM which is now a no-op
  drivers: hv: remove IRQF_SAMPLE_RANDOM which is now a no-op
  xen-blkfront: remove IRQF_SAMPLE_RANDOM which is now a no-op
  n2_crypto: remove IRQF_SAMPLE_RANDOM which is now a no-op
  pda_power: remove IRQF_SAMPLE_RANDOM which is now a no-op
  i2c-pmcmsp: remove IRQF_SAMPLE_RANDOM which is now a no-op
  input/serio/hp_sdc.c: remove IRQF_SAMPLE_RANDOM which is now a no-op
  mfd: remove IRQF_SAMPLE_RANDOM which is now a no-op
  ...

Pull MFD bits from Samuel Ortiz:
 "We have support for a few new drivers:
   - Samsung s2mps11
   - Wolfson Microelectronics wm5102 and wm5110
   - Marvell 88PM800 and 88PM805
   - TI twl6041

  We also have our regular driver improvements:
   - Device tree and IRQ domain support for STE AB8500
   - Regmap and devm_* API conversion for TI tps6586x
   - Device tree support for Samsung max77686
   - devm_* API conversion for STE AB3100

  Besides that, quite a lot of fixing and cleanup for mc13xxx, tps65910,
  tps65090, da9052 and twl-core."

Fix up mostly trivial conflicts, with the exception of
drivers/usb/host/ehci-omap.c in particular, which had some
re-organization of the reset sequence (commit 1a49e2ac9651: "EHCI:
centralize controller initialization") that clashed with commit
2761a6394516 ("mfd: USB: Fix the omap-usb EHCI ULPI PHY reset fix
issues").

In particular, commit 2761a6394516 moved the usb_add_hcd() to the
*middle* of the reset sequence, which clashes fairly badly with the
reset sequence re-organization (although it could have been done inside
the new omap_ehci_init() function).

I left that part of commit 2761a6394516 just undone.

* tag 'mfd-3.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: (110 commits)
  mfd: Ensure AB8500 platform data is passed through db8500-prcmu to MFD Core
  mfd: Arizone core should select MFD_CORE
  mfd: Fix arizona-irq.c build by selecting REGMAP_IRQ
  mfd: Add debug trace on entering and leaving arizone runtime suspend
  mfd: Correct tps65090 cell names
  mfd: Remove gpio support from tps6586x core driver
  ARM: tegra: defconfig: Enable tps6586x gpio
  gpio: tps6586x: Add gpio support through platform driver
  mfd: Cache tps6586x register through regmap
  mfd: Use regmap for tps6586x register access.
  mfd: Use devm managed resources for tps6586x
  input: Add onkey support for 88PM80X PMIC
  mfd: Add support for twl6041
  mfd: Fix twl6040 revision information
  mfd: Matches should be NULL when populate anatop child devices
  input: ab8500-ponkey: Create AB8500 domain IRQ mapping
  mfd: Add missing out of memory check for pcf50633
  Documentation: Describe the AB8500 Device Tree bindings
  mfd: Add tps65910 32-kHz-crystal-input init
  mfd: Drop modifying mc13xxx driver's id_table in probe
  ...

Pull input updates from Dmitry Torokhov:
 "A new driver for FT5x06 based EDT displays and a couple of other
  driver changes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: synaptics - handle out of bounds values from the hardware
  Input: wacom - add support to Cintiq 22HD
  Input: add driver for FT5x06 based EDT displays

Prepare second set of changes for 3.6 merge window.

Pull ARM updates from Russell King:
 "First ARM push of this merge window, post me coming back from holiday.
  This is what has been in linux-next for the last few weeks.  Not much
  to say which isn't described by the commit summaries."

* 'for-linus' of git://git.linaro.org/people/rmk/linux-arm: (32 commits)
  ARM: 7463/1: topology: Update cpu_power according to DT information
  ARM: 7462/1: topology: factorize the update of sibling masks
  ARM: 7461/1: topology: Add arch_scale_freq_power function
  ARM: 7456/1: ptrace: provide separate functions for tracing syscall {entry,exit}
  ARM: 7455/1: audit: move syscall auditing until after ptrace SIGTRAP handling
  ARM: 7454/1: entry: don't bother with syscall tracing on ret_from_fork path
  ARM: 7453/1: audit: only allow syscall auditing for pure EABI userspace
  ARM: 7452/1: delay: allow timer-based delay implementation to be selected
  ARM: 7451/1: arch timer: implement read_current_timer and get_cycles
  ARM: 7450/1: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs
  ARM: 7449/1: use generic strnlen_user and strncpy_from_user functions
  ARM: 7448/1: perf: remove arm_perf_pmu_ids global enumeration
  ARM: 7447/1: rwlocks: remove unused branch labels from trylock routines
  ARM: 7446/1: spinlock: use ticket algorithm for ARMv6+ locking implementation
  ARM: 7445/1: mm: update CONTEXTIDR register to contain PID of current process
  ARM: 7444/1: kernel: add arch-timer C3STOP feature
  ARM: 7460/1: remove asm/locks.h
  ARM: 7439/1: head.S: simplify initial page table mapping
  ARM: 7437/1: zImage: Allow DTB command line concatenation with ATAG_CMDLINE
  ARM: 7436/1: Do not map the vectors page as write-through on UP systems
  ...

Pull input layer updates from Dmitry Torokhov:
 "First set of updates for the input subsystem.  You will get a new
  touchscreen driver (Melfas mms114), a new keypad driver for LPC32xx
  SoC, large update to Atmel mXT touchscreen driver, a lot of drivers
  acquired device tree support and a slew of other fixes."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (57 commits)
  Input: add MELFAS mms114 touchscreen driver
  Input: add support for key scan interface of the LPC32xx SoC
  Input: omap4-keypad - add device tree support
  Input: hanwang - add support for Art Master II tablet
  Input: spear_keyboard - reconfigure operating frequency on suspend
  Input: spear_keyboard - fix clock handling during suspend/resume
  Input: ff-memless - fix a couple min_t() casts
  Input: synaptics - print firmware ID and board number at init
  Input: spear_keyboard - generalize keyboard frequency configuration
  Input: spear_keyboard - rename bit definitions to reflect register
  Input: spear_keyboard - use correct io accessors
  Input: spear-keyboard - fix disable device_init_wakeup in remove
  Input: wacom_i2c - fix compiler warning
  Input: imx_keypad - check error returned by clk_prepare_enable()
  Input: imx_keypad - adapt the new kpp clock name
  Input: imx_keypad - use clk_prepare_enable/clk_disable_unprepare()
  Input: ad7879 - add option to correct xy axis
  Input: synaptics_usb - Remove TrackPoint name trailing whitespace
  Revert "Input: atmel_mxt_ts - warn if sysfs could not be created"
  Input: MT - Include win8 support
  ...

The touchpad on the Acer Aspire One D250 will report out of range values
in the extreme lower portion of the touchpad. These appear as abrupt
changes in the values reported by the hardware from very low values to
very high values, which can cause unexpected vertical jumps in the
position of the mouse pointer.

What seems to be happening is that the value is wrapping to a two's
compliment negative value of higher resolution than the 13-bit value
reported by the hardware, with the high-order bits being truncated. This
patch adds handling for these values by converting them to the
appropriate negative values.

The only tricky part about this is deciding when to treat a number as
negative. It stands to reason that if out of range values can be
reported on the low end then it could also happen on the high end, so
not all out of range values should be treated as negative. The approach
taken here is to split the difference between the maximum legitimate
value for the axis and the maximum possible value that the hardware can
report, treating values greater than this number as negative and all
other values as positive. This can be tweaked later if hardware is found
that operates outside of these parameters.

BugLink: http://bugs.launchpad.net/bugs/1001251
Cc: stable@vger.kernel.org
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>