Do not call xpad_identify_controller at init with wireless devices: it
conflicts with the already sent presence packet and will be called by
xpad360w_process_packet as needed anyway.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In the touchscreen controller ISR, reading the tsc starting from
register 0x2 causes the tsc to infrequently update the detected
finger's x and y coordinate. The irq pin toggles at a fast rate to
indicate touch events are happening. However, the tsc on average
updates the touch point's x and y value every ~100 ms which is much
slower than the advertised rate of 100+ Hz. This leads to multiple reads
within this ~100 ms time window returning the same value.

Example:
X: 10 , Y: 30
X: 10 , Y: 30
X: 10,  Y: 30
..
// After 100 ms
X: 300, Y: 300
X: 300, y: 300
..
// After 100 ms
X: 1743, Y: 621
X: 1743, Y: 621

For some reason if instead of starting to read at register 0x2 you
start reading at register 0x0 this issue isn't seen. This seems like
a quirk only seen in the EDT FT5506 so to fix this issue simply
adjust the code to start reading from 0x0. Technically this isn't wrong
so no regressions should be seen with other touchscreen controllers
supported by this driver.
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

FT5506 is essentially the same as other FT5x06 devices other than
supporting 10 support points.
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Update the code so that the maximum supported points aren't hard coded but
can be changed.

Set the maximum support points based on the data passed along side the
compatible field.
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Calculate the amount of data that needs to be read for the specified max
number of support points. If the maximum number of support points changes
then the amount that is read from the touch screen controller should
reflect this.
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some encoders have both outputs low in stable states, others also have
a stable state with both outputs high (half-period mode) and some have
a stable state in all steps (quarter-period mode). The driver used to
support the former states and with this change it can also support the
later.

This commit also deprecates the 'half-period' property and introduces
a new property 'steps-per-period'. This property specifies the
number of steps (stable states) produced by the rotary encoder
for each GPIO period.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This commit makes uses of_property_read_bool() to read
boolean properties. This is just cosmetic cleanup.
Signed-off-by: NBen Gamari <bgamari.foss@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

There is an undocumented upper bound for the total number of ff effects:
    FF_GAIN (= 96).
This can be found as follows:
- user: write(EV_FF, effect_id, iterations)
    calls kernel: ff->playback(effect_id, ...): starts effect "effect_id"
- user: write(EV_FF, FF_GAIN, gain)
    calls kernel: ff->set_gain(gain, ...): sets gain

A collision occurs when effect_id equals FF_GAIN.
According to input_ff_event(),
FF_GAIN is the smallest value where a collision occurs.
Therefore the greatest safe value for effect_id is FF_GAIN - 1,
and thus the total number of effects should never exceed FF_GAIN.

Define FF_MAX_EFFECTS as FF_GAIN and check on this limit in ff-core.
Signed-off-by: NElias Vanderstuyft <elias.vds@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Just like the EVIOCSABS(abs) macro, use the more compact
_IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type))
for the EVIOCSFF macro.
Signed-off-by: NElias Vanderstuyft <elias.vds@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add a symlink to uapi/linux/linux-event-codes.h, and include that
instead of (re)defining all the evdev type and code values in
dt-bindings/input/input.h. This way we do not need to keep all the event
codes synced manually.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add input-event-codes header file and move all type and axis defines
there.

The purpose of this new header file is to have a single canonical source
for event-codes which can be used outside of C-code too. One example of
such usage is the use of event-codes in devicetree source files.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This changAdd support for EV_ABS / EV_REL events to the gpio-keys-polled driver.


The driver already allows specifying what type of events (key / rel / abs)
a button generates when pressed, but for rel / abs axis we also need to
specify which value this specific gpio represents.

One use case is digital joysticks / direction-pads which are hooked up to
gpio, in this case we've left and right buttons which we want to map to
EV_ABS, ABS_X and we want generate events for left with a value of -1 and
for right with a value of +1 (and similar for up / down and ABS_Y).
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

