kernel/linux.git/drivers, branch v4.14.78

IB/hfi1: Fix destroy_qp hang after a link down

2018-10-20T07:48:54+00:00

commit b4a4957d3d1c328b733fce783b7264996f866ad2 upstream. rvt_destroy_qp() cannot complete until all in process packets have been released from the underlying hardware. If a link down event occurs, an application can hang with a kernel stack similar to: cat /proc//stack quiesce_qp+0x178/0x250 [hfi1] rvt_reset_qp+0x23d/0x400 [rdmavt] rvt_destroy_qp+0x69/0x210 [rdmavt] ib_destroy_qp+0xba/0x1c0 [ib_core] nvme_rdma_destroy_queue_ib+0x46/0x80 [nvme_rdma] nvme_rdma_free_queue+0x3c/0xd0 [nvme_rdma] nvme_rdma_destroy_io_queues+0x88/0xd0 [nvme_rdma] nvme_rdma_error_recovery_work+0x52/0xf0 [nvme_rdma] process_one_work+0x17a/0x440 worker_thread+0x126/0x3c0 kthread+0xcf/0xe0 ret_from_fork+0x58/0x90 0xffffffffffffffff quiesce_qp() waits until all outstanding packets have been freed. This wait should be momentary. During a link down event, the cleanup handling does not ensure that all packets caught by the link down are flushed properly. This is caused by the fact that the freeze path and the link down event is handled the same. This is not correct. The freeze path waits until the HFI is unfrozen and then restarts PIO. A link down is not a freeze event. The link down path cannot restart the PIO until link is restored. If the PIO path is restarted before the link comes up, the application (QP) using the PIO path will hang (until link is restored). Fix by separating the linkdown path from the freeze path and use the link down path for link down events. Close a race condition sc_disable() by acquiring both the progress and release locks. Close a race condition in sc_stop() by moving the setting of the flag bits under the alloc lock. Cc: # 4.9.x+ Fixes: 7724105686e7 ("IB/hfi1: add driver files") Reviewed-by: Mike Marciniszyn Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman

i2c: rcar: handle RXDMA HW behaviour on Gen3

2018-10-20T07:48:54+00:00

commit 2b16fd63059ab9a46d473620749672dc342e1d21 upstream. On Gen3, we can only do RXDMA once per transfer reliably. For that, we must reset the device, then we can have RXDMA once. This patch implements this. When there is no reset controller or the reset fails, RXDMA will be blocked completely. Otherwise, it will be disabled after the first RXDMA transfer. Based on a commit from the BSP by Hiromitsu Yamasaki, yet completely refactored to handle multiple read messages within one transfer. Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

2018-10-20T07:48:53+00:00

commit 0ca9488193e61ec5f31a631d8147f74525629e8a upstream. On GLK NUC platforms the HDMI retiming buffer needs additional disabled time to correctly sync to a faster incoming signal. When measured on a scope the highspeed lines of the HDMI clock turn off for ~400uS during a normal resolution change. The HDMI retimer on the GLK NUC appears to require at least a full frame of quiet time before a new faster clock can be correctly sync'd. Wait 100ms due to msleep inaccuracies while waiting for a completed frame. Add a quirk to the driver for GLK boards that use ITE66317 HDMI retimers. V2: Add more devices to the quirk list V3: Delay increased to 100ms, check to confirm crtc type is HDMI. V4: crtc type check extended to include _DDI and whitespace fixes v5: Fix white spaces, remove the macro for delay. Revert the crtc type check introduced in v4. Cc: Imre Deak Cc: # v4.14+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887 Signed-off-by: Clint Taylor Tested-by: Daniel Scheller Signed-off-by: Radhakrishna Sripada Signed-off-by: Imre Deak Reviewed-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20180710200205.1478-1-radhakrishna.sripada@intel.com (cherry picked from commit 90c3e2198777aaa355b6994a31a79c636c8d4306) Signed-off-by: Rodrigo Vivi Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

staging: ccree: check DMA pool buf !NULL before free

2018-10-20T07:48:53+00:00

commit 2f7caf6b02145bd9cd9d0b56204f51a5fefe7790 upstream. If we ran out of DMA pool buffers, we get into the unmap code path with a NULL before. Deal with this by checking the virtual mapping is not NULL. Cc: stable@vger.kernel.org Signed-off-by: Gilad Ben-Yossef Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

drm/i915: Nuke the LVDS lid notifier

2018-10-20T07:48:53+00:00

