linux-stable.git/drivers, branch v5.2.3

dm bufio: fix deadlock with loop device

2019-07-26T07:11:11+00:00

commit bd293d071ffe65e645b4d8104f9d8fe15ea13862 upstream.

When thin-volume is built on loop device, if available memory is low,
the following deadlock can be triggered:

One process P1 allocates memory with GFP_FS flag, direct alloc fails,
memory reclaim invokes memory shrinker in dm_bufio, dm_bufio_shrink_scan()
runs, mutex dm_bufio_client->lock is acquired, then P1 waits for dm_buffer
IO to complete in __try_evict_buffer().

But this IO may never complete if issued to an underlying loop device
that forwards it using direct-IO, which allocates memory using
GFP_KERNEL (see: do_blockdev_direct_IO()).  If allocation fails, memory
reclaim will invoke memory shrinker in dm_bufio, dm_bufio_shrink_scan()
will be invoked, and since the mutex is already held by P1 the loop
thread will hang, and IO will never complete.  Resulting in ABBA
deadlock.

Cc: stable@vger.kernel.org
Signed-off-by: Junxiao Bi 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dm thin metadata: check if in fail_io mode when setting needs_check

2019-07-26T07:11:11+00:00

commit 54fa16ee532705985e6c946da455856f18f63ee1 upstream.

Check if in fail_io mode at start of dm_pool_metadata_set_needs_check().
Otherwise dm_pool_metadata_set_needs_check()'s superblock_lock() can
crash in dm_bm_write_lock() while accessing the block manager object
that was previously destroyed as part of a failed
dm_pool_abort_metadata() that ultimately set fail_io to begin with.

Also, update DMERR() message to more accurately describe
superblock_lock() failure.

Cc: stable@vger.kernel.org
Reported-by: Zdenek Kabelac 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-07-26T07:11:11+00:00

commit 885bd765963b42c380db442db7f1c0f2a26076fa upstream.

After issuing a PHY_START request to the QMP, the hardware documentation
states that the software should wait for the PCS_READY_STATUS to become
1.

