aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-04-19ARM: 8563/1: fix demoting HWCAP_SWPVladimir Murzin1-1/+1
Commit b8c9592 "ARM: 8318/1: treat CPU feature register fields as signed quantities" accidentally altered cpuid register used to demote HWCAP_SWP. ARM ARM says that SyncPrim_instrs bits in ID_ISAR3 should be used with SynchPrim_instrs_frac from ID_ISAR4. So, follow this rule. Signed-off-by: Vladimir Murzin <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Russell King <[email protected]>
2016-04-19Input: twl6040-vibra - ignore return value of schedule_workH. Nikolaus Schaller1-5/+1
Returning ret is wrong. And checking for an error as well. User space may call multiple times until the work is really scheduled. twl4030-vibra.c also ignores the return value. Signed-off-by: H. Nikolaus Schaller <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-04-19Input: twl6040-vibra - fix NULL pointer dereference by removing workqueueH. Nikolaus Schaller1-2/+1
commit 21fb9f0d5e91 ("Input: twl6040-vibra - use system workqueue") says that it switches to use the system workqueue but it did neither - remove the workqueue struct variable - replace code to really use the system workqueue Instead it calls queue_work() on uninitialized info->workqueue. The result is a NULL pointer dereference in vibra_play(). Solution: use schedule_work Signed-off-by: H. Nikolaus Schaller <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-04-19ALSA: ens1371: Fix "Line In->Rear Out Switch" controlTakashi Iwai1-1/+1
The "Line In->Rear Out Switch" control on ens1371 driver returns a bogus value, always true, as its check is totally broken. Fix it to check the proper GPIO bit mask. Reported-by: David Binderman <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-04-19locking/pvqspinlock: Fix division by zero in qstat_read()Davidlohr Bueso1-3/+5
While playing with the qstat statistics (in <debugfs>/qlockstat/) I ran into the following splat on a VM when opening pv_hash_hops: divide error: 0000 [#1] SMP ... RIP: 0010:[<ffffffff810b61fe>] [<ffffffff810b61fe>] qstat_read+0x12e/0x1e0 ... Call Trace: [<ffffffff811cad7c>] ? mem_cgroup_commit_charge+0x6c/0xd0 [<ffffffff8119750c>] ? page_add_new_anon_rmap+0x8c/0xd0 [<ffffffff8118d3b9>] ? handle_mm_fault+0x1439/0x1b40 [<ffffffff811937a9>] ? do_mmap+0x449/0x550 [<ffffffff811d3de3>] ? __vfs_read+0x23/0xd0 [<ffffffff811d4ab2>] ? rw_verify_area+0x52/0xd0 [<ffffffff811d4bb1>] ? vfs_read+0x81/0x120 [<ffffffff811d5f12>] ? SyS_read+0x42/0xa0 [<ffffffff815720f6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 Fix this by verifying that qstat_pv_kick_unlock is in fact non-zero, similarly to what the qstat_pv_latency_wake case does, as if nothing else, this can come from resetting the statistics, thus having 0 kicks should be quite valid in this context. Signed-off-by: Davidlohr Bueso <[email protected]> Reviewed-by: Waiman Long <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-04-19Merge tag 'perf-urgent-for-mingo-20160418' of ↵Ingo Molnar1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull a perf/urgent fix from Arnaldo Carvalho de Melo: - Fix segfault tracing transactions in Intel PT (Adrian Hunter) Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2016-04-19Revert "serial: 8250: Add hardware dependency to RT288X option"Greg Kroah-Hartman1-1/+0
This reverts commit 8d2acdb9fc3a544ab0442634531834d6007b5467. It's causing problems, and somehow I missed that Peter didn't like it at all :( So revert it for now until it gets sorted out. Reported-by: Mason <[email protected]> Cc: Peter Hurley <[email protected]> Cc: Jean Delvare <[email protected]> Cc: Mans Rullgard <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: John Crispin <[email protected]> Signed-off-by: Greg Kroah-Hartman [email protected]
2016-04-19tty/serial/8250: fix RS485 half-duplex RXYegor Yefremov1-1/+10
When in half-duplex mode RX will be disabled before TX, but not enabled after deactivating transmitter. This patch enables UART_IER_RLSI and UART_IER_RDI interrupts after TX is over. Cc: Matwey V. Kornilov <[email protected]> Signed-off-by: Yegor Yefremov <[email protected]> Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250") Acked-by: Matwey V. Kornilov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-04-19Revert "serial-uartlite: Constify uartlite_be/uartlite_le"Sudip Mukherjee1-4/+4
This reverts commit 2905697a82eaf20606ced164d853b52d1b94aaa8. The commit introduced two build warnings: drivers/tty/serial/uartlite.c: In function ‘ulite_request_port’: drivers/tty/serial/uartlite.c:348:21: warning: assignment discards ‘const’ qualifier from pointer target type port->private_data = &uartlite_be; ^ drivers/tty/serial/uartlite.c:354:22: warning: assignment discards ‘const’ qualifier from pointer target type port->private_data = &uartlite_le; ^ Signed-off-by: Sudip Mukherjee <[email protected]> Cc: Maarten Brock <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-04-18Merge tag 'pci-v4.6-fixes-2' of ↵Linus Torvalds5-6/+68
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: "These are fixes for two issues: - The VPD parsing code we added for v4.6 keeps some devices from crashing, but also keeps cxgb4 from reading non-standard extra VPD data that is relies on. Hariprasad added a way for the driver to specify how much VPD is valid. - The i.MX6 active-low reset GPIO support we added in v4.5 caused regressions on some boards, so we're reverting that. VPD: Add pci_set_vpd_size() (Hariprasad Shenai) cxgb4: Set VPD size so we can read both VPD structures (Hariprasad Shenai) Freescale i.MX6 host bridge driver: Revert "PCI: imx6: Add support for active-low reset GPIO" (Fabio Estevam)" * tag 'pci-v4.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: cxgb4: Set VPD size so we can read both VPD structures PCI: Add pci_set_vpd_size() to set VPD size Revert "PCI: imx6: Add support for active-low reset GPIO"
2016-04-18cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended setRafael J. Wysocki1-0/+3
Since governor operations are generally skipped if cpufreq_suspended is set, cpufreq_start_governor() should do nothing in that case. That function is called in the cpufreq_online() path, and may also be called from cpufreq_offline() in some cases, which are invoked by the nonboot CPUs disabing/enabling code during system suspend to RAM and resume. That happens when all devices have been suspended, so if the cpufreq driver relies on things like I2C to get the current frequency, it may not be ready to do that then. To prevent problems from happening for this reason, make cpufreq_update_current_freq(), which is the only function invoked by cpufreq_start_governor() that doesn't check cpufreq_suspended already, return 0 upfront if cpufreq_suspended is set. Fixes: 3bbf8fe3ae08 (cpufreq: Always update current frequency before startig governor) Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2016-04-18devpts: clean up interface to pty driversLinus Torvalds3-82/+64
This gets rid of the horrible notion of having that struct inode *ptmx_inode be the linchpin of the interface between the pty code and devpts. By de-emphasizing the ptmx inode, a lot of things actually get cleaner, and we will have a much saner way forward. In particular, this will allow us to associate with any particular devpts instance at open-time, and not be artificially tied to one particular ptmx inode. The patch itself is actually fairly straightforward, and apart from some locking and return path cleanups it's pretty mechanical: - the interfaces that devpts exposes all take "struct pts_fs_info *" instead of "struct inode *ptmx_inode" now. NOTE! The "struct pts_fs_info" thing is a completely opaque structure as far as the pty driver is concerned: it's still declared entirely internally to devpts. So the pty code can't actually access it in any way, just pass it as a "cookie" to the devpts code. - the "look up the pts fs info" is now a single clear operation, that also does the reference count increment on the pts superblock. So "devpts_add/del_ref()" is gone, and replaced by a "lookup and get ref" operation (devpts_get_ref(inode)), along with a "put ref" op (devpts_put_ref()). - the pty master "tty->driver_data" field now contains the pts_fs_info, not the ptmx inode. - because we don't care about the ptmx inode any more as some kind of base index, the ref counting can now drop the inode games - it just gets the ref on the superblock. - the pts_fs_info now has a back-pointer to the super_block. That's so that we can easily look up the information we actually need. Although quite often, the pts fs info was actually all we wanted, and not having to look it up based on some magical inode makes things more straightforward. In particular, now that "devpts_get_ref(inode)" operation should really be the *only* place we need to look up what devpts instance we're associated with, and we do it exactly once, at ptmx_open() time. The other side of this is that one ptmx node could now be associated with multiple different devpts instances - you could have a single /dev/ptmx node, and then have multiple mount namespaces with their own instances of devpts mounted on /dev/pts/. And that's all perfectly sane in a model where we just look up the pts instance at open time. This will eventually allow us to get rid of our odd single-vs-multiple pts instance model, but this patch in itself changes no semantics, only an internal binding model. Cc: Eric Biederman <[email protected]> Cc: Peter Anvin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Al Viro <[email protected]> Cc: Peter Hurley <[email protected]> Cc: Serge Hallyn <[email protected]> Cc: Willy Tarreau <[email protected]> Cc: Aurelien Jarno <[email protected]> Cc: Alan Cox <[email protected]> Cc: Jann Horn <[email protected]> Cc: Greg KH <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Florian Weimer <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-04-18Merge branch 'for-linus' of ↵Linus Torvalds6-4/+12
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "A couple of bug fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: add CPU_BIG_ENDIAN config option s390/spinlock: avoid yield to non existent cpu s390/dcssblk: fix possible deadlock in remove vs. per-device attributes s390/seccomp: include generic seccomp header file s390/pci: add extra padding to function measurement block s390/scm_blk: fix deadlock for requests != REQ_TYPE_FS
2016-04-18drm/radeon: print a message if ATPX dGPU power control is missingAlex Deucher1-1/+4
It will help identify problematic boards. Signed-off-by: Alex Deucher <[email protected]>
2016-04-18arm64: fix invalidation of wrong __early_cpu_boot_status cachelineArd Biesheuvel1-1/+2
In head.S, the str_l macro, which takes a source register, a symbol name and a temp register, is used to store a status value to the variable __early_cpu_boot_status. Subsequently, the value of the temp register is reused to invalidate any cachelines covering this variable. However, since str_l resolves to adrp \tmp, \sym str \src, [\tmp, :lo12:\sym] the temp register never actually holds the address of the variable but only of the 4 KB window that covers it, and reusing it leads to the wrong cacheline being invalidated. So instead, take the address explicitly before doing the store, and reuse that value to perform the cache invalidation. Fixes: bb9052744f4b ("arm64: Handle early CPU boot failures") Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Suzuki K Poulose <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2016-04-18Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"Alex Deucher2-11/+5
This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1. ATPX is the ACPI method for controlling AMD PowerXpress laptops. There are flags to indicate which methods are supported. If the dGPU power down flag is not supported, the driver needs to implement the dGPU power down manually. We had previously always forced the driver to assume the ATPX dGPU power down was present, but this causes problems on boards where it is not, leading to GPU hangs when attempting to power down the dGPU. Manual dGPU power down is not currently supported in the Linux driver. Some laptops indicate that the ATPX dGPU power down method is not present, but it actually apparently is. I'm not sure if this is a bios bug and it should be set or if there is a reason it was unset and the method should not be used. This is not an issue on other OSes since both the ATPX and the manual driver power down methods are supported. This is apparently fairly widespread, so just revert for now. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=115321 https://bugzilla.kernel.org/show_bug.cgi?id=116581 https://bugzilla.kernel.org/show_bug.cgi?id=116251 Cc: [email protected]
2016-04-18drm/amdgpu/acp: fix resume on CZ systems with AZ audioAlex Deucher1-0/+4
Nothing to do on resume on systems with AZ audio. Signed-off-by: Alex Deucher <[email protected]>
2016-04-18drm/radeon: add a quirk for a XFX R9 270XAlex Deucher1-0/+1
bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2016-04-18drm/radeon: print pci revision as well as pci ids on driver loadAlex Deucher1-3/+3
The pci revision id is useful in debugging certain things as it's part of how SKUs are defined on newer asics. Signed-off-by: Alex Deucher <[email protected]>
2016-04-18perf intel-pt: Fix segfault tracing transactionsAdrian Hunter1-1/+1
Tracing a workload that uses transactions gave a seg fault as follows: perf record -e intel_pt// workload perf report Program received signal SIGSEGV, Segmentation fault. 0x000000000054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110) at util/intel-pt.c:929 929 ptq->last_branch_rb->nr = 0; (gdb) p ptq->last_branch_rb $1 = (struct branch_stack *) 0x0 (gdb) up 1148 intel_pt_reset_last_branch_rb(ptq); (gdb) l 1143 if (ret) 1144 pr_err("Intel Processor Trace: failed to deliver transaction event 1145 ret); 1146 1147 if (pt->synth_opts.callchain) 1148 intel_pt_reset_last_branch_rb(ptq); 1149 1150 return ret; 1151 } 1152 (gdb) p pt->synth_opts.callchain $2 = true (gdb) (gdb) bt #0 0x000000000054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110) #1 0x000000000054c1e0 in intel_pt_synth_transaction_sample (ptq=0x1a36110) #2 0x000000000054c5b2 in intel_pt_sample (ptq=0x1a36110) Caused by checking the 'callchain' flag when it should have been the 'last_branch' flag. Fix that. Reported-by: Andi Kleen <[email protected]> Signed-off-by: Adrian Hunter <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: [email protected] # v4.4+ Fixes: f14445ee72c5 ("perf intel-pt: Support generating branch stack") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-04-18powerpc: Update TM user feature bits in scan_features()Anton Blanchard1-4/+5
We need to update the user TM feature bits (PPC_FEATURE2_HTM and PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature bit. At the moment, if firmware reports TM is not available we turn off the kernel TM feature bit but leave the userspace ones on. Userspace thinks it can execute TM instructions and it dies trying. This (together with a QEMU patch) fixes PR KVM, which doesn't currently support TM. Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] Signed-off-by: Michael Ellerman <[email protected]>
2016-04-18powerpc: Update cpu_user_features2 in scan_features()Anton Blanchard1-8/+11
scan_features() updates cpu_user_features but not cpu_user_features2. Amongst other things, cpu_user_features2 contains the user TM feature bits which we must keep in sync with the kernel TM feature bit. Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] Signed-off-by: Michael Ellerman <[email protected]>
2016-04-18powerpc: scan_features() updates incorrect bits for REAL_LEAnton Blanchard2-1/+2
The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by: Anton Blanchard <[email protected]> Cc: [email protected] [mpe: Flesh out changelog, add comment reserving 0x4] Signed-off-by: Michael Ellerman <[email protected]>
2016-04-18ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020mBastien Nocera1-0/+1
The Optiplex 9020m with Haswell-DT processor needs a quirk for the headset jack at the front of the machine to be able to use microphones. A quirk for this model was originally added in 3127899, but c77900e removed it in favour of a more generic version. Unfortunately, pin configurations can changed based on firmware/BIOS versions, and the generic version doesn't have any effect on newer versions of the machine/firmware anymore. With help from David Henningsson <[email protected]> Signed-off-by: Bastien Nocera <[email protected]> Tested-by: Bastien Nocera <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-04-18drm/i915: Use fw_domains_put_with_fifo() on HSWVille Syrjälä1-1/+5
HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <[email protected]> Cc: Deepak S <[email protected]> Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: [email protected] Reviewed-by: Mika Kuoppala <[email protected]> (cherry picked from commit 3d7d0c85e41afb5a05e98b3a8a72c38357f02594) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915: Force ringbuffers to not be at offset 0Chris Wilson1-2/+5
For reasons unknown Sandybridge GT1 (at least) will eventually hang when it encounters a ring wraparound at offset 0. The test case that reproduces the bug reliably forces a large number of interrupted context switches, thereby causing very frequent ring wraparounds, but there are similar bug reports in the wild with the same symptoms, seqno writes stop just before the wrap and the ringbuffer at address 0. It is also timing crucial, but adding various delays hasn't helped pinpoint where the window lies. Whether the fault is restricted to the ringbuffer itself or the GTT addressing is unclear, but moving the ringbuffer fixes all the hangs I have been able to reproduce. References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262 Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1 Signed-off-by: Chris Wilson <[email protected]> Cc: [email protected] Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a687a43a48f0f91ba37dce5a14b467258ed6f035) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno writeMichał Winiarski1-2/+8
We started to use PIPE_CONTROL to write render ring seqno in order to combat seqno write vs interrupt generation problems. This was introduced by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists"). On gen8+ size of PIPE_CONTROL with Post Sync Operation should be 6 dwords. When we're using older 5-dword variant it's possible to observe inconsistent values written by PIPE_CONTROL with Post Sync Operation from user batches, resulting in rendering corruptions. v2: Fix BAT failures v3: Comments on alignment and thrashing high dword of seqno (Chris) v4: Updated commit msg (Mika) Testcase: igt/gem_pipe_control_store_loop/*-qword-write Issue: VIZ-7393 Cc: [email protected] Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Abdiel Janulgue <[email protected]> Signed-off-by: Michał Winiarski <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Tested-by: Abdiel Janulgue <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ce81a65c79d6012a384563caf76d47e28947a347) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revsMika Kuoppala1-2/+3
Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa) suggest that WaForceContextSaveRestoreNonCoherent is needed for all revs. Extending this to all revs cures a gpu hang with rev 0xa when running heaven4.0 gpu benchmark. We have been here before, with problems enabling gt4e and extending up to revision F0 instead of false claims of bspec of E0 only. See commit <e238659ddd88> ("drm/i915/skl: Default to noncoherent access up to F0"). In retrospect we should have covered this with this big blanket back then already, as E0 vs F0 discrepancy was suspicious enough. Previously the WaForceEnableNonCoherent has been tied to context non-coherence, atleast in relevant hsds. So keep this tie and extended this alongside. Cc: Abdiel Janulgue <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Timo Aaltonen <[email protected]> Cc: [email protected] Reported-by: Mike Lothian <[email protected]> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491 Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Tested-by: Timo Aaltonen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 97ea6be161c55dec896b65c95157d953c330ae05) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915/skl: Fix rc6 based gpu/system hangMika Kuoppala1-2/+3
For all gt3 and gt4 skylake variants, extend the usage of WaRsDisableCoarsePowerGating for all revisions. Without this gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or system hang. Cc: Abdiel Janulgue <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Timo Aaltonen <[email protected]> Cc: <[email protected]> Reported-by: Mikael Djurfeldt <[email protected]> References: https://bugs.freedesktop.org/show_bug.cgi?id=94161 Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Tested-by: Timo Aaltonen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 185c66e57ce725afeb58a3cfa48547706af3a7af) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915/userptr: Hold mmref whilst calling get-user-pagesChris Wilson1-12/+17
Holding a reference to the containing task_struct is not sufficient to prevent the mm_struct from being reaped under memory pressure. If this happens whilst we are calling get_user_pages(), explosions erupt - sometimes an immediate GPF, sometimes page flag corruption. To prevent the target mm from being reaped as we are reading from it, acquire a reference before we begin. Testcase: igt/gem_shrink/*userptr Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Michał Winiarski <[email protected]> Cc: [email protected] Reviewed-by: Michał Winiarski <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 40313f0cd0b711a7a5905e5182422799e157d8aa) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915: Fixup the free space logic in ring_prepareAkash Goel2-6/+6
Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free space at the beginning to accommodate the base request, as before the wraparound, the wait was effectively done for the reserved_size free space from the start of Ring buffer. In such a case there is a potential of Ring buffer overflow, the instructions at the head of Ring (ACTHD) can get overwritten. Since the base request can fit in the remaining space, there is no need to wraparound immediately. The wraparound will anyway happen later when the reserved part starts getting used. Cc: Chris Wilson <[email protected]> Signed-off-by: Akash Goel <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] (cherry picked from commit 782f6bc0aba037436d6a04d19b23f8b61020a576) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18drm/i915/skl+: Use plane size for relative data rate calculationKumar, Mahesh1-14/+28
Use plane size for relative data rate calculation. don't always use pipe source width & height. adjust height & width according to rotation. use plane size for watermark calculations also. v2: Address Matt's comments. Use intel_plane_state->visible to avoid divide-by-zero error. Where FB was present but not visible so causing total data rate to be zero, hence divide-by-zero. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93917 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94044 Cc: [email protected] Signed-off-by: Kumar, Mahesh <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a280f7dd9f1a85eed242d0f62498bfc11520a1a3) Signed-off-by: Jani Nikula <[email protected]>
2016-04-18usb: dwc3: gadget: Fix suspend/resume during device modeRoger Quadros1-0/+6
Gadget controller might not be always active during system suspend/resume as gadget driver might not have yet been loaded or might have been unloaded prior to system suspend. Check if we're active and only then perform necessary actions during suspend/resume. Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2016-04-18usb: dwc3: fix memory leak of dwc->regsetDu, Changbin1-5/+8
dwc->regset is allocated on dwc3_debugfs_init, and should be released on init failure or dwc3_debugfs_exit. Btw, The line "dwc->root = NULL" is unnecessary, so remove it. Signed-off-by: Du, Changbin <[email protected]> [ [email protected] : add another err label for the new error condition ] Signed-off-by: Felipe Balbi <[email protected]>
2016-04-18usb: dwc3: core: fix PHY handling during suspendFelipe Balbi1-1/+22
we need to power off the PHY during suspend and power it back on during resume. Signed-off-by: Felipe Balbi <[email protected]> [[email protected]: fix call to usb_phy_set_suspend() in dwc3_suspend()] Signed-off-by: Sekhar Nori <[email protected]> Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2016-04-18usb: dwc3: omap: fix up error path on probe()Felipe Balbi1-8/+4
Even if pm_runtime_get*() fails, we *MUST* call pm_runtime_put_sync() before disabling PM. While at it, remove superfluous dwc3_omap_disable_irqs() in error path. Signed-off-by: Felipe Balbi <[email protected]> [[email protected]: patch description updates] Signed-off-by: Sekhar Nori <[email protected]> Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2016-04-18usb: gadget: composite: Clear reserved fields of SSP Dev CapJohn Youn1-0/+2
Set the reserved fields of the SuperSpeed Plus Device Capability descriptor to 0. Otherwise there might be stale data there which will cause USB CV to fail. Fixes: f228a8de242a ("usb: gadget: composite: Return SSP Dev Cap descriptor") Signed-off-by: John Youn <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2016-04-18omapfb: panel-sharp-ls037v7dw01: fix check of gpio_to_desc() return valueVladimir Zapolskiy1-8/+4
The change fixes a check of gpio_to_desc() return value, the function returns either a valid pointer to struct gpio_desc or NULL, this makes IS_ERR() check invalid and may lead to a NULL pointer dereference in runtime. Signed-off-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-04-18video: ARM CLCD: runtime check for VersatileLinus Walleij1-7/+8
The current compile-time check for inversed IENB/CNTL does not work in multiplatform boots: as soon as versatile is included in the build, the IENB/CNTL is switched and breaks graphics. Convert this to a runtime switch. Cc: [email protected] Cc: Rob Herring <[email protected]> Cc: Russell King <[email protected]> Fixes: a29da136de34 ("ARM: versatile: convert to multi-platform") Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-04-18ALSA - hda: hdmi check NULL pointer in hdmi_set_chmapLibin Yang1-0/+2
Make sure per_pin is not NULL before using it. Fixes: 9b3dc8aa3fb1 ('ALSA: hda - Register chmap obj as priv data instead of codec') Signed-off-by: Libin Yang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2016-04-17Linux 4.6-rc4Linus Torvalds1-1/+1
2016-04-17macsec: fix crypto Kconfig dependencyArnd Bergmann1-0/+1
The new MACsec driver uses the AES crypto algorithm, but can be configured even if CONFIG_CRYPTO is disabled, leading to a build error: warning: (MAC80211 && MACSEC) selects CRYPTO_GCM which has unmet direct dependencies (CRYPTO) warning: (BT && CEPH_LIB && INET && MAC802154 && MAC80211 && BLK_DEV_RBD && MACSEC && AIRO_CS && LIBIPW && HOSTAP && USB_WUSB && RTLLIB_CRYPTO_CCMP && FS_ENCRYPTION && EXT4_ENCRYPTION && CEPH_FS && BIG_KEYS && ENCRYPTED_KEYS) selects CRYPTO_AES which has unmet direct dependencies (CRYPTO) crypto/built-in.o: In function `gcm_enc_copy_hash': aes_generic.c:(.text+0x2b8): undefined reference to `crypto_xor' aes_generic.c:(.text+0x2dc): undefined reference to `scatterwalk_map_and_copy' This adds an explicit 'select CRYPTO' statement the way that other drivers handle it. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by: David S. Miller <[email protected]>
2016-04-17Merge tag 'dm-4.6-fix-2' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fix from Mike Snitzer: "Fix for earlier 4.6-rc4 stable@ commit that introduced improper use of write lock in cmd_read_lock() -- due to cut-n-paste gone awry (and sparse didn't catch it)" * tag 'dm-4.6-fix-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm cache metadata: fix cmd_read_lock() acquiring write lock
2016-04-17dm cache metadata: fix cmd_read_lock() acquiring write lockAhmed Samy1-2/+2
Commit 9567366fefdd ("dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros") uses down_write() instead of down_read() in cmd_read_lock(), yet up_read() is used to release the lock in READ_UNLOCK(). Fix it. Fixes: 9567366fefdd ("dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros") Cc: [email protected] Signed-off-by: Ahmed Samy <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2016-04-17Input: pmic8xxx-pwrkey - fix algorithm for converting trigger delayStephen Boyd1-3/+4
The trigger delay algorithm that converts from microseconds to the register value looks incorrect. According to most of the PMIC documentation, the equation is delay (Seconds) = (1 / 1024) * 2 ^ (x + 4) except for one case where the documentation looks to have a formatting issue and the equation looks like delay (Seconds) = (1 / 1024) * 2 x + 4 Most likely this driver was written with the improper documentation to begin with. According to the downstream sources the valid delays are from 2 seconds to 1/64 second, and the latter equation just doesn't make sense for that. Let's fix the algorithm and the range check to match the documentation and the downstream sources. Reported-by: Bjorn Andersson <[email protected]> Fixes: 92d57a73e410 ("input: Add support for Qualcomm PMIC8XXX power key") Signed-off-by: Stephen Boyd <[email protected]> Tested-by: John Stultz <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-04-17Input: arizona-haptic - don't assign input_dev parentCharles Keepax1-1/+0
We shouldn't assign the parent device of the input_dev to be the parent MFD device, because this will be used for devres which causes input_unregister_device to run after the haptics device has been removed, since it is itself a child of the MFD device. The default of using the haptics device itself as the parent is correct. Signed-off-by: Charles Keepax <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2016-04-17ALSA: hda - Don't trust the reported actual power stateTakashi Iwai1-2/+4
We've got a regression report that the recording on Mac with a cirrus codec doesn't work any longer. This turned out to be the missing power up to D0 by power_save_node enablement. After analyzing the traces, we found out that the culprit is that the codec advertises the "actual" power state of a few nodes to be D0 while the "target" power state is D3. This inconsistency is usually OK, as it implies the power transition. But in the case of cirrus codec, this seems to be stuck to D3 while it's not actually D0. This patch addresses the issue by checking the power state difference more strictly. It sends the power-state change verb unless both the target and the actual power states show the given value. We may introduce yet another flag indicating the possible broken hardware power state, but it's anyway safer to set the proper power state even in a transition (at least it's harmless as long as the target state is same). So this simpler change was applied now. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Cc: <[email protected]> # v4.4+ Signed-off-by: Takashi Iwai <[email protected]>
2016-04-16Merge tag 'char-misc-4.6-rc4' of ↵Linus Torvalds2-5/+9
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc fixes from Greg KH: "Here are some small char/misc driver fixes for 4.6-rc4. Full details are in the shortlog, nothing major here. These have all been in linux-next for a while with no reported issues" * tag 'char-misc-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: lkdtm: do not leak free page on kmalloc failure lkdtm: fix memory leak of base lkdtm: fix memory leak of val extcon: palmas: Drop stray IRQF_EARLY_RESUME flag
2016-04-16Merge tag 'driver-core-4.6-rc4' of ↵Linus Torvalds2-13/+14
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull misc fixes from Greg KH: "Here are three small fixes for 4.6-rc4. Two fix up some lz4 issues with big endian systems, and the remaining one resolves a minor debugfs issue that was reported. All have been in linux-next with no reported issues" * tag 'driver-core-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: lib: lz4: cleanup unaligned access efficiency detection lib: lz4: fixed zram with lz4 on big endian machines debugfs: Make automount point inodes permanently empty
2016-04-16Merge tag 'usb-4.6-rc4' of ↵Linus Torvalds15-13/+94
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB driver fixes from Greg KH: "Here are some small USB fixes for 4.6-rc4. Mostly xhci fixes for reported issues, a UAS bug that has hit a number of people, including stable tree users, and a few other minor things. All have been in linux-next for a while with no reported issues" * tag 'usb-4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: hcd: out of bounds access in for_each_companion USB: uas: Add a new NO_REPORT_LUNS quirk USB: uas: Limit qdepth at the scsi-host level doc: usb: Fix typo in gadget_multi documentation usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers usb: xhci: fix wild pointers in xhci_mem_cleanup usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT xhci: resume USB 3 roothub first usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host cdc-acm: fix crash if flushed with nothing buffered
Powered by cgit, Gruvboxed by Blaster4385.