summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-02-05Merge tag 'rpmsg-v4.16' of git://github.com/andersson/remoteprocLinus Torvalds
Pull rpmsg updates from Bjorn Andersson: "This fixes a few issues found in the SMD and GLINK drivers and corrects the handling of SMD channels that are found in an (previously) unexpected state" * tag 'rpmsg-v4.16' of git://github.com/andersson/remoteproc: rpmsg: smd: Fix double unlock in __qcom_smd_send() rpmsg: glink: Fix missing mutex_init() in qcom_glink_alloc_channel() rpmsg: smd: Don't hold the tx lock during wait rpmsg: smd: Fail send on a closed channel rpmsg: smd: Wake up all waiters rpmsg: smd: Create device for all channels rpmsg: smd: Perform handshake during open rpmsg: glink: smem: Ensure ordering during tx drivers: rpmsg: remove duplicate includes remoteproc: qcom: Use PTR_ERR_OR_ZERO() in glink prob
2018-02-05drm/i915: fix misalignment in HDCP register defRamalingam C
This patch aligns all definitions of hdcp registers and their bits. v2: No changes. Added reviewed-by tag. v3: No change. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-9-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Reauthenticate HDCP on failureRamalingam C
Incase of HDCP authentication failure, HDCP spec expects reauthentication. Hence this patch adds the reauthentications to be compliance with spec. v2: do-while to for loop for simplicity. [Seanpaul] v3: positioning the logs effectively. [Seanpaul] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-8-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Detect panel's hdcp capabilityRamalingam C
DP HDCP1.4 spec mandates that An can be written to panel only after detecting the panel's hdcp capability. For DP 0th Bit of Bcaps register indicates the panel's hdcp capability For HDMI valid BKSV indicates the panel's hdcp capability. For HDMI it is optional to detect the panel's hdcp capability before An Write. v2: Added comments explaining the need for action [Seanpaul]. Made panel's hdcp capability detection optional for hdmi [Seanpaul]. Defined a func for reading bcaps for DP [Seanpaul]. v3: Removed the NULL initialization [Seanpaul]. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-7-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Optimize HDCP key loadRamalingam C
HDCP key need not be cleared on each hdcp disable. And HDCP key Load is skipped if key is already loaded. v2: No change. Added Reviewed-by tag. v3: No change. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-6-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Retry HDCP bksv readRamalingam C
HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv. v2: Rephrased the commit msg [Seanpaul] v3: do-while to for-loop [Seanpaul] v4: retry only if bksv is invalid and no error msg on each attempt [Seanpaul] v5: Correcting the return value [Seanpaul]. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517851922-30547-1-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Connector info in HDCP debug msgsRamalingam C
When HDCP authentication is triggered on multiple connector, having connector name and ID in debug message will be more informative. v2: Added logs with connector info at the start of en/disable [Seanpaul] Added the connector info into Check link failure msgs too. v3: No Changes. Added Reviewed-by tag. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-4-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Stop encryption for repeater with no sinkRamalingam C
If a HDCP repeater is detected with zero downstream devices, HDCP spec approves either of below actions: 1. Dont continue on second stage authentication. Disable encryption. 2. Continue with second stage authentication excluding the KSV list and on success, continue encryption. Since disable encryption is agreed, repeater is not expected to have its own display. So there is no consumption of the display content in such setup. Hence, incase of repeater with zero device count, this patch fails the HDCP authentication and stops the HDCP encryption. v2: Rephrased commit msg and added comments in code [Seanpaul] v3: No changes. Added Reviewed-by tag. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-3-git-send-email-ramalingam.c@intel.com
2018-02-05drm/i915: Handle failure from 2nd stage HDCP authRamalingam C
We enable the HDCP encryption as a part of first stage authentication. So when second stage authentication fails, we need to disable the HDCP encryption and signalling. This patch ensures that, when hdcp authentication fails, HDCP encryption and signalling is turned off. v2: Dropped connector ref passing to auth [Seanpaul] Moved the call to disable_hdcp() to enable_hdcp() [Seanpaul] v3: No Changes. Added the Reveiwed-by tag. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-2-git-send-email-ramalingam.c@intel.com
2018-02-05Merge tag 'mmc-v4.16-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC host fixes from Ulf Hansson: - renesas_sdhi: Fix build error in case NO_DMA=y - sdhci: Implement a bounce buffer to address throughput regressions * tag 'mmc-v4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: MMC_SDHI_{SYS,INTERNAL}_DMAC should depend on HAS_DMA mmc: sdhci: Implement an SDHCI-specific bounce buffer
2018-02-05Merge tag 'pwm/for-4.16-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "The Meson PWM controller driver gains support for the AXG series and a minor bug is fixed for the STMPE driver. To round things off, the class is now set for PWM channels exported via sysfs which allows non-root access, provided that the system has been configured accordingly" * tag 'pwm/for-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: meson: Add clock source configuration for Meson-AXG dt-bindings: pwm: Update bindings for the Meson-AXG pwm: stmpe: Fix wrong register offset for hwpwm=2 case pwm: Set class for exported channels in sysfs
2018-02-05net: mediatek: Explicitly include pinctrl headersThierry Reding
The Mediatek ethernet driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h and pinctrl/devinfo.h being pulled in by the device.h header implicitly. Include these headers explicitly to avoid the build failure. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-05mmc: meson-gx-mmc: Explicitly include pinctr/consumer.hThierry Reding
The Meson GX MMC driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h being pulled in by the device.h header implicitly. Include the header explicitly to avoid the build failure. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-05drm/rockchip: lvds: Explicitly include pinctrl headersThierry Reding
The Rockchip LVDS driver fails to build after commit 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") because it relies on the pinctrl/consumer.h and pinctrl/devinfo.h being pulled in by the device.h header implicitly. Include these headers explicitly to avoid the build failure. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-05pinctrl: files should directly include apis they useStephen Rothwell
Fixes: 23c35f48f5fb ("pinctrl: remove include file from <linux/device.h>") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-05perf tools: Add trace/beauty/generated/ into .gitignoreRavi Bangoria
No functionality changes. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/20180130053053.13214-2-ravi.bangoria@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-02-05perf trace: Fix call-graph outputRavi Bangoria
Recently, Arnaldo fixed global vs event specific --max-stack usage with commit bd3dda9ab0fb ("perf trace: Allow overriding global --max-stack per event"). This commit is having a regression when we don't use --max-stack at all with perf trace. Ex, $ ./perf trace record -g ls $ ./perf trace -i perf.data 0.076 ( 0.002 ms): ls/9109 brk( 0.196 ( 0.008 ms): ls/9109 access(filename: 0x9f998b70, mode: R 0.209 ( 0.031 ms): ls/9109 open(filename: 0x9f998978, flags: CLOEXEC This is missing call-traces. After patch: $ ./perf trace -i perf.data 0.076 ( 0.002 ms): ls/9109 brk( do_syscall_trace_leave ([kernel.kallsyms]) [0] ([unknown]) syscall_exit_work ([kernel.kallsyms]) brk (/usr/lib64/ld-2.17.so) _dl_sysdep_start (/usr/lib64/ld-2.17.so) _dl_start_final (/usr/lib64/ld-2.17.so) _dl_start (/usr/lib64/ld-2.17.so) _start (/usr/lib64/ld-2.17.so) 0.196 ( 0.008 ms): ls/9109 access(filename: 0x9f998b70, mode: R do_syscall_trace_leave ([kernel.kallsyms]) [0] ([unknown]) Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: bd3dda9ab0fb ("perf trace: Allow overriding global --max-stack per event") Link: http://lkml.kernel.org/r/20180130053053.13214-3-ravi.bangoria@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-02-05x86/events/intel/ds: Add PERF_SAMPLE_PERIOD into PEBS_FREERUNNING_FLAGSJiri Olsa
Stephane reported that we don't support period for enabling large PEBS data, which there's no reason for. Adding PERF_SAMPLE_PERIOD into freerunning flags. Tested it with: # perf record -e cycles:P -c 100 --no-timestamp -C 0 --period Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Kan Liang <kan.liang@intel.com> Tested-by: Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180201083812.11359-4-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-02-05net/mlx5: increase async EQ to avoid EQ overrunMax Gurtovoy
Currently the async EQ has 256 entries only. It might not be big enough for the SW to handle all the needed pending events. For example, in case of many QPs (let's say 1024) connected to a SRQ created using NVMeOF target and the target goes down, the FW will raise 1024 "last WQE reached" events and may cause EQ overrun. Increase the EQ to more reasonable size, that beyond it the FW should be able to delay the event and raise it later on using internal backpressure mechanism. Signed-off-by: Max Gurtovoy <maxg@mellanox.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Doug Ledford <dledford@redhat.com>
2018-02-05mlx5: fix mlx5_get_vector_affinity to start from completion vector 0Sagi Grimberg
The consumers of this routine expects the affinity map of of vector index relative to the first completion vector. The upper layers are not aware of internal/private completion vectors that mlx5 allocates for its own usage. Hence, return the affinity map of vector index relative to the first completion vector. Fixes: 05e0cc84e00c ("net/mlx5: Fix get vector affinity helper function") Reported-by: Logan Gunthorpe <logang@deltatee.com> Tested-by: Max Gurtovoy <maxg@mellanox.com> Reviewed-by: Max Gurtovoy <maxg@mellanox.com> Cc: <stable@vger.kernel.org> # v4.15 Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Doug Ledford <dledford@redhat.com>
2018-02-05RDMA/hns: Fix the endian problem for hnsoulijun
The hip06 and hip08 run on a little endian ARM, it needs to revise the annotations to indicate that the HW uses little endian data in the various DMA buffers, and flow the necessary swaps throughout. The imm_data use big endian mode. The cpu_to_le32/le32_to_cpu swaps are no-op for this, which makes the only substantive change the handling of imm_data which is now mandatory swapped. This also keep match with the userspace hns driver and resolve the warning by sparse. Signed-off-by: Lijun Ou <oulijun@huawei.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2018-02-05drm/i915: Skip post-reset request emission if the engine is not idleChris Wilson
Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") we submit a request following the engine reset. The intent is that we don't submit a request if the engine is busy (as it will restart active by itself) but we only checked to see if there were remaining requests in flight on the hardware and skipped checking to see if there were any ready requests that would be immediately submitted on restart (the same time as our new request would be). Having convinced the engine to appear idle in the previous patch, we can use intel_engine_is_idle() as a better test to only submit a new request if there are no pending requests. As it happens, this is tripping up igt/drv_selftest/live_hangcheck in CI as we overfill the kernel_context ringbuffer trigger an infinite recursion from within the reset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104786 References: 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") 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> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-4-chris@chris-wilson.co.uk
2018-02-05drm/i915/execlists: Move the reset bits to a more natural homeChris Wilson
In preparation for the next patch, we want the engine to appear idle after a reset (if there are no requests in flight). For execlists, this entails clearing the active status on reset, it will be regenerated on restarting the engine after the reset. In the process, note that a couple of other status flags and checks could be moved into the describing function. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-3-chris@chris-wilson.co.uk
2018-02-05drm/i915/selftests: Use a sacrificial context for hang testingChris Wilson
Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky; export a function (for selftests) from i915_gem_context.c to get it right. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-2-chris@chris-wilson.co.uk
2018-02-05drm/i915/selftests: Flush old resets between enginesChris Wilson
When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In practice, since we wait for each hanging batch to start before injecting the reset, this too-fast-reset condition can only be triggered when moving onto the next engine in the test, so we need only wait for the existing reset to complete before switching engines. v2: Wrap up the wait inside a safety net to bail out in case of angry hw. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-1-chris@chris-wilson.co.uk
2018-02-05drm/i915/breadcrumbs: Drop request reference for the signaler threadChris Wilson
If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request references, causing severe memory fragmentation and premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL and frequent use of inter-engine fences). v2: Rename first_signal(), document reads outside of locks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203101914.24880-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2018-02-05perf record: Fix period option handlingJiri Olsa
Stephan reported we don't unset PERIOD sample type when --no-period is specified. Adding the unset check and reset PERIOD if --no-period is specified. Committer notes: Check the sample_type, it shouldn't have PERF_SAMPLE_PERIOD there when --no-period is used. Before: # perf record --no-period sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.018 MB perf.data (7 samples) ] # perf evlist -v cycles:ppp: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1 # After: [root@jouet ~]# perf record --no-period sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.019 MB perf.data (17 samples) ] [root@jouet ~]# perf evlist -v cycles:ppp: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1 [root@jouet ~]# Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180201083812.11359-3-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-02-05perf evsel: Fix period/freq terms setupJiri Olsa
Stephane reported that we don't set properly PERIOD sample type for events with period term defined. Before: $ perf record -e cpu/cpu-cycles,period=1000/u ls $ perf evlist -v cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME|PERIOD, ... After: $ perf record -e cpu/cpu-cycles,period=1000/u ls $ perf evlist -v cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME, ... Setting PERIOD sample type based on period term setup. Committer note: When we use -c or a period=N term in the event definition, then we don't need to ask the kernel, for this event, via perf_event_attr.sample_type |= PERF_SAMPLE_PERIOD, to put the event period in each sample for this event, as we know it already, it is in perf_event_attr.sample_period. Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180201083812.11359-2-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-02-05dwc-xlgmac: remove Jie Deng as co-maintainerJie Deng
Jose Abreu is working on this driver and I will leave Synopsys soon. Thus it does not seem appropriate for me to be a co-maintainer anymore. Signed-off-by: Jie Deng <jiedeng@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-05doc: Change the min default value of tcp_wmem/tcp_rmem.Tonghao Zhang
The SK_MEM_QUANTUM was changed from PAGE_SIZE to 4096. And the tcp_wmem/tcp_rmem min default values are 4096. Fixes: bd68a2a854ad ("net: set SK_MEM_QUANTUM to 4096") Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-05MIPS: SMP-CPS: Remove duplicate assignment of core in play_deadMatt Redfearn
The merge of commit f875a832d2028 ("MIPS: Abstract CPU core & VP(E) ID access through accessor functions") ended up creating a duplicate assignment of core during the rebase on commit bac06cf0fb9d ("MIPS: smp-cps: Fix potentially uninitialised value of core"). Remove the duplicate. Fixes: f875a832d202 ("MIPS: Abstract CPU core & VP(E) ID access through accessor functions") Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17955/ Signed-off-by: James Hogan <jhogan@kernel.org>
2018-02-05MIPS: Generic: Support GIC in EIC modeMatt Redfearn
The GIC supports running in External Interrupt Controller (EIC) mode, and will signal this via cpu_has_veic if enabled in hardware. Currently the generic kernel will panic if cpu_has_veic is set - but the GIC can legitimately set this flag if either configured to boot in EIC mode, or if the GIC driver enables this mode. Make the kernel not panic in this case, and instead just check if the GIC is present. If so, use it's CPU local interrupt routing functions. If an EIC is present, but it is not the GIC, then the kernel does not know how to get the VIRQ for the CPU local interrupts and should panic. Support for alternative EICs being present is needed here for the generic kernel to support them. Suggested-by: Paul Burton <paul.burton@mips.com> Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18191/ Signed-off-by: James Hogan <jhogan@kernel.org>
2018-02-05s390: run user space and KVM guests with modified branch predictionMartin Schwidefsky
Define TIF_ISOLATE_BP and TIF_ISOLATE_BP_GUEST and add the necessary plumbing in entry.S to be able to run user space and KVM guests with limited branch prediction. To switch a user space process to limited branch prediction the s390_isolate_bp() function has to be call, and to run a vCPU of a KVM guest associated with the current task with limited branch prediction call s390_isolate_bp_guest(). Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-02-05MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASSMatt Redfearn
When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support") added board support for the RBTX4939, it added a call to led_classdev_register even if the LED class is built as a module. Built-in arch code cannot call module code directly like this. Commit b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently changed the inclusion of this code to a single check that CONFIG_LEDS_CLASS is either builtin or a module, but the same issue remains. This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y is set: arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe': setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register' make: *** [Makefile:999: vmlinux] Error 1 Fix this by using the IS_BUILTIN() macro instead. Fixes: b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support") Signed-off-by: Matt Redfearn <matt.redfearn@mips.com> Reviewed-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18544/ Signed-off-by: James Hogan <jhogan@kernel.org>
2018-02-05drm/i915: Remove unbannable context spam from resetChris Wilson
During testing, we trigger a lot of resets on an unbannable context leading to massive amounts of irrelevant debug spam. Remove the ban_score accounting and message for the unbannable context so that we improve the signal:noise in the log messages for when the unexpected occurs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-7-chris@chris-wilson.co.uk
2018-02-05drm/i915/execlists: Remove the startup spamChris Wilson
Execlists is now enabled by default and included in the list of capabilities printed out to dmesg and beyond. We do not need to mention it again, every time we restart the engine, so kill the spam. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-6-chris@chris-wilson.co.uk
2018-02-05drm/i915: Show the GPU state when declaring wedgedChris Wilson
Dump each engine state when i915_gem_set_wedged() is called to give us some more clues as to why we had to terminate the GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-5-chris@chris-wilson.co.uk
2018-02-05s390: add options to change branch prediction behaviour for the kernelMartin Schwidefsky
Add the PPA instruction to the system entry and exit path to switch the kernel to a different branch prediction behaviour. The instructions are added via CPU alternatives and can be disabled with the "nospec" or the "nobp=0" kernel parameter. If the default behaviour selected with CONFIG_KERNEL_NOBP is set to "n" then the "nobp=1" parameter can be used to enable the changed kernel branch prediction. Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-02-05s390/alternative: use a copy of the facility bit maskMartin Schwidefsky
To be able to switch off specific CPU alternatives with kernel parameters make a copy of the facility bit mask provided by STFLE and use the copy for the decision to apply an alternative. Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-02-05drm/crc: Add support for polling on the data fd.Maarten Lankhorst
This will make it possible for userspace to know whether reading will block, without blocking on the fd. This makes it possible to drain all queued CRC's in blocking mode, without having to reopen the fd. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202142743.68527-1-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Use POLLIN|POLLRDNORM, based on Ville's suggestion]
2018-02-05MIPS: CPS: Fix MIPS_ISA_LEVEL_RAW falloutJames Hogan
Commit 17278a91e04f ("MIPS: CPS: Fix r1 .set mt assembler warning") added .set MIPS_ISA_LEVEL_RAW to silence warnings about .set mt on r1, however this can result in a MOVE being encoded as a 64-bit DADDU instruction on certain version of binutils (e.g. 2.22), and reserved instruction exceptions at runtime on 32-bit hardware. Reduce the sizes of the push/pop sections to include only instructions that are part of the MT ASE or which won't convert to 64-bit instructions after .set mips64r2/mips64r6. Reported-by: Greg Ungerer <gerg@linux-m68k.org> Fixes: 17278a91e04f ("MIPS: CPS: Fix r1 .set mt assembler warning") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 4.15 Tested-by: Greg Ungerer <gerg@linux-m68k.org> Patchwork: https://patchwork.linux-mips.org/patch/18578/
2018-02-05drm/i915: Always update the no_fbc_reason when disablingChris Wilson
Provide the reason why we call intel_fbc_deactivate() so that debugging issues with FBC being delayed is clearer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180125224122.27480-1-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-02-05drm/i915: Add some newlines to intel_engine_dump() headersChris Wilson
The headers should be on a separate line for consistency, so add the missing trailing newline in a few intel_engine_dump() callers. Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205100618.11001-1-chris@chris-wilson.co.uk
2018-02-05drm/i915: Report if an unbannable context is involved in a GPU hangChris Wilson
Since unbannable contexts are special and supposed not to be causing GPU hangs in the first place, make it clear when they are implicated in said hang. In practice, most unbannable contexts are those created by igt for the express purpose of throwing untold thousands of hangs at the GPU and wish to keep doing so to finish the test. Normally they are cleaned up, but it's when they or the other unbannable kernel contexts stay stuck in an erroneous state that we need to worry and so need highlighting. Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205094139.10671-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2018-02-05MIPS: generic: Fix Makefile alignmentJames Hogan
Fix whitespace of generic platform Makefile so that obj-y values align. Fixes: f2d0b0d5c171 ("MIPS: ranchu: Add Ranchu as a new generic-based board") Signed-off-by: James Hogan <jhogan@kernel.org> Reviewed-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Miodrag Dinic <miodrag.dinic@mips.com> Cc: Goran Ferenc <goran.ferenc@mips.com> Cc: Aleksandar Markovic <aleksandar.markovic@mips.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18582/
2018-02-05MIPS: generic: Fix ranchu_of_match[] terminationJames Hogan
ranchu_of_match[] has no terminating element to end the search for a matching compatible string when the first and only element does not match, so add one now. Fixes: f2d0b0d5c171 ("MIPS: ranchu: Add Ranchu as a new generic-based board") Signed-off-by: James Hogan <jhogan@kernel.org> Reviewed-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Miodrag Dinic <miodrag.dinic@mips.com> Cc: Goran Ferenc <goran.ferenc@mips.com> Cc: Aleksandar Markovic <aleksandar.markovic@mips.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18581/
2018-02-05MIPS: generic: Fix machine compatible matchingJames Hogan
We now have a platform (Ranchu) in the "generic" platform which matches based on the FDT compatible string using mips_machine_is_compatible(), however that function doesn't stop at a blank struct of_device_id::compatible as that is an array in the struct, not a pointer to a string. Fix the loop completion to check the first byte of the compatible array rather than the address of the compatible array in the struct. Fixes: eed0eabd12ef ("MIPS: generic: Introduce generic DT-based board support") Signed-off-by: James Hogan <jhogan@kernel.org> Reviewed-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18580/
2018-02-05cpufreq: Skip cpufreq resume if it's not suspendedBo Yan
cpufreq_resume can be called even without preceding cpufreq_suspend. This can happen in following scenario: suspend_devices_and_enter --> dpm_suspend_start --> dpm_prepare --> device_prepare : this function errors out --> dpm_suspend: this is skipped due to dpm_prepare failure this means cpufreq_suspend is skipped over --> goto Recover_platform, due to previous error --> goto Resume_devices --> dpm_resume_end --> dpm_resume --> cpufreq_resume In case schedutil is used as frequency governor, cpufreq_resume will eventually call sugov_start, which does following: memset(sg_cpu, 0, sizeof(*sg_cpu)); .... This effectively erases function pointer for frequency update, causing crash later on. The function pointer would have been set correctly if subsequent cpufreq_add_update_util_hook runs successfully, but that function returns earlier because cpufreq_suspend was not called: if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu))) return; The fix is to check cpufreq_suspended first, if it's false, that means cpufreq_suspend was not called in the first place, so do not resume cpufreq. Signed-off-by: Bo Yan <byan@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Dropped printing a message ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-05ovl: check ERR_PTR() return value from ovl_encode_fh()Amir Goldstein
Another fix for an issue reported by 0-day robot. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 8ed5eec9d6c4 ("ovl: encode pure upper file handles") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-02-05ovl: fix regression in fsnotify of overlay merge dirAmir Goldstein
A re-factoring patch in NFS export series has passed the wrong argument to ovl_get_inode() causing a regression in the very recent fix to fsnotify of overlay merge dir. The regression has caused merge directory inodes to be hashed by upper instead of lower real inode, when NFS export and directory indexing is disabled. That caused an inotify watch to become obsolete after directory copy up and drop caches. LTP test inotify07 was improved to catch this regression. The regression also caused multiple redirect dirs to same origin not to be detected on lookup with NFS export disabled. An xfstest was added to cover this case. Fixes: 0aceb53e73be ("ovl: do not pass overlay dentry to ovl_get_inode()") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-15 23:06:27 +0000