BMC/Intel-BMC/linux.git/drivers/hid/uhid.c, branch v3.18

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

HID: uhid: avoid magic-numbers when setting strings

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

Avoid hard-coding the target buffer sizes and use sizeof() instead. This also makes us future-proof to buffer-extensions later on. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina

HID: uhid: avoid dangling pointers in uhid context

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

Avoid keeping uhid->rd_data and uhid->rd_size set in case uhid_dev_create2() fails. This is non-critical as we never flip uhid->running and thus never enter uhid_dev_destroy(). However, it's much nicer for debugging if pointers are only set if they point to valid data. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina

HID: uhid: forward create_req to create2_req

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

Instead of hard-coding the uhid_dev_create() function twice, copy any create_req into a create2_req structure and forward it. We allocate uhid_create_req on the stack here, but that should be fine. Unlike uhid_create2_req it is fairly small (<1KB) and it's only used temporarily to swap entries. uhid_dev_create2() doesn't access it. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina