The basic API of rc-core used to be:

	dev = rc_allocate_device();
	dev->x = a;
	dev->y = b;
	dev->z = c;
	rc_register_device();

which is a pretty common pattern in the kernel, after the introduction of
protocol arrays the API looks something like:

	dev = rc_allocate_device();
	dev->x = a;
	rc_set_allowed_protocols(dev, RC_BIT_X);
	dev->z = c;
	rc_register_device();

There's no real need for the protocols to be an array, so change it
back to be consistent (and in preparation for the following patches).

[m.chehab@samsung.com: added missing changes at some files]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This device generates ABS_Z and ABS_RX events instead of ABS_X and
ABS_Y.
Signed-off-by: NWen-chien Jesse Sung <jesse.sung@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

hsdev is not freed in sensor_hub_probe when kasprintf inside the for
loop fails. This is because hsdev is not set to platform_data yet (to
be freed by the code in the err_no_mem label). So free the memory
explicitly in the 'if' branch, as this is the only place where this is
(and will) be needed.

Reported-by: coverity
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: srinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

These device needs to be added to the quirks list with HID_QUIRK_NOGET,
otherwise they will reset upon receiving the get input report requests.
Signed-off-by: NJohn Sung <penmount.touch@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If CONFIG_PM=n:

drivers/hid/hid-rmi.c:432: warning: ‘rmi_post_reset’ defined but not used
drivers/hid/hid-rmi.c:437: warning: ‘rmi_post_resume’ defined but not used
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When NO_IOMEM is enabled (e.g. score architecture), some drivers which
need HAS_IOMEM need notice about it, or it will report related warning:

  warning: (GPIO_SCH && GPIO_ICH && GPIO_VX855 && GPIO_RDC321X && IE6XX_WDT && RADIO_WL1273 && HID_SENSOR_HUB && MFD_NVEC) selects MFD_CORE which has unmet direct dependencies (HAS_IOMEM)
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

dyn_callback_lock is being taken from IRQ context through hid_irq_in() ->
hid_input_report() -> sensor_hub_raw_event() -> sensor_hub_get_callback(),
therefore anyone else acquiring it needs to disable IRQs to disable deadlocks.
Reported-by: NAlexander Holler <holler@ahsoftware.de>
Tested-by: NAlexander Holler <holler@ahsoftware.de>
Reported-by: NReyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

No need to pollute global namespace by thingm_fwinfo[]. Make it static.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

On Feb 17, 2014, two new usages are approved to HID usage Table 18 -
Digitizer Page:

5A	Secondary Barrel Switch		MC	16.4
5B	Transducer Serial Number	SV	16.3.1

This patch adds relevant definitions to hid/input. It also removes
outdated comments in hid.h.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Added STM sensor hub new device id. Also added this new device
in HID_SENSOR_HUB_ENUM_QUIRK to fix report descriptors.
These devices uses old FW which uses logical 0 as minimum.
In these, HID reports are not using proper collection classes.
So we need to fix report descriptors,for such devices. This
will not have any impact, if the FW uses logical 1 as minimum.
Signed-off-by: NArchana Patni <archana.patni@intel.com>
Signed-off-by: NSubramony Sesha <subramony.sesha@intel.com>
Reviewed-by: NSrinivas Pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The device which identifies itself as a "USB Keykoard" (no typo) with VID:PID
1a2c:0023 does not seem to be handling the reports initialization very well.
This results in a "usb_submit_urb(ctrl) failed: -1" message from the kernel
when connected, and a delay before its initialization.  This patch adds the
quirk for this device, which causes the delay to disappear.

[jkosina@suse.cz: remove superfluous comment and fix ordering]
Signed-off-by: NDaniel Kamil Kozar <dkk089@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add the Microsoft Surface Pro 2 Type/Touch and default device hardware ID's
Set report quirk for the device in hid-sensor-hub
Signed-off-by: NReyad Attiyat <reyad.attiyat@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add in debugfs report descriptor labels for HID Sensor Usages.
Signed-off-by: NReyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This issue was reported by coccicheck using the semantic patch
at scripts/coccinelle/api/memdup.cocci
Signed-off-by: NBenoit Taine <benoit.taine@lip6.fr>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Currently, hid-rmi drives every Synaptics product, but the touchscreens
on the Windows tablets should be handled through hid-multitouch.

