aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-09-19Hexagon: change maintainer to Brian CainBrian Cain1-2/+1
Signed-off-by: Brian Cain <bcain@codeaurora.org> Signed-off-by: Richard Kuo <rkuo@codeaurora.org>
2019-09-19selftests/ftrace: Update kprobe event error testcaseMasami Hiramatsu1-0/+1
Update kprobe event error testcase to test if it correctly finds the exact same probe event. Link: http://lkml.kernel.org/r/156879695513.31056.1580235733738840126.stgit@devnote2 Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-19tracing/probe: Reject exactly same probe eventMasami Hiramatsu3-17/+90
Reject exactly same probe events as existing probes. Multiprobe allows user to define multiple probes on same event. If user appends a probe which exactly same definition (same probe address and same arguments) on existing event, the event will record same probe information twice. That can be confusing users, so reject it. Link: http://lkml.kernel.org/r/156879694602.31056.5533024778165036763.stgit@devnote2 Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-19tracing/probe: Fix to allow user to enable events on unloaded modulesMasami Hiramatsu1-12/+5
Fix to allow user to enable probe events on unloaded modules. This operations was allowed before commit 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe"), because if users need to probe module init functions, they have to enable those probe events before loading module. Link: http://lkml.kernel.org/r/156879693733.31056.9331322616994665167.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-19of: restore old handling of cells_name=NULL in of_*_phandle_with_args()Uwe Kleine-König1-2/+33
Before commit e42ee61017f5 ("of: Let of_for_each_phandle fallback to non-negative cell_count") the iterator functions calling of_for_each_phandle assumed a cell count of 0 if cells_name was NULL. This corner case was missed when implementing the fallback logic in e42ee61017f5 and resulted in an endless loop. Restore the old behaviour of of_count_phandle_with_args() and of_parse_phandle_with_args() and add a check to of_phandle_iterator_init() to prevent a similar failure as a safety precaution. of_parse_phandle_with_args_map() doesn't need a similar fix as cells_name isn't NULL there. Affected drivers are: - drivers/base/power/domain.c - drivers/base/power/domain.c - drivers/clk/ti/clk-dra7-atl.c - drivers/hwmon/ibmpowernv.c - drivers/i2c/muxes/i2c-demux-pinctrl.c - drivers/iommu/mtk_iommu.c - drivers/net/ethernet/freescale/fman/mac.c - drivers/opp/of.c - drivers/perf/arm_dsu_pmu.c - drivers/regulator/of_regulator.c - drivers/remoteproc/imx_rproc.c - drivers/soc/rockchip/pm_domains.c - sound/soc/fsl/imx-audmix.c - sound/soc/fsl/imx-audmix.c - sound/soc/meson/axg-card.c - sound/soc/samsung/tm2_wm5110.c - sound/soc/samsung/tm2_wm5110.c Thanks to Geert Uytterhoeven for reporting the issue, Peter Rosin for helping pinpoint the actual problem and the testers for confirming this fix. Fixes: e42ee61017f5 ("of: Let of_for_each_phandle fallback to non-negative cell_count") Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Rob Herring <robh@kernel.org>
2019-09-18KVM: coalesced_mmio: add bounds checkingMatt Delco1-8/+11
The first/last indexes are typically shared with a user app. The app can change the 'last' index that the kernel uses to store the next result. This change sanity checks the index before using it for writing to a potentially arbitrary address. This fixes CVE-2019-14821. Cc: stable@vger.kernel.org Fixes: 5f94c1741bdc ("KVM: Add coalesced MMIO support (common part)") Signed-off-by: Matt Delco <delco@chromium.org> Signed-off-by: Jim Mattson <jmattson@google.com> Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com [Use READ_ONCE. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-09-17selftests/ftrace: Select an existing function in kprobe_eventname testSteven Rostedt (VMware)1-1/+15
Running the ftrace selftests on the latest kernel caused the kprobe_eventname test to fail. It was due to the test that searches for a function with at "dot" in the name and adding a probe to that. Unfortunately, for this test, it picked: optimize_nops.isra.2.cold.4 Which happens to be marked as "__init", which means it no longer exists in the kernel! (kallsyms keeps those function names around for tracing purposes) As only functions that still exist are in the available_filter_functions file, as they are removed when the functions are freed at boot or module exit, have the test search for a function with ".isra." in the name as well as being in the available_filter_functions (if the file exists). Link: http://lkml.kernel.org/r/20190322150923.1b58eca5@gandalf.local.home Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-17tracing/kprobe: Fix NULL pointer access in trace_porbe_unlink()Masami Hiramatsu1-5/+6
Fix NULL pointer access in trace_probe_unlink() by initializing trace_probe.list correctly in trace_probe_init(). In the error case of trace_probe_init(), it can call trace_probe_unlink() before initializing trace_probe.list member. This causes NULL pointer dereference at list_del_init() in trace_probe_unlink(). Syzbot reported : kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8633 Comm: syz-executor797 Not tainted 5.3.0-rc8-next-20190915 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__list_del_entry_valid+0x85/0xf5 lib/list_debug.c:51 Code: 0f 84 e1 00 00 00 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 e2 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 53 49 8b 14 24 4c 39 f2 0f 85 99 00 00 00 49 8d 7d RSP: 0018:ffff888090a7f9d8 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88809b6f90c0 RCX: ffffffff817c0ca9 RDX: 0000000000000000 RSI: ffffffff817c0a73 RDI: ffff88809b6f90c8 RBP: ffff888090a7f9f0 R08: ffff88809a04e600 R09: ffffed1015d26aed R10: ffffed1015d26aec R11: ffff8880ae935763 R12: 0000000000000000 R13: 0000000000000000 R14: ffff88809b6f90c0 R15: ffff88809b6f90d0 FS: 0000555556f99880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000006cc090 CR3: 00000000962b2000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __list_del_entry include/linux/list.h:131 [inline] list_del_init include/linux/list.h:190 [inline] trace_probe_unlink+0x1f/0x200 kernel/trace/trace_probe.c:959 trace_probe_cleanup+0xd3/0x110 kernel/trace/trace_probe.c:973 trace_probe_init+0x3f2/0x510 kernel/trace/trace_probe.c:1011 alloc_trace_uprobe+0x5e/0x250 kernel/trace/trace_uprobe.c:353 create_local_trace_uprobe+0x109/0x4a0 kernel/trace/trace_uprobe.c:1508 perf_uprobe_init+0x131/0x210 kernel/trace/trace_event_perf.c:314 perf_uprobe_event_init+0x106/0x1a0 kernel/events/core.c:8898 perf_try_init_event+0x135/0x590 kernel/events/core.c:10184 perf_init_event kernel/events/core.c:10228 [inline] perf_event_alloc.part.0+0x1b89/0x33d0 kernel/events/core.c:10505 perf_event_alloc kernel/events/core.c:10887 [inline] __do_sys_perf_event_open+0xa2d/0x2d00 kernel/events/core.c:10989 __se_sys_perf_event_open kernel/events/core.c:10871 [inline] __x64_sys_perf_event_open+0xbe/0x150 kernel/events/core.c:10871 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Link: http://lkml.kernel.org/r/156869709721.22406.5153754822203046939.stgit@devnote2 Reported-by: syzbot+2f807f4d3a2a4e87f18f@syzkaller.appspotmail.com Fixes: ca89bc071d5e ("tracing/kprobe: Add multi-probe per event support") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-17tracing: Make sure variable reference alias has correct var_ref_idxTom Zanussi1-0/+2
Original changelog from Steve Rostedt (except last sentence which explains the problem, and the Fixes: tag): I performed a three way histogram with the following commands: echo 'irq_lat u64 lat pid_t pid' > synthetic_events echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function == 0xffffffff81200580' > events/timer/hrtimer_start/trigger echo 'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid) if common_flags & 1' > events/sched/sched_waking/trigger echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' > events/synthetic/irq_lat/trigger echo 'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)' > events/sched/sched_switch/trigger echo 1 > events/synthetic/wake_lat/enable Basically I wanted to see: hrtimer_start (calling function tick_sched_timer) Note: # grep tick_sched_timer /proc/kallsyms ffffffff81200580 t tick_sched_timer And save the time of that, and then record sched_waking if it is called in interrupt context and with the same pid as the hrtimer_start, it will record the latency between that and the waking event. I then look at when the task that is woken is scheduled in, and record the latency between the wakeup and the task running. At the end, the wake_lat synthetic event will show the wakeup to scheduled latency, as well as the irq latency in from hritmer_start to the wakeup. The problem is that I found this: <idle>-0 [007] d... 190.485261: wake_lat: lat=27 irqlat=190485230 pid=698 <idle>-0 [005] d... 190.485283: wake_lat: lat=40 irqlat=190485239 pid=10 <idle>-0 [002] d... 190.488327: wake_lat: lat=56 irqlat=190488266 pid=335 <idle>-0 [005] d... 190.489330: wake_lat: lat=64 irqlat=190489262 pid=10 <idle>-0 [003] d... 190.490312: wake_lat: lat=43 irqlat=190490265 pid=77 <idle>-0 [005] d... 190.493322: wake_lat: lat=54 irqlat=190493262 pid=10 <idle>-0 [005] d... 190.497305: wake_lat: lat=35 irqlat=190497267 pid=10 <idle>-0 [005] d... 190.501319: wake_lat: lat=50 irqlat=190501264 pid=10 The irqlat seemed quite large! Investigating this further, if I had enabled the irq_lat synthetic event, I noticed this: <idle>-0 [002] d.s. 249.429308: irq_lat: lat=164968 pid=335 <idle>-0 [002] d... 249.429369: wake_lat: lat=55 irqlat=249429308 pid=335 Notice that the timestamp of the irq_lat "249.429308" is awfully similar to the reported irqlat variable. In fact, all instances were like this. It appeared that: irqlat=$irqlat Wasn't assigning the old $irqlat to the new irqlat variable, but instead was assigning the $irqts to it. The issue is that assigning the old $irqlat to the new irqlat variable creates a variable reference alias, but the alias creation code forgets to make sure the alias uses the same var_ref_idx to access the reference. Link: http://lkml.kernel.org/r/1567375321.5282.12.camel@kernel.org Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org> Cc: linux-rt-users <linux-rt-users@vger.kernel.org> Cc: stable@vger.kernel.org Fixes: 7e8b88a30b085 ("tracing: Add hist trigger support for variable reference aliases") Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-17tracing: Be more clever when dumping hex in __print_hex()Andy Shevchenko1-3/+3
Hex dump as many as 16 bytes at once in trace_print_hex_seq() instead of byte-by-byte approach. Link: http://lkml.kernel.org/r/20190806151543.86061-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-17ftrace: Simplify ftrace hash lookup code in clear_func_from_hash()Changbin Du1-5/+1
Function ftrace_lookup_ip() will check empty hash table. So we don't need extra check outside. Link: http://lkml.kernel.org/r/20190910143336.13472-1-changbin.du@gmail.com Signed-off-by: Changbin Du <changbin.du@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-17mailbox: qcom-apcs: fix max_register valueJorge Ramirez-Ortiz1-1/+1
The mailbox length is 0x1000 hence the max_register value is 0xFFC. Fixes: c6a8b171ca8e ("mailbox: qcom: Convert APCS IPC driver to use regmap") Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mailbox: qcom: Add support for IPQ8074 APCSGokul Sriram Palanisamy1-0/+1
Add support of IPQ8074 with IPC register offset as 8. Signed-off-by: Gokul Sriram Palanisamy <gokulsri@codeaurora.org> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17dt-bindings: mailbox: qom: Add ipq8074 APPS compatibleGokul Sriram Palanisamy1-0/+1
Add mailbox support required in IPQ8074 SoCs. Signed-off-by: Gokul Sriram Palanisamy <gokulsri@codeaurora.org> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mailbox: qcom: Add support for Qualcomm SM8150 and SC7180 SoCsSibi Sankar1-0/+2
Add the corresponding APSS shared offset for SM8150 and SC7180 SoCs. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17dt-bindings: mailbox: Add APSS shared for SM8150 and SC7180 SoCsSibi Sankar1-0/+2
Add SM8150 and SC7180 APSS shared to the list of possible bindings. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mbox: qcom: replace integer with valid macroJorge Ramirez-Ortiz1-1/+2
Use the correct macro when registering the platform device. Co-developed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mbox: qcom: add APCS child device for QCS404Jorge Ramirez-Ortiz1-2/+6
There is clock controller functionality in the APCS hardware block of qcs404 devices similar to msm8916. Co-developed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mailbox: mediatek: cmdq: clear the event in cmdq initial flowBibby Hsieh3-3/+8
GCE hardware stored event information in own internal sysram, if the initial value in those sysram is not zero value it will cause a situation that gce can wait the event immediately after client ask gce to wait event but not really trigger the corresponding hardware. In order to make sure that the wait event function is exactly correct, we need to clear the sysram value in cmdq initial flow. Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mailbox: mediatek: cmdq: support mt8183 gce functionBibby Hsieh1-0/+1
add mt8183 compatible name for supporting gce function Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver dataBibby Hsieh1-5/+7
The interrupt mask and thread number has positive correlation, so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate it by thread number. Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17dt-binding: gce: add binding for gce client reg propertyBibby Hsieh1-4/+12
cmdq driver provide a function that get the relationship of sub system number from device node for client. add specification for #subsys-cells, mediatek,gce-client-reg. Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17dt-binding: gce: add gce header file for mt8183Bibby Hsieh2-3/+178
Add documentation for the mt8183 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt8183. Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17dt-binding: gce: remove thread-num propertyBibby Hsieh1-1/+0
"thread-num" is an unused property so we remove it from example. Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17mailbox: armada-37xx-rwtm: Use device-managed registration APIChuhong Yuan1-13/+1
Use devm_mbox_controller_register to get rid of redundant remove function. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2019-09-17drm/nouveau/bar/gm20b: Avoid BAR1 teardown during initThierry Reding1-1/+0
Writing the 0x1704 (BUS_BAR1_BLOCK) register causes the GPU to probe the memory region at the programmed address. The result is an address decode error in the external memory controller because address 0, which is what is written to the register, is not designated as accessible to devices. Avoid triggering DMA from the GPU by removing teardown of the BAR1. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau: Fix ordering between TTM and GEM releaseThierry Reding2-6/+8
When the last reference to a TTM BO is dropped, ttm_bo_release() will acquire the DMA reservation object's wound/wait mutex while trying to clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is therefore essential that drm_gem_object_release() be called after the TTM BO has been uninitialized, otherwise drm_gem_object_release() has already destroyed the wound/wait mutex (via dma_resv_fini()). Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau/prime: Extend DMA reservation object lockThierry Reding1-6/+14
Prior to commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object"), the reservation object was locked across all of the buffer object creation. After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and nouveau_bo_init() functions, the reservation object is passed to the latter, so the lock needs to be held across that function as well. Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau: Fix fallout from reservation object reworkThierry Reding4-13/+17
Commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") introduced a subtle change in how the buffer allocation size is handled. Prior to that change, the size would get aligned to at least a page, whereas after that change a non-page-aligned size would get passed through unmodified. This ultimately causes a BUG_ON() to trigger in drm_gem_private_object_init() and crashes the system. Fix this by restoring the code that align the allocation size. Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectorsLyude Paul1-1/+2
On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS encoders +4 DPMST encoders *5 ports == 35 encoders Which breaks things, since DRM has a hard coded limit of 32 encoders. So, fix this by not creating MSTMs for any eDP connectors. This brings us down to 31 encoders, although we can do better. This fixes driver probing for nouveau on the ThinkPad P71. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-16cifs: update internal module version numberSteve French1-1/+1
To 2.23 Signed-off-by: Steve French <stfrench@microsoft.com>
2019-09-16cifs: modefromsid: write mode ACE firstAurelien Aptel1-17/+19
DACL should start with mode ACE first but we are putting it at the end. reorder them to put it first. Signed-off-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2019-09-16mlxsw: spectrum_buffers: Add the ability to query the CPU port's shared bufferShalom Toledo1-8/+33
While debugging packet loss towards the CPU, it is useful to be able to query the CPU port's shared buffer quotas and occupancy. Since the CPU port has no ingress buffers, all the shared buffers ingress information will be cleared. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16mlxsw: spectrum: Register CPU port with devlinkShalom Toledo3-9/+105
Register CPU port with devlink. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16mlxsw: spectrum_buffers: Prevent changing CPU port's configurationShalom Toledo1-0/+10
Next patch is going to register the CPU port with devlink, but only so that the CPU port's shared buffer configuration and occupancy could be queried. Prevent changing CPU port's shared buffer threshold and binding configuration. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: fix incorrect update of intr_delay_resolutionArthur Kiyanovski3-4/+19
ena_dev->intr_moder_rx/tx_interval save the intervals received from the user after dividing them by ena_dev->intr_delay_resolution. Therefore when intr_delay_resolution changes, the code needs to first mutiply intr_moder_rx/tx_interval by the previous intr_delay_resolution to get the value originally given by the user, and only then divide it by the new intr_delay_resolution. Current code does not first multiply intr_moder_rx/tx_interval by the old intr_delay_resolution. This commit fixes it. Also initialize ena_dev->intr_delay_resolution to be 1. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: fix retrieval of nonadaptive interrupt moderation intervalsArthur Kiyanovski1-2/+3
Nonadaptive interrupt moderation intervals are assigned the value set by the user in ethtool -C divided by ena_dev->intr_delay_resolution. Therefore when the user tries to get the nonadaptive interrupt moderation intervals with ethtool -c the code needs to multiply the saved value by ena_dev->intr_delay_resolution. The current code erroneously divides instead of multiplying in ethtool -c. This patch fixes this. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: fix update of interrupt moderation registerArthur Kiyanovski1-1/+4
Current implementation always updates the interrupt register with the smoothed_interval of the rx_ring. However this should be done only in case of adaptive interrupt moderation. If non-adaptive interrupt moderation is used, the non-adaptive interrupt moderation interval should be used. This commit fixes that. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: remove all old adaptive rx interrupt moderation code from ena_comArthur Kiyanovski2-252/+0
Remove previous implementation of adaptive rx interrupt moderation from ena_com files. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: remove ena_restore_ethtool_params() and relevant fieldsArthur Kiyanovski2-13/+0
Deleted unused 4 fields from struct ena_adapter and their only user ena_restore_ethtool_params(). Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: remove old adaptive interrupt moderation code from ena_netdevArthur Kiyanovski2-10/+0
1. Out of the fields {per_napi_bytes, per_napi_packets} in struct ena_ring, only rx_ring->per_napi_packets are used to determine if napi did work for dim. This commit removes all other uses of these fields. 2. Remove ena_ring->moder_tbl_idx, which is not used by dim. 3. Remove all calls to ena_com_destroy_interrupt_moderation(), since all it did was to destroy the interrupt moderation table, which is removed as part of removing old interrupt moderation code. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: remove code duplication in ena_com_update_nonadaptive_moderation_interval _*()Arthur Kiyanovski1-14/+16
Remove code duplication in: ena_com_update_nonadaptive_moderation_interval_tx() ena_com_update_nonadaptive_moderation_interval_rx() functions. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: enable the interrupt_moderation in driver_supported_featuresArthur Kiyanovski2-0/+11
Add driver_supported_features to host_host info which is a new API used to communicate to the device which features are supported by the driver. Add the interrupt_moderation bit to host_info->driver_supported_features and enable it to signal the device that this driver supports interrupt moderation properly. Reserved bits are for features implemented in the future Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: reimplement set/get_coalesce()Arthur Kiyanovski1-58/+26
1. Remove old adaptive interrupt moderation code from set/get_coalesce() 2. Add ena_update_rx_rings_intr_moderation() function for updating nonadaptive interrupt moderation intervals similarly to ena_update_tx_rings_intr_moderation(). 3. Remove checks of multiple unsupported received interrupt coalescing parameters. This makes code cleaner and cancels the need to update it every time a new coalescing parameter is invented. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: switch to dim algorithm for rx adaptive interrupt moderationArthur Kiyanovski3-21/+41
Use the dim library for the rx adaptive interrupt moderation implementation Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: ena: add intr_moder_rx_interval to struct ena_com_dev and use itArthur Kiyanovski3-18/+13
Add intr_moder_rx_interval to struct ena_com_dev and use it as the location where the interrupt moderation rx interval is saved, instead of the interrupt moderation table. This is done as a first step before removing the old interrupt moderation code. Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16net: phy: adin: implement Energy Detect Powerdown mode via phy-tunableAlexandru Ardelean1-0/+61
This driver becomes the first user of the kernel's `ETHTOOL_PHY_EDPD` phy-tunable feature. EDPD is also enabled by default on PHY config_init, but can be disabled via the phy-tunable control. When enabling EDPD, it's also a good idea (for the ADIN PHYs) to enable TX periodic pulses, so that in case the other PHY is also on EDPD mode, there is no lock-up situation where both sides are waiting for the other to transmit. Via the phy-tunable control, TX pulses can be disabled if specifying 0 `tx-interval` via ethtool. The ADIN PHY supports only fixed 1 second intervals; they cannot be configured. That is why the acceptable values are 1, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS and ETHTOOL_PHY_EDPD_NO_TX (which disables TX pulses). Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16ethtool: implement Energy Detect Powerdown support via phy-tunableAlexandru Ardelean2-0/+28
The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like this feature is common across other PHYs (like EEE), and defining `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long. The way EDPD works, is that the RX block is put to a lower power mode, except for link-pulse detection circuits. The TX block is also put to low power mode, but the PHY wakes-up periodically to send link pulses, to avoid lock-ups in case the other side is also in EDPD mode. Currently, there are 2 PHY drivers that look like they could use this new PHY tunable feature: the `adin` && `micrel` PHYs. The ADIN's datasheet mentions that TX pulses are at intervals of 1 second default each, and they can be disabled. For the Micrel KSZ9031 PHY, the datasheet does not mention whether they can be disabled, but mentions that they can modified. The way this change is structured, is similar to the PHY tunable downshift control: * a `ETHTOOL_PHY_EDPD_DFLT_TX_MSECS` value is exposed to cover a default TX interval; some PHYs could specify a certain value that makes sense * `ETHTOOL_PHY_EDPD_NO_TX` would disable TX when EDPD is enabled * `ETHTOOL_PHY_EDPD_DISABLE` will disable EDPD As noted by the `ETHTOOL_PHY_EDPD_DFLT_TX_MSECS` the interval unit is 1 millisecond, which should cover a reasonable range of intervals: - from 1 millisecond, which does not sound like much of a power-saver - to ~65 seconds which is quite a lot to wait for a link to come up when plugging a cable Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16xen-netfront: do not assume sk_buff_head list is empty in error handlingDongli Zhang1-1/+1
When skb_shinfo(skb) is not able to cache extra fragment (that is, skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes the sk_buff_head list is already empty. As a result, cons is increased only by 1 and returns to error handling path in xennet_poll(). However, if the sk_buff_head list is not empty, queue->rx.rsp_cons may be set incorrectly. That is, queue->rx.rsp_cons would point to the rx ring buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are already cleared to NULL. This leads to NULL pointer access in the next iteration to process rx ring buffer entries. Below is how xennet_poll() does error handling. All remaining entries in tmpq are accounted to queue->rx.rsp_cons without assuming how many outstanding skbs are remained in the list. 985 static int xennet_poll(struct napi_struct *napi, int budget) ... ... 1032 if (unlikely(xennet_set_skb_gso(skb, gso))) { 1033 __skb_queue_head(&tmpq, skb); 1034 queue->rx.rsp_cons += skb_queue_len(&tmpq); 1035 goto err; 1036 } It is better to always have the error handling in the same way. Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-16s390/ctcm: Delete unnecessary checks before the macro call “dev_kfree_skb”Markus Elfring1-4/+2
The dev_kfree_skb() function performs also input parameter validation. Thus the test around the shown calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.