wacom_setup_numbered_buttons() is not used outside of wacom_wac.c,
make it static.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This device is pad (buttons) only, there is no stylus or touch. Up to
five remotes can pair with the device's associated USB dongle.
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Prior to this commit, numbered button bit setting was done separately
for each device type in wacom_setup_pad_capabilities(). Here we add a
numbered_buttons property to the wacom_features struct and extract the
repeated bit setting code to a new function:
wacom_settup_numbered_buttons().
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Looks like 0x8882 needs the same quirk than 0x8883.
Given that both devices claim they are "TPV OpticalTouchScreen" rename
the 0x8883 to add its PID in the #define.
Reported-by: NBlaine Lee <blaine.j.lee@medtronic.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.

Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason.  The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.

The check for HID_NO_BANDWIDTH was inverted.  Fix was simple.

Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Enabling irq wake could potentially fail and calling disable_irq_wake
after a failed call to enable_irq_wake could result in an unbalanced irq
warning. This patch warns if enable_irq_wake fails and avoids other
potential issues caused by calling disable_irq_wake on resume after
enable_irq_wake failed during suspend.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The current generation of "Intuos" tablets (i.e. INTUOSHT) report touch
width and height data just like the "Intuos Pro" do. This commit changes
the code to allow these tablets to use the appropriate codepath instead
of the one intended for Intuos5/Bamboo.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This gamepad advertise 5 absolute axis while 4 are actually used.
The second Z axis shows some garbage, so it has to be ignored by HID.
The first Z axis and the Rz one are actually Rx and Ry. Remap them.

We could also just remap and ignore the axis in .input_mapping(). I
went ahead with .report_fixup() first, so here it is.
Reported-by: NOrivej Desh <orivej@gmx.fr>
Tested-by: NOrivej Desh <orivej@gmx.fr>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Don't relay a middle button press to userspace until release, and then
only if there was no scroll events inbetween. This is closer to what
Xorg's wheel emulation does, and avoids spurious middle-click pastes.
Signed-off-by: NJamie Lentin <jm@lentin.co.uk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJamie Lentin <jm@lentin.co.uk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJamie Lentin <jm@lentin.co.uk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Unlike other IRQ functions, 'wacom_pl_irq' uses the second element of
the 'tool' array to store information about its single pen. This makes
the function more difficult to understand (since it doesn't follow the
general pattern of other IRQ functions) and prevents the possibility of
refactoring how pen state is stored.

This patch rewrites 'wacom_pl_irq' to follow the usual IRQ conventions,
including storing tool type in 'tool[0]' and implicitly tracking prox
with the 'id[0]' variable.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The 'wacom_wireless_work' function does not recalculate the tablet's
resolution, causing the value contained in the 'features' struct to
always be reported to userspace. This value is valid only for the pen
interface, meaning that the value will be incorrect for the touchpad (if
present). This in particular causes problems for libinput which relies
on the reported resolution being correct.

This patch adds the necessary calls to recalculate the resolution for
each interface. This requires a little bit of code shuffling since both
the 'wacom_set_default_phy' and 'wacom_calculate_res' are declared below
their new first point of use in 'wacom_wireless_work'.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As an extension of aef3156d, there is no sense in repeatedly calling the
'wacom_set_report' and 'wacom_get_report' functions if they return an
error. Getting an error from them implies that the device is out to lunch:
either a hard error code was returned or repeated attempts at recovering
from a "soft" error all failed. In either case, doing even more retries is
not likely to resolve whatever is wrong.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As an extension of aef3156d, there is no sense in repeatedly calling the
'wacom_set_report' and 'wacom_get_report' functions if they return an
error. Getting an error from them implies that the device is out to lunch:
either a hard error code was returned or repeated attempts at recovering
from a "soft" error all failed. In either case, doing even more retries is
not likely to resolve whatever is wrong.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Avoid any chance of format string expansion when calling dev_set_name.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

Remove early dereference of a pointer that is checked later in the code.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAllen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

A plain 32 bit integer will overflow for values over 4GiB.

Change the plain integer size to the appropriate size type in
ntb_set_mw.  Change the type of the size parameter and two local
variables used for size.

Even if there is no overflow, a size of zero is invalid here.
Reported-by: NJuyoung Jung <jjung@micron.com>
Signed-off-by: NAllen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