Instead of providing a long list of PIDs, rely on the scan_report
capability to detect which should go to hid-multitouch, and which
should not go to hid-rmi.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=74241
https://bugzilla.redhat.com/show_bug.cgi?id=1089583Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some saitek mice implement a tristate button (for switching button mappings in
the original driver) by keeping one of three (non-physical)
buttons constantly pressed.

This breaks X and probably other userspace software.

This patch implements a quirk for the R.A.T.7 and M.M.O.7, tracking the mode
and generating presses of a single button if it changes.  Also the missing
release event is generated instantly.
Signed-off-by: NHarald Brinkmann <hbrinkmann@braincalibration.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some drivers use the first HID report in the list instead of using an
index. In these cases, validation uses ID 0, which was supposed to mean
"first known report". This fixes the problem, which was causing at least
the lgff family of devices to stop working since hid_validate_values
was being called with ID 0, but the devices used single numbered IDs
for their reports:

0x05, 0x01,         /*  Usage Page (Desktop),                   */
0x09, 0x05,         /*  Usage (Gamepad),                        */
0xA1, 0x01,         /*  Collection (Application),               */
0xA1, 0x02,         /*      Collection (Logical),               */
0x85, 0x01,         /*          Report ID (1),                  */
...

Cc: stable@vger.kernel.org
Reported-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The F11 data in the HID report contains four bits of data for w_x and the least significant bits
of x. Currently only the first three bits are being used which is resulting in small jumps in
the position data on the x axis and in the w_x data.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Acked-by: NBruno Prémont <bonbons@linux-vserver.org>
Acked-by: NJiri Kosina <jkosina@suse.cz>

In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.

Cc: Simon Wood <simon@mungewell.org>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

x_size_mm should be y_size_mm, otherwise neither the duplicated
condition nor the assignment make any sense whatsoever.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A firmware bug is present on the XPS Haswell edition which silently
split the request in two responses when the caller ask for a read of
more than 16 bytes.
The FW sends the first 16 then the 4 next, but it says that it answered
the 20 bytes in the first report.

This occurs only on the retrieving of the min/max of X and Y of the F11
function.
We only use the first 10 bytes of the Ctrl register, so we can get only
those 10 bytes to prevent the bug from happening.

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1090161Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The rmi4 spec defines some optional query registers in F11 which appear before
query 12. This patch checks for the existence of some of the lesser used queries to
 compute the location of query12 and all subsequent query registers.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Reading the partial HID Descriptor is causing a firmware lockup in some
sensor hubs. Instead of a partial read, this patch implements the
i2c hid fetch using a fixed descriptor size (30 bytes) followed by a
verification of the BCDVersion (V01.00), and value stored in
wHIDDescLength (30 Bytes) for V1.00 descriptors.

As per i2c hid spec, this is the preferred model.

From hid-over-i2c-protocol-spec-v1-0:

  There are a variety of ways a HOST may choose to retrieve
  the HID Descriptor from the DEVICE. The following is a preferred
  implementation but should not be considered the only implementation.
  A HOST may read the entire HID Descriptor in a single read by
  issuing a read for 30 Bytes to get the entire HID Descriptor
  from the DEVICE.However, the HOST is responsible for validating that

  1. The BCDVersion is V01.00 (later revisions may have different
     descriptor lengths), and

  2. The value stored in wHIDDescLength is 30 (Bytes) for V1.00
     descriptors.
Reported-by: NJoe Tijerina <joe.tijerina@st.com>
Signed-off-by: NArchana Patni <archana.patni@intel.com>
Signed-off-by: NSubramony Sesha <subramony.sesha@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The sensor hub in Lenovo Yogas needs the enumeration quirk.  I've been running
the patch for over a month with no problems, whereas the unpatched drivers
reliably mis-initialized the sensors.
Signed-off-by: NPeter F. Patel-Schneider <pfpschneider@gmail.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This touchpad seriously dislikes init reports, not only timeing out, but
also refusing to work after this.

Cc: stable@vger.kernel.org
Reported-and-tested-by: NVincent Fortier <th0ma7@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The extra seven bits are only required when allocating the report buffer.
We can not use those extra bytes for the length of the report in the
generic implementation of .request because the device might (will) refuse
the set_report command.
This has been verified on the Atmel touchpad found on the Samsung Ativ 9
plus, which uses hid-multitouch and HID over I2C. Without this fix, the
device refuses to switch to the multitouch mode, and it becomes unresponsive
from the user point of view.

