commit 3d8f8d06abb388529cde045375e40c856862b80c Author: Greg Kroah-Hartman Date: Mon Jan 9 08:22:35 2017 +0100 Linux 4.8.17 commit adf363fd5ab9eb39c71d5532f72175f5ad864630 Author: Paulo Zanoni Date: Wed Dec 14 12:55:37 2016 -0200 drm/i915: skip the first 4k of stolen memory on everything >= gen8 commit 6ba0566cf2afcdb17bff882e3a95cbbcb22c4a83 upstream. BSpec got updated and this workaround is now listed as standard required programming for all subsequent projects. This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory). v2: this is the patch that fixes the screen flickering, document it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Tested-by: Dominik Klementowski Signed-off-by: Paulo Zanoni Acked-by: Chris Wilson Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 000e612673dabe754c5eec2c50bdfcea3f40056e Author: Ville Syrjälä Date: Tue Nov 29 16:13:57 2016 +0200 drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time commit 1f3dc3e334c1192ebe2939ea17ba12f4776f90c3 upstream. Looks like we're only initializing dev_priv->atomic_cdclk_freq at resume and commit times, not at init time. Let's do that as well. We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in hsw_compute_linetime_wm() on account of populating intel_state->cdclk from dev_priv->atomic_cdclk_freq. Previously we were mispopulating intel_state->cdclk with dev_priv->cdclk_freq which always had a proper value at init time and hence the WARN_ON() didn't trigger. Cc: Matthew Auld Reported-by: Matthew Auld Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902 Fixes: 14676ec6b1a6 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.com Tested-by: Matthew Auld Reviewed-by: Matthew Auld (cherry picked from commit 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 22aba475d97b52930d5e75529be35fd68aa576bc Author: Ville Syrjälä Date: Mon Nov 14 18:35:09 2016 +0200 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things commit 14676ec6b1a6f2f7fa0bafd98ab42ce77be7a7d4 upstream. When we end up not recomputing the cdclk, we need to populate intel_state->cdclk with the "atomic_cdclk_freq" instead of the current cdclk_freq. When no pipes are active, the actual cdclk_freq may be lower than what the configuration of the planes and pipes would require from the point of view of the software state. This fixes bogus WARNS from skl_max_scale() which is trying to check the plane software state against the cdclk frequency. So any time it got called during DPMS off for instance, we might have tripped the warn if the current mode would have required a higher than minimum cdclk. v2: Drop the dev_cdclk stuff (Maarten) Cc: Maarten Lankhorst Cc: Mika Kahola Cc: bruno.pagani@ens-lyon.org Cc: Daniel J Blueman Cc: Paul Bolle Cc: Joseph Yasi Tested-by: Paul Bolle Tested-by: Joseph Yasi (v1) Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were active.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214 Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit e0ca7a6be38ce603d26df5707c22e53870a623e0) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 294bb3402c763ea206ec5e531e8337beaee22f52 Author: Hans de Goede Date: Fri Dec 2 15:29:04 2016 +0100 drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating commit bb98e72adaf9d19719aba35f802d4836f5d5176c upstream. On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Signed-off-by: Hans de Goede Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä (cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6a412ff3df875fafce66e52cc45e12cd7b613363 Author: Hans de Goede Date: Thu Dec 1 21:29:09 2016 +0100 drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting commit 22ca0d4991169b76e753d767a45f1105c356bbb8 upstream. Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") Cc: Jani Nikula Cc: Ville Syrjälä Signed-off-by: Hans de Goede Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20161201202925.12220-3-hdegoede@redhat.com Signed-off-by: Ville Syrjälä (cherry picked from commit b2b45fcd921e864a5e9bbc7aa55dee96d5e11c06) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 4803ec2a74c49814a6176ab001164df985320576 Author: Thomas Petazzoni Date: Wed Dec 21 11:28:49 2016 +0100 net: mvpp2: fix dma unmapping of TX buffers for fragments commit 8354491c9d5b06709384cea91d13019bf5e61449 upstream. Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping"), we are not correctly DMA unmapping TX buffers for fragments. Indeed, the mvpp2_txq_inc_put() function only stores in the txq_cpu->tx_buffs[] array the physical address of the buffer to be DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use skb_headlen(skb) to get the size to be unmapped. Both of this works fine for TX descriptors that are associated directly to a SKB, but not the ones that are used for fragments, with a NULL pointer as skb: - We have a NULL physical address when calling DMA unmap - skb_headlen(skb) crashes because skb is NULL This causes random crashes when fragments are used. To solve this problem, we need to: - Store the physical address of the buffer to be unmapped unconditionally, regardless of whether it is tied to a SKB or not. - Store the length of the buffer to be unmapped, which requires a new field. Instead of adding a third array to store the length of the buffer to be unmapped, and as suggested by David Miller, this commit refactors the tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is added. Therefore, instead of having three arrays to allocate/free, we have a single one, which also improve data locality, reducing the impact on the CPU cache. Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping") Reported-by: Raphael G Cc: Raphael G Signed-off-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 48f26edb689c83af15b6afe657e96424ca9d13d9 Author: Al Viro Date: Fri Dec 16 13:42:06 2016 -0500 sg_write()/bsg_write() is not fit to be called under KERNEL_DS commit 128394eff343fc6d2f32172f03e24829539c5835 upstream. Both damn things interpret userland pointers embedded into the payload; worse, they are actually traversing those. Leaving aside the bad API design, this is very much _not_ safe to call with KERNEL_DS. Bail out early if that happens. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit d787c6b32c3f7b15e7ecf41c636edb167797d939 Author: Ben Hutchings Date: Thu Nov 24 22:10:23 2016 +0000 kconfig/nconf: Fix hang when editing symbol with a long prompt commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream. Currently it is impossible to edit the value of a config symbol with a prompt longer than (terminal width - 2) characters. dialog_inputbox() calculates a negative x-offset for the input window and newwin() fails as this is invalid. It also doesn't check for this failure, so it busy-loops calling wgetch(NULL) which immediately returns -1. The additions in the offset calculations also don't match the intended size of the window. Limit the window size and calculate the offset similarly to show_scroll_win(). Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)") Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit e141d1a21e31e57728a6f72c377ae1d63558734f Author: Andy Grover Date: Mon Nov 21 16:35:30 2016 -0800 target/user: Fix use-after-free of tcmu_cmds if they are expired commit d0905ca757bc40bd1ebc261a448a521b064777d7 upstream. Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by an entry in our cmd_id->cmd idr. If userspace ever resumes processing, tcmu_handle_completions() will use the now-invalid cmd pointer. Instead, don't free cmd. It will be freed by tcmu_handle_completion() if userspace ever recovers, or tcmu_free_device if not. Reported-by: Bryant G Ly Tested-by: Bryant G Ly Signed-off-by: Andy Grover Signed-off-by: Bart Van Assche Signed-off-by: Greg Kroah-Hartman commit 29f3d1127c4b475ebbd631903ce69dea1d042277 Author: Dan Williams Date: Sat Dec 10 08:12:05 2016 -0800 libnvdimm, pfn: fix align attribute commit af7d9f0c57941b465043681cb5c3410f7f3f1a41 upstream. Fix the format specifier so that the attribute can be parsed correctly. Currently it returns decimal 1000 for a 4096-byte alignment. Reported-by: Dave Jiang Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute, default to HPAGE_SIZE") Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 3a4e4281b5cdd032a44595a83b25d8773f626ddf Author: Geoff Levand Date: Tue Nov 29 10:47:32 2016 -0800 powerpc/ps3: Fix system hang with GCC 5 builds commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream. GCC 5 generates different code for this bootwrapper null check that causes the PS3 to hang very early in its bootup. This check is of limited value, so just get rid of it. Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit e451d674bac550e2f311fe18abe36345f826470a Author: Nicholas Piggin Date: Thu Nov 24 00:02:07 2016 +1100 powerpc/64e: Convert cmpi to cmpwi in head_64.S commit f87f253bac3ce4a4eb2a60a1ae604d74e65f9042 upstream. From 80f23935cadb ("powerpc: Convert cmp to cmpd in idle enter sequence"): PowerPC's "cmp" instruction has four operands. Normally people write "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently people forget, and write "cmp" with just three operands. With older binutils this is silently accepted as if this was "cmpw", while often "cmpd" is wanted. With newer binutils GAS will complain about this for 64-bit code. For 32-bit code it still silently assumes "cmpw" is what is meant. In this case, cmpwi is called for, so this is just a build fix for new toolchains. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0349fbebd9847dfaea56e172be50b41380c300bd Author: NeilBrown Date: Mon Dec 5 15:10:11 2016 +1100 SUNRPC: fix refcounting problems with auth_gss messages. commit 1cded9d2974fe4fe339fc0ccd6638b80d465ab2c upstream. There are two problems with refcounting of auth_gss messages. First, the reference on the pipe->pipe list (taken by a call to rpc_queue_upcall()) is not counted. It seems to be assumed that a message in pipe->pipe will always also be in pipe->in_downcall, where it is correctly reference counted. However there is no guaranty of this. I have a report of a NULL dereferences in rpc_pipe_read() which suggests a msg that has been freed is still on the pipe->pipe list. One way I imagine this might happen is: - message is queued for uid=U and auth->service=S1 - rpc.gssd reads this message and starts processing. This removes the message from pipe->pipe - message is queued for uid=U and auth->service=S2 - rpc.gssd replies to the first message. gss_pipe_downcall() calls __gss_find_upcall(pipe, U, NULL) and it finds the *second* message, as new messages are placed at the head of ->in_downcall, and the service type is not checked. - This second message is removed from ->in_downcall and freed by gss_release_msg() (even though it is still on pipe->pipe) - rpc.gssd tries to read another message, and dereferences a pointer to this message that has just been freed. I fix this by incrementing the reference count before calling rpc_queue_upcall(), and decrementing it if that fails, or normally in gss_pipe_destroy_msg(). It seems strange that the reply doesn't target the message more precisely, but I don't know all the details. In any case, I think the reference counting irregularity became a measureable bug when the extra arg was added to __gss_find_upcall(), hence the Fixes: line below. The second problem is that if rpc_queue_upcall() fails, the new message is not freed. gss_alloc_msg() set the ->count to 1, gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1, then the pointer is discarded so the memory never gets freed. Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service") Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250 Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c513ade4ca564a17814bcaffff981489be2afcf4 Author: Trond Myklebust Date: Sun Nov 27 15:12:39 2016 -0500 pNFS: Fix a deadlock between read resends and layoutreturn commit 54e4a0dfa25d9365c4e80a639e80d9213eb6edbe upstream. We must not call nfs_pageio_init_read() on a new nfs_pageio_descriptor while holding a reference to a layout segment, as that can deadlock pnfs_update_layout(). Fixes: d67ae825a59d6 ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit abb2903f1ac21ba17698728d17c442deb3266ab8 Author: Trond Myklebust Date: Mon Nov 14 14:34:18 2016 -0500 pNFS: Clear NFS_LAYOUT_RETURN_REQUESTED when invalidating the layout stateid commit ae5a459d5f65c3e83f3e14068dde5fb9c9d81807 upstream. We must ensure that we don't schedule a layoutreturn if the layout stateid has been marked as invalid. Fixes: 2a59a0411671e ("pNFS: Fix pnfs_set_layout_stateid() to clear...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit f061c76c1d56fd8783bfd1393f2987f346280e9a Author: Trond Myklebust Date: Mon Nov 14 13:10:48 2016 -0500 pNFS: Don't clear the layout stateid if a layout return is outstanding commit 7b650994ab07434ae58a247dc9ac87d2488ca75c upstream. If we no longer hold any layout segments, we're normally expected to consider the layout stateid to be invalid. However we cannot assume this if we're about to, or in the process of sending a layoutreturn. Fixes: 334a8f37115b ("pNFS: Don't forget the layout stateid if...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7de1b81c27fd271e5df350ab6ca8316e0724cc22 Author: Trond Myklebust Date: Mon Oct 17 17:54:32 2016 -0400 pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed commit 6604b203fb6394ed1f24c21bfa3c207e5ae8e461 upstream. If there is an I/O error, we should not call LAYOUTGET until the LAYOUTRETURN that reports the error is complete. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8f5ff877bf19076c49eda0b440ad16507ebd1fcf Author: Al Viro Date: Mon Sep 5 21:42:32 2016 -0400 nfs_write_end(): fix handling of short copies commit c0cf3ef5e0f47e385920450b245d22bead93e7ad upstream. What matters when deciding if we should make a page uptodate is not how much we _wanted_ to copy, but how much we actually have copied. As it is, on architectures that do not zero tail on short copy we can leave uninitialized data in page marked uptodate. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 1678adac85dadd18fca4c185381812500cfb1262 Author: Ilya Dryomov Date: Fri Dec 2 16:35:09 2016 +0100 libceph: verify authorize reply on connect commit 5c056fdc5b474329037f2aa18401bd73033e0ce0 upstream. After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b), the client gets back a ceph_x_authorize_reply, which it is supposed to verify to ensure the authenticity and protect against replay attacks. The code for doing this is there (ceph_x_verify_authorizer_reply(), ceph_auth_verify_authorizer_reply() + plumbing), but it is never invoked by the the messenger. AFAICT this goes back to 2009, when ceph authentication protocols support was added to the kernel client in 4e7a5dcd1bba ("ceph: negotiate authentication protocol; implement AUTH_NONE protocol"). The second param of ceph_connection_operations::verify_authorizer_reply is unused all the way down. Pass 0 to facilitate backporting, and kill it in the next commit. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 1f93d1a77b176282b3ae1842a9d353422bb32b1a Author: Alan Stern Date: Fri Oct 21 16:45:38 2016 -0400 PCI: Check for PME in targeted sleep state commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream. One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by: Pierre de Villemereuil Tested-by: Pierre de Villemereuil Signed-off-by: Alan Stern Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki CC: Lukas Wunner Signed-off-by: Greg Kroah-Hartman commit c75bc2bde1025ed047ba7f33d7509c76231f47ce Author: Shiraz Saleem Date: Fri Nov 11 10:55:41 2016 -0600 i40iw: Use correct src address in memcpy to rdma stats counters commit 91c42b72f8e8b45961ff05a05009b644e6316ca2 upstream. hw_stats is a pointer to i40_iw_dev_stats struct in i40iw_get_hw_stats(). Use hw_stats and not &hw_stats in the memcpy to copy the i40iw device stats data into rdma_hw_stats counters. Fixes: b40f4757daa1 ("IB/core: Make device counter infrastructure dynamic") Signed-off-by: Shiraz Saleem Signed-off-by: Faisal Latif Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 7d0a6cf3e8c952ef0ace732317148c247d4957a4 Author: Jingkui Wang Date: Mon Dec 12 13:51:46 2016 -0800 Input: drv260x - fix input device's parent assignment commit 5a8a6b89c15766446d845671d574a9243b6d8786 upstream. We were assigning I2C bus controller instead of client as parent device. Besides being logically wrong, it messed up with devm handling of input device. As a result we were leaving input device and event node behind after rmmod-ing the driver, which lead to a kernel oops if one were to access the event node later. Let's remove the assignment and rely on devm_input_allocate_device() to set it up properly for us. Signed-off-by: Jingkui Wang Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver") Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b7843712cbd227adf3c667e6103cdf26ac5e6dda Author: Laurent Pinchart Date: Thu Dec 8 20:22:43 2016 -0200 v4l: tvp5150: Add missing break in set control handler commit d183e4efcae8d88a2f252e546978658ca6d273cc upstream. A break is missing resulting in the hue control enabling or disabling the decode completely. Fix it. Fixes: c43875f66140 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control") Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4963b191009049ffeaab0db818124892ca31c40f Author: Andrey Utkin Date: Sat Oct 22 13:34:36 2016 -0200 media: solo6x10: fix lockup by avoiding delayed register write commit 5fc4b067ec082c3127e0156f800769b7e0dce078 upstream. This fixes a lockup at device probing which happens on some solo6010 hardware samples. This is a regression introduced by commit e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers") The observed lockup happens in solo_set_motion_threshold() called from solo_motion_config(). This extra "flushing" is not fundamentally needed for every write, but apparently the code in driver assumes such behaviour at last in some places. Actual fix was proposed by Hans Verkuil. Fixes: e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers") Signed-off-by: Andrey Utkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 88bfde25e60f985b42d415146c937831e9738c0d Author: Marek Szyprowski Date: Fri Sep 16 03:14:33 2016 -0300 s5p-mfc: fix failure path of s5p_mfc_alloc_memdev() commit 3467c9a7e7f9209a9ecd8f9db65b04a323a13932 upstream. s5p_mfc_alloc_memdev() function lacks proper releasing of allocated device in case of reserved memory initialization failure. This results in NULL pointer dereference: [ 2.828457] Unable to handle kernel NULL pointer dereference at virtual address 00000001 [ 2.835089] pgd = c0004000 [ 2.837752] [00000001] *pgd=00000000 [ 2.844696] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 2.848680] Modules linked in: [ 2.851722] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00002-gafa1b97 #878 [ 2.859357] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2.865433] task: ef080000 task.stack: ef06c000 [ 2.869952] PC is at strcmp+0x0/0x30 [ 2.873508] LR is at platform_match+0x84/0xac [ 2.877847] pc : [] lr : [] psr: 20000013 [ 2.877847] sp : ef06dea0 ip : 00000000 fp : 00000000 [ 2.889303] r10: 00000000 r9 : c0b34848 r8 : c0b1e968 [ 2.894511] r7 : 00000000 r6 : 00000001 r5 : c086e7fc r4 : eeb8e010 [ 2.901021] r3 : 0000006d r2 : 00000000 r1 : c086e7fc r0 : 00000001 [ 2.907533] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 2.914649] Control: 10c5387d Table: 4000404a DAC: 00000051 [ 2.920378] Process swapper/0 (pid: 1, stack limit = 0xef06c210) [ 2.926367] Stack: (0xef06dea0 to 0xef06e000) [ 2.930711] dea0: eeb8e010 c0c2d91c c03f4a6c c03f4a8c 00000000 c0c2d91c c03f4a6c c03f2fc8 [ 2.938870] dec0: ef003274 ef10c4c0 c0c2d91c ef10cc80 c0c21270 c03f3fa4 c09c1be8 c0c2d91c [ 2.947028] dee0: 00000006 c0c2d91c 00000006 c0b3483c c0c47000 c03f5314 c0c2d908 c0b5fed8 [ 2.955188] df00: 00000006 c010178c 60000013 c0a4ef14 00000000 c06feaa0 ef080000 60000013 [ 2.963347] df20: 00000000 c0c095c8 efffca76 c0816b8c 000000d5 c0134098 c0b34848 c09d6cdc [ 2.971506] df40: c0a4de70 00000000 00000006 00000006 c0c09568 efffca40 c0b5fed8 00000006 [ 2.979665] df60: c0b3483c c0c47000 000000d5 c0b34848 c0b005a4 c0b00d84 00000006 00000006 [ 2.987824] df80: 00000000 c0b005a4 00000000 c06fb4d8 00000000 00000000 00000000 00000000 [ 2.995983] dfa0: 00000000 c06fb4e0 00000000 c01079b8 00000000 00000000 00000000 00000000 [ 3.004142] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 3.012302] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 3.020469] [] (strcmp) from [] (platform_match+0x84/0xac) [ 3.027672] [] (platform_match) from [] (__driver_attach+0x20/0xb0) [ 3.035654] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88) [ 3.043812] [] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x1f4) [ 3.051971] [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [ 3.059958] [] (driver_register) from [] (do_one_initcall+0x3c/0x16c) [ 3.068123] [] (do_one_initcall) from [] (kernel_init_freeable+0x120/0x1ec) [ 3.076802] [] (kernel_init_freeable) from [] (kernel_init+0x8/0x118) [ 3.084958] [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) [ 3.092506] Code: 1afffffb e12fff1e e1a03000 eafffff7 (e4d03001) [ 3.098618] ---[ end trace 511bf9d750810709 ]--- [ 3.103207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b This patch fixes this issue. Fixes: c79667dd93b084fe412bcfe7fbf0ba43f7dec520 ("media: s5p-mfc: replace custom reserved memory handling code with generic one") Signed-off-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c3fe33d185e0d3f10a4b4a494c291dd7553d0167 Author: Antti Palosaari Date: Wed Nov 30 19:36:14 2016 -0200 mn88473: fix chip id check on probe commit d930b5b5bf122a61952cfebabb1e618682a2631a upstream. A register used to identify chip during probe was overwritten during firmware download and due to that later probe's for warm chip were failing. Detect chip from the another register, which is located on different register bank 2. Fixes: 7908fad99a6c ("[media] mn88473: finalize driver") Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 84b2f664409c26196f6f1e2f2eb7a5bc0ba7fbe4 Author: Antti Palosaari Date: Wed Nov 30 22:08:27 2016 -0200 mn88472: fix chip id check on probe commit 365fe4e0ce218dc5ad10df17b150a366b6015499 upstream. A register used to identify chip during probe was overwritten during firmware download and due to that later probe's for warm chip were failing. Detect chip from the another register, which is located on different register bank 2. Fixes: 94d0eaa41987 ("[media] mn88472: move out of staging to media") Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 15d1d226eab460617f6e4d33e64d0be34676ddf4 Author: Bart Van Assche Date: Mon Dec 19 18:00:05 2016 +0100 IB/cma: Fix a race condition in iboe_addr_get_sgid() commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream. Code that dereferences the struct net_device ip_ptr member must be protected with an in_dev_get() / in_dev_put() pair. Hence insert calls to these functions. Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing") Signed-off-by: Bart Van Assche Reviewed-by: Moni Shoua Cc: Or Gerlitz Cc: Roland Dreier Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 7b3721aff59b00a3ee7ba659db61129a46dad8ef Author: Bart Van Assche Date: Thu Dec 15 17:15:07 2016 +0100 IB/rxe: Fix a memory leak in rxe_qp_cleanup() commit e259934d4df7f99f2a5c2c4f074f6a55bd4b1722 upstream. A socket is associated with every QP by the rxe driver but sock_release() is never called. Add a call to sock_release() in rxe_qp_cleanup(). Fixes: commit 8700e3e7c48A5 ("Add Soft RoCE driver") Signed-off-by: Bart Van Assche Cc: Moni Shoua Cc: Kamal Heib Cc: Amir Vadai Cc: Haggai Eran Reviewed-by: Moni Shoua Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 2a0aa77a54fb3f79b134535c056c7bdd02a882bf Author: Bart Van Assche Date: Mon Nov 21 10:22:17 2016 -0800 IB/multicast: Check ib_find_pkey() return value commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 upstream. This patch avoids that Coverity complains about not checking the ib_find_pkey() return value. Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes") Signed-off-by: Bart Van Assche Cc: Sean Hefty Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 37d4adba02d34bce1fa94769a922ef88e1cbcc34 Author: Bart Van Assche Date: Mon Nov 21 10:21:41 2016 -0800 IPoIB: Avoid reading an uninitialized member variable commit 11b642b84e8c43e8597de031678d15c08dd057bc upstream. This patch avoids that Coverity reports the following: Using uninitialized value port_attr.state when calling printk Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports") Signed-off-by: Bart Van Assche Cc: Erez Shitrit Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit f079fc11f28e6e2e6e1e6cc1ca452dbc33caf87e Author: Bart Van Assche Date: Mon Nov 21 10:21:17 2016 -0800 IB/mad: Fix an array index check commit 2fe2f378dd45847d2643638c07a7658822087836 upstream. The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS (80) elements. Hence compare the array index with that value instead of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity reports the following: Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127). Fixes: commit b7ab0b19a85f ("IB/mad: Verify mgmt class in received MADs") Signed-off-by: Bart Van Assche Cc: Sean Hefty Reviewed-by: Hal Rosenstock Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit e661b5d4b94f6272dff87714c55c8d456c3ddded Author: Steven Rostedt (Red Hat) Date: Thu Dec 8 20:54:49 2016 -0500 fgraph: Handle a case where a tracer ignores set_graph_notrace commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 upstream. Both the wakeup and irqsoff tracers can use the function graph tracer when the display-graph option is set. The problem is that they ignore the notrace file, and record the entry of functions that would be ignored by the function_graph tracer. This causes the trace->depth to be recorded into the ring buffer. The set_graph_notrace uses a trick by adding a large negative number to the trace->depth when a graph function is to be ignored. On trace output, the graph function uses the depth to record a stack of functions. But since the depth is negative, it accesses the array with a negative number and causes an out of bounds access that can cause a kernel oops or corrupt data. Have the print functions handle cases where a tracer still records functions even when they are in set_graph_notrace. Also add warnings if the depth is below zero before accessing the array. Note, the function graph logic will still prevent the return of these functions from being recorded, which means that they will be left hanging without a return. For example: # echo '*spin*' > set_graph_notrace # echo 1 > options/display-graph # echo wakeup > current_tracer # cat trace [...] _raw_spin_lock() { preempt_count_add() { do_raw_spin_lock() { update_rq_clock(); Where it should look like: _raw_spin_lock() { preempt_count_add(); do_raw_spin_lock(); } update_rq_clock(); Cc: Namhyung Kim Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b2758da04d73e2fe9e8ffc276130f02a143d41f7 Author: Marcos Paulo de Souza Date: Tue Nov 29 23:23:06 2016 -0200 platform/x86: asus-nb-wmi.c: Add X45U quirk commit e74e259939275a5dd4e0d02845c694f421e249ad upstream. Without this patch, the Asus X45U wireless card can't be turned on (hard-blocked), but after a suspend/resume it just starts working. Following this bug report[1], there are other cases like this one, but this Asus is the only model that I can test. [1] https://ubuntuforums.org/showthread.php?t=2181558 Signed-off-by: Marcos Paulo de Souza Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit f61152e3bbf0bc1a3a2f0bd635835e0bb90ced7a Author: Steven Rostedt (Red Hat) Date: Thu Dec 8 12:48:26 2016 -0500 ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream. With new binutils, gcc may get smart with its optimization and change a jmp from a 5 byte jump to a 2 byte one even though it was jumping to a global function. But that global function existed within a 2 byte radius, and gcc was able to optimize it. Unfortunately, that jump was also being modified when function graph tracing begins. Since ftrace expected that jump to be 5 bytes, but it was only two, it overwrote code after the jump, causing a crash. This was fixed for x86_64 with commit 8329e818f149, with the same subject as this commit, but nothing was done for x86_32. Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls") Reported-by: Colin Ian King Tested-by: Colin Ian King Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8569aadeed3fe07befec67127acaecc58eca1a5f Author: Michael S. Tsirkin Date: Tue Dec 6 06:07:15 2016 +0200 vsock/virtio: fix src/dst cid format commit f83f12d660d11718d3eed9d979ee03e83aa55544 upstream. These fields are 64 bit, using le32_to_cpu and friends on these will not do the right thing. Fix this up. Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 576ea9e5e92e9211ae26d75880d4d3142ff1b8d0 Author: Jan Kara Date: Mon Dec 12 16:08:41 2016 +0100 fsnotify: Fix possible use-after-free in inode iteration on umount commit 5716863e0f8251d3360d4cbfc0e44e08007075df upstream. fsnotify_unmount_inodes() plays complex tricks to pin next inode in the sb->s_inodes list when iterating over all inodes. Furthermore the code has a bug that if the current inode is the last on i_sb_list that does not have e.g. I_FREEING set, then we leave next_i pointing to inode which may get removed from the i_sb_list once we drop s_inode_list_lock thus resulting in use-after-free issues (usually manifesting as infinite looping in fsnotify_unmount_inodes()). Fix the problem by keeping current inode pinned somewhat longer. Then we can make the code much simpler and standard. Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 43983ce75e6119b0ba3249a38f1160805e3d761c Author: Jim Mattson Date: Mon Dec 12 11:01:37 2016 -0800 kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF) commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream. When L2 exits to L0 due to "exception or NMI", software exceptions (#BP and #OF) for which L1 has requested an intercept should be handled by L1 rather than L0. Previously, only hardware exceptions were forwarded to L1. Signed-off-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9a5cf8c4b112714d458475f83a39e539772b3dfb Author: Paul Mackerras Date: Wed Nov 16 16:43:28 2016 +1100 KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT commit f064a0de1579fabded8990bed93971e30deb9ecb upstream. The hashed page table MMU in POWER processors can update the R (reference) and C (change) bits in a HPTE at any time until the HPTE has been invalidated and the TLB invalidation sequence has completed. In kvmppc_h_protect, which implements the H_PROTECT hypercall, we read the HPTE, modify the second doubleword, invalidate the HPTE in memory, do the TLB invalidation sequence, and then write the modified value of the second doubleword back to memory. In doing so we could overwrite an R/C bit update done by hardware between when we read the HPTE and when the TLB invalidation completed. To fix this we re-read the second doubleword after the TLB invalidation and OR in the (possibly) new values of R and C. We can use an OR since hardware only ever sets R and C, never clears them. This race was found by code inspection. In principle this bug could cause occasional guest memory corruption under host memory pressure. Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29) Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit b751eb6e9d99c9a65c32123d3726994f6473f7b8 Author: Paul Mackerras Date: Mon Nov 7 15:09:58 2016 +1100 KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream. When switching from/to a guest that has a transaction in progress, we need to save/restore the checkpointed register state. Although XER is part of the CPU state that gets checkpointed, the code that does this saving and restoring doesn't save/restore XER. This fixes it by saving and restoring the XER. To allow userspace to read/write the checkpointed XER value, we also add a new ONE_REG specifier. The visible effect of this bug is that the guest may see its XER value being corrupted when it uses transactions. Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support") Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit") Signed-off-by: Paul Mackerras Reviewed-by: Thomas Huth Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 0773e9248ae32dae961ebaa615c378bb0e01892f Author: Kevin Barnett Date: Thu Dec 8 10:29:29 2016 -0600 scsi: aacraid: remove wildcard for series 9 controllers commit ae2aae2421983f6f68eb7c4692624bc43ea50712 upstream. Controllers with this PCI ID never shipped outside of PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the correct driver for these controllers. [mkp: patch description] Reviewed-by: Scott Teel Signed-off-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b202064f0b3f92d4ce3feec09ad55a20e771947b Author: Konstantin Khlebnikov Date: Sun Nov 27 19:32:32 2016 +0300 md/raid5: limit request size according to implementation limits commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream. Current implementation employ 16bit counter of active stripes in lower bits of bio->bi_phys_segments. If request is big enough to overflow this counter bio will be completed and freed too early. Fortunately this not happens in default configuration because several other limits prevent that: stripe_cache_size * nr_disks effectively limits count of active stripes. And small max_sectors_kb at lower disks prevent that during normal read/write operations. Overflow easily happens in discard if it's enabled by module parameter "devices_handle_discard_safely" and stripe_cache_size is set big enough. This patch limits requests size with 256Mb - 8Kb to prevent overflows. Signed-off-by: Konstantin Khlebnikov Cc: Shaohua Li Cc: Neil Brown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 47090341ec97222f47c9ac7dc35b587b85bf1d0d Author: Josh Cartwright Date: Thu Oct 13 10:44:33 2016 -0500 sc16is7xx: Drop bogus use of IRQF_ONESHOT commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream. The use of IRQF_ONESHOT when registering an interrupt handler with request_irq() is non-sensical. Not only that, it also prevents the handler from being threaded when it otherwise should be w/ IRQ_FORCED_THREADING is enabled. This causes the following deadlock observed by Sean Nyekjaer on -rt: Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [..] rt_spin_lock_slowlock from queue_kthread_work queue_kthread_work from sc16is7xx_irq sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu handle_irq_event_percpu from handle_irq_event handle_irq_event from handle_level_irq handle_level_irq from generic_handle_irq generic_handle_irq from mxc_gpio_irq_handler mxc_gpio_irq_handler from mx3_gpio_irq_handler mx3_gpio_irq_handler from generic_handle_irq generic_handle_irq from __handle_domain_irq __handle_domain_irq from gic_handle_irq gic_handle_irq from __irq_svc __irq_svc from rt_spin_unlock rt_spin_unlock from kthread_worker_fn kthread_worker_fn from kthread kthread from ret_from_fork Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq") Reported-by: Sean Nyekjaer Signed-off-by: Josh Cartwright Cc: linux-rt-users@vger.kernel.org Cc: Jakub Kicinski Cc: linux-serial@vger.kernel.org Cc: Sebastian Andrzej Siewior Signed-off-by: Julia Cartwright Acked-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c33e1abd2e31d08c96f512e1af09d874be9bcbfe Author: Marc Zyngier Date: Tue Dec 6 14:34:22 2016 +0000 arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest commit 21cbe3cc8a48ff17059912e019fbde28ed54745a upstream. The ARMv8 architecture allows the cycle counter to be configured by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0, hence accessing PMCCFILTR_EL0. But it disallows the use of PMSELR_EL0.SEL==0x1f to access the cycle counter itself through PMXEVCNTR_EL0. Linux itself doesn't violate this rule, but we may end up with PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1, despite the guest not having done anything wrong. In order to avoid this unfortunate course of events (haha!), let's sanitize PMSELR_EL0 on guest entry. This ensures that the guest won't explode unexpectedly. Acked-by: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit d3d61bb37afb6218cc26970e16cb7568624b5552 Author: Heiko Carstens Date: Mon Nov 28 11:40:27 2016 +0100 s390/kexec: use node 0 when re-adding crash kernel memory commit 9f88eb4df728aebcd2ddd154d99f1d75b428b897 upstream. When re-adding crash kernel memory within setup_resources() the function memblock_add() is used. That function will add memory by default to node "MAX_NUMNODES" instead of node 0, like the memory detection code does. In case of !NUMA this will trigger this warning when the kernel generates the vmemmap: Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead WARNING: CPU: 0 PID: 0 at mm/memblock.c:1261 memblock_virt_alloc_internal+0x76/0x220 CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6 #16 Call Trace: [<0000000000d0b2e8>] memblock_virt_alloc_try_nid+0x88/0xc8 [<000000000083c8ea>] __earlyonly_bootmem_alloc.constprop.1+0x42/0x50 [<000000000083e7f4>] vmemmap_populate+0x1ac/0x1e0 [<0000000000840136>] sparse_mem_map_populate+0x46/0x68 [<0000000000d0c59c>] sparse_init+0x184/0x238 [<0000000000cf45f6>] paging_init+0xbe/0xf8 [<0000000000cf1d4a>] setup_arch+0xa02/0xae0 [<0000000000ced75a>] start_kernel+0x72/0x450 [<0000000000100020>] _stext+0x20/0x80 If NUMA is selected numa_setup_memory() will fix the node assignments before the vmemmap will be populated; so this warning will only appear if NUMA is not selected. To fix this simply use memblock_add_node() and re-add crash kernel memory explicitly to node 0. Reported-and-tested-by: Christian Borntraeger Fixes: 4e042af463f8 ("s390/kexec: fix crash on resize of reserved memory") Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 9652b62af49d8e23eefce58240927bdb61cc3801 Author: Gerald Schaefer Date: Mon Nov 21 12:13:58 2016 +0100 s390/vmlogrdr: fix IUCV buffer allocation commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream. The buffer for iucv_message_receive() needs to be below 2 GB. In __iucv_message_receive(), the buffer address is casted to an u32, which would result in either memory corruption or an addressing exception when using addresses >= 2 GB. Fix this by using GFP_DMA for the buffer allocation. Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit f356ab038e78acb9f34286f060ae1489680434bb Author: Yves-Alexis Perez Date: Fri Nov 11 11:28:40 2016 -0800 firmware: fix usermode helper fallback loading commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream. When you use the firmware usermode helper fallback with a timeout value set to a value greater than INT_MAX (2147483647) a cast overflow issue causes the timeout value to go negative and breaks all usermode helper loading. This regression was introduced through commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") on kernel v4.0. The firmware_class drivers relies on the firmware usermode helper fallback as a mechanism to look for firmware if the direct filesystem search failed only if: a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros): Then all of these callers will rely on the fallback mechanism in case the firmware is not found through an initial direct filesystem lookup: o request_firmware() o request_firmware_into_buf() o request_firmware_nowait() b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros): Then only callers using request_firmware_nowait() with the second argument set to false, this explicitly is requesting the UMH firmware fallback to be relied on in case the first filesystem lookup fails. Using Coccinelle SmPL grammar we have identified only two drivers explicitly requesting the UMH firmware fallback mechanism: - drivers/firmware/dell_rbu.c - drivers/leds/leds-lp55xx-common.c Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the biggest impact of this regression are users of the dell_rbu and leds-lp55xx-common device driver which required the UMH to find their respective needed firmwares. The default timeout for the UMH is set to 60 seconds always, as of commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") the timeout was bumped to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET value was also used if the timeout was configured by a user to 0. The following works: echo 2147483647 > /sys/class/firmware/timeout But both of the following set the timeout to MAX_JIFFY_OFFSET even if we display 0 back to userspace: echo 2147483648 > /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 echo 0> /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 A max value of INT_MAX (2147483647) seconds is therefore implicit due to the another cast with simple_strtol(). This fixes the secondary cast (the first one is simple_strtol() but its an issue only by forcing an implicit limit) by re-using the timeout variable and only setting retval in appropriate cases. Lastly worth noting systemd had ripped out the UMH firmware fallback mechanism from udev since udev 2014 via commit be2ea723b1d023b3d ("udev: remove userspace firmware loading support"), so as of systemd v217. Signed-off-by: Yves-Alexis Perez Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()" Cc: Luis R. Rodriguez Cc: Ming Lei Cc: Bjorn Andersson Cc: Greg Kroah-Hartman Acked-by: Luis R. Rodriguez Reviewed-by: Bjorn Andersson [mcgrof@kernel.org: gave commit log a whole lot of love] Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5c98bf834d6f3d28d7eff26767f3dca564f45c6d Author: Vineet Gupta Date: Mon Dec 19 11:38:38 2016 -0800 ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream. An ARC700 customer reported linux boot crashes when upgrading to bigger L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and current code only assumed 2 colours, while theirs had 4. So default to 4 colours and complain if there are fewer. Ideally this needs to be a Kconfig option, but heck that's too much of hassle for a single user. Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit cc328ce59a4ac7f3a5298038ee8a5e248cf67d3d Author: Wei Fang Date: Tue Dec 13 09:25:21 2016 +0800 scsi: avoid a permanent stop of the scsi device's request queue commit d2a145252c52792bc59e4767b486b26c430af4bb upstream. A race between scanning and fc_remote_port_delete() may result in a permanent stop if the device gets blocked before scsi_sysfs_add_sdev() and unblocked after. The reason is that blocking a device sets both the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However, scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the device to be ignored by scsi_target_unblock() and thus never have its QUEUE_FLAG_STOPPED cleared leading to a device which is apparently running but has a stopped queue. We actually have two places where SDEV_RUNNING is set: once in scsi_add_lun() which respects the blocked flag and once in scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely spurious, simply remove it to fix the problem. Reported-by: Zengxi Chen Signed-off-by: Wei Fang Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6d675dffd425a68e6647e77647eb9976fd6868a1 Author: Steffen Maier Date: Fri Dec 9 17:16:33 2016 +0100 scsi: zfcp: fix rport unblock race with LUN recovery commit 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c upstream. It is unavoidable that zfcp_scsi_queuecommand() has to finish requests with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time window when zfcp detected an unavailable rport but fc_remote_port_delete(), which is asynchronous via zfcp_scsi_schedule_rport_block(), has not yet blocked the rport. However, for the case when the rport becomes available again, we should prevent unblocking the rport too early. In contrast to other FCP LLDDs, zfcp has to open each LUN with the FCP channel hardware before it can send I/O to a LUN. So if a port already has LUNs attached and we unblock the rport just after port recovery, recoveries of LUNs behind this port can still be pending which in turn force zfcp_scsi_queuecommand() to unnecessarily finish requests with DID_IMM_RETRY. This also opens a time window with unblocked rport (until the followup LUN reopen recovery has finished). If a scsi_cmnd timeout occurs during this time window fc_timed_out() cannot work as desired and such command would indeed time out and trigger scsi_eh. This prevents a clean and timely path failover. This should not happen if the path issue can be recovered on FC transport layer such as path issues involving RSCNs. Fix this by only calling zfcp_scsi_schedule_rport_register(), to asynchronously trigger fc_remote_port_add(), after all LUN recoveries as children of the rport have finished and no new recoveries of equal or higher order were triggered meanwhile. Finished intentionally includes any recovery result no matter if successful or failed (still unblock rport so other successful LUNs work). For simplicity, we check after each finished LUN recovery if there is another LUN recovery pending on the same port and then do nothing. We handle the special case of a successful recovery of a port without LUN children the same way without changing this case's semantics. For debugging we introduce 2 new trace records written if the rport unblock attempt was aborted due to still unfinished or freshly triggered recovery. The records are only written above the default trace level. Benjamin noticed the important special case of new recovery that can be triggered between having given up the erp_lock and before calling zfcp_erp_action_cleanup() within zfcp_erp_strategy(). We must avoid the following sequence: ERP thread rport_work other context ------------------------- -------------- -------------------------------- port is unblocked, rport still blocked, due to pending/running ERP action, so ((port->status & ...UNBLOCK) != 0) and (port->rport == NULL) unlock ERP zfcp_erp_action_cleanup() case ZFCP_ERP_ACTION_REOPEN_LUN: zfcp_erp_try_rport_unblock() ((status & ...UNBLOCK) != 0) [OLD!] zfcp_erp_port_reopen() lock ERP zfcp_erp_port_block() port->status clear ...UNBLOCK unlock ERP zfcp_scsi_schedule_rport_block() port->rport_task = RPORT_DEL queue_work(rport_work) zfcp_scsi_rport_work() (port->rport_task != RPORT_ADD) port->rport_task = RPORT_NONE zfcp_scsi_rport_block() if (!port->rport) return zfcp_scsi_schedule_rport_register() port->rport_task = RPORT_ADD queue_work(rport_work) zfcp_scsi_rport_work() (port->rport_task == RPORT_ADD) port->rport_task = RPORT_NONE zfcp_scsi_rport_register() (port->rport == NULL) rport = fc_remote_port_add() port->rport = rport; Now the rport was erroneously unblocked while the zfcp_port is blocked. This is another situation we want to avoid due to scsi_eh potential. This state would at least remain until the new recovery from the other context finished successfully, or potentially forever if it failed. In order to close this race, we take the erp_lock inside zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or LUN. With that, the possible corresponding rport state sequences would be: (unblock[ERP thread],block[other context]) if the ERP thread gets erp_lock first and still sees ((port->status & ...UNBLOCK) != 0), (block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock after the other context has already cleard ...UNBLOCK from port->status. Since checking fields of struct erp_action is unsafe because they could have been overwritten (re-used for new recovery) meanwhile, we only check status of zfcp_port and LUN since these are only changed under erp_lock elsewhere. Regarding the check of the proper status flags (port or port_forced are similar to the shown adapter recovery): [zfcp_erp_adapter_shutdown()] zfcp_erp_adapter_reopen() zfcp_erp_adapter_block() * clear UNBLOCK ---------------------------------------+ zfcp_scsi_schedule_rports_block() | write_lock_irqsave(&adapter->erp_lock, flags);-------+ | zfcp_erp_action_enqueue() | | zfcp_erp_setup_act() | | * set ERP_INUSE -----------------------------------|--|--+ write_unlock_irqrestore(&adapter->erp_lock, flags);--+ | | .context-switch. | | zfcp_erp_thread() | | zfcp_erp_strategy() | | write_lock_irqsave(&adapter->erp_lock, flags);------+ | | ... | | | zfcp_erp_strategy_check_target() | | | zfcp_erp_strategy_check_adapter() | | | zfcp_erp_adapter_unblock() | | | * set UNBLOCK -----------------------------------|--+ | zfcp_erp_action_dequeue() | | * clear ERP_INUSE ---------------------------------|-----+ ... | write_unlock_irqrestore(&adapter->erp_lock, flags);-+ Hence, we should check for both UNBLOCK and ERP_INUSE because they are interleaved. Also we need to explicitly check ERP_FAILED for the link down case which currently does not clear the UNBLOCK flag in zfcp_fsf_link_down_info_eval(). Signed-off-by: Steffen Maier Fixes: 8830271c4819 ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport") Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors") Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI") Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable") Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again") Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 057fe03d627eb6eadf8ca67067b479e6ab52405e Author: Steffen Maier Date: Fri Dec 9 17:16:32 2016 +0100 scsi: zfcp: do not trace pure benign residual HBA responses at default level commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream. Since quite a while, Linux issues enough SCSI commands per scsi_device which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE, and SAM_STAT_GOOD. This floods the HBA trace area and we cannot see other and important HBA trace records long enough. Therefore, do not trace HBA response errors for pure benign residual under counts at the default trace level. This excludes benign residual under count combined with other validity bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL. For all those other cases, we still do want to see both the HBA record and the corresponding SCSI record by default. Signed-off-by: Steffen Maier Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5cebfea8080cafff89cf5881516824a1dec750bf Author: Benjamin Block Date: Fri Dec 9 17:16:31 2016 +0100 scsi: zfcp: fix use-after-"free" in FC ingress path after TMF commit dac37e15b7d511e026a9313c8c46794c144103cd upstream. When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and eh_target_reset_handler(), it expects us to relent the ownership over the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN or target - when returning with SUCCESS from the callback ('release' them). SCSI EH can then reuse those commands. We did not follow this rule to release commands upon SUCCESS; and if later a reply arrived for one of those supposed to be released commands, we would still make use of the scsi_cmnd in our ingress tasklet. This will at least result in undefined behavior or a kernel panic because of a wrong kernel pointer dereference. To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req *)->data in the matching scope if a TMF was successful. This is done under the locks (struct zfcp_adapter *)->abort_lock and (struct zfcp_reqlist *)->lock to prevent the requests from being removed from the request-hashtable, and the ingress tasklet from making use of the scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler(). For cases where a reply arrives during SCSI EH, but before we get a chance to NULLify the pointer - but before we return from the callback -, we assume that the code is protected from races via the CAS operation in blk_complete_request() that is called in scsi_done(). The following stacktrace shows an example for a crash resulting from the previous behavior: Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000 Oops: 0038 [#1] SMP CPU: 2 PID: 0 Comm: swapper/2 Not tainted task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000 Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015 ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800 000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93 00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918 Krnl Code: 00000000001156a2: a7190000 lghi %r1,0 00000000001156a6: a7380015 lhi %r3,21 #00000000001156aa: e32050000008 ag %r2,0(%r5) >00000000001156b0: 482022b0 lh %r2,688(%r2) 00000000001156b4: ae123000 sigp %r1,%r2,0(%r3) 00000000001156b8: b2220020 ipm %r2 00000000001156bc: 8820001c srl %r2,28 00000000001156c0: c02700000001 xilf %r2,1 Call Trace: ([<0000000000000000>] 0x0) [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp] [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp] [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp] [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp] [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio] [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio] [<0000000000141fd4>] tasklet_action+0x9c/0x170 [<0000000000141550>] __do_softirq+0xe8/0x258 [<000000000010ce0a>] do_softirq+0xba/0xc0 [<000000000014187c>] irq_exit+0xc4/0xe8 [<000000000046b526>] do_IRQ+0x146/0x1d8 [<00000000005d6a3c>] io_return+0x0/0x8 [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0 ([<0000000000000000>] 0x0) [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0 [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8 [<0000000000114782>] smp_start_secondary+0xda/0xe8 [<00000000005d6efe>] restart_int_handler+0x56/0x6c [<0000000000000000>] 0x0 Last Breaking-Event-Address: [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0 Suggested-by: Steffen Maier Signed-off-by: Benjamin Block Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git) Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit de8a06c673ac38e9f76fb97a6ffe48034d9ba6b8 Author: Varun Prakash Date: Sun Dec 11 22:05:56 2016 +0530 iscsi-target: Return error if unable to add network portal commit 83337e544323a8bd7492994d64af339175ac7107 upstream. If iscsit_tpg_add_network_portal() fails then return error code instead of 0 to user space. If iscsi-target returns 0 then user space keeps on retrying same command infinitely, targetcli or echo hangs till command completes with non zero return value. In some cases it is possible that add network portal command never completes with success even after retrying multiple times, for example - cxgbit_setup_np() always returns -EINVAL if portal IP does not belong to Chelsio adapter interface. Signed-off-by: Varun Prakash Signed-off-by: Bart Van Assche [ bvanassche: Added "Fixes:" and "Cc: stable" tags ] Fixes: commit d4b3fa4b0881 ("iscsi-target: Make iscsi_tpg_np driver show/store use generic code") Signed-off-by: Greg Kroah-Hartman commit 9c3928be0dbac79a2f5c340e2ea829b296f8a946 Author: Kashyap Desai Date: Fri Oct 21 06:33:35 2016 -0700 scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map commit d5573584429254a14708cf8375c47092b5edaf2c upstream. Signed-off-by: Sumit Saxena Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit dbd4e6c60b4feecd0eb98537325bfc1caa2a40ef Author: Kashyap Desai Date: Fri Oct 21 06:33:29 2016 -0700 scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset commit 18e1c7f68a5814442abad849abe6eacbf02ffd7c upstream. For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. Signed-off-by: Kiran Kumar Kasturi Signed-off-by: Sumit Saxena Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3863ab6d710d7d1012c651601bd97403501bbb6f Author: Johan Hovold Date: Fri Nov 18 14:17:31 2016 +0200 stm class: Fix device leak in open error path commit a0ebf519b8a2666438d999c62995618c710573e5 upstream. Make sure to drop the reference taken by class_find_device() also on allocation errors in open(). Signed-off-by: Johan Hovold Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for...") Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit 698ac693dbb4aa3cefa042aecfd08475e97fe390 Author: Maciej S. Szmigiero Date: Wed Nov 16 00:55:57 2016 +0100 vt: fix Scroll Lock LED trigger name commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream. There is a disagreement between drivers/tty/vt/keyboard.c and drivers/input/input-leds.c with regard to what is a Scroll Lock LED trigger name: input calls it "kbd-scrolllock", but vt calls it "kbd-scrollock" (two l's). This prevents Scroll Lock LED trigger from binding to this LED by default. Since it is a scroLL Lock LED, this interface was introduced only about a year ago and in an Internet search people seem to reference this trigger only to set it to this LED let's simply rename it to "kbd-scrolllock". Also, it looks like this was supposed to be changed before this code was merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on the input side. Signed-off-by: Maciej S. Szmigiero Acked-by: Samuel Thibault Signed-off-by: Greg Kroah-Hartman commit 6d8bb567102cddf46b349cdc3ae6a73254503c61 Author: Rabin Vincent Date: Thu Dec 1 09:18:28 2016 +0100 block: protect iterate_bdevs() against concurrent close commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream. If a block device is closed while iterate_bdevs() is handling it, the following NULL pointer dereference occurs because bdev->b_disk is NULL in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in turn called by the mapping_cap_writeback_dirty() call in __filemap_fdatawrite_range()): BUG: unable to handle kernel NULL pointer dereference at 0000000000000508 IP: [] blk_get_backing_dev_info+0x10/0x20 PGD 9e62067 PUD 9ee8067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000 RIP: 0010:[] [] blk_get_backing_dev_info+0x10/0x20 RSP: 0018:ffff880009f5fe68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940 RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0 RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860 R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38 FS: 00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0 Stack: ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff 0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001 ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f Call Trace: [] __filemap_fdatawrite_range+0x85/0x90 [] filemap_fdatawrite+0x1f/0x30 [] fdatawrite_one_bdev+0x16/0x20 [] iterate_bdevs+0xf2/0x130 [] sys_sync+0x63/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x76 Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d RIP [] blk_get_backing_dev_info+0x10/0x20 RSP CR2: 0000000000000508 ---[ end trace 2487336ceb3de62d ]--- The crash is easily reproducible by running the following command, if an msleep(100) is inserted before the call to func() in iterate_devs(): while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done Fix it by holding the bd_mutex across the func() call and only calling func() if the bdev is opened. Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices") Reported-and-tested-by: Wei Fang Signed-off-by: Rabin Vincent Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2695afd5e9c2ac7014760972107a2dd3013fec72 Author: Tomas Winkler Date: Tue Nov 29 16:49:27 2016 +0200 mei: me: add lewisburg device ids commit 9ff2007bea1f1bfc53ac0bc7ccf8200bb275fd52 upstream. Add MEI Lewisburg PCH IDs for Purley based workstations. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 7be0a5f39d64df67bd1d1d0e0174b4c310bec82e Author: Alexander Usyskin Date: Thu Nov 24 13:34:02 2016 +0200 mei: request async autosuspend at the end of enumeration commit d5f8e166c25750adc147b0adf64a62a91653438a upstream. pm_runtime_autosuspend can take synchronous or asynchronous paths, Because we are calling pm_runtime_mark_last_busy just before this most of the cases it takes the asynchronous way. However, when the FW or driver resets during already running runtime suspend, the call will result in calling to the driver's rpm callback and results in a deadlock on device_lock. The simplest fix is to replace pm_runtime_autosuspend with asynchronous pm_request_autosuspend. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit dfc3c8a0fa1b0a2299fbb5cb01f73657c7213479 Author: Russell Currey Date: Thu Dec 15 16:12:41 2016 +1100 drivers/gpu/drm/ast: Fix infinite loop if read fails commit 298360af3dab45659810fdc51aba0c9f4097e4f6 upstream. ast_get_dram_info() configures a window in order to access BMC memory. A BMC register can be configured to disallow this, and if so, causes an infinite loop in the ast driver which renders the system unusable. Fix this by erroring out if an error is detected. On powerpc systems with EEH, this leads to the device being fenced and the system continuing to operate. Signed-off-by: Russell Currey Reviewed-by: Joel Stanley Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.cc Signed-off-by: Greg Kroah-Hartman commit 0f95e4a58ecdd368299558e46500e2064e5e5f67 Author: Rex Zhu Date: Wed Dec 7 17:44:20 2016 +0800 drm/amdgpu: fix init save/restore list in gfx_v8.0 commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream. set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx. Signed-off-by: Rex Zhu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8bfa4f5e639544520fc1854942a2fbb5581cf2df Author: Patrik Jakobsson Date: Tue Nov 1 15:43:15 2016 +0100 drm/gma500: Add compat ioctl commit 0a97c81a9717431e6c57ea845b59c3c345edce67 upstream. Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels. It turns out that N2600 and N2800 comes with 64-bit enabled. We previously assumed there where no such systems out there. Signed-off-by: Patrik Jakobsson Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.com Signed-off-by: Greg Kroah-Hartman commit 10b598df92d9912a0ebac911fadc4ae1a79102b7 Author: Alex Deucher Date: Fri Dec 2 00:23:35 2016 -0500 drm/radeon/si: load the proper firmware on 0x87 oland boards commit abb2e3c1ce64c8bba678973800c34ea1dc97c42c upstream. New variant. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit cdb7aaaaecff06e1bf9b227608757f7eaf89b79a Author: Alex Deucher Date: Fri Dec 2 00:21:48 2016 -0500 drm/radeon: add additional pci revision to dpm workaround commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream. New variant. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1f884ec818a6577d2ca447f93d08645ca6293fb8 Author: Michel Dänzer Date: Thu Oct 27 14:54:31 2016 +0900 drm/radeon: Hide the HW cursor while it's out of bounds commit 6b16cf7785a4200b1bddf4f70c9dda2efc49e278 upstream. Fixes hangs in that case under some circumstances. v2: * Only use non-0 x/yorigin if the cursor is (partially) outside of the top/left edge of the total surface with AVIVO/DCE Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000433 Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher (v1) Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6fb94229b2f640815ec4086a532ab99c56303241 Author: Michel Dänzer Date: Thu Oct 27 13:03:23 2016 +0900 drm/radeon: Also call cursor_move_locked when the cursor size changes commit dcab0fa64e300afa18f39cd98d05e0950f652adf upstream. The cursor size also affects the register programming. Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9c6fb7bf404d3ea131e16a083e678f792019a78c Author: Ben Skeggs Date: Sat Nov 5 14:33:14 2016 +1000 drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex commit b27add13f500469127afdf011dbcc9c649e16e54 upstream. This avoids an issue that occurs when we're attempting to preempt multiple channels simultaneously. HW seems to ignore preempt requests while it's still processing a previous one, which, well, makes sense. Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel piglit runs on (at least) GM107. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 2a7a43772bffce5e2e155d63d9e1f895153063b3 Author: Ben Skeggs Date: Thu Nov 3 16:37:33 2016 +1000 drm/nouveau/i2c/gk110b,gm10x: use the correct implementation commit 5b3800a6b763874e4a23702fb9628d3bd3315ce9 upstream. DPAUX registers moved on Kepler, these chipsets were still using the Fermi implementation for some reason. This fixes detection of hotplug/sink IRQs on DP connectors. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 28d18643068671b6e63100d5d14acb22725fcbad Author: Ben Skeggs Date: Mon Dec 12 17:52:45 2016 +1000 drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream. TTM was changed a while back to allow for pipelining of buffer moves, and part of this was the removal of waiting for a BO to idle before calling move(), placing the responsibility on the driver to do this if required. That's all well and good, except, we make use of move_notify() to handle mapping/unmapping from the GPU VMM as move() isn't called on all paths. This commit adds a wait before unmapping from a VMM in move_notify(), to prevent GPU page faults where a buffer is still being accessed. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 82d9824d94467b20469dde7291c68012a36e80bf Author: Ben Skeggs Date: Tue Dec 13 09:29:55 2016 +1000 drm/nouveau/ltc: protect clearing of comptags with mutex commit f4e65efc88b64c1dbca275d42a188edccedb56c6 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit ce71868acee24bdc9c8d436d5bc562bf43beab2f Author: Ben Skeggs Date: Fri Oct 14 13:16:36 2016 +1000 drm/nouveau/bios: require checksum to match for fast acpi shadow method commit 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 764e8e8af1906f1cb1031c57d985daecf74055dd Author: Ben Skeggs Date: Wed Oct 19 12:15:52 2016 +1000 drm/nouveau/kms: lvds panel strap moved again on maxwell commit 768e847759d551c96e129e194588dbfb11a1d576 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 00e1fb138ffacf4c8141a03e5d5ef81cc548dc10 Author: Alexandre Courbot Date: Fri Nov 4 18:36:17 2016 +0900 drm/nouveau/gr: fallback to legacy paths during firmware lookup commit e137040e0d0376b404fc5155eba44ea07126e3bd upstream. Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia//gr/" path. Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external firmwares") Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit fef542735a48d2029c8c1e509772884e4ec321e7 Author: Arindam Nath Date: Fri Nov 25 16:55:16 2016 +0530 drm/amd/amdgpu: enable GUI idle INT after enabling CGCG commit dd31ae9ac933636c3712b7dd0f6152c1d71f81fe upstream. GUI idle interrupts should be enabled only after we have enabled coarse grain clock gating (CGCG). This prevents GFX engine generating idle interrupt even though CGCG is not completely enabled. Most of the time this goes un-noticed, but on some Stoney ASICs this results in GFX engine hang after system resumes from suspend. The issue is not particular to Stoney though and could have occured on any ASIC. The patch fixes this issue. Reviewed-by: Alex Deucher Reported-by: Sunil Uttarwar Signed-off-by: Arindam Nath Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit bab520835f81565c2e88ca15063de00f22e56331 Author: Hans de Goede Date: Tue Nov 29 15:32:16 2016 +0100 ACPI / video: Add force_native quirk for HP Pavilion dv6 commit 6276e53fa8c06a3a5cf7b95b77b079966de9ad66 upstream. The HP Pavilion dv6 has a non-working acpi_video0 backlight interface and an intel_backlight interface which works fine. Add a force_native quirk for it so that the non-working acpi_video0 interface does not get registered. Note that there are quite a few HP Pavilion dv6 variants, some woth ATI and some with NVIDIA hybrid gfx, both seem to need this quirk to have working backlight control. There are also some versions with only Intel integrated gfx, these may not need this quirk, but it should not hurt there. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1204476 Link: https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1416940 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b7eea51a3a5cfe625c671cfc2d004758fa2a36c3 Author: Hans de Goede Date: Tue Nov 29 15:32:15 2016 +0100 ACPI / video: Add force_native quirk for Dell XPS 17 L702X commit 350fa038c31b056fc509624efb66348ac2c1e3d0 upstream. The Dell XPS 17 L702X has a non-working acpi_video0 backlight interface and an intel_backlight interface which works fine. Add a force_native quirk for it so that the non-working acpi_video0 interface does not get registered. Note that there also is an issue with the brightnesskeys on this laptop, they do not generate key-press events in anyway. That is not solved by this patch. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123661 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ce8100660364624c1b7f649a0a59f0554f9ce540 Author: Ian Abbott Date: Mon Nov 14 20:16:22 2016 +0000 staging: comedi: ni_mio_common: fix E series ni_ai_insn_read() data commit 857a661020a2de3a0304edf33ad656abee100891 upstream. Commit 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for 32-bit read") changed the type of local variable `d` from `unsigned short` to `unsigned int` to fix a bug introduced in commit 9c340ac934db ("staging: comedi: ni_stc.h: add read/write callbacks to struct ni_private") when reading AI data for NI PCI-6110 and PCI-6111 cards. Unfortunately, other parts of the function rely on the variable being `unsigned short` when an offset value in local variable `signbits` is added to `d` before writing the value to the `data` array: d += signbits; data[n] = d; The `signbits` variable will be non-zero in bipolar mode, and is used to convert the hardware's 2's complement, 16-bit numbers to Comedi's straight binary sample format (with 0 representing the most negative voltage). This breaks because `d` is now 32 bits wide instead of 16 bits wide, so after the addition of `signbits`, `data[n]` ends up being set to values above 65536 for negative voltages. This affects all supported "E series" cards except PCI-6143 (and PXI-6143). Fix it by ANDing the value written to the `data[n]` with the mask 0xffff. Fixes: 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for 32-bit read") Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 689d592593859f2ff20b7adce6b69e0c3999ecc6 Author: Ian Abbott Date: Mon Nov 14 20:16:21 2016 +0000 staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask commit 655c4d442d1213b617926cc6d54e2a9a793fb46b upstream. For NI M Series cards, the Comedi `insn_read` handler for the AI subdevice is broken due to ANDing the value read from the AI FIFO data register with an incorrect mask. The incorrect mask clears all but the most significant bit of the sample data. It should preserve all the sample data bits. Correct it. Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'") Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 823c5c94f716d1dcfa8335cc87667f25a1573fb9 Author: Vitaly Kuznetsov Date: Sat Dec 3 12:34:32 2016 -0800 hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels() commit abd1026da4a7700a8db370947f75cd17b6ae6f76 upstream. "kernel BUG at drivers/hv/channel_mgmt.c:350!" is observed when hv_vmbus module is unloaded. BUG_ON() was introduced in commit 85d9aa705184 ("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()") as vmbus_free_channels() codepath was apparently forgotten. Fixes: 85d9aa705184 ("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()") Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 235394e1625c812f2498455cee05598715afa2ea Author: Dmitry Shachnev Date: Sun Dec 18 13:11:46 2016 +0300 docs: sphinx-extensions: make rstFlatTable work with docutils 0.13 commit 217e2bfab22e740227df09f22165e834cddd8a3b upstream. In docutils 0.13, the return type of get_column_widths method of the Table directive has changed [1], which breaks our flat-table directive and leads to a TypeError when trying to build the docs [2]. This patch adds support for the new return type, while keeping support for older docutils versions too. [1] https://sourceforge.net/p/docutils/patches/120/ [2] https://sourceforge.net/p/docutils/bugs/303/ Signed-off-by: Dmitry Shachnev Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit a26a016a4e2f28d54a2145e705c4466ca4b9677a Author: Krzysztof Kozlowski Date: Tue Nov 22 19:22:44 2016 +0200 thermal: hwmon: Properly report critical temperature in sysfs commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream. In the critical sysfs entry the thermal hwmon was returning wrong temperature to the user-space. It was reporting the temperature of the first trip point instead of the temperature of critical trip point. For example: /sys/class/hwmon/hwmon0/temp1_crit:50000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:50000 /sys/class/thermal/thermal_zone0/trip_point_0_type:active /sys/class/thermal/thermal_zone0/trip_point_3_temp:120000 /sys/class/thermal/thermal_zone0/trip_point_3_type:critical Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver have been registering a sysfs entry if get_crit_temp() callback was provided. However when accessed, it was calling get_trip_temp() instead of the get_crit_temp(). Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit def2c87dc7ac57e2c80a4436db9931755208c1a6 Author: Boris Brezillon Date: Thu Dec 1 20:27:21 2016 +0100 clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk commit 68af4fa8f39b542a6cde7ac19518d88e9b3099dc upstream. bcm2835_pll_divider_off() is resetting the divider field in the A2W reg to zero when disabling the clock. Make sure we preserve this value by reading the previous a2w_reg value first and ORing the result with A2W_PLL_CHANNEL_DISABLE. Signed-off-by: Boris Brezillon Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Reviewed-by: Eric Anholt Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 2f885dafe704099a32047f086885b6f7ae1b0937 Author: Alexandre Courbot Date: Fri Dec 2 20:57:55 2016 +0100 arm64: tegra: Add VDD_GPU regulator to Jetson TX1 commit 5e6b9a89afceadb1ee45472098f7d20af260335c upstream. Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson TX1 board. This addition allows the GPU to be used provided the bootloader properly enabled the GPU node. Signed-off-by: Alexandre Courbot Signed-off-by: Thierry Reding [as pointed out by Thierry on IRC, nobody has reported a bug in the field, but using a new bootloader with a .dtb that has the incorrect data, it will crash on boot] Fixes: 336f79c7b6d7 ("arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit bd12562fceb4135c1afde730aa2aab24feff6705 Author: Lars-Peter Clausen Date: Wed Nov 30 13:05:21 2016 +0100 gpio: chardev: Return error for seek operations commit f4e81c529767b9a33d1b27695c54dc84a14af30d upstream. The GPIO chardev is used for management tasks (allocating line and event handles) and does neither support read() nor write() operations. Hence it does not make much sense to allow seek operations. Currently the chardev uses noop_llseek() for its seek implementation. This function does not move the pointer and simply returns the current position (always 0 for the GPIO chardev). noop_llseek() is primarily meant for devices that can not support seek, but where there might be a user that depends on the seek() operation succeeding. For newly added devices that can not support seek operations it is recommended to use no_llseek(), which will return an error. For more information see commit 6038f373a3dc ("llseek: automatically add .llseek fop"). Unfortunately this was overlooked when the GPIO chardev ABI was introduced. But it is highly unlikely that since then userspace applications have appeared that rely on being able to perform non-failing seek operations on a GPIO chardev file descriptor. So it should be safe to change from noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags from the file. Neither of these should be set on a file that does not support seek operations. Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 61d0b7139cf97fedfd9176a3ae7d7ed560121c65 Author: Thomas Gleixner Date: Thu Dec 8 20:49:32 2016 +0000 timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion commit 9c1645727b8fa90d07256fdfcc45bf831242a3ab upstream. The clocksource delta to nanoseconds conversion is using signed math, but the delta is unsigned. This makes the conversion space smaller than necessary and in case of a multiplication overflow the conversion can become negative. The conversion is done with scaled math: s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift; Shifting a signed integer right obvioulsy preserves the sign, which has interesting consequences: - Time jumps backwards - __iter_div_u64_rem() which is used in one of the calling code pathes will take forever to piecewise calculate the seconds/nanoseconds part. This has been reported by several people with different scenarios: David observed that when stopping a VM with a debugger: "It was essentially the stopped by debugger case. I forget exactly why, but the guest was being explicitly stopped from outside, it wasn't just scheduling lag. I think it was something in the vicinity of 10 minutes stopped." When lifting the stop the machine went dead. The stopped by debugger case is not really interesting, but nevertheless it would be a good thing not to die completely. But this was also observed on a live system by Liav: "When the OS is too overloaded, delta will get a high enough value for the msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so after the shift the nsec variable will gain a value similar to 0xffffffffff000000." Unfortunately this has been reintroduced recently with commit 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation"). It had been fixed a year ago already in commit 35a4933a8959 ("time: Avoid signed overflow in timekeeping_get_ns()"). Though it's not surprising that the issue has been reintroduced because the function itself and the whole call chain uses s64 for the result and the propagation of it. The change in this recent commit is subtle: s64 nsec; - nsec = (d * m + n) >> s: + nsec = d * m + n; + nsec >>= s; d being type of cycle_t adds another level of obfuscation. This wouldn't have happened if the previous change to unsigned computation would have made the 'nsec' variable u64 right away and a follow up patch had cleaned up the whole call chain. There have been patches submitted which basically did a revert of the above patch leaving everything else unchanged as signed. Back to square one. This spawned a admittedly pointless discussion about potential users which rely on the unsigned behaviour until someone pointed out that it had been fixed before. The changelogs of said patches added further confusion as they made finally false claims about the consequences for eventual users which expect signed results. Despite delta being cycle_t, aka. u64, it's very well possible to hand in a signed negative value and the signed computation will happily return the correct result. But nobody actually sat down and analyzed the code which was added as user after the propably unintended signed conversion. Though in sensitive code like this it's better to analyze it proper and make sure that nothing relies on this than hunting the subtle wreckage half a year later. After analyzing all call chains it stands that no caller can hand in a negative value (which actually would work due to the s64 cast) and rely on the signed math to do the right thing. Change the conversion function to unsigned math. The conversion of all call chains is done in a follow up patch. This solves the starvation issue, which was caused by the negative result, but it does not solve the underlying problem. It merily procrastinates it. When the timekeeper update is deferred long enough that the unsigned multiplication overflows, then time going backwards is observable again. It does neither solve the issue of clocksources with a small counter width which will wrap around possibly several times and cause random time stamps to be generated. But those are usually not found on systems used for virtualization, so this is likely a non issue. I took the liberty to claim authorship for this simply because analyzing all callsites and writing the changelog took substantially more time than just making the simple s/s64/u64/ change and ignore the rest. Fixes: 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation") Reported-by: David Gibson Reported-by: Liav Rehana Signed-off-by: Thomas Gleixner Reviewed-by: David Gibson Acked-by: Peter Zijlstra (Intel) Cc: Parit Bhargava Cc: Laurent Vivier Cc: "Christopher S. Hall" Cc: Chris Metcalf Cc: Richard Cochran Cc: John Stultz Link: http://lkml.kernel.org/r/20161208204228.688545601@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 95d2a43e5a59f4ff08976171a7f205d926b2b168 Author: Linus Walleij Date: Sat Nov 12 15:22:38 2016 +0100 regulator: stw481x-vmmc: fix ages old enable error commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream. The regulator has never been properly enabled, it has been dormant all the time. It's strange that MMC was working at all, but it likely worked by the signals going through the levelshifter and reaching the card anyways. Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver") Signed-off-by: Linus Walleij Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 52980ceb1832dcf9629cbd34b762d55ac7cd46b7 Author: Adrian Hunter Date: Fri Dec 2 15:14:20 2016 +0200 mmc: sdhci: Fix recovery from tuning timeout commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream. Clearing the tuning bits should reset the tuning circuit. However there is more to do. Reset the command and data lines for good measure, and then for eMMC ensure the card is not still trying to process a tuning command by sending a stop command. Note the JEDEC eMMC specification says the stop command (CMD12) can be used to stop a tuning command (CMD21) whereas the SD specification is silent on the subject with respect to the SD tuning command (CMD19). Considering that CMD12 is not a valid SDIO command, the stop command is sent only when the tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far which have been on eMMC. Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits after tuning failure") which is being reverted for v4.9+. Signed-off-by: Adrian Hunter Tested-by: Dan O'Donovan Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0ed0b2592437dd614aaf3eef6d5eb540c7eccf77 Author: Vittorio Gambaletta (VittGam) Date: Wed Nov 9 03:40:56 2016 +0200 ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards. commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream. The active_high LED of my Wistron DNMA-92 is still being recognized as active_low on 4.7.6 mainline. When I was preparing my former commit 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.") to fix that I must have somehow messed up with testing, because I tested the final version of that patch before sending it, and it was apparently working; but now it is not working on 4.7.6 mainline. I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section for 0x0029; but then I moved the former below the latter after seeing how 0x002A sections were sorted in the file. This turned out to be wrong: if a generic PCI_VDEVICE entry (that has both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will match first and will be used. With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6. While I'm at it, let's fix 0x002A too by also moving its generic definition below its specific ones. Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.") Signed-off-by: Vittorio Gambaletta [kvalo@qca.qualcomm.com: improve the commit log based on email discussions] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit d80ff7cb5d06a8ef3fe910f7c0b2569f1bba60b6 Author: Matthias Schiffer Date: Tue Nov 15 18:47:21 2016 +0100 ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success commit 91851cc7a939039bd401adb6ca3da4402bec1d0c upstream. Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs, changing the return on success from 1 to BIT(gpio). This broke some callers like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the moment, but should be fixed anyway. Instead of fixing all callers, change ath9k_hw_gpio_get() back to only return 0 or 1. Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC") Signed-off-by: Matthias Schiffer [kvalo@qca.qualcomm.com: mention that doesn't fix any known bug] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 42e76c596c938769891b04f0619c87fd001ac1de Author: Johannes Berg Date: Thu Dec 8 17:22:09 2016 +0100 cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream. When mac80211 abandons an association attempt, it may free all the data structures, but inform cfg80211 and userspace about it only by sending the deauth frame it received, in which case cfg80211 has no link to the BSS struct that was used and will not cfg80211_unhold_bss() it. Fix this by providing a way to inform cfg80211 of this with the BSS entry passed, so that it can clean up properly, and use this ability in the appropriate places in mac80211. This isn't ideal: some code is more or less duplicated and tracing is missing. However, it's a fairly small change and it's thus easier to backport - cleanups can come later. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d2546f653bb00fbced0c667a499242b0fc69d2ad Author: Jes Sorensen Date: Tue Nov 29 18:59:02 2016 -0500 rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting commit c59f13bbead475096bdfebc7ef59c12e180858de upstream. The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and 8723bu devices not being able to reconnect. Reported-by: Barry Day Signed-off-by: Jes Sorensen Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 2abcc023a46046bce2b378715394c88fd9a6cdc7 Author: Thomas Gleixner Date: Thu Dec 22 11:02:08 2016 +0100 perf/x86/intel/cstate: Prevent hotplug callback leak commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream. If the pmu registration fails the registered hotplug callbacks are not removed. Wrong in any case, but fatal in case of a modular driver. Replace the nonsensical state names with proper ones while at it. Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug state machine") Signed-off-by: Thomas Gleixner Cc: Sebastian Siewior Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 7b9e1a16a1b080939a5fabf4441ba337246f531e Author: Andi Kleen Date: Thu Dec 8 16:14:17 2016 -0800 perf/x86: Fix exclusion of BTS and LBR for Goldmont commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream. An earlier patch allowed enabling PT and LBR at the same time on Goldmont. However it also allowed enabling BTS and LBR at the same time, which is still not supported. Fix this by bypassing the check only for PT. Signed-off-by: Andi Kleen Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: alexander.shishkin@intel.com Cc: kan.liang@intel.com Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") Link: http://lkml.kernel.org/r/20161209001417.4713-1-andi@firstfloor.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e24523a80c19b549e6dbc4cb7b9ec8a066a2d75c Author: Larry Finger Date: Sat Nov 26 14:43:35 2016 -0600 rtlwifi: Fix enter/exit power_save commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream. In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue"), an error was introduced in the power-save routines due to the fact that leaving PS was delayed by the use of a work queue. This problem is fixed by detecting if the enter or leave routines are in interrupt mode. If so, the workqueue is used to place the request. If in normal mode, the enter or leave routines are called directly. Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue") Reported-by: Ping-Ke Shih Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit c9fce6ba9c09b0b396ea07544b41be5c21921196 Author: Larry Finger Date: Sat Nov 5 14:08:57 2016 -0500 ssb: Fix error routine when fallback SPROM fails commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream. When there is a CRC error in the SPROM read from the device, the code attempts to handle a fallback SPROM. When this also fails, the driver returns zero rather than an error code. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman