summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-04-20drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dmaDaniel Vetter
The sg table isn't refcounted, there's no corresponding locking for unmapping and drm_map_sg is ok with being called concurrently. So drop the locking since it doesn't protect anything. Cc: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-8-git-send-email-daniel.vetter@ffwll.ch
2016-04-20drm/exynos: Drop dev->struct_mutex from mmap offset functionDaniel Vetter
Simply forgotten about this when I was doing my general cleansing of simple gem mmap offset functions. There's nothing but core functions called here, and they all have their own protection already. Aside: DRM_ERROR for userspace controlled input isn't great, but that's for another patch. v2: Use _unlocked unreference (Daniel Stone). Cc: Daniel Stone <daniel@fooishbar.org> Cc: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-7-git-send-email-daniel.vetter@ffwll.ch
2016-04-20drm/nouveau: Drop dev->struct_mutex from fbdev initDaniel Vetter
Doesn't protect anything at all. With this patch nouveau is completely dev->struct_mutex free! Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-6-git-send-email-daniel.vetter@ffwll.ch
2016-04-20drm/qxl: Use unlocked gem unreferencingDaniel Vetter
For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-4-git-send-email-daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-5-git-send-email-daniel.vetter@ffwll.ch
2016-04-20drm/omapdrm: Use unlocked gem unreferencingDaniel Vetter
For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-3-git-send-email-daniel.vetter@ffwll.ch
2016-04-20drm/nouveau: Use unlocked gem unreferencingDaniel Vetter
For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-2-git-send-email-daniel.vetter@ffwll.ch
2016-04-20drm: fix lut value extraction functionLionel Landwerlin
When extracting the value at full precision (16 bits), no need to round the value. This was spotted by Jani when running sparse. Unfortunately this fix doesn't get rid of the warning. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reported-by: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: dri-devel@lists.freedesktop.org Fixes: 5488dc16fde7 ("drm: introduce pipe color correction properties") Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458655833-19547-1-git-send-email-lionel.g.landwerlin@intel.com
2016-04-20futex: Handle unlock_pi race gracefullySebastian Andrzej Siewior
If userspace calls UNLOCK_PI unconditionally without trying the TID -> 0 transition in user space first then the user space value might not have the waiters bit set. This opens the following race: CPU0 CPU1 uval = get_user(futex) lock(hb) lock(hb) futex |= FUTEX_WAITERS .... unlock(hb) cmpxchg(futex, uval, newval) So the cmpxchg fails and returns -EINVAL to user space, which is wrong because the futex value is valid. To handle this (yes, yet another) corner case gracefully, check for a flag change and retry. [ tglx: Massaged changelog and slightly reworked implementation ] Fixes: ccf9e6a80d9e ("futex: Make unlock_pi more robust") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: stable@vger.kernel.org Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1460723739-5195-1-git-send-email-bigeasy@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-04-20crypto: talitos - fix AEAD tcrypt testsHoria Geant?
After conversion to new AEAD interface, tcrypt tests fail as follows: [...] [ 1.145414] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos [ 1.153564] 00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67 [ 1.160041] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1.166509] 00000020: 00 00 00 00 [...] Fix them by providing the correct cipher in & cipher out pointers, i.e. must skip over associated data in src and dst S/G. While here, fix a problem with the HW S/G table index usage: tbl_off must be updated after the pointer to the table entries is set. Cc: <stable@vger.kernel.org> # 4.3+ Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface") Reported-by: Jonas Eymann <J.Eymann@gmx.net> Signed-off-by: Horia Geant? <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-20crypto: talitos - fix crash in talitos_cra_init()Jonas Eymann
Conversion of talitos driver to the new AEAD interface hasn't been properly tested. AEAD algorithms crash in talitos_cra_init as follows: [...] [ 1.141095] talitos ffe30000.crypto: hwrng [ 1.145381] Unable to handle kernel paging request for data at address 0x00000058 [ 1.152913] Faulting instruction address: 0xc02accc0 [ 1.157910] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.163315] SMP NR_CPUS=2 P1020 RDB [ 1.166810] Modules linked in: [ 1.169875] CPU: 0 PID: 1007 Comm: cryptomgr_test Not tainted 4.4.6 #1 [ 1.176415] task: db5ec200 ti: db4d6000 task.ti: db4d6000 [ 1.181821] NIP: c02accc0 LR: c02acd18 CTR: c02acd04 [ 1.186793] REGS: db4d7d30 TRAP: 0300 Not tainted (4.4.6) [ 1.192457] MSR: 00029000 <CE,EE,ME> CR: 95009359 XER: e0000000 [ 1.198585] DEAR: 00000058 ESR: 00000000 GPR00: c017bdc0 db4d7de0 db5ec200 df424b48 00000000 00000000 df424bfc db75a600 GPR08: df424b48 00000000 db75a628 db4d6000 00000149 00000000 c0044cac db5acda0 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 df424940 GPR24: df424900 00003083 00000400 c0180000 db75a640 c03e9f84 df424b40 df424b48 [ 1.230978] NIP [c02accc0] talitos_cra_init+0x28/0x6c [ 1.236039] LR [c02acd18] talitos_cra_init_aead+0x14/0x28 [ 1.241443] Call Trace: [ 1.243894] [db4d7de0] [c03e9f84] 0xc03e9f84 (unreliable) [ 1.249322] [db4d7df0] [c017bdc0] crypto_create_tfm+0x5c/0xf0 [ 1.255083] [db4d7e10] [c017beec] crypto_alloc_tfm+0x98/0xf8 [ 1.260769] [db4d7e40] [c0186a20] alg_test_aead+0x28/0xc8 [ 1.266181] [db4d7e60] [c0186718] alg_test+0x260/0x2e0 [ 1.271333] [db4d7ee0] [c0183860] cryptomgr_test+0x30/0x54 [ 1.276843] [db4d7ef0] [c0044d80] kthread+0xd4/0xd8 [ 1.281741] [db4d7f40] [c000e4a4] ret_from_kernel_thread+0x5c/0x64 [ 1.287930] Instruction dump: [ 1.290902] 38600000 4e800020 81230028 7c681b78 81490010 38e9ffc0 3929ffe8 554a073e [ 1.298691] 2b8a000a 7d474f9e 812a0008 91230030 <80e90058> 39270060 7c0004ac 7cc04828 Cc: <stable@vger.kernel.org> # 4.3+ Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface") Signed-off-by: Jonas Eymann <J.Eymann@gmx.net> Fix typo - replaced parameter of __crypto_ahash_alg(): s/tfm/alg Remove checkpatch warnings. Add commit message. Signed-off-by: Horia Geant? <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-20arm64: spin-table: add missing of_node_put()Masahiro Yamada
Since of_get_cpu_node() increments refcount, the node should be put. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2016-04-20drm/i915: Remove a couple pointless WARN_ONsTvrtko Ursulin
Just two WARN_ONs followed by pointer dereference I spotted by accident. v2: Remove some more of the same. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1461080770-14693-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-20drm/i915/gen8+: Do not enable DPF interrupt since the handler does not existTvrtko Ursulin
Looks like DPF was not implemented for gen8+ but the IER and IMR are still enabled on initialization. Since there is no code to handle this interrupt, gate the irq enablement behind HAS_L3_DPF in case the feature gets enabled in the future. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-04-20drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupportTim Gore
WaEnableSamplerGPGPUPreemptionSupport fixes a problem related to mid thread pre-emption. Signed-off-by: Tim Gore <tim.gore@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461077152-31899-1-git-send-email-tim.gore@intel.com
2016-04-20ALSA: hda - add PCI ID for Intel Broxton-TLu, Han
Add HD Audio Device PCI ID for the Intel Broxton-T platform. It is an HDA Intel PCH controller. Signed-off-by: Lu, Han <han.lu@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-04-20usb: gadget: f_fs: Fix use-after-freeLars-Peter Clausen
When using asynchronous read or write operations on the USB endpoints the issuer of the IO request is notified by calling the ki_complete() callback of the submitted kiocb when the URB has been completed. Calling this ki_complete() callback will free kiocb. Make sure that the structure is no longer accessed beyond that point, otherwise undefined behaviour might occur. Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support") Cc: <stable@vger.kernel.org> # v3.15+ Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-04-19VSOCK: Only check error on skb_recv_datagram when skb is NULLJorgen Hansen
If skb_recv_datagram returns an skb, we should ignore the err value returned. Otherwise, datagram receives will return EAGAIN when they have to wait for a datagram. Acked-by: Adit Ranadive <aditr@vmware.com> Signed-off-by: Jorgen Hansen <jhansen@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-19cls_cgroup: get sk_classid only from full socketsKonstantin Khlebnikov
skb->sk could point to timewait or request socket which has no sk_classid. Detected as "BUG: KASAN: slab-out-of-bounds in cls_cgroup_classify". Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-19net/mlx4_en: do batched put_page using atomic_subKonstantin Khlebnikov
This patch fixes couple error paths after allocation failures. Atomic set of page reference counter is safe only if it is zero, otherwise set can race with any speculative get_page_unless_zero. Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-19net/mlx4_en: allocate non 0-order pages for RX ring with __GFP_NOMEMALLOCKonstantin Khlebnikov
High order pages are optional here since commit 51151a16a60f ("mlx4: allow order-0 memory allocations in RX path"), so here is no reason for depleting reserves. Generic __netdev_alloc_frag() implements the same logic. Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-19Merge branch 'ptmx-cleanup'Linus Torvalds
Merge the ptmx internal interface cleanup branch. This doesn't change semantics, but it should be a sane basis for eventually getting the multi-instance devpts code into some sane shape where we can get rid of the kernel config option. Which we can hopefully get done next merge window.. * ptmx-cleanup: devpts: clean up interface to pty drivers
2016-04-20ARM: shmobile: timer: Fix preset_lpj leading to too short delaysGeert Uytterhoeven
On all shmobile ARM SoCs, loop-based delays may complete early, which can be after only 1/3 (Cortex A9) or 1/2 (Cortex A7 or A15) of the minimum required time. This is caused by calculating preset_lpj based on incorrect assumptions about the number of clock cycles per loop: - All of Cortex A7, A9, and A15 run __loop_delay() at 1 loop per CPU clock cycle, - As of commit 11d4bb1bd067f9d0 ("ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation"), Cortex A8 runs __loop_delay() at 1 loop per 2 instead of 3 CPU clock cycles. On SoCs with Cortex A7 and/or A15 CPU cores, this went unnoticed, as delays use the ARM arch timer if available. R-Car Gen2 doesn't work if the arch timer is disabled. However, APE6 can be used without the arch timer. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2016-04-20Revert "ARM: dts: porter: Enable SCIF_CLK frequency and pins"Sjoerd Simons
This reverts commit 19417bd9c511 ("ARM: dts: porter: Enable SCIF_CLK frequency and pins") as according to http://elinux.org/File:R-CarM2-KOELSCH_PORTER-B_PORTER_C_Comparison.pdf the external oscillator for SCIF_CLK is not mounted on the porter boards. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2016-04-20ARM: dts: r8a7791: Don't disable referenced optional clocksSjoerd Simons
clk_get on a disabled clock node will return EPROBE_DEFER, which can cause drivers to be deferred forever if such clocks are referenced in their clocks property. Update the various disabled external clock nodes to default to a frequency of 0, but don't disable them to prevent this. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2016-04-19platform:x86 decouple telemetry driver from the optional IPC resourcesAubrey Li
Currently the optional IPC resources prevent telemetry driver from probing if these resources are not in ACPI table. This patch decouples telemetry driver from these optional resources, so that telemetry driver has dependency only on the necessary ACPI resources. Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-04-19ALSA: hda - Keep powering up ADCs on Cirrus codecsTakashi Iwai
Although one weird behavior about the input path (inconsistent D0/D3 switch) on Cirrus CS420x codecs was fixed in the previous commit, there is still an issue on some Mac machines: the capture stream stalls when switching the ADCs on the fly. More badly, this keeps stuck until the next reboot. The dynamic ADC switching is already a bit fragile and assuming optimistically that the chip accepts the frequent power changes. On Cirrus codecs, this doesn't seem applicable. As a quick workaround, we pin down the ADCs to keep up in D0 when spec->dyn_adc_switch is set. In this way, the ADCs are kept up only for the system that were confirmed to be broken. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-04-19ARM: 8564/1: fix cpu feature extracting helperVladimir Murzin
Commit b8c9592 "ARM: 8318/1: treat CPU feature register fields as signed quantities" introduced helper to extract signed quantities of 4-bit blocks. However, with a current code feature with value 0b1000 isn't rejected as negative. So fix the "if" condition. Reported-by: Jonathan Brawn <Jon.Brawn@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-04-19ARM: 8563/1: fix demoting HWCAP_SWPVladimir Murzin
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 <vladimir.murzin@arm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-04-19Input: twl6040-vibra - ignore return value of schedule_workH. Nikolaus Schaller
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 <hns@goldelico.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2016-04-19Input: twl6040-vibra - fix NULL pointer dereference by removing workqueueH. Nikolaus Schaller
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 <hns@goldelico.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2016-04-19drm/i915: Fixing eDP detection on certain platformsShubhangi Shrivastava
Since commit 30d9aa4265fe ("drm/i915: Read sink_count dpcd always"), the status of a DP connector depends on its sink count value. However, some eDP panels don't set that value appropriately, causing them to be reported as disconnected. Fix this by ignoring sink count for eDP. v2: Rephrased commit message. (Ander) In case of eDP, returning status as connected if DPCD read succeeds to avoid any further operations. Fixes: 30d9aa4265fe ("drm/i915: Read sink_count dpcd always") Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Tested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460444034-22320-1-git-send-email-shubhangi.shrivastava@intel.com
2016-04-19drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()jim.bride@linux.intel.com
In commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some much needed clean-up was done, but unfortunately part of the change broke DP MST. The real issue was setting the connector state to disconnected in the MST case, which is good, but the code then (after a goto) checks if the connector state is not connected and shuts down MST if this is the case, which is bad. With this change both SST and MST seem to be happy. v2: Add removed check further up in the function to be sure that MST is shut down when we lose the link. (Ander) Fixes: commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> cc: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Reviewed-by: Lyude <cpaul@redhat.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460394684-7036-1-git-send-email-jim.bride@linux.intel.com
2016-04-19Revert "ARM: OMAP: Catch callers of revision information prior to it being ↵Tony Lindgren
populated" This reverts commit 571afb4c8a4bbe88541364e7f6827340562f2736.
2016-04-19drm/i915: Clean up PCI config register handlingJoonas Lahtinen
Do not use magic numbers, do not prefix stuff with "PCI_", do not declare registers in implementation files. Also move the PCI registers under correct comment in i915_reg.h. v2: - Consistently use BSM (not BDSM or other variants from PRM) (Chris) - Also include register address to help identify the register (Chris) v3: - Refer to register value as *_val instead of *_reg (Chris) v4: - Make style checker happy Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2016-04-19drm/i915: call kunmap_px on pt_vaddrMatthew Auld
We need to kunmap pt_vaddr and not pt itself, otherwise we end up mapping a bunch of pages without ever unmapping them. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: d1c54acd67dc ("drm/i915/gtt: Introduce kmap|kunmap for dma page") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460476663-24890-4-git-send-email-matthew.auld@intel.com
2016-04-19drm/i915: Wait for power cycle delay after turning off DSI panel powerVille Syrjälä
The power cycle delay starts _after_ turning off the panel power. Do the msleep after frobbing the pmic panel power gpio. Also toss in a FIXME about optimizing away needless waits. Cc: Shobhit Kumar <shobhit.kumar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Fixes: fc45e8219907 ("drm/i915: Use the CRC gpio for panel enable/disable") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460996271-29795-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-19drm/i915: Define HSW/BDW display power domains the right way upVille Syrjälä
Currently we're trying to define HSW/BDW power wells by what's not included. Let's do it the other way around, so that you can actually tell when the power well would get enabled. This will also allow us to add new power domains without accidentally adding it to the HSW/BDW display power domains. The current set of domains looks rather buggy even: - POWER_DOMAIN_MODESET is included in the display power well needlessly - DDI-B to DDI-E were not part of the display power well when they should be So let's fix that up while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-19drm/i915: Define VLV/CHV display power well domains properlyVille Syrjälä
Currently we're using POWER_DOMAIN_MASK as the power domains for the display power well on VLV/CHV. That includes all power domains even though the disp2d/pipe-a power well is not needed for a lot of things. Let's reduce these to what we actually need. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-19drm/i915: Set .domains=POWER_DOMAIN_MASK for the always-on wellVille Syrjälä
The always-on well is the same as runtime PM, so we should just "enable" it for any power domain. Throw out the usless FOO_ALWAYS_ON_DOMAINS defines and just use POWER_DOMAIN_MASK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-19drm/i915: Fix oops in vlv_force_pll_on()Ville Syrjälä
intel_pipe_will_have_type() doesn't just look at the passied in pipe_config, instead it expects there to be a full atomic state behind it. Obviously that won't go so well when vlv_force_pll_on() just uses a temp pipe_config. Fix things by using pipe_config->has_dsi_encoder instead intel_pipe_will_have_type(INTEL_OUTPUT_DSI) to check if we need to actually enable the DPLL. Here's an example oops for reference: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 IP: [<ffffffffa0389a5b>] intel_pipe_will_have_type+0x15/0x7b [i915] PGD 7acda067 PUD 72696067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole psmouse atkbd iTCO_wdt libps2 coretemp hwmon efi_pstore intel_rapl punit_atom_debug efivars pcspkr i2c_i801 r8169 lpc_ich mii processor_thermal_device snd_soc_rt5670 intel_soc_dts_iosf snd_soc_rl6231 i2c_hid hid snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_mfld_platform snd_soc_sst_match snd_soc_core i8042 serio snd_compress snd_pcm snd_timer snd i2c_designware_platform sdhci_acpi i2c_designware_core soundcore sdhci pwm_lpss_platform mmc_core pwm_lpss spi_pxa2xx_platform evdev int3403_thermal int3400_thermal int340x_thermal_zone acpi_thermal_rel sch_fq_codel ip_tables x_tables ipv6 autofs4 CPU: 3 PID: 290 Comm: Xorg Tainted: G U 4.6.0-rc4-bsw+ #2876 Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Braswell CRB, BIOS BRAS.X64.X088.R00.1510270350 10/27/2015 task: ffff88007a8dd200 ti: ffff880173ac4000 task.ti: ffff880173ac4000 RIP: 0010:[<ffffffffa0389a5b>] [<ffffffffa0389a5b>] intel_pipe_will_have_type+0x15/0x7b [i915] RSP: 0018:ffff880173ac7928 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880176594000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff880176594000 RBP: ffff880173ac7930 R08: 0000000000019290 R09: 0000000000000000 R10: ffff880173ac7890 R11: 00000000000080cf R12: ffff88017fbd4000 R13: ffffffffa03e3c44 R14: ffff88007492c000 R15: ffff88007492c000 FS: 00007ff8936a6940(0000) GS:ffff88017ef80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000177e08000 CR4: 00000000001006e0 Stack: ffff880176594000 ffff880173ac7948 ffffffffa0389b42 ffff880176594000 ffff880173ac7978 ffffffffa0396e02 ffff8801765b0000 ffff88007af660d8 0000000000000000 0000000000000004 ffff880173ac79c0 ffffffffa03b6b64 Call Trace: [<ffffffffa0389b42>] chv_compute_dpll.isra.39+0x33/0x55 [i915] [<ffffffffa0396e02>] vlv_force_pll_on+0x80/0xc6 [i915] [<ffffffffa03b6b64>] vlv_power_sequencer_pipe+0x29b/0x3dd [i915] [<ffffffffa03b6cd4>] _pp_stat_reg+0x2e/0x38 [i915] [<ffffffffa03b6dc1>] wait_panel_status+0x4c/0x1ec [i915] [<ffffffffa03b6fcb>] wait_panel_power_cycle+0x6a/0xb4 [i915] [<ffffffffa03b70da>] edp_panel_vdd_on+0xc5/0x1d1 [i915] [<ffffffffa03b861b>] intel_dp_aux_ch+0x55/0x572 [i915] [<ffffffff810af5c8>] ? mark_held_locks+0x5d/0x74 [<ffffffff81518e61>] ? mutex_lock_nested+0x321/0x346 [<ffffffff81094007>] ? preempt_count_sub+0xf2/0x102 [<ffffffffa03b8cb4>] intel_dp_aux_transfer+0x17c/0x1b5 [i915] [<ffffffffa03028ef>] drm_dp_dpcd_access+0x62/0xed [drm_kms_helper] [<ffffffffa0302995>] drm_dp_dpcd_read+0x1b/0x1f [drm_kms_helper] [<ffffffffa03b5147>] intel_dp_dpcd_read_wake+0x31/0x69 [i915] [<ffffffffa03bb36a>] intel_dp_long_pulse+0x15f/0x5ed [i915] [<ffffffffa03bbb09>] intel_dp_detect+0x79/0x95 [i915] [<ffffffffa030340e>] drm_helper_probe_single_connector_modes+0xc7/0x3db [drm_kms_helper] [<ffffffffa029de23>] drm_mode_getconnector+0xe9/0x333 [drm] [<ffffffff810b1cfb>] ? lock_acquire+0x137/0x1df [<ffffffffa0292364>] drm_ioctl+0x266/0x3ae [drm] [<ffffffffa029dd3a>] ? drm_mode_getcrtc+0x126/0x126 [drm] [<ffffffff811af082>] vfs_ioctl+0x18/0x34 [<ffffffff811af682>] do_vfs_ioctl+0x547/0x5fe [<ffffffff811b9acb>] ? __fget_light+0x62/0x71 [<ffffffff811af77c>] SyS_ioctl+0x43/0x61 [<ffffffff81001a82>] do_syscall_64+0x63/0xf8 [<ffffffff8151bc9a>] entry_SYSCALL64_slow_path+0x25/0x25 Code: 35 00 40 a0 e8 97 4b ce e0 b8 17 00 00 00 5d c3 b8 17 00 00 00 c3 0f 1f 44 00 00 55 31 c0 31 d2 48 89 e5 53 48 8b 8f e8 01 00 00 <44> 8b 49 30 41 39 c1 7e 2d 4c 8b 51 38 4c 8b 41 40 49 83 3c c2 RIP [<ffffffffa0389a5b>] intel_pipe_will_have_type+0x15/0x7b [i915] RSP <ffff880173ac7928> CR2: 0000000000000030 The regressing patch wasn't exactly new (as in first posted more than six months ago), so I'm a bit baffled how I didn't manage to hit this myself so far. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Marius Vlad <marius.c.vlad@intel.com> Reported-by: Marius Vlad <marius.c.vlad@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94995 Fixes: cd2d34d9b61f ("drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461000844-20543-1-git-send-email-ville.syrjala@linux.intel.com Tested-by: Marius Vlad <marius.c.vlad@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-19drm/i915/gen9: Fix runtime PM refcounting in case DMC firmware isn't loadedImre Deak
While we disable runtime PM and with that display power well support if the DMC firmware isn't loaded, we still want to disable power wells during system suspend and driver unload. So drop/reacquire the corresponding power refcount during suspend/resume and driver unloading. This also means we have to check if DMC is not loaded and skip enabling DC states in the power well code. v2: - Reuse intel_csr_ucode_suspend() in intel_csr_ucode_fini() instead of opencoding the former. (Chris) - Add docbook comment to the public resume and suspend functions. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460980101-14713-1-git-send-email-imre.deak@intel.com
2016-04-19drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resumeImre Deak
The driver's VDD on/off logic assumes that whenever the VDD is on we also hold an AUX power domain reference. Since BIOS can leave the VDD on during booting and resuming and on DDI platforms we won't take a corresponding power reference, the above assumption won't hold on those platforms and an eventual delayed VDD off work will do an extraneous AUX power domain put resulting in a refcount underflow. Fix this the same way we did this for non-DDI DP encoders: commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system resume") At the same time call the DP encoder suspend handler the same way as the non-DDI DP encoders do to flush any pending VDD off work. Leaving the work running may cause a HW access where we don't expect this (at a point where power domains are suspended already). While at it remove an unnecessary function call indirection. This fixed for me AUX refcount underflow problems on BXT during suspend/resume. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
2016-04-19drm/i915: Fix system resume if PCI device remained enabledImre Deak
During system resume we depended on pci_enable_device() also putting the device into PCI D0 state. This won't work if the PCI device was already enabled but still in D3 state. This is because pci_enable_device() is refcounted and will not change the HW state if called with a non-zero refcount. Leaving the device in D3 will make all subsequent device accesses fail. This didn't cause a problem most of the time, since we resumed with an enable refcount of 0. But it fails at least after module reload because after that we also happen to leak a PCI device enable reference: During probing we call drm_get_pci_dev() which will enable the PCI device, but during device removal drm_put_dev() won't disable it. This is a bug of its own in DRM core, but without much harm as it only leaves the PCI device enabled. Fixing it is also a bit more involved, due to DRM mid-layering and because it affects non-i915 drivers too. The fix in this patch is valid regardless of the problem in DRM core. v2: - Add a code comment about the relation of this fix to the freeze/thaw vs. the suspend/resume phases. (Ville) - Add a code comment about the inconsistent ordering of set power state and device enable calls. (Chris) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
2016-04-19drm/i915: Fix error path in i915_drm_resume_earlyImre Deak
If system resume fails, this may lead to a runtime PM wake reference underflow used for runtime PM state checking. Fixes: 1f814daca43a ("drm/i915: add support for checking if we hold an RPM reference") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-2-git-send-email-imre.deak@intel.com
2016-04-19locking/pvqspinlock: Fix division by zero in qstat_read()Davidlohr Bueso
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 <dbueso@suse.de> Reviewed-by: Waiman Long <Waiman.Long@hpe.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: dave@stgolabs.net Cc: waiman.long@hpe.com Link: http://lkml.kernel.org/r/1460961103-24953-1-git-send-email-dave@stgolabs.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-19Merge tag 'perf-urgent-for-mingo-20160418' of ↵Ingo Molnar
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 <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-19Revert "serial: 8250: Add hardware dependency to RT288X option"Greg Kroah-Hartman
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 <slash.tmp@free.fr> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Jean Delvare <jdelvare@suse.de> Cc: Mans Rullgard <mans@mansr.com> Cc: Jiri Slaby <jslaby@suse.com> Cc: John Crispin <blogic@openwrt.org> Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
2016-04-19tty/serial/8250: fix RS485 half-duplex RXYegor Yefremov
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 <matwey@sai.msu.ru> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250") Acked-by: Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-19Revert "serial-uartlite: Constify uartlite_be/uartlite_le"Sudip Mukherjee
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 <sudip.mukherjee@codethink.co.uk> Cc: Maarten Brock <m.brock@vanmierlo.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-18Merge tag 'pci-v4.6-fixes-2' of ↵Linus Torvalds
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"
generated by cgit (git 2.34.1) at 2025-09-14 20:05:24 +0000