Actually, this has been discussed during the initial submission of the
commit 4fa5a7f7, see
https://patchwork.kernel.org/patch/3621751/

Unfortunately, I completely forgot about it later.
Reported-by: NMatthias Bayer <thematthiasbayer@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add some missing hid usages from consumer page, add
some display brightness control usages from approved hid usage
table request HUTTR41:
http://www.usb.org/developers/hidpage/HUTRR41.pdf
and add voice command usage from approved request HUTTR45:
http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf

[jkosina@suse.cz: removed KEY_BRIGHTNESS_TOGGLE / KEY_DISPLAYTOGGLE
 conflict from hid-debug.c]
Signed-off-by: NOlivier Gay <ogay@logitech.com>
Signed-off-by: NMathieu Meisser <mmeisser@logitech.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Without this patch the 3rd party INTEC (PS3) controller will blink all
leds when user turns them off, it appears to require an extra flag set.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for setting the blink rate of the LEDs.  The Sixaxis allows control
over each individual LED, but the Dualshock 4 only has one global control for
controlling the hardware blink rate so individual colors will fall back to
software timers.

Setting the brightness cancels the blinking as per the LED class specifications.

The Sixaxis and Dualshock 4 controllers accept delays in decisecond increments
from 0 to 255 (2550 milliseconds).

The value at index 1 of the DualShock 4 USB output report must be 0xFF or the
light bar won't blink.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add an IDA id allocator to assign unique, sequential device ids to Sixaxis and
DualShock 4 controllers.

Use the device ID to initialize the Sixaxis and DualShock 4 controller LEDs to
default values.  The number or color of the controller is set relative to other
connected Sony controllers.

Set the LED class brightness values to the initial values and add the new led to
the array before calling led_classdev_register so that the correct brightness
value shows up in the LED sysfs entry.

Use explicit module init and exit functions since the IDA allocator must be
manually destroyed when the module is unloaded.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use the controller Bluetooth MAC address as the unique identifier in the
battery name string instead of the atomic integer that was used before.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Convert all of the local initialization and shutdown functions to take a
parameter type of struct sony_sc* instead of using a mix of struct sony_sc* and
struct hid_device*.

Allows for the removal of some calls to hid_get_drvdata().
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use a struct for the Sixaxis output report that uses named members to set the
report fields.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use inliners to make sure that the work queue initialization flag is always
checked and set correctly when initializing or cancelling the work queue.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

They need to have the class SERIAL.

Note: it is a Win 7 panel, not Win 8 certified.
Signed-off-by: NTomas Sokorai <tsokorai@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The blink(1) mk2 is a new version of the blink(1) USB RGB LED. The new
generation has 2 individually-controllable RGB chips.

This patch adds support for this device to the thingm driver, which
registers 3 new standard LED class instances for the second RGB chip.

Note that the 'n' (set) command does not support setting a color for a
single RGB chip, so it was changed to 'c' (fade) with a timeout of 0.
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch refactors the way the thingm driver registers a blink(1) LED.
In order to make the driver simpler and more standard, drop the "rgb"
sysfs attribute and create one instance of LED class per RGB channel.

Actually, the name of the LED class instance registered for a blink(1)
device is "blink1::ABCD", where ABCD is the last 4 chars of the serial
number. The driver now registers 3 instances per RGB chip, named
"thingmX:{red,green,blue}:ledY" where X is the hidraw minor number and Y
is the RGB chip number (as seen by the firmware).

This patch also uses work queues to defer calls with the device, which
now allows triggers to work as expected with this LED device.

Also remove the brightness structure field and the brightness_get
backend, as it is already handled by the LED class, and changes the
prefix of functions and structures to thingm_ to match the driver name.
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As for the "play" sysfs attribute, remove this other non-standard
attribute, so the driver only implements what is required to switch the
LED on and off. Thus, a fade time won't be ideal for some fast-changing
triggers.
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When the thingm driver registers an instance of LED class, it creates a
"play" sysfs attribute for this blink(1) specific feature.

Since this feature is not specific to the RGB chip but to the HID device
itself, let's remove this attribute from the LED instance and only
implement what is useful to switch on and off the LED.

This feature is still easily accessible through hidraw.
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>