Commit Graph

2668 Commits

Author SHA1 Message Date
Song Hongyan
d443a0aa3a HID: hid-sensor-hub: clear memory to avoid random data
When user tried to read some fields like hysteresis from IIO sysfs on some
systems, it fails. The reason is that this field is a byte field and caller
of sensor_hub_get_feature() passes a buffer of 4 bytes. Here the function
sensor_hub_get_feature() copies the single byte from the report to the
caller buffer and returns "1" as the number of bytes copied. So caller
can use the return value.

But this is done by multiple callers, so if we just change the
sensor_hub_get_feature so that caller buffer is initialized with 0s
then we don't to change all functions.

Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-23 17:54:58 +01:00
Benjamin Tissoires
6dab07df55 HID: rmi: make transfer buffers DMA capable
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-23 17:43:25 +01:00
Benjamin Tissoires
b7a87ad677 HID: magicmouse: make transfer buffers DMA capable
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-23 17:43:25 +01:00
Benjamin Tissoires
061232f0d4 HID: lg: make transfer buffers DMA capable
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.

[jkosina@suse.cz: fix up second usage of hid_hw_raw_request(), spotted by
 0day build bot]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-23 17:42:43 +01:00
Benjamin Tissoires
1ffb3c40ff HID: cp2112: make transfer buffers DMA capable
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.

Use a spinlock to prevent concurrent accesses to the buffer.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-23 17:38:12 +01:00
Ooi, Joyce
4c4480aad0 HID: sensor: fix attributes in HID sensor interface
User is unable to access to input-X-yyy and feature-X-yyy where
X is a hex value and more than 9 (e.g. input-a-yyy, feature-b-yyy) in HID
sensor custom sysfs interface.
This is because when creating the attribute, the attribute index is
written to using %x (hex). However, when reading and writing values into
the attribute, the attribute index is scanned using %d (decimal). Hence,
user is unable to access to attributes with index in hex values
(e.g. 'a', 'b', 'c') but able to access to attributes with index in
decimal values (e.g. 1, 2, 3,..).
This fix will change input-%d-%x-%s and feature-%d-%x-%s to input-%x-%x-%s
and feature-%x-%x-%s in show_values() and store_values() accordingly.

Signed-off-by: Ooi, Joyce <joyce.ooi@intel.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-05 16:56:09 +01:00
Srinivas Pandruvada
021afd55e2 HID: intel-ish-hid: request_irq failure
On some platforms ISH interrupt is shared, which causes request_irq to
fail. This requires IRQF_SHARED irq flag.

But IRQF_NO_SUSPEND and IRQF_SHARED should not be used together, so
removed IRQF_NO_SUSPEND flag. Anyway this driver doesn't require
IRQF_NO_SUSPEND, as this interrupt is not required during "noirq" phases
of suspending and resuming devices as well as during the time when
nonboot CPUs are taken offline and brought back online.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-05 15:57:38 +01:00
Even Xu
2a1e3b932c HID: intel-ish-hid: Fix driver reinit failure
When built as a module, modprobe followed by rmmod can fail because
DMA was still active. So to fix this, DMA needs to be disabled during
module exit.

This change disables DMA during modules exit and change the ISH PCI
device status to D3.

Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-05 15:57:38 +01:00
Even Xu
8b2979febc HID: intel-ish-hid: Move DMA disable code to new function
Add a new function ish_disable_dma() and move DMA disable operations
here, so that this functionality can be reused.

Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-05 15:57:37 +01:00
Even Xu
c2ed83f542 HID: intel-ish-hid: consolidate ish wake up operation
Same operations are done in ish_hw_start() and _ish_hw_reset() to
wakeup ISH device. Consolidate them by introducing a new function
ish_wakeup() and move the code there.

Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-05 15:57:37 +01:00
Oliver Neukum
cf0ea4da4c HID: usbhid: add ATEN CS962 to list of quirky devices
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>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-03 12:23:01 -06:00
Borislav Petkov
1793e1c521 HID: intel-ish-hid: Fix !CONFIG_PM build warning
Fix

  drivers/hid/intel-ish-hid/ipc/pci-ish.c:247:12: warning: ‘ish_suspend’ defined but not used [-Wunused-function]
   static int ish_suspend(struct device *device)
              ^
  drivers/hid/intel-ish-hid/ipc/pci-ish.c:282:12: warning: ‘ish_resume’ defined but not used [-Wunused-function]
   static int ish_resume(struct device *device)
            ^
