summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-23xsk: Fix registration of Rx-only socketsMagnus Karlsson
Having Rx-only AF_XDP sockets can potentially lead to a crash in the system by a NULL pointer dereference in xsk_umem_consume_tx(). This function iterates through a list of all sockets tied to a umem and checks if there are any packets to send on the Tx ring. Rx-only sockets do not have a Tx ring, so this will cause a NULL pointer dereference. This will happen if you have registered one or more Rx-only sockets to a umem and the driver is checking the Tx ring even on Rx, or if the XDP_SHARED_UMEM mode is used and there is a mix of Rx-only and other sockets tied to the same umem. Fixed by only putting sockets with a Tx component on the list that xsk_umem_consume_tx() iterates over. Fixes: ac98d8aab61b ("xsk: wire upp Tx zero-copy functions") Reported-by: Kal Cutter Conley <kal.conley@dectris.com> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/bpf/1571645818-16244-1-git-send-email-magnus.karlsson@intel.com
2019-10-23net/flow_dissector: switch to siphashEric Dumazet
UDP IPv6 packets auto flowlabels are using a 32bit secret (static u32 hashrnd in net/core/flow_dissector.c) and apply jhash() over fields known by the receivers. Attackers can easily infer the 32bit secret and use this information to identify a device and/or user, since this 32bit secret is only set at boot time. Really, using jhash() to generate cookies sent on the wire is a serious security concern. Trying to change the rol32(hash, 16) in ip6_make_flowlabel() would be a dead end. Trying to periodically change the secret (like in sch_sfq.c) could change paths taken in the network for long lived flows. Let's switch to siphash, as we did in commit df453700e8d8 ("inet: switch IP ID generator to siphash") Using a cryptographically strong pseudo random function will solve this privacy issue and more generally remove other weak points in the stack. Packet schedulers using skb_get_hash_perturb() benefit from this change. Fixes: b56774163f99 ("ipv6: Enable auto flow labels by default") Fixes: 42240901f7c4 ("ipv6: Implement different admin modes for automatic flow labels") Fixes: 67800f9b1f4e ("ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel") Fixes: cb1ce2ef387b ("ipv6: Implement automatic flow label generation on transmit") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Berger <jonathann1@walla.com> Reported-by: Amit Klein <aksecurity@gmail.com> Reported-by: Benny Pinkas <benny@pinkas.net> Cc: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23Merge tag 'arm-soc/for-5.5/maintainers' of ↵Olof Johansson
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains MAINTAINERS file updates for Broadcom SoCs for the 5.5 kernel, please pull the following: - Simon adds a .mailmap alias for his old email - Stefan updates the existing BCM2835 with BCM2711 which is the chip name for the Raspberry Pi 4 - Florian removes Gregory and Brian from the MAINTAINERS file for BRCMSTB SoCs * tag 'arm-soc/for-5.5/maintainers' of https://github.com/Broadcom/stblinux: MAINTAINERS: Remove Gregory and Brian for ARCH_BRCMSTB mailmap: Add Simon Arlott (replacement for expired email address) MAINTAINERS: Add BCM2711 to BCM2835 ARCH Link: https://lore.kernel.org/r/20191023212814.30622-3-f.fainelli@gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-23MAINTAINERS: Update the Spreadtrum SoC maintainerBaolin Wang
Change my email address, and add more Spreadtrum SC27xx series PMIC drivers to maintain. Link: https://lore.kernel.org/r/a48483d13243450ecf3b777d49e741b6367f2c6b.1571881956.git.baolin.wang@linaro.org Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-23drm/i915/gvt: fix dead locking in early workload shadowZhenyu Wang
As early workload scan and shadow happens in execlist mmio handler, which has already taken vgpu_lock. So remove extra lock taking here. Fixes: 952f89f098c7 ("drm/i915/gvt: Wean off struct_mutex") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2019-10-23drm/i915/gt: Replace hangcheck by heartbeatsChris Wilson
Replace sampling the engine state every so often with a periodic heartbeat request to measure the health of an engine. This is coupled with the forced-preemption to allow long running requests to survive so long as they do not block other users. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023133108.21401-5-chris@chris-wilson.co.uk
2019-10-23drm/i915/gem: Cancel contexts when hangchecking is disabledChris Wilson
Normally, we rely on our hangcheck to prevent persistent batches from hogging the GPU. However, if the user disables hangcheck, this mechanism breaks down. Despite our insistence that this is unsafe, the users are equally insistent that they want to use endless batches and will disable the hangcheck mechanism. We are looking at replacing hangcheck, in the next patch, with a softer mechanism, that sends a pulse down the engine to check if it is well. We can use the same preemptive pulse to flush an active context off the GPU upon context close, preventing resources being lost and unkillable requests remaining on the GPU after process termination. Testcase: igt/gem_ctx_exec/basic-nohangcheck Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023133108.21401-4-chris@chris-wilson.co.uk
2019-10-23drm/i915/execlists: Cancel banned contexts on schedule-outChris Wilson
On schedule-out (CS completion) of a banned context, scrub the context image so that we do not replay the active payload. The intent is that we skip banned payloads on request submission so that the timeline advancement continues on in the background. However, if we are returning to a preempted request, i915_request_skip() is ineffective and instead we need to patch up the context image so that it continues from the start of the next request. v2: Fixup cancellation so that we only scrub the payload of the active request and do not short-circuit the breadcrumbs (which might cause other contexts to execute out of order). v3: Grammar pass Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023133108.21401-3-chris@chris-wilson.co.uk
2019-10-23drm/i915/execlists: Force preemptionChris Wilson
If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging unresponsive contexts more frequently (i.e. instead of using an ~10s hangcheck, we now evict at ~100ms). The challenge of lies in picking a timeout that can be reasonably serviced by HW for typical workloads, balancing the existing clients against the needs for responsiveness. Note that coupled with timeslicing, this will lead to rapid GPU "hang" detection with multiple active contexts vying for GPU time. The forced preemption mechanism can be compiled out with ./scripts/config --set-val DRM_I915_PREEMPT_TIMEOUT 0 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023133108.21401-2-chris@chris-wilson.co.uk
2019-10-23drm/i915/gt: Try to more gracefully quiesce the system before resetsChris Wilson
If we are doing a normal GPU reset triggered after detecting a long period of stalled work, we can take our time and allow the engines to quiesce. Since we've stopped submission to the engine, and if we wait long enough an innocent context should complete, leaving the engine idle. So by waiting a short amount of time, we should prevent clobbering other users when resetting a stuck context. Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023133108.21401-1-chris@chris-wilson.co.uk
2019-10-23drm/i915/guc: Update H2G enable logging action definitionRobert M. Fosha
GuC enable logging H2G action definition changed some time ago from 0xE000 to 0x40. All current GuC FW blobs use this definition, so fix the action definition in driver to match. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022163754.23870-2-robert.m.fosha@intel.com
2019-10-23drm/i915/guc: Enable guc logging on guc log relay writeRobert M. Fosha
Creating and opening the GuC log relay file enables and starts the relay potentially before the caller is ready to consume logs. Change the behavior so that relay starts only on an explicit call to the write function (with a value of '1'). Other values flush the log relay as before. v2: Style changes and fix typos. Add guc_log_relay_stop() function. (Daniele) Cc: Matthew Brost <matthew.brost@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022163754.23870-1-robert.m.fosha@intel.com
2019-10-23riscv: cleanup <asm/bug.h>Christoph Hellwig
Remove various not required ifdefs and externs. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-10-23riscv: Fix undefined reference to vmemmap_populate_basepagesKefeng Wang
Using CONFIG_SPARSEMEM_VMEMMAP instead of CONFIG_SPARSEMEM to fix following build issue. riscv64-linux-ld: arch/riscv/mm/init.o: in function 'vmemmap_populate': init.c:(.meminit.text+0x8): undefined reference to 'vmemmap_populate_basepages' Cc: Logan Gunthorpe <logang@deltatee.com> Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-10-23riscv: Fix implicit declaration of 'page_to_section'Kefeng Wang
With CONFIG_SPARSEMEM and !CONFIG_SPARSEMEM_VMEMMAP, arch/riscv/include/asm/pgtable.h: In function ‘mk_pte’: include/asm-generic/memory_model.h:64:14: error: implicit declaration of function ‘page_to_section’; did you mean ‘present_section’? [-Werror=implicit-function-declaration] int __sec = page_to_section(__pg); \ ^~~~~~~~~~~~~~~ Fixed by changing mk_pte() from inline function to macro. Cc: Logan Gunthorpe <logang@deltatee.com> Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> [paul.walmsley@sifive.com: fixed checkpatch errors] Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-10-23riscv: fix fs/proc/kcore.c compilation with sparsemem enabledDavid Abdurachmanov
Failed to compile Fedora/RISCV kernel (5.4-rc3+) with sparsemem enabled: fs/proc/kcore.c: In function 'read_kcore': fs/proc/kcore.c:510:8: error: implicit declaration of function 'kern_addr_valid'; did you mean 'virt_addr_valid'? [-Werror=implicit-function-declaration] 510 | if (kern_addr_valid(start)) { | ^~~~~~~~~~~~~~~ | virt_addr_valid Looking at other architectures I don't see kern_addr_valid being guarded by CONFIG_FLATMEM. Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem") Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com> Tested-by: David Abdurachmanov <david.abdurachmanov@sifive.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-10-23of: reserved_mem: add missing of_node_put() for proper ref-countingChris Goldsworthy
Commit d698a388146c ("of: reserved-memory: ignore disabled memory-region nodes") added an early return in of_reserved_mem_device_init_by_idx(), but didn't call of_node_put() on a device_node whose ref-count was incremented in the call to of_parse_phandle() preceding the early exit. Fixes: d698a388146c ("of: reserved-memory: ignore disabled memory-region nodes") Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-23Merge tag 'trace-v5.4-rc3-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "Two minor fixes: - A race in perf trace initialization (missing mutexes) - Minor fix to represent gfp_t in synthetic events as properly signed" * tag 'trace-v5.4-rc3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix race in perf_trace_buf initialization tracing: Fix "gfp_t" format for synthetic events
2019-10-23of: unittest: fix memory leak in unittest_data_addNavid Emamdoost
In unittest_data_add, a copy buffer is created via kmemdup. This buffer is leaked if of_fdt_unflatten_tree fails. The release for the unittest_data buffer is added. Fixes: b951f9dc7f25 ("Enabling OF selftest to run without machine's devicetree") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-23dt-bindings: riscv: Fix CPU schema errorsRob Herring
Fix the errors in the RiscV CPU DT schema: Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: 'timebase-frequency' is a required property Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@1: 'timebase-frequency' is a required property Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: compatible:0: 'riscv' is not one of ['sifive,rocket0', 'sifive,e5', 'sifive,e51', 'sifive,u54-mc', 'sifive,u54', 'sifive,u5'] Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: compatible: ['riscv'] is too short Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: 'timebase-frequency' is a required property The DT spec allows for 'timebase-frequency' to be in 'cpu' or 'cpus' node and RiscV requires it in /cpus node, so make it disallowed in cpu nodes. Fixes: 4fd669a8c487 ("dt-bindings: riscv: convert cpu binding to json-schema") Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: linux-riscv@lists.infradead.org Acked-by: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-10-23Merge tag 'vfio-v5.4-rc5' of git://github.com/awilliam/linux-vfioLinus Torvalds
Pull VFIO fixlet from Alex Williamson: "Fix (false) uninitialized variable warning (Joerg Roedel)" * tag 'vfio-v5.4-rc5' of git://github.com/awilliam/linux-vfio: vfio/type1: Initialize resv_msi_base
2019-10-23Merge tag 'regulator-fix-v5.4-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "There are a few core fixes here around error handling and handling if suspend mode configuration and some driver specific fixes here but the most important change is the fix to the fixed-regulator DT schema conversion introduced during the last merge window. That fixes one of the last two errors preventing successful execution of "make dt_binding_check" which will be enormously helpful for DT schema development" * tag 'regulator-fix-v5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: qcom-rpmh: Fix PMIC5 BoB min voltage regulator: pfuze100-regulator: Variable "val" in pfuze100_regulator_probe() could be uninitialized regulator: lochnagar: Add on_off_delay for VDDCORE regulator: ti-abb: Fix timeout in ti_abb_wait_txdone/ti_abb_clear_all_txdone regulator: da9062: fix suspend_enable/disable preparation dt-bindings: fixed-regulator: fix compatible enum regulator: fixed: Prevent NULL pointer dereference when !CONFIG_OF regulator: core: make regulator_register() EPROBE_DEFER aware regulator: of: fix suspend-min/max-voltage parsing
2019-10-23MAINTAINERS: Remove Gregory and Brian for ARCH_BRCMSTBFlorian Fainelli
The last time Gregory and Brian did a review was sometime around 2015, since then, they have not been active for ARCH_BRCMSTB changes. Following the position of other maintainers and Harald Welte's position here: [1] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/ remove both of them. Acked-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-23drm/v3d: Fix memory leak in v3d_submit_cl_ioctlNavid Emamdoost
In the impelementation of v3d_submit_cl_ioctl() there are two memory leaks. One is when allocation for bin fails, and the other is when bin initialization fails. If kcalloc fails to allocate memory for bin then render->base should be put. Also, if v3d_job_init() fails to initialize bin->base then allocated memory for bin should be released. Fixes: a783a09ee76d ("drm/v3d: Refactor job management.") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021185250.26130-1-navid.emamdoost@gmail.com
2019-10-23panfrost: Properly undo pm_runtime_enable when deferring a probeTomeu Vizoso
When deferring the probe because of a missing regulator, we were calling pm_runtime_disable even if pm_runtime_enable wasn't called. Move the call to pm_runtime_disable to the right place. Fixes: 635430797d3f ("drm/panfrost: Rework runtime PM initialization") Reported-by: Chen-Yu Tsai <wens@csie.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191023122157.32067-1-tomeu.vizoso@collabora.com
2019-10-23drm/i915: Add new CNL PCH ID seen on a CML platformImre Deak
Atm we don't detect a PCH with PCI ID 0xA3C1 which showed up now on a CML platform. We don't have the official assignment of the PCH PCI IDs, but this looks like a CNP which was already used on CML platforms. Let's add the new ID->PCH type mapping accordingly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051 Reported-and-tested-by: Cyrus <cyrus.lien@canonical.com> Cc: Cyrus <cyrus.lien@canonical.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022095155.30991-1-imre.deak@intel.com
2019-10-23ASoC: kirkwood: fix device remove orderingRussell King
The devm conversion of kirkwood was incorrect; on removal, devm takes effect after the "remove" function has returned. So, the effect of the conversion was to change the order during remove from: - snd_soc_unregister_component() (unpublishes interfaces) - clk_disable_unprepare() - cleanup resources After the conversion, this became: - clk_disable_unprepare() - while the device may still be active - snd_soc_unregister_component() - cleanup resources Hence, it introduces a bug, where the internal clock for the device may be shut down before the device itself has been shut down. It is known that Marvell SoCs, including Dove, locks up if registers for a peripheral that has its clocks disabled are accessed. Fixes: f98fc0f8154e ("ASoC: kirkwood: replace platform to component") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1iNGyP-0004oN-BA@rmk-PC.armlinux.org.uk Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-23ASoC: rsnd: dma: fix SSI9 4/5/6/7 busif dma addressJiada Wang
Currently each SSI unit's busif dma address is calculated by following calculation formula: 0xec540000 + 0x1000 * id + busif / 4 * 0xA000 + busif % 4 * 0x400 But according to R-Car3 HW manual 41.1.4 Register Configuration, ssi9 4/5/6/7 busif data register address (SSI9_4_BUSIF/SSI9_5_BUSIF/SSI9_6_BUSIF/SSI9_7_BUSIF) are out of this rule. This patch updates the calculation formula to correct ssi9 4/5/6/7 busif data register address. Fixes: 5e45a6fab3b9 ("ASoc: rsnd: dma: Calculate dma address with consider of BUSIF") Signed-off-by: Jiada Wang <jiada_wang@mentor.com> Signed-off-by: Timo Wischer <twischer@de.adit-jv.com> [erosca: minor improvements in commit description] Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com> Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20191022185429.12769-1-erosca@de.adit-jv.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-23ASoC: hdmi-codec: drop mutex locking againJerome Brunet
This reverts commit eb1ecadb7f67dde94ef0efd3ddaed5cb6c9a65ed. This fixes the following warning reported by lockdep and a potential issue with hibernation ==================================== WARNING: pulseaudio/1297 still has locks held! 5.3.0+ #1826 Not tainted ------------------------------------ 1 lock held by pulseaudio/1297: #0: ee815308 (&hcp->lock){....}, at: hdmi_codec_startup+0x20/0x130 stack backtrace: CPU: 0 PID: 1297 Comm: pulseaudio Not tainted 5.3.0+ #1826 Hardware name: Marvell Dove (Cubox) [<c0017b4c>] (unwind_backtrace) from [<c0014d10>] (show_stack+0x10/0x14) [<c0014d10>] (show_stack) from [<c00a2d18>] (futex_wait_queue_me+0x13c/0x19c) [<c00a2d18>] (futex_wait_queue_me) from [<c00a3630>] (futex_wait+0x184/0x24c) [<c00a3630>] (futex_wait) from [<c00a5e1c>] (do_futex+0x334/0x598) [<c00a5e1c>] (do_futex) from [<c00a62e8>] (sys_futex_time32+0x118/0x180) [<c00a62e8>] (sys_futex_time32) from [<c0009000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xebd31fa8 to 0xebd31ff0) 1fa0: 00000000 ffffffff 000c8748 00000189 00000001 00000000 1fc0: 00000000 ffffffff 00000000 000000f0 00000000 00000000 00000000 00056200 1fe0: 000000f0 beac03a8 b6d6c835 b6d6f456 Fixes: eb1ecadb7f67 ("ASoC: hdmi-codec: re-introduce mutex locking") Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20191023161203.28955-2-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-23Merge tag 'omap-for-v5.4/fixes-rc4-signed' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Three fixes for omaps for v5.4-rc cycle Two regression fixes for omap3 iommu. I missed applying two omap3 related iommu pdata quirks patches earlier because the kbuild test robot produced errors on them for missing dependencies. Fix ti-sysc interconnect target module driver handling for watchdog quirk. I must have tested this earlier only with watchdog service running, but clearly it does not do what it needs to do. * tag 'omap-for-v5.4/fixes-rc4-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: bus: ti-sysc: Fix watchdog quirk handling ARM: OMAP2+: Add pdata for OMAP3 ISP IOMMU ARM: OMAP2+: Plug in device_enable/idle ops for IOMMUs Link: https://lore.kernel.org/r/pull-1571848757-282222@atomide.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-23ASoC: kirkwood: fix external clock probe deferRussell King
When our call to get the external clock fails, we forget to clean up the enabled internal clock correctly. Enable the clock after we have obtained all our resources. Fixes: 84aac6c79bfd ("ASoC: kirkwood: fix loss of external clock at probe time") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1iNGyK-0004oF-6A@rmk-PC.armlinux.org.uk Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-23clk: samsung: exynos542x: Move G3D subsystem clocks to its sub-CMUMarek Szyprowski
G3D clocks require special handling of their parent bus clock during power domain on/off sequences. Those clocks were not initially added to the sub-CMU handler, because that time there was no open-source driver for the G3D (MALI Panfrost) hardware module and it was not possible to test it. This patch fixes this issue. Parent clock for G3D hardware block is now properly preserved during G3D power domain on/off sequence. This restores proper MALI Panfrost performance broken by commit 8686764fc071 ("ARM: dts: exynos: Add G3D power domain to Exynos542x"). Reported-by: Marian Mihailescu <mihailescu2m@gmail.com> Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marian Mihailescu <mihailescu2m@gmail.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
2019-10-23clk: samsung: exynos5433: Fix error pathsMarek Szyprowski
Add checking the value returned by samsung_clk_alloc_reg_dump() and devm_kcalloc(). While fixing this, also release all gathered clocks. Fixes: 523d3de41f02 ("clk: samsung: exynos5433: Add support for runtime PM") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> [s.nawrocki: squashed patch from K. Kozlowski adding missing slab.h header] Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
2019-10-23drm/tegra: Move drm_dp_link helpers to Tegra DRMThierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. After all other drivers have been converted not to use these helpers anymore, move these helpers into the last remaining user: Tegra DRM. If at some point these helpers are deemed more widely useful, they can be moved out into the DRM DP helpers again. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-14-thierry.reding@gmail.com
2019-10-23drm/rockchip: Avoid drm_dp_link helpersThierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-13-thierry.reding@gmail.com
2019-10-23drm/msm: edp: Avoid drm_dp_link helpersThierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-12-thierry.reding@gmail.com
2019-10-23drm/bridge: tc358767: Use DP nomenclatureThierry Reding
The DP specification uses the term "default framing" instead of "non- enhanced framing". Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-11-thierry.reding@gmail.com
2019-10-23drm/bridge: tc358767: Avoid drm_dp_link helpersThierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v3: make link rate unsigned int to avoid overflow Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-10-thierry.reding@gmail.com
2019-10-23drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpersThierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v4: use bulk DPCD writes if possible (Daniel Vetter) Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191022145211.2258525-1-thierry.reding@gmail.com
2019-10-23drm/dp: Add helper to get post-cursor adjustmentsThierry Reding
If the transmitter supports pre-emphasis post cursor2 the sink will request adjustments in a similar way to how it requests adjustments to the voltage swing and pre-emphasis settings. Add a helper to extract these adjustments on a per-lane basis from the DPCD link status. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-8-thierry.reding@gmail.com
2019-10-23drm/dp: Do not busy-loop during link trainingThierry Reding
Use microsecond sleeps for the clock recovery and channel equalization delays during link training. The duration of these delays can be from 100 us up to 16 ms. It is rude to busy-loop for that amount of time. While at it, also convert to standard coding style by putting the opening braces in a function definition on a new line. Also switch to using an unsigned int for the AUX read interval to match the data type of the parameters to usleep_range(). v2: use correct multiplier for training delays (Philipp Zabel) v3: clarify data type change in commit message Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-7-thierry.reding@gmail.com
2019-10-23drm/dp: Add drm_dp_alternate_scrambler_reset_cap() helperThierry Reding
Add a helper to check if the sink supports the eDP alternate scrambler reset value of 0xfffe. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-6-thierry.reding@gmail.com
2019-10-23drm/dp: Add drm_dp_channel_coding_supported() helperThierry Reding
Add a helper to check whether the sink supports ANSI 8B/10B channel coding capability as specified in ANSI X3.230-1994, clause 11. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-5-thierry.reding@gmail.com
2019-10-23drm/dp: Add drm_dp_fast_training_cap() helperThierry Reding
Add a helper that checks for the fast training capability given the DPCD receiver capabilities blob. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-4-thierry.reding@gmail.com
2019-10-23drm/dp: Remove a gratuituous blank lineThierry Reding
It's idiomatic to check the return value of a function call immediately after the function call, without any blank lines in between, to make it more obvious that the two lines belong together. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-3-thierry.reding@gmail.com
2019-10-23drm/dp: Sort includes alphabeticallyThierry Reding
Keeping the list sorted alphabetically makes it much easier to determine where to add new includes. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-2-thierry.reding@gmail.com
2019-10-23dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idleTony Lindgren
Yegor Yefremov <yegorslists@googlemail.com> reported that musb and ftdi uart can fail for the first open of the uart unless connected using a hub. This is because the first dma call done by musb_ep_program() must wait if cppi41 is PM runtime suspended. Otherwise musb_ep_program() continues with other non-dma packets before the DMA transfer is started causing at least ftdi uarts to fail to receive data. Let's fix the issue by waking up cppi41 with PM runtime calls added to cppi41_dma_prep_slave_sg() and return NULL if still idled. This way we have musb_ep_program() continue with PIO until cppi41 is awake. Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support") Reported-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/20191023153138.23442-1-tony@atomide.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-10-23Merge tag 'sunxi-fixes-for-5.4-1' of ↵Olof Johansson
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes A number of fixes for this release, but mostly: - A fixup for the A10 CSI DT binding merged during the 5.4-rc1 window - A fix for a dt-binding error - Addition of phy regulator delays - The PMU on the A64 was found to be non-functional, so we've dropped it for now * tag 'sunxi-fixes-for-5.4-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: dts: sun7i: Drop the module clock from the device tree dt-bindings: media: sun4i-csi: Drop the module clock media: dt-bindings: Fix building error for dt_binding_check arm64: dts: allwinner: a64: sopine-baseboard: Add PHY regulator delay arm64: dts: allwinner: a64: Drop PMU node arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay Link: https://lore.kernel.org/r/80085a57-c40f-4bed-a9c3-19858d87564e.lettre@localhost Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-23Merge drm/drm-next into drm-misc-nextSean Paul
Parroting Daniel's backmerge justification from 2e79e22e092acd55da0b2db066e4826d7d152c41: Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Signed-off-by: Sean Paul <seanpaul@chromium.org>
2019-10-23Revert "drm/omap: add OMAP_BO flags to affect buffer allocation"Sean Paul
This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679. This patch does not have an acceptable open source userspace implementation, and as such it does not meet the requirements for adding new UAPI. Discussion is in the Link. Link: https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html Fixes: 23b482252836 ("drm/omap: add OMAP_BO flags to affect buffer allocation") Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191022204733.235801-1-sean@poorly.run
generated by cgit (git 2.34.1) at 2025-10-01 21:15:13 +0000