linux.git/drivers/hid/hidraw.c, branch v4.16

vfs: do bulk POLL* -> EPOLL* replacement

2018-02-11T22:34:03+00:00

This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.

Scripted-by: Al Viro 
Signed-off-by: Linus Torvalds

the rest of drivers/*: annotate ->poll() instances

2017-11-28T16:06:58+00:00

Signed-off-by: Al Viro

HID: hidraw: fix power sequence when closing device

2017-10-02T09:46:31+00:00

We should not try to bring HID device out of full power state before
calling hid_hw_close(), so that transport driver operates on powered up
device (making this inverse of the opening sequence).

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Guenter Roeck 
Reviewed-by: Benson Leung 
Signed-off-by: Jiri Kosina

sched/headers: Prepare to move signal wakeup & sigpending methods from into

2017-03-02T07:42:32+00:00

Fix up affected files that include this signal functionality via sched.h.

Acked-by: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

Merge branch 'for-4.7/upstream' into for-linus

2016-05-17T10:41:22+00:00

Conflicts:
	drivers/hid/usbhid/hid-quirks.c

HID: hidraw: silence an uninitialized variable warning

2016-04-04T07:49:12+00:00

My static checker complains that "devid" can be uninitialized if
alloc_chrdev_region() fails.  Fix this by moving the error hanling
forward a couple lines.

Signed-off-by: Dan Carpenter 
Signed-off-by: Jiri Kosina

HID: hidraw: switch to using memdup_user

2016-03-24T14:21:54+00:00

Instead of open-coding memory allocation and copying form user memory
sequence let's use memdup_user().

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

Merge branch 'for-3.15/hid-core-ll-transport-cleanup' into for-linus

2014-04-01T17:05:09+00:00

Conflicts:
	drivers/hid/hid-ids.h
	drivers/hid/hid-sony.c
	drivers/hid/i2c-hid/i2c-hid.c

HID: sony: do not rely on hid_output_raw_report

2014-03-14T14:30:20+00:00

hid_out_raw_report is going to be obsoleted as it is not part of the
unified HID low level transport documentation
(Documentation/hid/hid-transport.txt)

To do so, we need to introduce two new quirks:
* HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP: this quirks prevents the
  transport driver to use the interrupt channel to send output report
  (and thus force to use HID_REQ_SET_REPORT command)
* HID_QUIRK_SKIP_OUTPUT_REPORT_ID: this one forces usbhid to not
  include the report ID in the buffer it sends to the device through
  HID_REQ_SET_REPORT in case of an output report

This also fixes a regression introduced in commit 3a75b24949a8
(HID: hidraw: replace hid_output_raw_report() calls by appropriates ones).
The hidraw API was not able to communicate with the PS3 SixAxis
controllers in USB mode.

Reviewed-by: David Herrmann 
Signed-off-by: Benjamin Tissoires 
Tested-by: Antonio Ospite 
Signed-off-by: Jiri Kosina

HID: hidraw: fix warning destroying hidraw device files after parent

2014-02-26T10:01:28+00:00

I noticed that after hot unplugging a Logitech unifying receiver
(drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a
stack trace similar to this:

usb 1-1.1.2: USB disconnect, device number 7
WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0()
sysfs group ffffffff8187fa20 not found for kobject 'hidraw0'
[...]
CPU: 0 PID: 2865 Comm: upowerd Tainted: G        W 3.14.0-rc4 #7
Hardware name: LENOVO 7783PN4/        , BIOS 9HKT43AUS 07/11/2011
 0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7
 ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8
 ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028
Call Trace:
 [] ? dump_stack+0x41/0x51
 [] ? warn_slowpath_common+0x77/0x90
 [] ? warn_slowpath_fmt+0x4c/0x50
 [] ? device_del+0x40/0x1b0
 [] ? device_unregister+0x2f/0x50
 [] ? device_destroy+0x3a/0x40
 [] ? drop_ref+0x55/0x120 [hid]
 [] ? hidraw_release+0x96/0xb0 [hid]
 [] ? __fput+0xca/0x210
 [] ? task_work_run+0x97/0xd0
 [] ? do_notify_resume+0x69/0xa0
 [] ? int_signal+0x12/0x17
---[ end trace 63f4a46f6566d737 ]---

During device removal hid_disconnect() is called via hid_hw_stop() to
stop the device and free all its resources, including the sysfs
files. The problem is that if a user space process, such as upowerd,
holds a reference to a hidraw file the corresponding sysfs files will
be kept around (drop_ref() does not call device_destroy() if the open
counter is not 0) and it will be usb_disconnect() who, by calling
device_del() for the USB device, will indirectly remove the sysfs
files of the hidraw device (sysfs_remove_dir() is recursive these
days). Because of this, by the time user space releases the last
reference to the hidraw file and drop_ref() tries to destroy the
device the sysfs files are already gone and the kernel will print
the warning above.

Fix this by calling device_destroy() at USB disconnect time.

Signed-off-by: Fernando Luis Vazquez Cao 
Reviewed-by: David Herrmann 
Cc: stable@vger.kernel.org	# 3.13
Signed-off-by: Jiri Kosina