by sticking them in the CONFIG_PM range too.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: linux-input@vger.kernel.org
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-03 12:12:09 -06:00
Srinivas Pandruvada
5459ada2b3 HID: sensor-hub: Fix packing of result buffer for feature report
When report count is more than one and report size is not 4 bytes, then we
need some packing into result buffer from the caller of function
sensor_hub_get_feature.
By default the value extracted from a field is 4 bytes from hid core
(using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even
if report size if less than 4 byte. So when we copy data to user buffer in
sensor_hub_get_feature, we need to only copy report size bytes even
when report count is more than 1. This is
not an issue for most of the sensor hub fields as report count will be 1
where we already copy only report size bytes, but some string fields
like description, it is a problem as the report count will be more than 1.
For example:
    Field(6)
      Physical(Sensor.OtherCustom)
      Application(Sensor.Sensor)
      Usage(11)
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
        Sensor.0306
      Report Size(16)
      Report Count(11)

Here since the report size is 2 bytes, we will have 2 additional bytes of
0s copied into user buffer, if we directly copy to user buffer from
report->field[]->value

This change will copy report size bytes into the buffer of caller for each
usage report->field[]->value. So for example without this change, the
data displayed for a custom sensor field "sensor-model":

76 00 101 00 110 00 111 00 118 00 111
(truncated to report count of 11)

With change

76 101 110 111 118 111 32 89 111 103 97
("Lenovo Yoga" in ASCII )

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-11-03 12:08:43 -06:00
Steinar H. Gunderson
4973ca9a01 HID: add quirk for Akai MIDImix.
The Akai MIDImix (09e8:0031) is a MIDI fader controller that speaks
regular MIDI and works well with Linux. However, initialization gets
delayed due to reports timeout:

  [3643645.631124] hid-generic 0003:09E8:0031.0020: timeout initializing reports
  [3643645.632416] hid-generic 0003:09E8:0031.0020: hiddev0: USB HID v1.11 Device [AKAI MIDI Mix] on usb-0000:00:14.0-2/input0

Adding "usbhid.quirks=0x09e8:0x0031:0x20000000" on the kernel
command line makes the issues go away.

Signed-off-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-10-10 10:58:22 +02:00
Ioan-Adrian Ratiu
1bcaa05ebe Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"
This reverts commit 18339f59c3 ("HID: dragonrise: fix HID...") because it
breaks certain dragonrise 0079:0006 gamepads. While it may fix a breakage
caused by commit 79346d620e ("HID: input: force generic axis to be mapped
to their user space axis"), it is probable that the manufacturer released
different hardware with the same PID so this fix works for only a subset
and breaks the other gamepads sharing the PID.

What is needed is another more generic solution which fixes 79346d620e
("HID: input: force generic axis ...") breakage for this controller: we
need to add an exception for this driver to make it keep the old behaviour
previous to the initial breakage (this is done in patch 2 of this series).

Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-10-10 10:52:01 +02:00
Ioan-Adrian Ratiu
e159440998 HID: hid-dr: add input mapping for axis selection
Commit 79346d620e ("HID: input: force generic axis to be mapped to their
user space axis") made mapping generic axes to their userspace equivalents
mandatory and some lower end gamepads which were depending on the previous
behaviour suffered severe regressions because they were reusing axes and
expecting hid-input to multiplex their map to the respective userspace axis
by always searching for and using the next available axis.

One solution is to add a hid quirk for this type of "previous" behaviour in
hid-input to bypass the new axes policy in favour of the old one, but since
only one hardware vendor seems to be affected negatively we're better off
making and exception and mapping in the driver for now; if more vendors or
drivers turn out to experience the problem we should reconsider the quirk
solution.

Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-10-10 10:52:00 +02:00
Heiner Kallweit
3d1355b3cf HID: hid-led: fix issue with transfer buffer not being dma capable
The hid-led driver works fine under 4.8.0, however with the next
kernel from today I get this:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
transfer buffer not dma capable
Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm led_class mac80211 snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801 i2c_smbus snd_hda_intel cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169 snd_timer mei_me mii snd mei ir_lirc_codec lirc_dev nuvoton_cir rc_core btusb btintel bluetooth rfkill usb_storage efivarfs ipv6 ehci_pci ehci_hcd xhci_pci xhci_hcd usbcore usb_common ext4 jbd2 mbcache ahci libahci libata
CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
 ffffc90003dbb7e0 ffffffff81280425 ffffc90003dbb830 0000000000000000
 ffffc90003dbb820 ffffffff8105b086 0000063003dbb800 ffff88006f374480
 0000000000000000 0000000000000000 0000000000000001 ffff880079544000
Call Trace:
 [<ffffffff81280425>] dump_stack+0x68/0x93
 [<ffffffff8105b086>] __warn+0xc6/0xe0
 [<ffffffff8105b0ea>] warn_slowpath_fmt+0x4a/0x50
 [<ffffffffa0143a43>] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
 [<ffffffffa01441b6>] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
 [<ffffffff810bce80>] ? rcu_read_lock_sched_held+0x40/0x80
 [<ffffffff810e0043>] ? module_assert_mutex_or_preempt+0x13/0x50
 [<ffffffff810e0c07>] ? __module_address+0x27/0xf0
 [<ffffffffa01456e4>] usb_submit_urb+0x2c4/0x520 [usbcore]
 [<ffffffffa0145fea>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
 [<ffffffffa014612c>] usb_control_msg+0xbc/0xf0 [usbcore]
 [<ffffffff810e0c07>] ? __module_address+0x27/0xf0
 [<ffffffffa079a724>] usbhid_raw_request+0xa4/0x180 [usbhid]
 [<ffffffffa07a93b1>] hidled_recv+0x71/0xe0 [hid_led]
 [<ffffffffa07a947d>] thingm_init+0x2d/0x50 [hid_led]
 [<ffffffffa07a969b>] hidled_probe+0xcb/0x24a [hid_led]
 [<ffffffff814d96f2>] hid_device_probe+0xd2/0x150
 [<ffffffff8146023d>] driver_probe_device+0x1fd/0x2c0
 [<ffffffff8146039a>] __driver_attach+0x9a/0xa0
 [<ffffffff81460300>] ? driver_probe_device+0x2c0/0x2c0
 [<ffffffff8145e25d>] bus_for_each_dev+0x5d/0x90
 [<ffffffff8145fa79>] driver_attach+0x19/0x20
 [<ffffffff8145f5ff>] bus_add_driver+0x11f/0x220
 [<ffffffffa07ac000>] ? 0xffffffffa07ac000
 [<ffffffff8146086b>] driver_register+0x5b/0xd0
 [<ffffffffa07ac000>] ? 0xffffffffa07ac000
 [<ffffffff814d83d1>] __hid_register_driver+0x61/0xa0
 [<ffffffffa07ac01e>] hidled_driver_init+0x1e/0x20 [hid_led]
 [<ffffffff81000408>] do_one_initcall+0x38/0x150
 [<ffffffff810bce80>] ? rcu_read_lock_sched_held+0x40/0x80
 [<ffffffff81194ca0>] ? kmem_cache_alloc_trace+0x1d0/0x230
 [<ffffffff811342f9>] do_init_module+0x5a/0x1cb
 [<ffffffff810e3862>] load_module+0x1e42/0x2530
 [<ffffffff810e0990>] ? __symbol_put+0x50/0x50
 [<ffffffff810dfc50>] ? show_coresize+0x30/0x30
 [<ffffffff811ad650>] ? kernel_read_file+0x100/0x190
 [<ffffffff811ad794>] ? kernel_read_file_from_fd+0x44/0x70
 [<ffffffff810e415a>] SYSC_finit_module+0xba/0xc0
 [<ffffffff810e4179>] SyS_finit_module+0x9/0x10
 [<ffffffff815e082a>] entry_SYSCALL_64_fastpath+0x18/0xad
---[ end trace c9e6ea27003ecf9e ]---

Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-10-10 10:47:03 +02:00
Linus Torvalds
bc75450cc3 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
Pull HID updates from Jiri Kosina:

 - Integrated Sensor Hub support (Cherrytrail+) from Srinivas Pandruvada

 - Big cleanup of Wacom driver; namely it's now using devres, and the
   standardized LED API so that libinput doesn't need to have root
   access any more, with substantial amount of other cleanups
   piggy-backing on top. All this from Benjamin Tissoires

 - Report descriptor parsing would now ignore and out-of-range System
   controls in case of the application actually being System Control.
   This fixes quite some issues with several devices, and allows us to
   remove a few ->report_fixup callbacks. From Benjamin Tissoires

 - ... a lot of other assorted small fixes and device ID additions

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (76 commits)
  HID: add missing \n to end of dev_warn messages
  HID: alps: fix multitouch cursor issue
  HID: hid-logitech: Documentation updates/corrections
  HID: hid-logitech: Improve Wingman Formula Force GP support
  HID: hid-logitech: Rewrite of descriptor for all DF wheels
  HID: hid-logitech: Compute combined pedals value
  HID: hid-logitech: Add combined pedal support Logitech wheels
  HID: hid-logitech: Introduce control for combined pedals feature
  HID: sony: Update copyright and add Dualshock 4 rate control note
  HID: sony: Defer the initial USB Sixaxis output report
  HID: sony: Relax duplicate checking for USB-only devices
  Revert "HID: microsoft: fix invalid rdesc for 3k kbd"
  HID: alps: fix error return code in alps_input_configured()
  HID: alps: fix stick device not working after resume
  HID: support for keyboard - Corsair STRAFE
  HID: alps: Fix memory leak
  HID: uclogic: Add support for UC-Logic TWHA60 v3
  HID: uclogic: Override constant descriptors
  HID: uclogic: Support UGTizer GP0610 partially
  HID: uclogic: Add support for several more tablets
  ...
2016-10-07 11:58:38 -07:00
Jiri Kosina
179023e6af Merge branches 'for-4.8/upstream-fixes', 'for-4.9/alps', 'for-4.9/hid-input', 'for-4.9/intel-ish', 'for-4.9/kye-uclogic-waltop-fixes', 'for-4.9/logitech', 'for-4.9/sony', 'for-4.9/upstream' and 'for-4.9/wacom' into for-linus 2016-10-07 09:59:48 +02:00
Masaki Ota
9a54cf462d HID: alps: fix multitouch cursor issue
Issue reproduction procedure:

1. three or more fingers put on Touchpad.
2. release fingers from Touchpad.
3. move the cursor by one finger.
4. the cursor does not move.

Cause:

We do not notify multi fingers state correctly to input subsystem.  For
example, when three fingers release from Touchpad, fingers state is 3 -> 0. It
needs to notify first, second and third finger's releasing state.

Fix this by not breaking out on z axis and move x,y,z input handling
code to the correct place so that it's in fact per-finger.

[jkosina@suse.cz: reword changelog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-27 13:50:09 +02:00
Simon Wood
f777a3a7bd HID: hid-logitech: Documentation updates/corrections
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-26 15:39:56 +02:00
Simon Wood
560bea30ff HID: hid-logitech: Improve Wingman Formula Force GP support
Move ForceFeedback support for the Formula Force GP into hid-lgff4
and re-write HID descriptor, thus allowing combined pedals or not
as user desires.

Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-26 15:39:56 +02:00
Simon Wood
7363b25af3 HID: hid-logitech: Rewrite of descriptor for all DF wheels
Rewrite the HID descriptor for _all_ Driving Force wheels (real
or emulated) so that they can report separate Accelerator and
Brake axis.

If the user wants a combined accel/brake axis, they can use the
'combined pedals' feature.

$ echo 1 > /sys/bus/hid/devices/<device-id>/combine_pedals

Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-26 15:39:55 +02:00
Simon Wood
b456634b8d HID: hid-logitech: Compute combined pedals value
Add support for computing a combined accelerator/brake axis for wheels
which don't contain combined data in their HID stream.

This includes DFGT, G25, G27, G29 and Wii-Wheel.

Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-26 15:39:55 +02:00
Simon Wood
c832f86eff HID: hid-logitech: Add combined pedal support Logitech wheels
Add support for reporting a combined accelerator/brake axis for wheels
which contain combined data in their HID stream.

This includes DF, MOMO, MOMO2 and DFP.

Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-26 15:39:54 +02:00