commit 05c72e77ccda89ff624108b1b59a0fc43843f343 upstream. We broke the LVDS notifier resume thing in (presumably) commit e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as we no longer duplicate the current state in the LVDS notifier and thus we never resume it properly either. Instead of trying to fix it again let's just kill off the lid notifier entirely. None of the machines tested thus far have apparently needed it. Originally the lid notifier was added to work around cases where the VBIOS was clobbering some of the hardware state behind the driver's back, mostly on Thinkpads. We now have a few report of Thinkpads working just fine without the notifier. So maybe it was misdiagnosed originally, or something else has changed (ACPI video stuff perhaps?). If we do end up finding a machine where the VBIOS is still causing problems I would suggest that we first try setting various bits in the VBIOS scratch registers. There are several to choose from that may instruct the VBIOS to steer clear. With the notifier gone we'll also stop looking at the panel status in ->detect(). v2: Nuke enum modeset_restore (Rodrigo) Cc: stable@vger.kernel.org Cc: Wolfgang Draxinger Cc: Vito Caputo Cc: kitsunyan Cc: Joonas Saarinen Tested-by: Vito Caputo # Thinkapd X61s Tested-by: kitsunyan # ThinkPad X200 Tested-by: Joonas Saarinen # Fujitsu Siemens U9210 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902 References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html References: https://bugs.freedesktop.org/show_bug.cgi?id=21230 Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

HID: quirks: fix support for Apple Magic Keyboards

2018-10-20T07:48:53+00:00

Commit b6cc0ba2cbf4 (HID: add support for Apple Magic Keyboards) backported support for the Magic Keyboard over Bluetooth, but did not add the BT_VENDOR_ID_APPLE to hid_have_special_driver[] so the hid-apple driver is never loaded and Fn key does not work at all. Adding BT_VENDOR_ID_APPLE to hid_have_special_driver[] is not needed after commit e04a0442d33b (HID: core: remove the absolute need of hid_have_special_driver[]), so 4.16 kernels and newer does not need it. Fixes: b6cc0ba2cbf4 (HID: add support for Apple Magic Keyboards) Bugzilla-id: https://bugzilla.kernel.org/show_bug.cgi?id=99881 Signed-off-by: Natanael Copa Acked-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman

iommu/amd: Return devid as alias for ACPI HID devices

2018-10-20T07:48:52+00:00

[ Upstream commit 5ebb1bc2d63d90dd204169e21fd7a0b4bb8c776e ] ACPI HID devices do not actually have an alias for them in the IVRS. But dev_data->alias is still used for indexing into the IOMMU device table for devices being handled by the IOMMU. So for ACPI HID devices, we simply return the corresponding devid as an alias, as parsed from IVRS table. Signed-off-by: Arindam Nath Fixes: 2bf9a0a12749 ('iommu/amd: Add iommu support for ACPI HID devices') Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/fttmr010: Fix set_next_event handler

2018-10-20T07:48:52+00:00

[ Upstream commit 4451d3f59f2a6f95e5d205c2d04ea072955d080d ] Currently, the aspeed MATCH1 register is updated to in set_next_event handler, with the assumption that COUNT register value is preserved when the timer is disabled and it continues decrementing after the timer is enabled. But the assumption is wrong: RELOAD register is loaded into COUNT register when the aspeed timer is enabled, which means the next event may be delayed because timer interrupt won't be generated until <0xFFFFFFFF - current_count + cycles>. The problem can be fixed by updating RELOAD register to , and COUNT register will be re-loaded when the timer is enabled and interrupt is generated when COUNT register overflows. The test result on Facebook Backpack-CMM BMC hardware (AST2500) shows the issue is fixed: without the patch, usleep(100) suspends the process for several milliseconds (and sometimes even over 40 milliseconds); after applying the fix, usleep(100) takes averagely 240 microseconds to return under the same workload level. Signed-off-by: Tao Ren Reviewed-by: Linus Walleij Tested-by: Lei YU Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

net/mlx4: Use cpumask_available for eq->affinity_mask

2018-10-20T07:48:52+00:00

[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ] Clang warns that the address of a pointer will always evaluated as true in a boolean context: drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of array 'eq->affinity_mask' will always evaluate to 'true' [-Wpointer-bool-conversion] if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask)) ~~~~~^~~~~~~~~~~~~ 1 warning generated. Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add helper cpumask_available()"), which does the proper checking and avoids this warning. Link: https://github.com/ClangBuiltLinux/linux/issues/86 Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

scsi: sd: don't crash the host on invalid commands

2018-10-20T07:48:51+00:00

[ Upstream commit f1f1fadacaf08b7cf11714c0c29f8fa4d4ef68a9 ] When sd_init_command() get's a command with a unknown req_op() it crashes the system via BUG(). This makes debugging the actual reason for the broken request cmd_flags pretty hard as the system is down before it's able to write out debugging data on the serial console or the trace buffer. Change the BUG() to a WARN_ON() and return BLKPREP_KILL to fail gracefully and return an I/O error to the producer of the request. Signed-off-by: Johannes Thumshirn Cc: Hannes Reinecke Cc: Bart Van Assche Cc: Christoph Hellwig Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman