linux-toradex.git/drivers/hid/uhid.c, branch v4.10

miscdevice: Add helper macro for misc device boilerplate

2016-08-31T12:12:35+00:00

Many modules call misc_register and misc_deregister in its module init
and exit methods without any additional code. This ends up being
boilerplate. This patch adds helper macro module_misc_device(), that
replaces module_init()/ module_exit() with template functions.

This patch also converts drivers to use new macro.

Change since v1:
Add device.h include in miscdevice.h as module_driver macro was not
available from other include files in some architectures.

Signed-off-by: PrasannaKumar Muralidharan 
Signed-off-by: Greg Kroah-Hartman

HID: uhid: fix timeout when probe races with IO

2016-06-01T14:24:54+00:00

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 
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina

drivers/hid/uhid.c: check write() bitness using in_compat_syscall

2016-03-22T22:36:02+00:00

uhid changes the format expected in write() depending on bitness.  It
should check the syscall bitness directly.

Signed-off-by: Andy Lutomirski 
Cc: David Herrmann 
Acked-by: Jiri Kosina 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

HID: uHID: fix excepted report type

2014-10-01T18:58:46+00:00

When uhid_get_report() or uhid_set_report() are called, they emit on the
char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
or UHID_SET_REPORT_REPLY.

Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
or UHID_SET_REPORT instead of the reply one.
Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
reply, and validate the reply.

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

HID: uhid: report to user-space whether reports are numbered

2014-08-25T08:28:08+00:00

This makes UHID_START include a "dev_flags" field that describes details
of the hid-device in the kernel. The first flags we introduce describe
whether a given report-type uses numbered reports. This is useful for
transport layers that force report-numbers and therefore might have to
prefix kernel-provided HID-messages with the report-number.

Currently, only HoG needs this and the spec only talks about "global
report numbers". That is, it's a global boolean not a per-type boolean.
However, given the quirks we already have in kernel-space, a per-type
value seems much more appropriate.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: implement SET_REPORT

2014-08-25T08:28:08+00:00

We so far lacked support for hid_hw_raw_request(..., HID_REQ_SET_REPORT);
Add support for it and simply forward the request to user-space. Note that
SET_REPORT is synchronous, just like GET_REPORT, even though it does not
provide any data back besides an error code.

If a transport layer does SET_REPORT asynchronously, they can just ACK it
immediately by writing an uhid_set_report_reply to uhid.

This patch re-uses the synchronous uhid-report infrastructure to query
user-space. Note that this means you cannot run SET_REPORT and GET_REPORT
in parallel. However, that has always been a restriction of HID and due to
its blocking nature, this is just fine. Maybe some future transport layer
supports parallel requests (very unlikely), however, until then lets not
over-complicate things and avoid request-lookup-tables.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: rename uhid_raw_request to uhid_hid_raw_request

2014-08-25T08:28:08+00:00

We use strict prefixed in uhid.c:
  uhid_char_*: implement char-dev callbacks
  uhid_dev_*: implement uhid device management and runtime
  uhid_hid_*: implement hid-dev callbacks

uhid_raw_request is an hid callback, so rename it to uhid_hid_raw_request.

While at it, move it closer to it's extracted helpers and keep the same
order as in "struct hid_driver".

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: add ABI compatible UHID_GET_REPORT replacing UHID_FEATURE

2014-08-25T08:28:07+00:00

The old hdev->hid_get_raw_report() was broken by design. It was never
clear what kind of HW request it should trigger. Benjamin fixed that with
the core HID cleanup, though we never really adjusted uhid.

Unfortunately, our old UHID_FEATURE command was modelled around the broken
hid_get_raw_report(). We converted it silently to the new GET_REPORT and
nothing broke. Make this explicit by renaming UHID_FEATURE to
UHID_GET_REPORT and UHID_FEATURE_ANSWER to UHID_GET_REPORT_REPLY.

Note that this is 100% ABI compatible to UHID_FEATURE. This is just a
rename. But we have to keep the old definitions around to not break API.

>From now on, UHID_GET_REPORT must trigger a GET_REPORT request on the
user-space hardware layer. All the ambiguity due to the weird "feature"
name should be gone now.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: invert report_done and make non-atomic

2014-08-25T08:28:07+00:00

All accesses to @report_done are protected by qlock (or report-contexts).
No need to use an atomic.

While at it, invert the logic and call it "report_running". This is
similar to the uhid->running field and easier to read.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: turn report_id into u32

2014-08-25T08:28:06+00:00

All accesses to @report_id are protected by @qlock. No need to use an
atomic.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina