kernel/linux.git, branch v5.0.20

Linux 5.0.20

2019-05-31T13:45:24+00:00

NFS: Fix a double unlock from nfs_match,get_client

2019-05-31T13:45:24+00:00

[ Upstream commit c260121a97a3e4df6536edbc2f26e166eff370ce ] Now that nfs_match_client drops the nfs_client_lock, we should be careful to always return it in the same condition: locked. Fixes: 950a578c6128 ("NFS: make nfs_match_client killable") Reported-by: syzbot+228a82b263b5da91883d@syzkaller.appspotmail.com Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin

drm/sun4i: dsi: Enforce boundaries on the start delay

2019-05-31T13:45:24+00:00

[ Upstream commit efa31801203ac2f5c6a82a28cb991c7163ee0f1d ] The Allwinner BSP makes sure that we don't end up with a null start delay or with a delay larger than vtotal. The former condition is likely to happen now with the reworked start delay, so make sure we enforce the same boundaries. Signed-off-by: Maxime Ripard Reviewed-by: Paul Kocialkowski Link: https://patchwork.freedesktop.org/patch/msgid/c9889cf5f7a3d101ef380905900b45a182596f56.1549896081.git-series.maxime.ripard@bootlin.com Signed-off-by: Sasha Levin

ice: Put __ICE_PREPARED_FOR_RESET check in ice_prepare_for_reset

2019-05-31T13:45:24+00:00

[ Upstream commit 5abac9d7e1bb9a373673811154774d4c89a7f85e ] Currently we check if the __ICE_PREPARED_FOR_RESET bit is set prior to calling ice_prepare_for_reset in ice_reset_subtask(), but we aren't checking that bit in ice_do_reset() before calling ice_prepare_for_reset(). This is not consistent and can cause issues if ice_prepare_for_reset() is called prior to ice_do_reset(). Fix this by checking if the __ICE_PREPARED_FOR_RESET bit is set internal to ice_prepare_for_reset(). Signed-off-by: Brett Creeley Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

vfio-ccw: Prevent quiesce function going into an infinite loop

2019-05-31T13:45:23+00:00

[ Upstream commit d1ffa760d22aa1d8190478e5ef555c59a771db27 ] The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we: - wait for any interrupts - flush all I/O in the workqueue - retry cio_cancel_halt_clear During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever. Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device. Suggested-by: Eric Farman Signed-off-by: Farhan Ali Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com> Reviewed-by: Eric Farman Acked-by: Halil Pasic Signed-off-by: Cornelia Huck Signed-off-by: Sasha Levin

drm/sun4i: dsi: Change the start delay calculation

2019-05-31T13:45:23+00:00

[ Upstream commit da676c6aa6413d59ab0a80c97bbc273025e640b2 ] The current calculation for the video start delay in the current DSI driver is that it is the total vertical size, minus the front porch and sync length, plus 1. This equals to the active vertical size plus the back porch plus 1. That 1 is coming in the Allwinner BSP from an variable that is set to 1. However, if we look at the Allwinner BSP more closely, and especially in the "legacy" code for the display (in drivers/video/sunxi/legacy/), we can see that this variable is actually computed from the porches and the sync minus 10, clamped between 8 and 100. This fixes the start delay symptom we've seen on some panels (vblank timeouts with vertical white stripes at the bottom of the panel). Reviewed-by: Paul Kocialkowski Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/6e5f72e68f47ca0223877464bf12f0c3f3978de8.1549896081.git-series.maxime.ripard@bootlin.com Signed-off-by: Sasha Levin

drm: Wake up next in drm_read() chain if we are forced to putback the event

2019-05-31T13:45:23+00:00

[ Upstream commit 60b801999c48b6c1dd04e653a38e2e613664264e ] After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin

drm/drv: Hold ref on parent device during drm_device lifetime

2019-05-31T13:45:23+00:00

[ Upstream commit 56be6503aab2bc3a30beae408071b9be5e1bae51 ] This makes it safe to access drm_device->dev after the parent device has been removed/unplugged. Signed-off-by: Noralf Trønnes Reviewed-by: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-2-noralf@tronnes.org Signed-off-by: Sasha Levin

drm/v3d: Handle errors from IRQ setup.

2019-05-31T13:45:23+00:00

[ Upstream commit fc22771547e7e8a63679f0218e943d72b107de65 ] Noted in review by Dave Emett for V3D 4.2 support. Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-1-eric@anholt.net Reviewed-by: Dave Emett Signed-off-by: Sasha Levin

ASoC: ti: fix davinci_mcasp_probe dependencies

2019-05-31T13:45:23+00:00

[ Upstream commit 7d7b25d05ef1c5a1a9320190e1eeb55534847558 ] The SND_SOC_DAVINCI_MCASP driver can use either edma or sdma as a back-end, and it takes the presence of the respective dma engine drivers in the configuration as an indication to which ones should be built. However, this is flawed in multiple ways: - With CONFIG_TI_EDMA=m and CONFIG_SND_SOC_DAVINCI_MCASP=y, is enabled as =m, and we get a link error: sound/soc/ti/davinci-mcasp.o: In function `davinci_mcasp_probe': davinci-mcasp.c:(.text+0x930): undefined reference to `edma_pcm_platform_register' - When CONFIG_SND_SOC_DAVINCI_MCASP=m has already been selected by another driver, the same link error appears even if CONFIG_TI_EDMA is disabled There are possibly other issues here, but it seems that the only reasonable solution is to always build both SND_SOC_TI_EDMA_PCM and SND_SOC_TI_SDMA_PCM as a dependency here. Both are fairly small and do not have any other compile-time dependencies, so the cost is very small, and makes the configuration stage much more consistent. Fixes: f2055e145f29 ("ASoC: ti: Merge davinci and omap directories") Signed-off-by: Arnd Bergmann Acked-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Sasha Levin