user/sven/linux.git/drivers, branch v4.14.41

nvme: add quirk to force medium priority for SQ creation

2018-05-16T08:10:30Z

commit 9abd68ef454c824bfd18629033367b4382b5f390 upstream. Some P3100 drives have a bug where they think WRRU (weighted round robin) is always enabled, even though the host doesn't set it. Since they think it's enabled, they also look at the submission queue creation priority. We used to set that to MEDIUM by default, but that was removed in commit 81c1cd98351b. This causes various issues on that drive. Add a quirk to still set MEDIUM priority for that controller. Fixes: 81c1cd98351b ("nvme/pci: Don't set reserved SQ create flags") Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman

thermal: exynos: Propagate error value from tmu_read()

2018-05-16T08:10:30Z

commit c8da6cdef57b459ac0fd5d9d348f8460a575ae90 upstream. tmu_read() in case of Exynos4210 might return error for out of bound values. Current code ignores such value, what leads to reporting critical temperature value. Add proper error code propagation to exynos_get_temp() function. Signed-off-by: Marek Szyprowski CC: stable@vger.kernel.org # v4.6+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman

thermal: exynos: Reading temperature makes sense only when TMU is turned on

2018-05-16T08:10:30Z

commit 88fc6f73fddf64eb507b04f7b2bd01d7291db514 upstream. When thermal sensor is not yet enabled, reading temperature might return random value. This might even result in stopping system booting when such temperature is higher than the critical value. Fix this by checking if TMU has been actually enabled before reading the temperature. This change fixes booting of Exynos4210-based board with TMU enabled (for example Samsung Trats board), which was broken since v4.4 kernel release. Signed-off-by: Marek Szyprowski Fixes: 9e4249b40340 ("thermal: exynos: Fix first temperature read after registering sensor") CC: stable@vger.kernel.org # v4.6+ Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: Only check needs_reset_resume DMI table for QCA rome chipsets

2018-05-16T08:10:30Z

commit fc54910280eb38bde923cdf0898e74687d8e6989 upstream. Jeremy Cline correctly points out in rhbz#1514836 that a device where the QCA rome chipset needs the USB_QUIRK_RESET_RESUME quirk, may also ship with a different wifi/bt chipset in some configurations. If that is the case then we are needlessly penalizing those other chipsets with a reset-resume quirk, typically causing 0.4W extra power use because this disables runtime-pm. This commit moves the DMI table check to a btusb_check_needs_reset_resume() helper (so that we can easily also call it for other chipsets) and calls this new helper only for QCA_ROME chipsets for now. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Cc: stable@vger.kernel.org Cc: Jeremy Cline Suggested-by: Jeremy Cline Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: Add Dell XPS 13 9360 to btusb_needs_reset_resume_table

2018-05-16T08:10:30Z

commit 596b07a9a22656493726edf1739569102bd3e136 upstream. The Dell XPS 13 9360 uses a QCA Rome chip which needs to be reset (and have its firmware reloaded) for bluetooth to work after suspend/resume. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Cc: stable@vger.kernel.org Cc: Garrett LeSage Reported-and-tested-by: Garrett LeSage Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Revert "Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174"

2018-05-16T08:10:29Z

commit 544a591668813583021474fa5c7ff4942244d654 upstream. Commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174") is causing bluetooth to no longer work for several people, see: https://bugzilla.redhat.com/show_bug.cgi?id=1568911 So lets revert it for now and try to find another solution for devices which need the modified quirk. Cc: stable@vger.kernel.org Cc: Takashi Iwai Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

PCI / PM: Check device_may_wakeup() in pci_enable_wake()

2018-05-16T08:10:29Z

commit cfcadfaad7251d8b640713724b388164d75465b2 upstream. Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code) went too far and dropped the device_may_wakeup() check from pci_enable_wake() which causes wakeup to be enabled during system suspend, hibernation or shutdown for some PCI devices that are not allowed by user space to wake up the system from sleep (or power off). As a result of this, excessive power is drawn by some of the affected systems while in sleep states or off. Restore the device_may_wakeup() check in pci_enable_wake(), but make sure that the PCI bus type's runtime suspend callback will not call device_may_wakeup() which is about system wakeup from sleep and not about device wakeup from runtime suspend. Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code) Reported-by: Joseph Salisbury Cc: 4.13+ # 4.13+ Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

PCI / PM: Always check PME wakeup capability for runtime wakeup support

2018-05-16T08:10:29Z

commit 8feaec33b9868582654cd3d5355225dcb79aeca6 upstream. USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info). The device in question is not power managed by platform firmware, furthermore, it only supports PME# from D3cold: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Before commit de3ef1eb1cd0, the device never gets runtime suspended. After that commit, the device gets runtime suspended to D3hot, which can not generate any PME#. usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence device_can_wakeup() in pci_dev_run_wake() always returns true. So pci_dev_run_wake() needs to check PME wakeup capability as its first condition. In addition, change wakeup flag passed to pci_target_state() from false to true, because we want to find the deepest state different from D3cold that the device can still generate PME#. In this case, it's D0 for the device in question. Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info) Signed-off-by: Kai-Heng Feng Cc: 4.13+ # 4.13+ Acked-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

atm: zatm: Fix potential Spectre v1

2018-05-16T08:10:29Z

commit 2be147f7459db5bbf292e0a6f135037b55e20b39 upstream. pool can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue 'zatm_dev->pool_info' (local cap) Fix this by sanitizing pool before using it to index zatm_dev->pool_info Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

drm/atomic: Clean private obj old_state/new_state in drm_atomic_state_default_clear()

2018-05-16T08:10:29Z

commit b5cb2e5a1f64d882a155add7522247ab0523051e upstream. Clear the old_state and new_state pointers for private objects in drm_atomic_state_default_clear(). We don't actually have functions to get the new/old state for private objects so getting access to the potentially stale pointers requires a bit more manual labour than for other object types. But let's clear the pointers for private objects as well, if only to avoid future surprises when someone decides to add the functions to get at them. v2: Split private objs to a separate patch (Daniel) Cc: # v4.14+ Cc: Maarten Lankhorst Cc: Laurent Pinchart Cc: Abhay Kumar Fixes: a4370c777406 (drm/atomic: Make private objs proper objects) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Signed-off-by: Greg Kroah-Hartman