With commit 3fffd128 ("i2c: allow specifying separate wakeup
interrupt in device tree") wakeirq is managed by i2c-core, so remove
wakeirq related code from pixcir_i2c_ts driver.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds wake up support to GPIO rotary encoders.
Signed-off-by: NSylvain Rochet <sylvain.rochet@finsecur.com>
Reviewed-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add new function input_enable_softrepeat() that allows drivers to
initialize their own values for input_dev->rep[REP_DELAY] and
input_dev->rep[REP_PERIOD], but also use the software autorepeat
functionality from input.c.

For example, a HID driver could do:

static void xyz_input_configured(struct hid_device *hid,
                                 struct hid_input *hidinput)
{
        input_enable_softrepeat(hidinput->input, 400, 100);
}

static struct hid_driver xyz_driver = {
        .input_configured = xyz_input_configured,
}
Signed-off-by: NPetri Gynther <pgynther@google.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When we initialize the driver/device, we really don't know how many
controllers are connected.  So send a "query presence" command to the
base-station. (Command discovered by Zachary Lund)

Presence packet taken from:

https://github.com/computerquip/xpad5Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

To allow us to later create / destroy the input device from the urb
callback, we need to initialize/ deinitialize the input device from a
separate function.  So pull that logic out now to make later patches
more "obvious" as to what they do.
Signed-off-by: N"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

as discussed here[0], x360w is the only pad that maps dpad_to_button.
This is bad for downstream developers as they have to differ between
x360 and x360w which is not intuitive.

This patch implements the suggested solution of exposing the dpad both
as axes and as buttons. This retains backward compatibility with software
already dealing with the difference while makes new software work as
expected across x360/ x360w pads.

[0] http://www.spinics.net/lists/linux-input/msg34421.htmlSigned-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Move submission logic to a single point at the end of the function.
This makes it easy to add locking/ queuing code later on.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This code was probably wrong ever since and is redundant with
xpad_send_led_command. Both try to send a similar command to the xbox360
controller. However xpad_send_led_command correctly uses the pad_nr instead
of bInterfaceNumber to select the led and re-uses the irq_out URB instead
of creating a new one.

Note that this change only affects the two supported wireless controllers.
Tested using the xbox360 wireless controller (PC).
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The pad_nr corresponds to the lit up LED on the controller. Therefore there
should be no gaps when enumerating. Currently a LED is only re-assigned
after a controller is re-connected 4 times.

This patch uses ida to track connected pads - this way we can re-assign
freed up pad number immediately.

Consider the following case:
1. pad A is connected and gets pad_nr = 0
2. pad B is connected and gets pad_nr = 1
3. pad A is disconnected
4. pad A is connected again

using ida_simple_get() controller A now correctly gets pad_nr = 0 again.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Rename led_no -> pad_nr: the number stored there is not the LED number - it
gets translated later on to a LED number in xpad_identify_controller;
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The "Razer Atrox Arcade Stick" features 10 buttons, and two of them (LT/RT)
don't work properly.  Change its definition in xpad_device[] (mapping
field) to fix.
Signed-off-by: NDario Scarpa <dario.scarpa@duskzone.it>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

It is identical to the Xbox One controller but has a different product ID.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The copyright/license notice says that the code is licensed under GPL v2
only (not GPL v2+), so let's use proper string in MODULE_LICENSE().
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