Schedule to receive on QP link up, to make sure that the doorbell is
properly cleared for interrupts.
Signed-off-by: NAllen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

When the remote side is not up, we do not have all the context for the
transport, and that causes NULL ptr access. Have the debugfs reads check
to see if transport is up before we make access.
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

ntb_netdev is allowing the link to come up even when -ENOMEM is returned
from ntb_transport_rx_enqueue.  Fix to cover all possible errors.
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

Currently the debugfs does not have files for all NTB transport queue
pairs.  When there are multiple NTBs present in a system, the QP names
of the last transport clobber the names of previously added transport
QPs.  Only the last added QPs can be observed via debugfs.

Create a directory per NTB transport to associate the QPs with that
transport.  Name the directory the same as the PCI device.
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

It was possible for a synchronous update of the RX index in the error
case to get ahead of the asynchronous RX index update in the normal
case.  Change the RX processing to preserve an RX completion order.

There were two error cases.  First, if a buffer is not present to
receive data, there would be no queue entry to preserve the RX
completion order.  Instead of dropping the RX frame, leave the RX frame
in the ring.  Schedule RX processing when RX entries are enqueued, in
case there are RX frames waiting in the ring to be received.

Second, if a buffer is too small to receive data, drop the frame in the
ring, mark the RX entry as done, and indicate the error in the RX entry
length.  Check for a negative length in the receive callback in
ntb_netdev, and count occurrences as rx_length_errors.
Signed-off-by: NAllen Hubbe <Allen.Hubbe@emc.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

It is no need to check the packet[0] for sanity check when doing
elantech_packet_check_v4() function for fw_version = 0x470f01 touchpad.

Signed-off by: Duson Lin <dusonlin@emc.com.tw>
Reviewed-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

remove_one() was not incrementing the key for the beginning of the
range, so not all entries were being removed.  This resulted in
discards that were not unmapping all blocks.

Fixes: 4ec331c3 ("dm btree: add dm_btree_remove_leaves()")
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

In

commit 99264a61
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 15 19:34:43 2015 +0200

    drm/vblank: Fixup and document timestamp update/read barriers

I've switched vblank->count from atomic_t to unsigned long and
accidentally created an integer comparison bug in
drm_vblank_count_and_time since vblanke->count might overflow the u32
local copy and hence the retry loop never succeed.

Fix this by consistently using u32.

Cc: Michel Dänzer <michel@daenzer.net>
Reported-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.

The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new);
since the struct config block won't shrink in newer versions it should
be harmless to copy the maximum known size in such cases, so that's
what we do, but emitting the warning is probably sensible anyway.

In the longer run it might make sense to modify the parser code to
use a version/feature mapping, rather than hardcoding things like this,
but for now the variants are fairly managable.

This fixes a regression introduced in

commit 90e4f159
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Mar 25 18:45:58 2015 +0200

    drm/i915: Fix the VBT child device parsing for BSW

since we're hitting a DRM_ERROR on older platforms with this.