With the introduction of commit c9b589791fc1 ("phy: qcom: Utilize UFS
reset controller") an additional 1ms delay was introduced between the
start request and the check of the status bit. This greatly increases
the chances for the hardware to actually becoming ready before the
status bit is read.

The result can be seen in that UFS PHY enabling is now reported as a
failure in 10% of the boots on SDM845, which is a clear regression from
the previous rare/occasional failure.

This patch fixes the "break condition" of the poll to check for the
correct state of the status bit.

Unfortunately PCIe on 8996 and 8998 does not specify the mask_pcs_ready
register, which means that the code checks a bit that's always 0. So the
patch also fixes these, in order to not regress these targets.

Fixes: 73d7ec899bd8 ("phy: qcom-qmp: Add msm8998 PCIe QMP PHY support")
Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
Cc: stable@vger.kernel.org
Cc: Evan Green 
Cc: Marc Gonzalez 
Cc: Vivek Gautam 
Reviewed-by: Evan Green 
Reviewed-by: Niklas Cassel 
Reviewed-by: Marc Gonzalez 
Tested-by: Marc Gonzalez 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Greg Kroah-Hartman

net: mvmdio: allow up to four clocks to be specified for orion-mdio

2019-07-26T07:11:11+00:00

commit 4aabed699c400810981d3dda170f05fa4d782905 upstream.

Allow up to four clocks to be specified and enabled for the orion-mdio
interface, which are required by the Armada 8k and defined in
armada-cp110.dtsi.

Fixes a hang in probing the mvmdio driver that was encountered on the
Clearfog GT 8K with all drivers built as modules, but also affects other
boards such as the MacchiatoBIN.

Cc: stable@vger.kernel.org
Fixes: 96cb43423822 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Reviewed-by: Andrew Lunn 
Signed-off-by: Josua Mayer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out

2019-07-26T07:11:10+00:00

commit 5b933e28d8b1fbdc7fbac4bfc569f3b152c3dd59 upstream.

There is no audio_pll2_clk registered, it should be audio_pll2_out.

Cc: 
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

usb: Handle USB3 remote wakeup for LPM enabled devices correctly

2019-07-26T07:11:10+00:00

commit e244c4699f859cf7149b0781b1894c7996a8a1df upstream.

With Link Power Management (LPM) enabled USB3 links transition to low
power U1/U2 link states from U0 state automatically.

Current hub code detects USB3 remote wakeups by checking if the software
state still shows suspended, but the link has transitioned from suspended
U3 to enabled U0 state.

As it takes some time before the hub thread reads the port link state
after a USB3 wake notification, the link may have transitioned from U0
to U1/U2, and wake is not detected by hub code.

Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup
handling

This patch should be added to stable kernels since 4.13 where LPM was
kept enabled during suspend/resume

Cc:  # v4.13+
Signed-off-by: Lee, Chiasheng 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

intel_th: msu: Fix single mode with disabled IOMMU

2019-07-26T07:11:10+00:00

commit 918b8646497b5dba6ae82d4a7325f01b258972b9 upstream.

Commit 4e0eaf239fb3 ("intel_th: msu: Fix single mode with IOMMU") switched
the single mode code to use dma mapping pages obtained from the page
allocator, but with IOMMU disabled, that may lead to using SWIOTLB bounce
buffers and without additional sync'ing, produces empty trace buffers.

Fix this by using a DMA32 GFP flag to the page allocation in single mode,
as the device supports full 32-bit DMA addressing.

Signed-off-by: Alexander Shishkin 
Fixes: 4e0eaf239fb3 ("intel_th: msu: Fix single mode with IOMMU")
Reviewed-by: Andy Shevchenko 
Reported-by: Ammy Yi 
Cc: stable 
Link: https://lore.kernel.org/r/20190621161930.60785-4-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

intel_th: msu: Remove set but not used variable 'last'

2019-07-26T07:11:10+00:00

commit 9800db282dff675dd700d5985d90b605c34b5ccd upstream.

Commit aad14ad3cf3a ("intel_th: msu: Add current window tracking") added
the following gcc warning:

> drivers/hwtracing/intel_th/msu.c: In function msc_win_switch:
> drivers/hwtracing/intel_th/msu.c:1389:21: warning: variable last set but
> not used [-Wunused-but-set-variable]

Fix it by removing the variable.

Signed-off-by: YueHaibing 
Fixes: aad14ad3cf3a ("intel_th: msu: Add current window tracking")
Reviewed-by: Andy Shevchenko 
Signed-off-by: Alexander Shishkin 
Cc: stable 
Link: https://lore.kernel.org/r/20190621161930.60785-3-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

mtd: spinand: read returns badly if the last page has bitflips

2019-07-26T07:11:09+00:00

commit b83408b580eccf8d2797cd6cb9ae42c2a28656a7 upstream.

In case of the last page containing bitflips (ret > 0),
spinand_mtd_read() will return that number of bitflips for the last
page while it should instead return max_bitflips like it does when the
last page read returns with 0.

Signed-off-by: Weixiong Liao 
Reviewed-by: Boris Brezillon 
Reviewed-by: Frieder Schrempf 
Cc: stable@vger.kernel.org
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Signed-off-by: Miquel Raynal 
Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: mtk: Correct low level time calculation of r/w cycle

2019-07-26T07:11:09+00:00

commit e1884ffddacc0424d7e785e6f8087bd12f7196db upstream.

At present, the flow of calculating AC timing of read/write cycle in SDR
mode is that:
At first, calculate high hold time which is valid for both read and write
cycle using the max value between tREH_min and tWH_min.
Secondly, calculate WE# pulse width using tWP_min.
Thridly, calculate RE# pulse width using the bigger one between tREA_max
and tRP_min.

But NAND SPEC shows that Controller should also meet write/read cycle time.
That is write cycle time should be more than tWC_min and read cycle should
be more than tRC_min. Obviously, we do not achieve that now.

This patch corrects the low level time calculation to meet minimum
read/write cycle time required. After getting the high hold time, WE# low
level time will be promised to meet tWP_min and tWC_min requirement,
and RE# low level time will be promised to meet tREA_max, tRP_min and
tRC_min requirement.

Fixes: edfee3619c49 ("mtd: nand: mtk: add ->setup_data_interface() hook")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Xiaolei Li 
Reviewed-by: Miquel Raynal 
Signed-off-by: Miquel Raynal 
Signed-off-by: Greg Kroah-Hartman