linux-stable.git/drivers, branch v4.4.129

HID: hidraw: Fix crash on HIDIOCGFEATURE with a destroyed device

2018-04-24T07:32:10+00:00

commit a955358d54695e4ad9f7d6489a7ac4d69a8fc711 upstream.

Doing `ioctl(HIDIOCGFEATURE)` in a tight loop on a hidraw device
and then disconnecting the device, or unloading the driver, can
cause a NULL pointer dereference.

When a hidraw device is destroyed it sets 0 to `dev->exist`.
Most functions check 'dev->exist' before doing its work, but
`hidraw_get_report()` was missing that check.

Cc: stable@vger.kernel.org
Signed-off-by: Rodrigo Rivas Costa 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Fix PCIe lane width calculation

2018-04-24T07:32:09+00:00

commit 85e290d92b4b794d0c758c53007eb4248d385386 upstream.

Two years ago I tried an AMD Radeon E8860 embedded GPU with the drm driver.
The dmesg output included driver warnings about an invalid PCIe lane width.
Tracking the problem back led to si_set_pcie_lane_width_in_smc().
The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and
ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting
value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere.
Applying the increment silenced the warnings.
The code has not changed since, so either my analysis was incorrect or the
bug has gone unnoticed. Hence submitting this as an RFC.

Acked-by: Christian König 
Acked-by: Chunming Zhou 
Signed-off-by: Paul Parsons 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

vfio/pci: Virtualize Maximum Read Request Size

2018-04-24T07:32:09+00:00

commit cf0d53ba4947aad6e471491d5b20a567cbe92e56 upstream.

MRRS defines the maximum read request size a device is allowed to
make.  Drivers will often increase this to allow more data transfer
with a single request.  Completions to this request are bound by the
MPS setting for the bus.  Aside from device quirks (none known), it
doesn't seem to make sense to set an MRRS value less than MPS, yet
this is a likely scenario given that user drivers do not have a
system-wide view of the PCI topology.  Virtualize MRRS such that the
user can set MRRS >= MPS, but use MPS as the floor value that we'll
write to hardware.

Signed-off-by: Alex Williamson 
Signed-off-by: Greg Kroah-Hartman

vfio/pci: Virtualize Maximum Payload Size

2018-04-24T07:32:09+00:00

commit 523184972b282cd9ca17a76f6ca4742394856818 upstream.

With virtual PCI-Express chipsets, we now see userspace/guest drivers
trying to match the physical MPS setting to a virtual downstream port.
Of course a lone physical device surrounded by virtual interconnects
cannot make a correct decision for a proper MPS setting.  Instead,
let's virtualize the MPS control register so that writes through to
hardware are disallowed.  Userspace drivers like QEMU assume they can
write anything to the device and we'll filter out anything dangerous.
Since mismatched MPS can lead to AER and other faults, let's add it
to the kernel side rather than relying on userspace virtualization to
handle it.

Signed-off-by: Alex Williamson 
Reviewed-by: Eric Auger 
Signed-off-by: Greg Kroah-Hartman

vfio-pci: Virtualize PCIe & AF FLR

2018-04-24T07:32:09+00:00

commit ddf9dc0eb5314d6dac8b19b1cc37c739c6896e7e upstream.

We use a BAR restore trick to try to detect when a user has performed
a device reset, possibly through FLR or other backdoors, to put things
back into a working state.  This is important for backdoor resets, but
we can actually just virtualize the "front door" resets provided via
PCIe and AF FLR.  Set these bits as virtualized + writable, allowing
the default write to set them in vconfig, then we can simply check the
bit, perform an FLR of our own, and clear the bit.  We don't actually
have the granularity in PCI to specify the type of reset we want to
do, but generally devices don't implement both PCIe and AF FLR and
we'll favor these over other types of reset, so we should generally
lineup.  We do test whether the device provides the requested FLR type
to stay consistent with hardware capabilities though.

This seems to fix several instance of devices getting into bad states
with userspace drivers, like dpdk, running inside a VM.

Signed-off-by: Alex Williamson 
Reviewed-by: Greg Rose 
Signed-off-by: Greg Kroah-Hartman

watchdog: f71808e_wdt: Fix WD_EN register read

2018-04-24T07:32:08+00:00

commit 977f6f68331f94bb72ad84ee96b7b87ce737d89d upstream.

F71808FG_FLAG_WD_EN defines bit position, not a bitmask

Signed-off-by: Igor Pylypiv 
Reviewed-by: Guenter Roeck 
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

thermal: imx: Fix race condition in imx_thermal_probe()

2018-04-24T07:32:08+00:00

commit cf1ba1d73a33944d8c1a75370a35434bf146b8a7 upstream.

When device boots with T > T_trip_1 and requests interrupt,
the race condition takes place. The interrupt comes before
THERMAL_DEVICE_ENABLED is set. This leads to an attempt to
reading sensor value from irq and disabling the sensor, based on
the data->mode field, which expected to be THERMAL_DEVICE_ENABLED,
but still stays as THERMAL_DEVICE_DISABLED. Afher this issue
sensor is never re-enabled, as the driver state is wrong.

Fix this problem by setting the 'data' members prior to
requesting the interrupts.

Fixes: 37713a1e8e4c ("thermal: imx: implement thermal alarm interrupt handling")
Cc: 
Signed-off-by: Mikhail Lappo 
Signed-off-by: Fabio Estevam 
Reviewed-by: Philipp Zabel 
Acked-by: Dong Aisheng 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

clk: bcm2835: De-assert/assert PLL reset signal when appropriate

2018-04-24T07:32:08+00:00

commit 753872373b599384ac7df809aa61ea12d1c4d5d1 upstream.

In order to enable a PLL, not only the PLL has to be powered up and
locked, but you also have to de-assert the reset signal. The last part
was missing. Add it so PLLs that were not enabled by the FW/bootloader
can be enabled from Linux.

Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Cc: 
Signed-off-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: mvebu: armada-38x: add support for missing clocks

2018-04-24T07:32:08+00:00

commit 6a4a4595804548e173f0763a0e7274a3521c59a9 upstream.

Clearfog boards can come with a CPU clocked at 1600MHz (commercial)
or 1333MHz (industrial).

They have also some dip-switches to select a different clock (666, 800,
1066, 1200).

The funny thing is that the recovery button is on the MPP34 fq selector.
So, when booting an industrial board with this button down, the frequency
666MHz is selected (and the kernel didn't boot).

This patch add all the missing clocks.

The only mode I didn't test is 2GHz (uboot found 4294MHz instead :/ ).

Fixes: 0e85aeced4d6 ("clk: mvebu: add clock support for Armada 380/385")
Cc:  # 3.16.x: 9593f4f56cf5: clk: mvebu: armada-38x: add support for 1866MHz variants
Cc:  # 3.16.x

Signed-off-by: Richard Genoud 
Acked-by: Gregory CLEMENT 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: mvebu: armada-38x: add support for 1866MHz variants

2018-04-24T07:32:08+00:00

commit 9593f4f56cf5d1c443f66660a0c7f01de38f979d upstream.

The Linksys WRT3200ACM CPU is clocked at 1866MHz. Add 1866MHz to the
list of supported CPU frequencies. Also update multiplier and divisor
for the l2clk and ddrclk.

Noticed by the following warning:
[    0.000000] Selected CPU frequency (16) unsupported

Signed-off-by: Ralph Sennhauser 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman