Pull more input subsystem updates from Dmitry Torokhov:
"Just a few more driver fixes; new drivers will be coming in the next
merge window"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: pwm-beeper - fix - scheduling while atomic
Input: xpad - xbox one elite controller support
Input: xpad - add more third-party controllers
Input: xpad - prevent spurious input from wired Xbox 360 controllers
Input: xpad - move pending clear to the correct location
Input: uinput - handle compat ioctl for UI_SET_PHYS
Pwm config may sleep so defer it using a worker.
On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.
Tested on Freescale i.MX53 SoC with 4.6.0.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This set of changes introduces an atomic API to the PWM subsystem. This
is influenced by the DRM atomic API that was introduced a while back,
though it is obviously a lot simpler. The fundamental idea remains the
same, though: drivers provide a single callback to implement the atomic
configuration of a PWM channel.
As a side-effect the PWM subsystem gains the ability for initial state
retrieval, so that the logical state mirrors that of the hardware. Many
use-cases don't care about this, but for others it is essential.
These new features require changes in all users, which these patches
take care of. The core is transitioned to use the atomic callback if
available and provides a fallback mechanism for other drivers.
Changes to transition users and drivers to the atomic API are postponed
to v4.8.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXRcVWAAoJEN0jrNd/PrOhO3EP/RDuuco1fROml1ElCjcnWWfv
3dPyKEJhZktMmRNd/V0zMUJiOwr77wlbX4oQ5HajMHNYFQ65jfihbbylhSDepnxg
mjKV/yo18rzYZt9fv8huwvlwMOlLrJ9wQn4Gkbr5tzke6nITp52DTNH5y/anPQIk
B7neA1TerodAbE9FWjYuBZIltkmYZDqdm//RCHXVyYym8VuotE+jf+nrMXI78FoL
lgG64z/2OaGI+NZJQcpWftuz9nnenpa3sSLrvpitWEb/dAsXroMW/f08uVuOW87v
0xk7N7zmEkef7izVOWiPOK/MxIdc8hI4A5JftzMJ7nbgJvwG78dJiOxgFhrJYx0z
7zrYfjvvzjW0dpjZUvO37T/V5Rfxrk9sM7qUHJmN0+1oEkkCo1/c75JWTU2AmT4l
qkJdOGhgv7LumIiwbEyxc/5Jyh1akKOUX2svO0+0dptLRX2UpN3yeKIYinG1dAuT
86+/uuM6CL5gc+jVZ3GLNWfzHUu2RFVX0r0pzywq53pK5gMEs5WyxoIb5mHb8liA
sHsrZ3wbGGn95yZo8CwkzXIUsUH7qKYK+UVWA6OVBoTq4AOBZtII1AqvUttl25qL
xuKpj70xaBhK7VGqzDYQ68lqBaRySh+yzL/QsmnPEyx59mW81ytMrsn1Kmnuae2l
bzUsnWrpHc6530fRggTD
=sxT9
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set of changes introduces an atomic API to the PWM subsystem.
This is influenced by the DRM atomic API that was introduced a while
back, though it is obviously a lot simpler. The fundamental idea
remains the same, though: drivers provide a single callback to
implement the atomic configuration of a PWM channel.
As a side-effect the PWM subsystem gains the ability for initial state
retrieval, so that the logical state mirrors that of the hardware.
Many use-cases don't care about this, but for others it is essential.
These new features require changes in all users, which these patches
take care of. The core is transitioned to use the atomic callback if
available and provides a fallback mechanism for other drivers.
Changes to transition users and drivers to the atomic API are
postponed to v4.8"
* tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (30 commits)
pwm: Add information about polarity, duty cycle and period to debugfs
pwm: Switch to the atomic API
pwm: Update documentation
pwm: Add core infrastructure to allow atomic updates
pwm: Add hardware readout infrastructure
pwm: Move the enabled/disabled info into pwm_state
pwm: Introduce the pwm_state concept
pwm: Keep PWM state in sync with hardware state
ARM: Explicitly apply PWM config extracted from pwm_args
drm: i915: Explicitly apply PWM config extracted from pwm_args
input: misc: pwm-beeper: Explicitly apply PWM config extracted from pwm_args
input: misc: max8997: Explicitly apply PWM config extracted from pwm_args
backlight: lm3630a: explicitly apply PWM config extracted from pwm_args
backlight: lp855x: Explicitly apply PWM config extracted from pwm_args
backlight: lp8788: Explicitly apply PWM config extracted from pwm_args
backlight: pwm_bl: Use pwm_get_args() where appropriate
fbdev: ssd1307fb: Use pwm_get_args() where appropriate
regulator: pwm: Use pwm_get_args() where appropriate
leds: pwm: Use pwm_get_args() where appropriate
input: misc: max77693: Use pwm_get_args() where appropriate
...
When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
ioctl needs to be treated with special care, as it has the pointer
size encoded in the command.
Signed-off-by: Ricky Liang <jcliang@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information
provided in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information
provided in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM framework has clarified the concept of reference PWM config (the
platform dependent config retrieved from the DT or the PWM lookup table)
and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has just
been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
commit e7ec014a47 ("Input: twl6040-vibra - update for device tree support")
made the separate vibra DT node to a subnode of the twl6040.
It now calls of_find_node_by_name() to locate the "vibra" subnode.
This function has a side effect to call of_node_put on() for the twl6040
parent node passed in as a parameter. This causes trouble later on.
Solution: we must call of_node_get() before of_find_node_by_name()
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
fix checkpatch.pl warning about 'Prefer 'unsigned int' to bare use of
'unsigned''
Signed-off-by: Clifton Barnes <clifton.a.barnes@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
NULL pointer derefence happens when booting with DTB because the
platform data for haptic device is not set in supplied data from parent
MFD device.
The MFD device creates only platform data (from Device Tree) for itself,
not for haptic child.
Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
[0000009c] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
(max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0)
(platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0)
(driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0)
(__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c)
(bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218)
(bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8)
(driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8)
(do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
(kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114)
(kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c)
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: <stable@vger.kernel.org>
Fixes: 104594b01c ("Input: add driver support for MAX8997-haptic")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Complete() will be run with interrupt enabled, so change to
spin_lock_irqsave().
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The CM109 driver reported key press events of volume up / down and
record / playback mute buttons, but no release events. Report those events
properly by handling volume and mute keys seperately. For the record and
playback mute buttons, only presses are registered by the CM109, therefore
simulate press-n-release. This fixes the volume control buttons of various
USB headsets.
Signed-off-by: Florian Euchner <florian.euchner@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The mutex does not seem to be needed. twl4030-vibra doesn't
use one either.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit c6f39257c9 ("mfd: twl6040: Use regmap for register cache")
did remove the private cache for the vibra control registers and replaced
access within twl6040_get_vibralr_status() by calls to regmap. This is OK,
as long as twl6040_get_vibralr_status() uses already cached values or is
not called from interrupt context. But we call this in vibra_play() for
checking that the vibrator is not configured for audio mode.
The result is a "BUG: scheduling while atomic" if the first use of the
twl6040 is a vibra effect, because the first fetch is by reading the
twl6040 registers through (blocking) i2c and not from the cache.
As soon as the regmap has cached the status, further calls are fine.
The solution is to move the condition to the work() function which
runs in context that can block.
The original code returns -EBUSY, but the return value of ->play()
functions is ignored anyways. Hence, we do not loose functionality
by not returning an error but just reporting the issue to INFO loglevel.
Tested-on: Pyra (omap5) prototype
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
For devm-managed input devices we should not modify input device's parent,
otherwise automatic release of resources will not work properly.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
For devm-managed input devices we should not modify input device's parent,
otherwise automatic release of resources will not work properly.
Tested-by: "H. Nikolaus Schaller" <hns@goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Returning ret is wrong. And checking for an error as well. User space
may call multiple times until the work is really scheduled.
twl4030-vibra.c also ignores the return value.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 21fb9f0d5e ("Input: twl6040-vibra - use system workqueue")
says that it switches to use the system workqueue but it did neither
- remove the workqueue struct variable
- replace code to really use the system workqueue
Instead it calls queue_work() on uninitialized info->workqueue.
The result is a NULL pointer dereference in vibra_play().
Solution: use schedule_work
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The trigger delay algorithm that converts from microseconds to
the register value looks incorrect. According to most of the PMIC
documentation, the equation is
delay (Seconds) = (1 / 1024) * 2 ^ (x + 4)
except for one case where the documentation looks to have a
formatting issue and the equation looks like
delay (Seconds) = (1 / 1024) * 2 x + 4
Most likely this driver was written with the improper
documentation to begin with. According to the downstream sources
the valid delays are from 2 seconds to 1/64 second, and the
latter equation just doesn't make sense for that. Let's fix the
algorithm and the range check to match the documentation and the
downstream sources.
Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: 92d57a73e4 ("input: Add support for Qualcomm PMIC8XXX power key")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We shouldn't assign the parent device of the input_dev to be the
parent MFD device, because this will be used for devres which causes
input_unregister_device to run after the haptics device has been
removed, since it is itself a child of the MFD device. The default
of using the haptics device itself as the parent is correct.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Merge fourth patch-bomb from Andrew Morton:
"A lot more stuff than expected, sorry. A bunch of ocfs2 reviewing was
finished off.
- mhocko's oom-reaper out-of-memory-handler changes
- ocfs2 fixes and features
- KASAN feature work
- various fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (42 commits)
thp: fix typo in khugepaged_scan_pmd()
MAINTAINERS: fill entries for KASAN
mm/filemap: generic_file_read_iter(): check for zero reads unconditionally
kasan: test fix: warn if the UAF could not be detected in kmalloc_uaf2
mm, kasan: stackdepot implementation. Enable stackdepot for SLAB
arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections
mm, kasan: add GFP flags to KASAN API
mm, kasan: SLAB support
kasan: modify kmalloc_large_oob_right(), add kmalloc_pagealloc_oob_right()
include/linux/oom.h: remove undefined oom_kills_count()/note_oom_kill()
mm/page_alloc: prevent merging between isolated and other pageblocks
drivers/memstick/host/r592.c: avoid gcc-6 warning
ocfs2: extend enough credits for freeing one truncate record while replaying truncate records
ocfs2: extend transaction for ocfs2_remove_rightmost_path() and ocfs2_update_edge_lengths() before to avoid inconsistency between inode and et
ocfs2/dlm: move lock to the tail of grant queue while doing in-place convert
ocfs2: solve a problem of crossing the boundary in updating backups
ocfs2: fix occurring deadlock by changing ocfs2_wq from global to local
ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list
ocfs2/dlm: fix race between convert and recovery
ocfs2: fix a deadlock issue in ocfs2_dio_end_io_write()
...
INPUT_COMPAT_TEST became much simpler after commit f4056b5284
("input: redefine INPUT_COMPAT_TEST as in_compat_syscall()") so we can
cleanly eliminate it altogether.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The ati_remote2 driver expects at least two interfaces with one
endpoint each. If given malicious descriptor that specify one
interface or no endpoints, it will crash in the probe function.
Ensure there is at least two interfaces and one endpoint for each
interface before using it.
The full disclosure: http://seclists.org/bugtraq/2016/Mar/90
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
A malicious device missing interface can make the driver oops.
Add sanity checking.
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJW5j4RAAoJEHm+PkMAQRiGhVEH/0qZbM1J+WnCK92bm9+inCnB
JO2JViGIuCQB5BxljVMil2dzrw85D+dC7+fryr0wVBhhBlr0lXPJGSYCYYTEaI20
Wco5YlTmjRirUwmxWzBXvB5kvTdIaNfNYDcFch6lbsaLUNgqydNKtk08ckO/4k0D
AmaShW8swBiXE/RmHuj8H41ksHsnY8W62dlczEaAIfr4kluPX/kKnyXpmpvmZm1j
sM4fskPlq+Jz5pOXXFsFfrhiBgpSUnwSj1tNwK5+DkmaVnWOkPuwkqLBWqpy4pzm
GTeDBdf5/ixGxgNsZ2VWtbPnc2wEP7SIcu45MU7QFw5kqwDN2nN63BRVXI5Z5qY=
=RFx2
-----END PGP SIGNATURE-----
Merge tag 'v4.5' into next
Merge with Linux 4.5 to get PROPERTY_ENTRY_INTEGER() that is needed to
fix pxa/raumfeld rotary encoder properties.
The powermate driver expects at least one valid USB endpoint in its
probe function. If given malicious descriptors that specify 0 for
the number of endpoints, it will crash. Validate the number of
endpoints on the interface before using them.
The full report for this issue can be found here:
http://seclists.org/bugtraq/2016/Mar/85
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Bring in updates to roraty encoder driver switching it away from legacy
platform data and over to generic device properties and adding support
for encoders using more than 2 GPIOs.
This changes how the used gpios are stored (i.e. a struct gpio_descs
instead of two struct gpio_desc) and as with >2 gpios the states are
numbered differently the function rotary_encoder_get_state returns
unencoded numbers instead of grey encoded numbers before. The latter has
some implications on how the returned value is used and so the change is
bigger than one might expect at first.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Drop support for platform data passed via a C-structure and switch to
device properties instead, which should make the driver compatible with all
platforms: OF, ACPI and static boards. Static boards should use property
sets to communicate device parameters to the driver.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Instead of manipulating capability bits directly let's use appropriate
helpers. Also there is no need to explicitly set EV_ABS when calling
input_set_abs_params().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Instead of using old GPIO API, let's switch to GPIOD API, which
automatically handles polarity.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Instead of guarding PM methods with #ifdef let's mark them as
__maybe_unused as it allows for better compile coverage.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Convert to use threaded IRQs to support GPIOs that can sleep.
Protect the irq handler with mutex as it can be triggered from
two different irq lines accessing the same state.
This allows using GPIO expanders behind I2C or SPI bus.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CONFIG_INPUT may itself be a loadable module, but the sirf power key
driver is listed as 'bool', which makes it possible to select
a broken configuration with the driver built-in but the subsystem
not loaded. In this configuration, we get a link error:
drivers/input/built-in.o: In function `sirfsoc_pwrc_isr':
drivers/input/misc/sirfsoc-onkey.c:63: undefined reference to `input_event'
drivers/input/built-in.o: In function `sirfsoc_pwrc_isr':
include/linux/input.h:414: undefined reference to `input_event'
drivers/input/built-in.o: In function `sirfsoc_pwrc_probe':
drivers/input/misc/sirfsoc-onkey.c:132: undefined reference to `devm_input_allocate_device'
drivers/input/misc/sirfsoc-onkey.c:139: undefined reference to `input_set_capability'
drivers/input/misc/sirfsoc-onkey.c:161: undefined reference to `input_register_device'
drivers/input/built-in.o: In function `sirfsoc_pwrc_report_event':
drivers/input/misc/sirfsoc-onkey.c:48: undefined reference to `input_event'
drivers/input/built-in.o: In function `sirfsoc_pwrc_report_event':
include/linux/input.h:414: undefined reference to `input_event'
drivers/input/built-in.o:(.debug_addr+0x24): undefined reference to `input_event'
drivers/input/built-in.o:(.debug_addr+0xbc): undefined reference to `devm_input_allocate_device'
drivers/input/built-in.o:(.debug_addr+0x104): undefined reference to `input_set_capability'
drivers/input/built-in.o:(.debug_addr+0x128): undefined reference to `input_register_device'
This marks the driver as 'tristate' so it becomes possible to have
it in a loadable module, mainly to help with randconfig builds.
We also have to add a missing semicolon here, which ended up not
being needed in built-in mode because the following MODULE_DEVICE_TABLE
is an empty macro followed by another semicolon then.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use managed resource API for simplifying error paths.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The bma150_cfg structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Currently the user can set ff_effects_max to zero with the EV_FF bit (and
the FF_GAIN and/or FF_AUTOCENTER bits) set, in this case the uninitialized
methods ff->set_gain and/or ff->set_autocenter can be dereferenced,
resulting in a kernel oops.
Check in uinput_create_device() and print a helpful message and return
-EINVAL in case the check fails.
Signed-off-by: Elias Vanderstuyft <elias.vds@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Rework the uinput ABS validation to check passed absinfo data immediately,
but do ABS initialization as last step in UI_DEV_CREATE. The behavior
observed by user-space is not changed, as ABS initialization was never
checked for errors.
With this in place, the order of device initialization and abs
configuration is no longer fixed. Userspace can initialize the device and
afterwards set absinfo just fine.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This adds two new ioctls, UINPUT_DEV_SETUP and UI_ABS_SETUP, that replaces
the old device setup method (by write()'ing "struct uinput_user_dev" to the
node). The old method is not easily extendable and requires huge payloads.
Furthermore, overloading write() without properly versioned objects is
error-prone.
Therefore, we introduce two new ioctls to replace the old method. These
ioctls support all features of the old method, plus a "resolution" field
for absinfo. Furthermore, it's properly forward-compatible to new ABS codes
and a growing "struct input_absinfo" structure.
UI_ABS_SETUP also allows user-space to skip unknown axes if not set. There
is no need to copy the whole array temporarily into the kernel, but instead
the caller issues several ioctl where we copy each value manually.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Stop reporting KEY_SLEEP for a short key-press and report KEY_POWER instead
This change applies to both DA9063 and DA9062 ONKEY drivers.
A previous application used for testing by the developer required a
KEY_SLEEP and KEY_POWER input_report_key event to distinguish between a
short and long key-press of the power key. This is not the general
convention and the typical solution is for KEY_POWER to be used in both
cases: suspend and S/W power off.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
A small copy and paste error was preventing the haptics device being
disabled. This patch corrects the value written on disable.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull input updates from Dmitry Torokhov:
"Items of note:
- evdev users can now limit or mask the kind of events they will
receive. This will allow applications such as power manager or
network manager to only be woken when user presses special keys
such as KEY_POWER or KEY_WIFI and not be bothered with ordinary
key presses coming from keyboard
- support for FocalTech FT6236 touchscreen controller
- support for ROHM BU21023/24 touchscreen controller
- edt-ft5x06 touchscreen driver got a face lift and can now be used
with FT5506
- support for Google Fiber TV Box remote controls
- improvements in xpad driver (with more to come)
- several parport-based drivers have been switched to the new device
model
- other miscellaneous driver improvements"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (70 commits)
HID: hid-gfrm: avoid warning for input_configured API change
HID: hid-input: allow input_configured callback return errors
Input: evdev - fix bug in checking duplicate clock change request
Input: add userio module
Input: evdev - add event-mask API
Input: snvs_pwrkey - remove duplicated semicolon
HID: hid-gfrm: Google Fiber TV Box remote controls
Input: e3x0-button - update Kconfig description
Input: tegra-kbc - drop use of IRQF_NO_SUSPEND flag
Input: tegra-kbc - enable support for the standard "wakeup-source" property
Input: xen - check return value of xenbus_printf
Input: hp_sdc_rtc - fix y2038 problem in proc_show
Input: nomadik-ske-keypad - fix a trivial typo
Input: xpad - fix clash of presence handling with LED setting
Input: edt-ft5x06 - work around FT5506 firmware bug
Input: edt-ft5x06 - add support for FT5506
Input: edt-ft5x06 - add support for different max support points
Input: edt-ft5x06 - use max support points to determine how much to read
Input: rotary-encoder - add support for quarter-period mode
Input: rotary-encoder - use of_property_read_bool
...
