Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
to an unsigned type, sign-extension rules can cause the value of
wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
set if the highest bit of "value" was set.

This can cause problems for Tablet PC devices which use AES sensors and the
xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
serial number of '0' while the pen is entering or leaving proximity. The
xf86-input-wacom driver ignores events with a serial number of '0' since it
cannot match them up to an in-use tool.  To ensure the xf86-input-wacom driver
does not ignore the final out-of-proximity event, the kernel does not send
MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
sent to userspace, causing xf86-input-wacom to ignore the event. If the event
was the final out-of-prox event, then xf86-input-wacom may remain in a state
where it believes the pen is in proximity and refuses to allow other devices
under its control (e.g. the touchscreen) to move the cursor.

It should be noted that EMR devices and devices which use both the
HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
be immune to this issue. It appears only AES devices are affected.

Fixes: f85c9dc6 ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable@vger.kernel.org
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit 279967a6.

Multiple regressions [1] [2] [3] have been reported. The hid-rmi
support would have to fixed and redone in 4.11+.

[1] http://lkml.kernel.org/r/b79b88c8-770a-13f6-5668-c3a94254e5e0@gmail.com
[2] http://lkml.kernel.org/r/375e67b5-2cb8-3491-1d71-d8650d6e9451@gmail.com
[3] https://bugzilla.kernel.org/show_bug.cgi?id=195287Reported-by: NCameron Gutman <aicommander@gmail.com>
Reported-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: NLorenzo J. Lucchini <ljlbox@tiscali.it>
Reported-by: NThorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This device has a different vendor id but responds to initialization.
Signed-off-by: NXiaolei Yu <dreifachstein@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit a544c619 ("HID: wacom: do not attempt to switch mode
while in probe") introduces delayed work for querying (setting the
mode) on all tablets. Bamboo Touch (056a:00d0) has a ghost
interface which claims to be a pen device. Though this device can
be removed, we have to set the mode on the ghost pen interface
before we remove it. After the aforementioned delay was introduced
the device was being removed before the mode setting could be
executed.
Signed-off-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A previous commit (below) adds a check for already probed interfaces to
Wacom's matching heuristic. Unfortunately this causes the Bamboo Pen
(CTL-460) to match itself to its 'ghost' touch interface. After
subsequent changes to the driver this match to the ghost causes the
kernel to crash. This patch avoids calling wacom_add_shared_data()
for the BAMBOO_PEN's ghost touch interface.

Fixes: 41372d5d ("HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC")
Cc: stable <stable@vger.kernel.org>     # 4.9
Signed-off-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is a new clone of the XIN MO arcade controller which has same issue with
out of range like the original.  This fix will solve the issue where 2
directions on the joystick are not recognized by the new THT 2P arcade
controller with device ID 0x75e1.  In details the new device ID is added the
hid-id list and the hid-xinmo source code.
Signed-off-by: NPeter Stein <peter@stuntstein.dk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit f85c9dc6 ("Support tool ID and additional tool types") introduced mouse
and lens cursor tools to generic codepath, which covers both display (direct)
and opaque tablets (indirect devices). However, mouse and lens cursor tools are
only provided for opaque tablets. This patch ignores mouse and lens cursor tools
if the device is a display tablet.
Signed-off-by: NPing Cheng <ping.cheng@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This mouse sold by Corsair as Scimitar PRO RGB defines two consecutive
Logical Minimum items in its Application (Consumer.0001) report making
it non parseable. This patch fixes the report descriptor overriding
byte 77 in rdesc from 0x16 (Logical Minimum with 16 bits value) to 0x26
(Logical Maximum with 16 bits value).
Signed-off-by: NOscar Campos <oscar.campos@member.fsf.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add quirks for several corsair gaming devices to avoid long delays on
report initialization

Supported devices:

 - Corsair K65RGB Rapidfire Gaming Keyboard
 - Corsair K70RGB Rapidfire Gaming Keyboard
 - Corsair Scimitar Pro RGB Gaming Mouse
Signed-off-by: NOscar Campos <oscar.campos@member.fsf.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 5b779fc5 introduces the manual release of resources in wacom_remove() as
an addition to the driver's use of devm.  The EKR resources can only be
released through wacom_remote_destroy_one() so we skip the manual release for
it.

Fixes: 5b779fc5 ("HID: wacom: release the resources before leaving despite devm")
Signed-off-by: NAaron Armstrong Skomra <skomra@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The features struct for the second gen Intuos Pro uses the wrong constant for
the resolution. This fix is for commit 4922cd26.

Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Signed-off-by: NAaron Armstrong Skomra <skomra@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When a user connects a DS4 twice using USB and BT, we reject the
second device connection after the setup work. We then perform
a cleanup, but during cleanup we are not removing the touchpad
device. This leads to leakage of an input device, which we would
never remove. It can likely result into a kernel oops as well
when the touchpad evdev node is accessed and the underlaying HID
device has been removed from the system.

[jkosina@suse.cz: added stable annotation]
Fixes: ac797b95 ("HID: sony: Make the DS4 touchpad a separate device")
Cc: stable@vger.kernel.org
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for media keys on the keyboard that comes with the
Asus V221ID and ZN241IC All In One computers.

The keys to support here are WLAN, BRIGHTNESSDOWN and BRIGHTNESSUP.

This device is not visibly branded as Chicony, and the USB Vendor ID
suggests that it is a JESS device. However this seems like the right place
to put it: the usage codes are identical to the currently supported
devices, and this driver already supports the ASUS AIO keyboard AK1D.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 279967a6 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
unconditionally switches over handling of all Synaptics touchpads to hid-rmi
(to make use of extended features of the HW); in case CONFIG_HID_RMI is
disabled though this renders the touchpad unusable, as the

	HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)

match doesn't exist and generic/multitouch doesn't bind to it either (due
to hid group mismatch).

Fix this by switching over to hid-rmi only if it has been actually built.

Fixes: 279967a6 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Declare device_type structure as const as it is only stored in the
type field of a device structure. This field is of type const, so add
const to the declaration of device_type structure.

File size before: drivers/hid/intel-ish-hid/ishtp/bus.o
   text	   data	    bss	    dec	    hex	filename
   4260	    336	     16	   4612	   1204 hid/intel-ish-hid/ishtp/bus.o

File size after: drivers/hid/intel-ish-hid/ishtp/bus.o
   text	   data	    bss	    dec	    hex	filename
   4324	    272	     16	   4612	   1204 hid/intel-ish-hid/ishtp/bus.o
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The prox/range bits included in the Bluetooth reports from the Intuos Pro
were being ignored, leading to two issues. Firstly, the pen would never
announce a BTN_TOOL_PEN event with value 0, leaving userspace to believe
the pen was always active. Secondly, the driver would continue to send
events for data while the packet's "prox" bit was clear. This can lead
to sudden incorrect pointer jumps if the pen is slowly moved away from
the tablet surface.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NPing Cheng <ping.cheng@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

For ISH resume, there are two paths, they need different way to handle: one
where ISH is not powered off, in that case a simple resume message is enough,
in other case we need a reset sequence.

We can use ISH FW status to distinguish those two cases and handle them
properly.
Signed-off-by: NEven Xu <even.xu@intel.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The LG Melfas touchscreen has a bad firmware where it declares the Contact ID
field as constant while it shouldn't. This messes up the autodetection and the
reporting of the events by hid-multitouch given that hid-input ignores constant
fields.

The autodetection is simply worked around by manually adding the device to
hid_have_special_driver[].

The processing of the events requires either a report fixup, or some specific
case handling. Given that the report fixup would require to basically rewrite
all the report descriptor, I went for the programatic way of fixing that after
the report descriptors are loaded.

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

Non-generic devices have numbered_buttons set for both pen and
touch interfaces by default. The actual number of buttons on the
interface is normally manually decided later, which is different
from what those HID generic devices are processed, where number
of buttons are directly retrieved from HID descriptors.

This patch adds the missed HID_GENERIC check and moves the statement
to wacom_setup_pad_input_capabilities since it's not a quirk anymore.
Signed-off-by: NPing Cheng <ping.cheng@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In case of a zero-length report, the gpio direction_input callback would
currently return success instead of an errno.

Fixes: 1ffb3c40 ("HID: cp2112: make transfer buffers DMA capable")
Cc: stable <stable@vger.kernel.org>     # 4.9
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A recent commit fixing DMA-buffers on stack added a shared transfer
buffer protected by a spinlock. This is broken as the USB HID request
callbacks can sleep. Fix this up by replacing the spinlock with a mutex.

Fixes: 1ffb3c40 ("HID: cp2112: make transfer buffers DMA capable")
Cc: stable <stable@vger.kernel.org>	# 4.9
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

With NOGET quirk Logitech F510 is now fully workable in dinput mode including
rumble effects (according to fftest).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117091

[jkosina@suse.cz: fix patch format]
Signed-off-by: NArdinartsev Nikita <ardinar23@gmail.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Quirking the following AMI USB device with ALWAYS_POLL fixes an AMI
virtual keyboard and mouse from not responding and timing out when
it is attached to a ppc64el Power 8 system and when we have some
rapid open/closes on the mouse device.

 usb 1-3: new high-speed USB device number 2 using xhci_hcd
 usb 1-3: New USB device found, idVendor=046b, idProduct=ff01
 usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-3: Product: Virtual Hub
 usb 1-3: Manufacturer: American Megatrends Inc.
 usb 1-3: SerialNumber: serial
 usb 1-3.3: new high-speed USB device number 3 using xhci_hcd
 usb 1-3.3: New USB device found, idVendor=046b, idProduct=ff31
 usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-3.3: Product: Virtual HardDisk Device
 usb 1-3.3: Manufacturer: American Megatrends Inc.
 usb 1-3.4: new low-speed USB device number 4 using xhci_hcd
 usb 1-3.4: New USB device found, idVendor=046b, idProduct=ff10
 usb 1-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-3.4: Product: Virtual Keyboard and Mouse
 usb 1-3.4: Manufacturer: American Megatrends Inc.

With the quirk I have not been able to trigger the issue with
half an hour of saturation soak testing.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 025bcc15 performed cleanup work on the 'wacom_pl_irq' function, making
it follow the standards used in the rest of the codebase. The change
unintiontionally allowed the function to send input events from reports
that are not marked as being in prox. This can cause problems as the
report values for X, Y, etc. are not guaranteed to be correct. In
particular, occasionally the tablet will send a report with these values
set to zero. If such a report is received it can caus an unexpected jump
in the XY position.

This patch surrounds more of the processing code with a proximity check,
preventing these zeroed reports from overwriting the current state. To
be safe, only the tool type and ABS_MISC events should be reported when
the pen is marked as being out of prox.

Fixes: 025bcc15 ("HID: wacom: Simplify 'wacom_pl_irq'")
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for the LEDs around the mode switch to the generic code path in
support of the second generation Intuos Pro.
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The second generation Intuos Pro is the first device in the generic codepath
which has a touchswitch. We utilize a flag in wacom_shared in order to report
this switch event received from the pad on the touch input.
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add vendor defined touch to support the second generation Intuos Pro.
Previously all generic Wacom devices used true HID to report their touch.
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for the touchring to the generic code path in support of the second
generation Intuos Pro.

We also add checks for usage->type to ensure that we handle the usage before we
report it, or change the inrange_state based on it.
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Input_event_flag duplicates the information we track in
wacom_wac->hid_data.inrange_state for the pad.
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In addition to its USB interface, the second-generation Intuos Pro
includes a Bluetooth radio that offers two pairing interfaces: classic
and low-energy. The classic interface functions just like the earlier
Bluetooth-enabled Intuos4 and Graphire4 tablets, appearing as a HID device
that our driver can work with. The low-energy interface is intented to
be used by userspace applications that make use of its paper-to-digital
capabilities.