There is no need to explicitly set .owner for the driver, the core will do
it for us.
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Since reset and wake pin are optional the gpio structure for those
pins may be null. Therefore, they can't be blindly passed to
desc_to_gpio.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Commit 5702222c ("Input: joydev - use memdup_user() to duplicate
memory from user-space") changed the kmalloc() and copy_from_user()
with a single call to memdup_user() but wrongly used the same error
path than the old code in which the buffer allocated by kmalloc() was
freed if copy_from_user() failed.

This is of course wrong since if memdup_user() fails, no memory was
allocated and the error in the error-valued pointer should be returned.

Fixes: 5702222c ("Input: joydev - use memdup_user() to duplicate
memory from user-space")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This adds support for ROHM BU21023/24 Dual touch resistive touchscreens.
Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Modify parkbd driver to use the new Parallel Port device model.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Merge with mainline to sync up with changes to parkbd driver.

The variable i is used to check the port to attach to and we are
supposed to save the reference of struct tgfx in the location given by
tgfx_base[i]. But after finding out the index, i is getting modified
again so we saved in a wrong index.

Fixes: 4de27a63 ("Input: turbografx - use parallel port device model")
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The variable i is used to check the port to attach to and we are
supposed to save the reference of struct gc in the location given by
gc_base[i]. But after finding out the index, i is getting modified again
so we saved in a wrong index.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: a517e87c ("Input: gamecon - use parallel port device model")
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The variable i is used to check the port to attach to and we are
supposed to save the reference of struct db9 in the location given by
db9_base[i]. But after finding out the index, i is getting modified again
so we saved in a wrong index.
While at it mark db9_base[i] as NULL after it is freed.

Fixes: 2260c419 ("Input: db9 - use parallel port device model")
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Pull strscpy string copy function implementation from Chris Metcalf.

Chris sent this during the merge window, but I waffled back and forth on
the pull request, which is why it's going in only now.

The new "strscpy()" function is definitely easier to use and more secure
than either strncpy() or strlcpy(), both of which are horrible nasty
interfaces that have serious and irredeemable problems.

strncpy() has a useless return value, and doesn't NUL-terminate an
overlong result.  To make matters worse, it pads a short result with
zeroes, which is a performance disaster if you have big buffers.

strlcpy(), by contrast, is a mis-designed "fix" for strlcpy(), lacking
the insane NUL padding, but having a differently broken return value
which returns the original length of the source string.  Which means
that it will read characters past the count from the source buffer, and
you have to trust the source to be properly terminated.  It also makes
error handling fragile, since the test for overflow is unnecessarily
subtle.

strscpy() avoids both these problems, guaranteeing the NUL termination
(but not excessive padding) if the destination size wasn't zero, and
making the overflow condition very obvious by returning -E2BIG.  It also
doesn't read past the size of the source, and can thus be used for
untrusted source data too.

So why did I waffle about this for so long?

Every time we introduce a new-and-improved interface, people start doing
these interminable series of trivial conversion patches.

And every time that happens, somebody does some silly mistake, and the
conversion patch to the improved interface actually makes things worse.
Because the patch is mindnumbing and trivial, nobody has the attention
span to look at it carefully, and it's usually done over large swatches
of source code which means that not every conversion gets tested.

So I'm pulling the strscpy() support because it *is* a better interface.
But I will refuse to pull mindless conversion patches.  Use this in
places where it makes sense, but don't do trivial patches to fix things
that aren't actually known to be broken.

* 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  tile: use global strscpy() rather than private copy
  string: provide strscpy()
  Make asm/word-at-a-time.h available on all architectures

Pull md fixes from Neil Brown:
 "Assorted fixes for md in 4.3-rc.

  Two tagged for -stable, and one is really a cleanup to match and
  improve kmemcache interface.

* tag 'md/4.3-fixes' of git://neil.brown.name/md:
  md/bitmap: don't pass -1 to bitmap_storage_alloc.
  md/raid1: Avoid raid1 resync getting stuck
  md: drop null test before destroy functions
  md: clear CHANGE_PENDING in readonly array
  md/raid0: apply base queue limits *before* disk_stack_limits
  md/raid5: don't index beyond end of array in need_this_block().
  raid5: update analysis state for failed stripe
  md: wait for pending superblock updates before switching to read-only

Pull MIPS updates from Ralf Baechle:
 "This week's round of MIPS fixes:
   - Fix JZ4740 build
   - Fix fallback to GFP_DMA
   - FP seccomp in case of ENOSYS
   - Fix bootmem panic
   - A number of FP and CPS fixes
   - Wire up new syscalls
   - Make sure BPF assembler objects can properly be disassembled
   - Fix BPF assembler code for MIPS I"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: scall: Always run the seccomp syscall filters
  MIPS: Octeon: Fix kernel panic on startup from memory corruption
  MIPS: Fix R2300 FP context switch handling
  MIPS: Fix octeon FP context switch handling
  MIPS: BPF: Fix load delay slots.
  MIPS: BPF: Do all exports of symbols with FEXPORT().
  MIPS: Fix the build on jz4740 after removing the custom gpio.h
  MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT
  MIPS: CPS: Don't include MT code in non-MT kernels.
  MIPS: CPS: Stop dangling delay slot from has_mt.
  MIPS: dma-default: Fix 32-bit fall back to GFP_DMA
  MIPS: Wire up userfaultfd and membarrier syscalls.

Pull irq fixes from Thomas Gleixner:
 "This update contains:

   - Fix for a long standing race affecting /proc/irq/NNN

   - One line fix for ARM GICV3-ITS counting the wrong data

   - Warning silencing in ARM GICV3-ITS.  Another GCC trying to be
     overly clever issue"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/gic-v3-its: Count additional LPIs for the aliased devices
  irqchip/gic-v3-its: Silence warning when its_lpi_alloc_chunks gets inlined
  genirq: Fix race in register_irq_proc()

The MIPS syscall handler code used to return -ENOSYS on invalid
syscalls. Whilst this is expected, it caused problems for seccomp
filters because the said filters never had the change to run since
the code returned -ENOSYS before triggering them. This caused
problems on the chromium testsuite for filters looking for invalid
syscalls. This has now changed and the seccomp filters are always
run even if the syscall is invalid. We return -ENOSYS once we
return from the seccomp filters. Moreover, similar codepaths have
been merged in the process which simplifies somewhat the overall
syscall code.
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11236/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>