v2: Stricter size checks
Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com>
[danvet: Fixup format string.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spec requires a device reset during cleanup, so do it and avoid warn
in virtio core. And detach unused buffers to avoid memory leak.
Signed-off-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The fw_version and feature_verion should be set correctly when the
firmwares are loaded by SMU on Tonga/Carrzio/Iceland
Signed-off-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Signed-off-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Expose feature version to user space for RLC/MEC/MEC2 ucode as well

v2: fix coding style
Signed-off-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

gfx_v7_0_print_status contains a for loop on variable queue which does
not update this variable between each iteration.  This is bug is
reported by clang while building allmodconfig LLVMLinux on x86_64:

    drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5126:19: error: variable
    'queue' used in loop condition not modified in loop body
    [-Werror,-Wloop-analysis]
                for (queue = 0; queue < 8; i++) {
                                ^~~~~

Fix this by incrementing variable queue instead of i in this loop.
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Always set num_rbs to 2 for CZ.  The 1 RB parts are often harvest
configs.  The will get sorted out in mesa when we program
PA_SC_RASTER_CONFIG[_1].
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix following:
[    8.862274] ERROR: Bad of_node_put() on /ocp/i2c@48070000/twl@48/audio
[    8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175
[    8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    8.883514] [<c00159e0>] (unwind_backtrace) from [<c0012488>] (show_stack+0x10/0x14)
[    8.891693] [<c0012488>] (show_stack) from [<c05cb810>] (dump_stack+0x78/0x94)
[    8.899322] [<c05cb810>] (dump_stack) from [<c02cfd5c>] (kobject_release+0x68/0x7c)
[    8.907409] [<c02cfd5c>] (kobject_release) from [<bf0040c4>] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra])
[    8.917877] [<bf0040c4>] (twl4030_vibra_probe [twl4030_vibra]) from [<c03816ac>] (platform_drv_probe+0x48/0x90)
[    8.928497] [<c03816ac>] (platform_drv_probe) from [<c037feb4>] (really_probe+0xd4/0x238)
[    8.937103] [<c037feb4>] (really_probe) from [<c0380160>] (driver_probe_device+0x30/0x48)
[    8.945678] [<c0380160>] (driver_probe_device) from [<c03801e0>] (__driver_attach+0x68/0x8c)
[    8.954589] [<c03801e0>] (__driver_attach) from [<c037ea60>] (bus_for_each_dev+0x50/0x84)
[    8.963226] [<c037ea60>] (bus_for_each_dev) from [<c037f828>] (bus_add_driver+0xcc/0x1e4)
[    8.971832] [<c037f828>] (bus_add_driver) from [<c0380b60>] (driver_register+0x9c/0xe0)
[    8.980255] [<c0380b60>] (driver_register) from [<c00097e0>] (do_one_initcall+0x100/0x1b8)
[    8.988983] [<c00097e0>] (do_one_initcall) from [<c00b8008>] (do_init_module+0x58/0x1c0)
[    8.997497] [<c00b8008>] (do_init_module) from [<c00b8cac>] (SyS_init_module+0x54/0x64)
[    9.005950] [<c00b8cac>] (SyS_init_module) from [<c000ed20>] (ret_fast_syscall+0x0/0x54)
[    9.015838] input: twl4030:vibrator as /devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:audio/input/input2

node passed to of_find_node_by_name is put inside that function and new node
is returned if found. Free returned node not already freed node.
Signed-off-by: NMarek Belisko <marek@goldelico.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

CPU fan speed going up and down on Dell Studio XPS 8100 for
unknown reasons. Without further debugging on the affected
machine, it is not possible to find the problem.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NJan C Peters <jcpeters89@gmail.com>
Cc: stable@vger.kernel.org # v4.0+, will need backport
[groeck: cleaned up description, comments]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The commit 8c7a075d
"drm/i2c: tda998x: use drm_hdmi_avi_infoframe_from_display_mode()"
also uses hdmi_avi_infoframe_pack() to create the AVI infoframe.
This function sets the checksum of the frame and this breaks
the second calculation of the checksum done in tda998x_write_if().

Fixes: 8c7a075d ("drm/i2c: tda998x: use drm_hdmi_avi_infoframe_from_display_mode()")
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Including access_ok.h causes the ia64:allmodconfig build (and maybe others)
to fail with

include/linux/unaligned/le_struct.h:6:19: error:
	redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:7:19: note:
	previous definition of 'get_unaligned_le16' was here
include/linux/unaligned/le_struct.h:26:20: error:
	redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: note:
	previous definition of 'put_unaligned_le32' was here
include/linux/unaligned/le_struct.h:31:20: error:
	redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:47:20: note:
	previous definition of 'put_unaligned_le64' was here

Include unaligned.h instead and leave it up to the architecture to decide
how to implement unaligned accesses.

Fixes: 8c4f1364 ("Staging: lustre: Use put_unaligned_le64")
Cc: Vaishali Thakkar <vthakkar1994@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An event channel bound to a CPU that was offlined may still be linked
on that CPU's queue.  If this event channel is closed and reused,
subsequent events will be lost because the event channel is never
unlinked and thus cannot be linked onto the correct queue.

When a channel is closed and the event is still linked into a queue,
ensure that it is unlinked before completing.

If the CPU to which the event channel bound is online, spin until the
event is handled by that CPU. If that CPU is offline, it can't handle
the event, so clear the event queue during the close, dropping the
events.

This fixes the missing interrupts (and subsequent disk stalls etc.)
when offlining a CPU.
Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>