Despite the USB interface using Wacom's new vendor-defined HID usages,
the Bluetooth interface provides us with useless black-box "blob"
report descriptors like past devices. We thus have to explicitly add
support for the PIDs and reports used.

These devices pack a /lot/ of information into a single Bluetooth
input report. Each report contains up to seven snapshots of the pen
state, four snapshots of the touch state (of five touches each), pad
state, and battery data. Thankfully this isn't too hard for the driver
to report -- it just takes a fair amount of code to extract!
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Centralize our definition of report IDs by moving those for device commands
into wacom_wac.h alongside those for input reports.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There no reason a Bluetooth device with the appropriate HID descriptor couldn't
be used through the HID_GENERIC codepath in the future. Ensure that the driver
attempts to bind to these devices.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Intuos Pro seems to not like when we set the features right after
being powered up. Instead of waiting during probe, we can schedule the
switch mode and LED control in a deferred worker so that we don't have the
5 secs of delay from USB when the device is not accessible.

The USB timeout delays were really a pain because if you happen to unplug
the tablet while it is still waiting, you are just adding 5 second timeouts
to the USB stack. Which means that a new plug of the same tablet will also
gets delayed, and will also attempt to access the hardware while in
.probe(). So the tablet doesn't appear in the dmesg, the user unplug/replug
it to make it appearing... and so on so forth.

Really, this is for the best :)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When the LED class gets removed, it actually tries to reset the LED.
However, the device being disconnected, the set_report fails.

Previously, the attempt to cut lose this last event was through unsetting
the HID drvdata, but it was not working properly. Simply reset the LED
groups to NULL makes a more efficient solution.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In the general case, the resources are properly released by devm without
needing to do anything. However, when unplugging the wireless receiver,
the kernel segfaults from time to time while calling devres_release_all().

I think in that case the resources attempt to access hid_get_drvdata(hdev)
which has been set to null while leaving wacom_remove().
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Removes trailing whitespace in hid-core.c and usbhid/hid-quirks.c
Signed-off-by: NDennis Chen <barracks510@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Nearly identical to the previous set of patches related to Microsoft
Surface Keyboards.

Removes Surface Pro 3 generation TypeCover support from hid-microsoft
so proper multitouch data can be reported from the touchpad.
Signed-off-by: NDennis Chen <barracks510@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 345857bb ("HID: wacom: generic: Add support for sensor offsets") included
a change to the operation and location of the call to 'wacom_add_shared_data'
in 'wacom_parse_and_register'. The modifications included moving it higher up
so that it would occur before the call to 'wacom_retrieve_hid_descriptor'. This
was done to prevent a crash that would have occured when the report containing
tablet offsets was fed into the driver with 'wacom_hid_report_raw_event'
(specifically: the various 'wacom_wac_*_report' functions were written with the
assumption that they would only be called once tablet setup had completed;
'wacom_wac_pen_report' in particular dereferences 'shared' which wasn't yet
allocated).

Moving the call to 'wacom_add_shared_data' effectively prevented the crash but
also broke the sibiling detection code which assumes that the HID descriptor
has been read and the various device_type flags set.

To fix this situation, we restore the original 'wacom_add_shared_data'
operation and location and instead implement an alternative change that can
also prevent the crash. Specifically, we notice that the report functions
mentioned above expect to be called only for input reports.  By adding a check,
we can prevent feature reports (such as the offset report) from
causing trouble.

Fixes: 345857bb ("HID: wacom: generic: Add support for sensor offsets")
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Tested-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.

Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than necessary.

Fixes: 6f78193e ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.

Note that the macro-mode buffer was larger than necessary.

Fixes: 6f78193e ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>