| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.4.48 stable release
|
|
commit 282e4637bc1c0b338708bcebd09d31c69abec070 upstream.
Commit 025bcc1 performed cleanup work on the 'wacom_pl_irq' function, making
it follow the standards used in the rest of the codebase. The change
unintiontionally allowed the function to send input events from reports
that are not marked as being in prox. This can cause problems as the
report values for X, Y, etc. are not guaranteed to be correct. In
particular, occasionally the tablet will send a report with these values
set to zero. If such a report is received it can caus an unexpected jump
in the XY position.
This patch surrounds more of the processing code with a proximity check,
preventing these zeroed reports from overwriting the current state. To
be safe, only the tool type and ABS_MISC events should be reported when
the pen is marked as being out of prox.
Fixes: 025bcc1540 ("HID: wacom: Simplify 'wacom_pl_irq'")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 4.4.45 stable release
|
|
commit 7a546af50eb78ab99840903083231eb635c8a566 upstream.
Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.
Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than necessary.
Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6d104af38b570d37aa32a5803b04c354f8ed513d upstream.
Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.
Note that the macro-mode buffer was larger than necessary.
Fixes: 6f78193ee9ea ("HID: corsair: Add Corsair Vengeance K90 driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 4.4.43 stable release
|
|
commit 1ebb71143758f45dc0fa76e2f48429e13b16d110 upstream.
Make sure we have enough of a report structure to validate before
looking at it.
Reported-by: Benoit Camredon <benoit.camredon@airbus.com>
Tested-by: Benoit Camredon <benoit.camredon@airbus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This is the 4.4.32 stable release
Change-Id: I5028402eadfcf055ac44a5e67abc6da75b2068b3
|
|
commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 50220dead1650609206efe91f0cc116132d59b3f ]
Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
out-of-bound readings.
The fields are allocated up to MAX_USAGE, meaning that potentially, we do
not have enough fields to fit the incoming values.
Add checks and silence KASAN.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
(cherry picked from commit 50220dead1650609206efe91f0cc116132d59b3f)
Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
out-of-bound readings.
The fields are allocated up to MAX_USAGE, meaning that potentially, we do
not have enough fields to fit the incoming values.
Add checks and silence KASAN.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Change-Id: Iaf25e882a6696884439d7091b5fbb0b350d893d3
Bug: 30951261
|
|
This is the 4.4.19 stable release
|
|
commit 67f8ecc550b5bda03335f845dc869b8501d25fd0 upstream.
Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.
The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.
Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.
We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.
[jkosina@suse.cz: reword subject]
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 19f4c2ba869517048add62c202f9645b6adf5dfb upstream.
When setting the operational mode, some third party (Speedlink Strike-FX)
gamepads refuse the output report. Failing here means we refuse to
initialize the gamepad while this should be harmless.
The weird part is that the initial commit that added this: a7de9b8
("HID: sony: Enable Gasia third-party PS3 controllers") mentions this
very same controller as one requiring this output report.
Anyway, it's broken for one user at least, so let's change it.
We will report an error, but at least the controller should work.
And no, these devices present themselves as legacy Sony controllers
(VID:PID of 054C:0268, as in the official ones) so there are no ways
of discriminating them from the official ones.
https://bugzilla.redhat.com/show_bug.cgi?id=1255325
Reported-and-tested-by: Max Fedotov <thesourcehim@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Laura Abbott <labbott@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 4.4.16 stable release
Change-Id: Ibaf7b7e03695e1acebc654a2ca1a4bfcc48fcea4
|
|
commit 6dd2e27a103d716921cc4a1a96a9adc0a8e3ab57 upstream.
The usage Confidence is mandary to Windows Precision Touchpad devices. If
it is examined in input_mapping on a WIndows Precision Touchpad, a new add
quirk MT_QUIRK_CONFIDENCE desgned for such devices will be applied to the
device. A touch with the confidence bit is not set is determined as
invalid.
Tested on Dell XPS13 9343
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # XPS 13 9350, BIOS 1.4.3
Signed-off-by: Allen Hung <allen_hung@dell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 93a2001bdfd5376c3dc2158653034c20392d15c5 upstream.
This patch validates the num_values parameter from userland during the
HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
leading to a heap overflow.
Signed-off-by: Scott Bauer <sbauer@plzdonthack.me>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ed596a4a88bd161f868ccba078557ee7ede8a6ef upstream.
Flushing a work that reschedules itself is not a sensible operation. It needs
to be killed. Failure to do so leads to a kernel panic in the timer code.
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 567a44ecb44eb2584ddb93e962cfb133ce77e0bb upstream.
Needed for v2 of the device firmware, otherwise kernel will stuck for few
seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e1123fe975852cc0970b4e53ea65ca917e54c923 upstream.
DTK-1651 is a display pen-only tablet
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 0840b80cb9626906b57df54e7229db60f9aea4f2.
This patch is already upstreamed in v4.4, commit
658d4aed59b3 (HID: hid-multitouch: Filter collections by application usage.),
and further fixed/cleaned up afterwards in commits
c2ef8f21ea8f (HID: multitouch: add support for trackpads),
76f5902aebda (HID: hid-multitouch: Simplify setup and frame synchronization) et al.
By having this duplicate patch in AOSP we are doing redundant
checks for Touchscreen and Touchpad devices.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
|
|
This reverts commit 90037b2720acffa6da2269a10ecf24ec2dace89b.
Remove duplicate code. This patch is already upstreamed in v4.4,
commit 41df7f6d4372 (HID: steelseries: validate output report details).
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
|
|
commit 972e6a993f278b416a8ee3ec65475724fc36feb2 upstream.
The usbhid driver has inconsistently duplicated code in its post-reset,
resume, and reset-resume pathways.
reset-resume doesn't check HID_STARTED before trying to
restart the I/O queues.
resume fails to clear the HID_SUSPENDED flag if HID_STARTED
isn't set.
resume calls usbhid_restart_queues() with usbhid->lock held
and the others call it without holding the lock.
The first item in particular causes a problem following a reset-resume
if the driver hasn't started up its I/O. URB submission fails because
usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
This patch fixes the problem by creating a new subroutine,
hid_restart_io(), to carry out all the common activities. It also
adds some checks that were missing in the original code:
After a reset, there's no need to clear any halted endpoints.
After a resume, if a reset is pending there's no need to
restart any I/O until the reset is finished.
After a resume, if the interrupt-IN endpoint is halted there's
no need to submit the input URB until the halt has been
cleared.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Daniel Fraga <fragabr@gmail.com>
Tested-by: Daniel Fraga <fragabr@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 580549ef6b3e3fb3b958de490ca99f43a089a2cf upstream.
Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
The tablet behaves as if it was a regular Bamboo device with pen, touch
and pad, but there is no physical pad connected to it.
The weird part is that the pad is still sending events and given that
there is no input node connected to it, we get anull pointer exception.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4392bf333388cabdad5afe5b1500002d7b9c318e upstream.
hid_ignore_special_drivers works fine until hid_scan_report autodetects and
reassign devices (for hid-multitouch, hid-microsoft and hid-rmi).
Simplify the handling of the parameter: if it is there, use hid-generic, no
matter what, and if not, scan the device or rely on the hid_have_special_driver
table.
This was detected while trying to disable hid-multitouch on a Surface Pro cover
which prevented to use the keyboard.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 45c5c6828214605eaefa6755c47bd1a2c7eb203e upstream.
The Synaptics 0x11e5 over I2C found in the Asus T100-CHI requires to
fetch the signature blob to actually start sending events.
With this patch, we should be close enough to the Windows driver which
checks the content of the blob at plugin to validate or not the
touchscreen.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=113481
Fixes: 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices")
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3b654288b196ceaa156029d9457ccbded0489b98 upstream.
Even though hid_hw_* checks that passed in data_len is less than
HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily
allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device
reports and select largest size. In-kernel users normally just send as much
data as report needs, so there is no problem, but hidraw users can do
whatever they please:
BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80
Write of size 4101 by task syz-executor/8747
CPU: 2 PID: 8747 Comm: syz-executor Tainted: G BU 3.18.0 #37
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[<ffffffc00020ebcc>] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83
[<ffffffc00020ee40>] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffc001958114>] dump_stack+0x90/0x140 lib/dump_stack.c:50
[< inline >] print_error_description mm/kasan/report.c:97
[< inline >] kasan_report_error mm/kasan/report.c:278
[<ffffffc0004597dc>] kasan_report+0x268/0x530 mm/kasan/report.c:305
[<ffffffc0004592e8>] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718
[<ffffffc0004594e0>] memcpy+0x30/0x54 mm/kasan/kasan.c:299
[<ffffffc001306354>] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178
[< inline >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321
[<ffffffc0013079a0>] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589
[<ffffffc001307ad8>] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602
[< inline >] hid_hw_output_report include/linux/hid.h:1039
[<ffffffc0012cc7a0>] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154
[<ffffffc0012cc7f4>] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177
[<ffffffc0004681dc>] vfs_write+0x1d4/0x3cc fs/read_write.c:534
[< inline >] SYSC_pwrite64 fs/read_write.c:627
[<ffffffc000468984>] SyS_pwrite64+0xec/0x144 fs/read_write.c:614
Object at ffffffc07135ea80, in cache kmalloc-512
Object allocated with size 268 bytes.
Let's check data length against the buffer size before attempting to copy
data over.
Reported-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5d74325a2201376a95520a4a38a1ce2c65761c49 upstream.
The patch that added Logitech Dual Action gamepad support forgot to
update the special driver list for the device. This caused the logitech
driver not to probe unless kernel module load order was favorable.
Update the special driver list to fix it. Thanks to Simon Wood for the
idea.
Cc: Vitaly Katraew <zawullon@gmail.com>
Fixes: 56d0c8b7c8fb ("HID: add support for Logitech Dual Action gamepads")
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
do_div() must only be used with a u64 dividend.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
(cherry picked from commit 8d43b49e7e0070f96ac46d30659a336c0224fa0b)
Signed-off-by: Guenter Roeck <groeck@chromium.org>
|
|
commit 73e7d63efb4d774883a338997943bfa59e127085 upstream.
as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481
This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
reports on demand for Win8 devices") as the origin of the problem but this
commit actually masked 2 firmware bugs that are annihilating each other:
The report descriptor declares two features in reports 3 and 5:
0x05, 0x0d, // Usage Page (Digitizers) 318
0x09, 0x0e, // Usage (Device Configuration) 320
0xa1, 0x01, // Collection (Application) 322
0x85, 0x03, // Report ID (3) 324
0x09, 0x22, // Usage (Finger) 326
0xa1, 0x00, // Collection (Physical) 328
0x09, 0x52, // Usage (Inputmode) 330
0x15, 0x00, // Logical Minimum (0) 332
0x25, 0x0a, // Logical Maximum (10) 334
0x75, 0x08, // Report Size (8) 336
0x95, 0x02, // Report Count (2) 338
0xb1, 0x02, // Feature (Data,Var,Abs) 340
0xc0, // End Collection 342
0x09, 0x22, // Usage (Finger) 343
0xa1, 0x00, // Collection (Physical) 345
0x85, 0x05, // Report ID (5) 347
0x09, 0x57, // Usage (Surface Switch) 349
0x09, 0x58, // Usage (Button Switch) 351
0x15, 0x00, // Logical Minimum (0) 353
0x75, 0x01, // Report Size (1) 355
0x95, 0x02, // Report Count (2) 357
0x25, 0x03, // Logical Maximum (3) 359
0xb1, 0x02, // Feature (Data,Var,Abs) 361
0x95, 0x0e, // Report Count (14) 363
0xb1, 0x03, // Feature (Cnst,Var,Abs) 365
0xc0, // End Collection 367
The report ID 3 presents 2 input mode features, while only the first one
is handled by the device. Given that we did not checked if one was
previously assigned, we were dealing with the ignored featured and we
should never have been able to switch this panel into the multitouch mode.
However, the firmware presents an other bugs which allowed 6d4f5440
to counteract the faulty report descriptor. When we request the values
of the feature 5, the firmware answers "03 03 00". The fields are correct
but the report id is wrong. Before 6d4f5440, we retrieved all the features
and injected them in the system. So when we called report 5, we injected
in the system the report 3 with the values "03 00".
Setting the second input mode to 03 in this report changed it to "03 03"
and the touchpad switched to the mt mode. We could have set anything
in the second field because the actual value (the first 03 in this report)
was given by the query of report ID 5.
To sum up: 2 bugs in the firmware were hiding that we were accessing the
wrong feature.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.
The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).
The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().
There are two ways to get out of this deadlock:
1. Make the drivers work "around" the ctrl critical region, in the
wacom case for ex. by delaying the scheduling of the proximity read
request itself to a workqueue.
2. Shrink the critical region so the usbhid lock protects only the
instructions which modify usbhid state, calling hid_input_report()
with the spinlock unlocked, allowing the device driver to grab the
lock first, finish and then grab the lock afterwards in hid_ctrl().
This patch implements the 2nd solution.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This change fixes two problems.
First, it ensures that the hid-multitouch driver does not incorrectly
map GenericDesktop usages that are intended for other applications,
such as a Mouse.
Second, it sets the appropriate input properties so that user-space
can distinguish TouchScreen devices (INPUT_PROP_DIRECT) from
TouchPad devices (INPUT_PROP_POINTER) and configure them accordingly.
Change-Id: I8c2d947929186ffe7cf04b37c76e29b9abecf8cb
Signed-off-by: jeffbrown@android.com
|
|
A HID device could send a malicious output report that would cause the
steelseries HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 167.981534] usb 1-1: New USB device found, idVendor=1038, idProduct=1410
...
[ 182.050547] BUG kmalloc-256 (Tainted: G W ): Redzone overwritten
CVE-2013-2891
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB driver fixes from Greg KH:
"Here are a number of small USB fixes for 4.4-rc5. All of them have
been in linux-next. The majority are gadget and phy issues, with a
few new quirks and device ids added as well"
* tag 'usb-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (32 commits)
USB: add quirk for devices with broken LPM
xhci: fix usb2 resume timing and races.
usb: musb: fail with error when no DMA controller set
usb: gadget: uvc: fix permissions of configfs attributes
usb: musb: core: Fix pm runtime for deferred probe
usb: phy: msm: fix a possible NULL dereference
USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
usb: Quiet down false peer failure messages
usb: xhci: fix config fail of FS hub behind a HS hub with MTT
xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()
usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message
USB: whci-hcd: add check for dma mapping error
usb: core : hub: Fix BOS 'NULL pointer' kernel panic
USB: quirks: Apply ALWAYS_POLL to all ELAN devices
usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron
USB: quirks: Fix another ELAN touchscreen
usb: dwc3: gadget: don't prestart interrupt endpoints
USB: serial: Another Infineon flash loader USB ID
USB: cdc_acm: Ignore Infineon Flash Loader utility
USB: cp210x: Remove CP2110 ID from compatibility list
...
|
|
Looks like 29fae1c85 ("HID: logitech: Add support for G29") was a little
bit aggressive and broke other devices.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=108121
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
this quirk for all devices from this vendor, rather than maintaining a
list of all its known product IDs.
Tested-by: Adrien Vergé <adrienverge@gmail.com>
Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Without quirk keyboard repeats '6' until volume control is used since it
indicates the key is pressed without ever releasing.
Signed-off-by: Jimmy Berry <jimmy@boombatower.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Given that INTUOSHT < BAMBOO_PT
features->type >= INTUOSHT || features->type <= BAMBOO_PT
condition is always true, and therefore device_type is under certain
circumstances wrongly set with WACOM_DEVICETYPE_PAD bit set.
Fix the condition so that it actually represents the range as intended.
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
DTU1141 has an extra 1 mm tablet active outbounding area on each
side of the display, same as those recently released DTUs.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
Pull HID updates from Jiri Kosina:
"Highlights:
- Intel Skylake Win8 precision touchpads support fixes/improvements
from Mika Westerberg
- Lenovo Yoga 2 quirk from Ritesh Raj Sarraf
- potential uninitialized buffer access fix in HID core from Richard
Purdie
- Wacom Intuos and Wacom Cintiq 2 support improvements from Jason
Gerecke and Ping Cheng
- initiation of sysfs deprecation process for most of the roccat
drivers, from the roccat support maintiner Stefan Achatz
- quite a few device ID / quirk additions and small fixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (30 commits)
HID: logitech: Add support for G29
HID: logitech: Simplify wheel detection scheme
HID: wacom: Call 'wacom_query_tablet_data' only after 'hid_hw_start'
HID: wacom: Fix ABS_MISC reporting for Cintiq Companion 2
HID: wacom: Remove useless conditions from 'wacom_query_tablet_data'
HID: wacom: fix Intuos wireless report id issue
HID: fix some indenting issues
HID: wacom: Expect 'touch_max' touches if HID_DG_CONTACTCOUNT not present
HID: wacom: Tie cached HID_DG_CONTACTCOUNT indices to report ID
HID: roccat: Fixed resubmit: Deprecating most Roccat sysfs attributes
HID: wacom: Report full pressure range for Intuos, Cintiq 13HD Touch
HID: wacom: Add support for Cintiq Companion 2
HID: multitouch: Fetch feature reports on demand for Win8 devices
HID: sensor-hub: Add quirk for Lenovo Yoga 2 with ITE Chips
HID: usbhid: Fix for the WiiU adapter from Mayflash
HID: corsair: boolify struct k90_led.removed
HID: corsair: Add Corsair Vengeance K90 driver
HID: hid-input: allow input_configured callback return errors
HID: multitouch: Add suffix for HID_DG_TOUCHPAD
HID: i2c-hid: Fill in physical device providing HID functionality
...
|
|
'for-4.4/dragonrise', 'for-4.4/i2c-hid', 'for-4.4/logitech', 'for-4.4/microsoft', 'for-4.4/multitouch', 'for-4.4/roccat-sysfs-deprecation', 'for-4.4/upstream' and 'for-4.4/wacom' into for-linus
|
|
At present the G29 is mis-identified as a DFGT, this patch ensures
that the wheel is correctly detected and allows setting the LEDs and
turning range via the '/sys' interface.
This wheel can also emulate other types of Logitech wheels.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Simplfy how hid-logitech driver detects the native mode of the wheel,
done by looking at the USB-ID revision and comparing bit mask.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The input_configured callback was recently changed to return
an 'int', but the newly added driver uses the old API:
drivers/hid/hid-gfrm.c:151:22: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
This changes the driver like the other ones.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 34fc1322e7aa ("HID: hid-gfrm: Google Fiber TV Box remote controls")
Fixes: b2c68a2f1bab ("HID: hid-input: allow input_configured callback return errors")
Acked-by: Petri Gynther <pgynther@google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
When configuring input device via input_configured callback we may
encounter errors (for example input_mt_init_slots() may fail). Instead
of continuing with half-initialized input device let's allow driver
indicate failures.
Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Acked-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
When connecting the Cintiq Companion 2 as an external tablet (i.e., using
it in "hybrid" mode) it has been seen to cause the kernel of the machine
it is connected to to Oops. The cause has been traced to us attempting to
switch the tablet's mode prior to actually starting HID device (resulting
in the eventual dereference of the uninitialized control URB).
Commit 3b164a0 moved the mode switch from occuring post-start to occurring
pre-start. The change was not seen to cause issues largely due to the fact
that most devices mode switch with 'hid_hw_raw_request' (which is safe to
call prior to start) rather than 'hid_hw_request'.
Moving the call back to its original location resolves the issue, but
causes some touch-only Bamboo tablets (e.g. 056a:00d0) to stop working.
The affected tablets require us to perform a mode switch on their
vestigial pen interface prior ignoring with -ENODEV, meaning that the
code which is responsible for doing the ignoring has to move as well.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The pad handling code introduced for the Cintiq Companion 2 (f7acb55)
looks at the wrong bytes in the report when deciding whether ABS_MISC
should be sent. This does not cause any issues with the X driver now
that the pen and pad have been split to separate devices, but is
incorrect and has caused issues when backporting to distros with pre-
3.17 kernels.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
When support for the Cintiq Companion Hybrid and Cintiq Companion 2 was
added (36d3c51 and f7acb55), the 'wacom_query_tablet_data' function was
updated to include references to CINTIQ_HYBRID and CINTIQ_COMPANION_2
with the thought that they were necessary to switch the touch interface
into the proper mode. This is unnecessary, however, since those types
are only ever associated with the pen interface -- the touch interfaces
are either CINTIQ_24HDT or HID_GENERIC. To avoid confusion in the future,
we remove the unnecessary CINTIQ_HYBRID and CINTIQ_COMPANION_2 conditions.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Intuos Pen in wireless mode does not have the same report id (2) as
when it is in USB mode (17).
This patch also moves WIRELESS next to REMOTE in type enum so we
can group devices with similar features easily.
Reported-by: Dale Brewe <dlbrewe@hotmail.com>
Tested-by: Dale Brewe <dlbrewe@hotmail.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
