summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-09-03tg3: Fix soft lockup when tg3_reset_task() fails.Michael Chan
If tg3_reset_task() fails, the device state is left in an inconsistent state with IFF_RUNNING still set but NAPI state not enabled. A subsequent operation, such as ifdown or AER error can cause it to soft lock up when it tries to disable NAPI state. Fix it by bringing down the device to !IFF_RUNNING state when tg3_reset_task() fails. tg3_reset_task() running from workqueue will now call tg3_close() when the reset fails. We need to modify tg3_reset_task_cancel() slightly to avoid tg3_close() calling cancel_work_sync() to cancel tg3_reset_task(). Otherwise cancel_work_sync() will wait forever for tg3_reset_task() to finish. Reported-by: David Christensen <drc@linux.vnet.ibm.com> Reported-by: Baptiste Covolato <baptiste@arista.com> Fixes: db2199737990 ("tg3: Schedule at most one tg3_reset_task run") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-03drm/tve200: Stabilize enable/disableLinus Walleij
The TVE200 will occasionally print a bunch of lost interrupts and similar dmesg messages, sometimes during boot and sometimes after disabling and coming back to enablement. This is probably because the hardware is left in an unknown state by the boot loader that displays a logo. This can be fixed by bringing the controller into a known state by resetting the controller while enabling it. We retry reset 5 times like the vendor driver does. We also put the controller into reset before de-clocking it and clear all interrupts before enabling the vblank IRQ. This makes the video enable/disable/enable cycle rock solid on the D-Link DIR-685. Tested extensively. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200820203144.271081-1-linus.walleij@linaro.org
2020-09-03perf tools: Add bpf image check to __map__is_kmoduleJiri Olsa
When validating kcore modules the do_validate_kcore_modules function checks on every kernel module dso against modules record. The __map__is_kmodule check is used to get only kernel module dso objects through. Currently the bpf images are slipping through the check and making the validation to fail, so report falls back from kcore usage to kallsyms. Adding __map__is_bpf_image check for bpf image and adding it to __map__is_kmodule check. Fixes: 3c29d4483e85 ("perf annotate: Add basic support for bpf_image") Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lore.kernel.org/lkml/20200826213017.818788-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03perf record/stat: Explicitly call out event modifiers in the documentationKim Phillips
Event modifiers are not mentioned in the perf record or perf stat manpages. Add them to orient new users more effectively by pointing them to the perf list manpage for details. Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS") Signed-off-by: Kim Phillips <kim.phillips@amd.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Clarke <pc@us.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Tony Jones <tonyj@suse.de> Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03perf bench: The do_run_multi_threaded() function must use ↵YueHaibing
IS_ERR(perf_session__new()) In case of error, the function perf_session__new() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR() Committer notes: This wasn't compiling due to an extraneous '{' not matched by a '}', fix it. Fixes: 13edc237200c ("perf bench: Add a multi-threaded synthesize benchmark") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200902140526.26916-1-yuehaibing@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03perf stat: Turn off summary for interval mode by defaultJin Yao
There's a risk that outputting interval mode summaries by default breaks CSV consumers. It already broke pmu-tools/toplev. So now we turn off the summary by default but we create a new option '--summary' to enable the summary. This is active even when not using CSV mode. Before: root@kbl-ppc:~# perf stat -I1000 --interval-count 2 # time counts unit events 1.000265904 8,005.73 msec cpu-clock # 8.006 CPUs utilized 1.000265904 601 context-switches # 0.075 K/sec 1.000265904 10 cpu-migrations # 0.001 K/sec 1.000265904 0 page-faults # 0.000 K/sec 1.000265904 66,746,521 cycles # 0.008 GHz 1.000265904 71,874,398 instructions # 1.08 insn per cycle 1.000265904 13,356,781 branches # 1.668 M/sec 1.000265904 298,756 branch-misses # 2.24% of all branches 2.001857667 8,012.52 msec cpu-clock # 8.013 CPUs utilized 2.001857667 164 context-switches # 0.020 K/sec 2.001857667 10 cpu-migrations # 0.001 K/sec 2.001857667 2 page-faults # 0.000 K/sec 2.001857667 5,822,188 cycles # 0.001 GHz 2.001857667 2,186,170 instructions # 0.38 insn per cycle 2.001857667 442,378 branches # 0.055 M/sec 2.001857667 44,750 branch-misses # 10.12% of all branches Performance counter stats for 'system wide': 16,018.25 msec cpu-clock # 7.993 CPUs utilized 765 context-switches # 0.048 K/sec 20 cpu-migrations # 0.001 K/sec 2 page-faults # 0.000 K/sec 72,568,709 cycles # 0.005 GHz 74,060,568 instructions # 1.02 insn per cycle 13,799,159 branches # 0.861 M/sec 343,506 branch-misses # 2.49% of all branches 2.004118489 seconds time elapsed After: root@kbl-ppc:~# perf stat -I1000 --interval-count 2 # time counts unit events 1.001336393 8,013.28 msec cpu-clock # 8.013 CPUs utilized 1.001336393 82 context-switches # 0.010 K/sec 1.001336393 8 cpu-migrations # 0.001 K/sec 1.001336393 0 page-faults # 0.000 K/sec 1.001336393 4,199,121 cycles # 0.001 GHz 1.001336393 1,373,991 instructions # 0.33 insn per cycle 1.001336393 270,681 branches # 0.034 M/sec 1.001336393 31,659 branch-misses # 11.70% of all branches 2.003905006 8,020.52 msec cpu-clock # 8.021 CPUs utilized 2.003905006 184 context-switches # 0.023 K/sec 2.003905006 8 cpu-migrations # 0.001 K/sec 2.003905006 2 page-faults # 0.000 K/sec 2.003905006 5,446,190 cycles # 0.001 GHz 2.003905006 2,312,547 instructions # 0.42 insn per cycle 2.003905006 451,691 branches # 0.056 M/sec 2.003905006 37,925 branch-misses # 8.40% of all branches root@kbl-ppc:~# perf stat -I1000 --interval-count 2 --summary # time counts unit events 1.001313128 8,013.20 msec cpu-clock # 8.013 CPUs utilized 1.001313128 83 context-switches # 0.010 K/sec 1.001313128 8 cpu-migrations # 0.001 K/sec 1.001313128 0 page-faults # 0.000 K/sec 1.001313128 4,470,950 cycles # 0.001 GHz 1.001313128 1,440,045 instructions # 0.32 insn per cycle 1.001313128 283,222 branches # 0.035 M/sec 1.001313128 33,576 branch-misses # 11.86% of all branches 2.003857385 8,020.34 msec cpu-clock # 8.020 CPUs utilized 2.003857385 154 context-switches # 0.019 K/sec 2.003857385 8 cpu-migrations # 0.001 K/sec 2.003857385 2 page-faults # 0.000 K/sec 2.003857385 4,515,676 cycles # 0.001 GHz 2.003857385 2,180,449 instructions # 0.48 insn per cycle 2.003857385 435,254 branches # 0.054 M/sec 2.003857385 31,179 branch-misses # 7.16% of all branches Performance counter stats for 'system wide': 16,033.53 msec cpu-clock # 7.992 CPUs utilized 237 context-switches # 0.015 K/sec 16 cpu-migrations # 0.001 K/sec 2 page-faults # 0.000 K/sec 8,986,626 cycles # 0.001 GHz 3,620,494 instructions # 0.40 insn per cycle 718,476 branches # 0.045 M/sec 64,755 branch-misses # 9.01% of all branches 2.006124542 seconds time elapsed Fixes: c7e5b328a8d4 ("perf stat: Report summary for interval mode") Signed-off-by: Jin Yao <yao.jin@linux.intel.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200903010113.32232-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03libtraceevent: Fix build warning on 32-bit archesTzvetomir Stoyanov (VMware)
Fixed a compilation warning for casting to pointer from integer of different size on 32-bit platforms. Reported-by: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: linux-trace-devel@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03perf jevents: Fix suspicious code in fixregex()Namhyung Kim
The new string should have enough space for the original string and the back slashes IMHO. Fixes: fbc2844e84038ce3 ("perf vendor events: Use more flexible pattern matching for CPU identification for mapfile.csv") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Reviewed-by: Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: John Garry <john.garry@huawei.com> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: William Cohen <wcohen@redhat.com> Link: http://lore.kernel.org/lkml/20200903152510.489233-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03perf parse-events: Use uintptr_t when casting numbers to pointersArnaldo Carvalho de Melo
To address these errors found when cross building from x86_64 to MIPS little endian 32-bit: CC /tmp/build/perf/util/parse-events-bison.o util/parse-events.y: In function 'parse_events_parse': util/parse-events.y:514:6: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 514 | (void *) $2, $6, $4); | ^ util/parse-events.y:531:7: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 531 | (void *) $2, NULL, $4)) { | ^ util/parse-events.y:547:6: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 547 | (void *) $2, $4, 0); | ^ util/parse-events.y:564:7: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 564 | (void *) $2, NULL, 0)) { | ^ Fixes: cabbf26821aa210f ("perf parse: Before yyabort-ing free components") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Ian Rogers <irogers@google.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Garry <john.garry@huawei.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Cc: Stephane Eranian <eranian@google.com> Cc: Yonghong Song <yhs@fb.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-03dax: fix detection of dax support for non-persistent memory block devicesColy Li
When calling __generic_fsdax_supported(), a dax-unsupported device may not have dax_dev as NULL, e.g. the dax related code block is not enabled by Kconfig. Therefore in __generic_fsdax_supported(), to check whether a device supports DAX or not, the following order of operations should be performed: - If dax_dev pointer is NULL, it means the device driver explicitly announce it doesn't support DAX. Then it is OK to directly return false from __generic_fsdax_supported(). - If dax_dev pointer is NOT NULL, it might be because the driver doesn't support DAX and not explicitly initialize related data structure. Then bdev_dax_supported() should be called for further check. If device driver desn't explicitly set its dax_dev pointer to NULL, this is not a bug. Calling bdev_dax_supported() makes sure they can be recognized as dax-unsupported eventually. Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory block device") Cc: Jan Kara <jack@suse.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Reviewed-and-tested-by: Adrian Huang <ahuang12@lenovo.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Mike Snitzer <snitzer@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Link: https://lore.kernel.org/r/20200903161625.19524-1-colyli@suse.de
2020-09-03doc: net: dsa: Fix typo in config code samplePaul Barker
In the "single port" example code for configuring a DSA switch without tagging support from userspace the command to bring up the "lan2" link was typo'd. Signed-off-by: Paul Barker <pbarker@konsulko.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-03Merge tag 'fixes-2020-09-03' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock Pull misc build failure fixes from Mike Rapoport: "Fix min_low_pfn/max_low_pfn build errors on ia64 and microblaze. Some configurations of ia64 and microblaze use min_low_pfn and max_low_pfn in pfn_valid(). This causes build failures for modules that use pfn_valid(). The fix is to add EXPORT_SYMBOL() for these variables on ia64 and microblaze" * tag 'fixes-2020-09-03' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock: ia64: fix min_low_pfn/max_low_pfn build errors microblaze: fix min_low_pfn/max_low_pfn build errors
2020-09-03Merge tag 'affs-for-5.9-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull affs fix from David Sterba: "One fix to make permissions work the same way as on AmigaOS" * tag 'affs-for-5.9-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: affs: fix basic permission bits to actually work
2020-09-03xfs: fix xfs_bmap_validate_extent_raw when checking attr fork of rt filesDarrick J. Wong
The realtime flag only applies to the data fork, so don't use the realtime block number checks on the attr fork of a realtime file. Fixes: 30b0984d9117 ("xfs: refactor bmap record validation") Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
2020-09-03Merge tag 'media/v5.9-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - a compilation fix issue with ti-vpe on arm 32 bits - two Kconfig fixes for imx214 and max9286 drivers - a kernel information leak at v4l2-core on time32 compat ioctls - some fixes at rc core unbind logic - a fix at mceusb driver for it to not use GFP_ATOMIC - fixes at cedrus and vicodec drivers at the control handling logic - a fix at gpio-ir-tx to avoid disabling interruts on a spinlock * tag 'media/v5.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: mceusb: Avoid GFP_ATOMIC where it is not needed media: gpio-ir-tx: spinlock is not needed to disable interrupts media: rc: do not access device via sysfs after rc_unregister_device() media: rc: uevent sysfs file races with rc_unregister_device() media: max9286: Depend on OF_GPIO media: i2c: imx214: select V4L2_FWNODE media: cedrus: Add missing v4l2_ctrl_request_hdl_put() media: vicodec: add missing v4l2_ctrl_request_hdl_put() media: media/v4l2-core: Fix kernel-infoleak in video_put_user() media: ti-vpe: cal: Fix compilation on 32-bit ARM
2020-09-03media: rc: rename ir_lirc_* functions to lirc_*Sean Young
Remove pointless ir_ prefix. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: rc: harmonize infrared durations to microsecondsSean Young
rc-core kapi uses nanoseconds for infrared durations for receiving, and microseconds for sending. The uapi already uses microseconds for both, so this patch does not change the uapi. Infrared durations do not need nanosecond resolution. IR protocols do not have durations shorter than about 100 microseconds. Some IR hardware offers 250 microseconds resolution, which is sufficient for most protocols. Better hardware has 50 microsecond resolution and is enough for every protocol I am aware off. Unify on microseconds everywhere. This simplifies the code since less conversion between microseconds and nanoseconds needs to be done. This affects: - rx_resolution member of struct rc_dev - timeout member of struct rc_dev - duration member in struct ir_raw_event Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Patrick Lerda <patrick9876@free.fr> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: "David Härdeman" <david@hardeman.nu> Cc: Benjamin Valentin <benpicco@googlemail.com> Cc: Antti Palosaari <crope@iki.fi> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: rc: rename lirc char dev region to "lirc"Sean Young
BaseRemoteCtl is not descriptive. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: dvb_usb_pctv452e: use ISL6423 voltage regulator per defaultAlex Bee
Both TT-connect S2-3600 and Pinnacle PCTV Sat HDTV are using Intersil ISL6423 as LNB voltage regulator. This makes TT-connect S2-3650 CI the only device which uses STM LNBP22 regulator which is currently used for all devices driven by pctv452e driver. This patch fixes this by creating an exception for TT-connect S2-3650 CI to continue to use STM LNBP22 while all others now using correct ISL6423 driver which makes DiSEqC/EN50494 comands which involve voltage changes now working on the other devices (which didn't work before). Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: mxl5xx: remove unused including <linux/version.h>Jason Yan
Fix the following versioncheck warning: drivers/media/dvb-frontends/mxl5xx.c:30:1: unused including <linux/version.h> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03libbpf: Remove arch-specific include path in MakefileNaveen N. Rao
Ubuntu mainline builds for ppc64le are failing with the below error (*): CALL /home/kernel/COD/linux/scripts/atomic/check-atomics.sh DESCEND bpf/resolve_btfids Auto-detecting system features: ... libelf: [ [32mon[m ] ... zlib: [ [32mon[m ] ... bpf: [ [31mOFF[m ] BPF API too old make[6]: *** [Makefile:295: bpfdep] Error 1 make[5]: *** [Makefile:54: /home/kernel/COD/linux/debian/build/build-generic/tools/bpf/resolve_btfids//libbpf.a] Error 2 make[4]: *** [Makefile:71: bpf/resolve_btfids] Error 2 make[3]: *** [/home/kernel/COD/linux/Makefile:1890: tools/bpf/resolve_btfids] Error 2 make[2]: *** [/home/kernel/COD/linux/Makefile:335: __build_one_by_one] Error 2 make[2]: Leaving directory '/home/kernel/COD/linux/debian/build/build-generic' make[1]: *** [Makefile:185: __sub-make] Error 2 make[1]: Leaving directory '/home/kernel/COD/linux' resolve_btfids needs to be build as a host binary and it needs libbpf. However, libbpf Makefile hardcodes an include path utilizing $(ARCH). This results in mixing of cross-architecture headers resulting in a build failure. The specific header include path doesn't seem necessary for a libbpf build. Hence, remove the same. (*) https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.9-rc3/ppc64el/log Reported-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200902084246.1513055-1-naveen.n.rao@linux.vnet.ibm.com
2020-09-03dma-buf: fence-chain: Document missing dma_fence_chain_init() parameter in ↵Krzysztof Kozlowski
kerneldoc Fix W=1 compile warnings (invalid kerneldoc): drivers/dma-buf/dma-fence-chain.c:233: warning: Function parameter or member 'seqno' not described in 'dma_fence_chain_init' Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200819175134.19261-2-krzk@kernel.org
2020-09-03dma-buf: Fix kerneldoc of dma_buf_set_name()Krzysztof Kozlowski
Fix W=1 compile warnings (invalid kerneldoc): drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member 'dmabuf' not described in 'dma_buf_set_name' Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200819175134.19261-1-krzk@kernel.org
2020-09-03ALSA: hda/realtek - Improved routing for Thinkpad X1 7th/8th GenTakashi Iwai
There've been quite a few regression reports about the lowered volume (reduced to ca 65% from the previous level) on Lenovo Thinkpad X1 after the commit d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen"). Although the commit itself does the right thing from HD-audio POV in order to have a volume control for bass speakers, it seems that the machine has some secret recipe under the hood. Through experiments, Benjamin Poirier found out that the following routing gives the best result: * DAC1 (NID 0x02) -> Speaker pin (NID 0x14) * DAC2 (NID 0x03) -> Shared by both Bass Speaker pin (NID 0x17) & Headphone pin (0x21) * DAC3 (NID 0x06) -> Unused DAC1 seems to have some equalizer internally applied, and you'd get again the output in a bad quality if you connect this to the headphone pin. Hence the headphone is connected to DAC2, which is now shared with the bass speaker pin. DAC3 has no volume amp, hence it's not connected at all. For achieving the routing above, this patch introduced a couple of workarounds: * The connection list of bass speaker pin (NID 0x17) is reduced not to include DAC3 (NID 0x06) * Pass preferred_pairs array to specify the fixed connection Here, both workarounds are needed because the generic parser prefers the individual DAC assignment over others. When the routing above is applied, the generic parser creates the two volume controls "Front" and "Bass Speaker". Since we have only two DACs for three output pins, those are not fully controlling each output individually, and it would confuse PulseAudio. For avoiding the pitfall, in this patch, we rename those volume controls to some unique ones ("DAC1" and "DAC2"). Then PulseAudio ignore them and concentrate only on the still good-working "Master" volume control. If a user still wants to control each DAC volume, they can still change manually via "DAC1" and "DAC2" volume controls. Fixes: d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") Reported-by: Benjamin Poirier <benjamin.poirier@gmail.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Tested-by: Benjamin Poirier <benjamin.poirier@gmail.com> Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207407#c10 BugLink: https://gist.github.com/hamidzr/dd81e429dc86f4327ded7a2030e7d7d9#gistcomment-3214171 BugLink: https://gist.github.com/hamidzr/dd81e429dc86f4327ded7a2030e7d7d9#gistcomment-3276276 Link: https://lore/kernel.org/r/20200829112746.3118-1-benjamin.poirier@gmail.com Link: https://lore.kernel.org/r/20200903083300.6333-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-09-03media: atomisp: cleanup isys_irq headersMauro Carvalho Chehab
Don't need to declare those functions with extern: drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:51:35: warning: function 'isys_irqc_state_dump' with external linkage has definition drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:68:35: warning: function 'isys_irqc_reg_store' with external linkage has definition drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:85:39: warning: function 'isys_irqc_reg_load' with external linkage has definition drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq.c:31:35: warning: function 'isys_irqc_status_enable' with external linkage has definition Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: fix some bad indentsMauro Carvalho Chehab
As smatch reports, there are several bad indents: drivers/staging/media/atomisp/pci/hmm/hmm.c:271 hmm_alloc() warn: inconsistent indenting drivers/staging/media/atomisp/pci/runtime/bufq/src/bufq.c:390 ia_css_bufq_enqueue_psys_event() warn: inconsistent indenting drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c:2132 ia_css_debug_dump_isys_state() warn: inconsistent indenting drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:246 sh_css_binary_get_sc_requirements() warn: inconsistent indenting drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:565 ia_css_binary_get_shading_info_type_1() warn: inconsistent indenting drivers/staging/media/atomisp/pci/sh_css.c:5109 sh_css_pipes_stop() warn: inconsistent indenting drivers/staging/media/atomisp/pci/sh_css.c:8791 ia_css_pipe_create() warn: inconsistent indenting Some of them are due to ifdefs. Get rid of them by either getting a common code that would work for both ISP2400 and ISP2401 or by creating separate functions, one for each ISP version. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: remove compile-time tests from input_system_global.hMauro Carvalho Chehab
Now that there's no duplication between ISP2400 and ISP2401 input system functions, we can include both at the system global. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: reorder functions at pixelgen_private.hMauro Carvalho Chehab
Reorder functions in order to declare before usage. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: de-duplicate names at *_input_system_global.hMauro Carvalho Chehab
There are some duplicated names between the ISP2401 and ISP2400 for the input system, with different meanings. In order to avoid ubiquity, let's prepend those with the name of the ISP. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: unify INPUT error return typeMauro Carvalho Chehab
There is a typedef for INPUT errors. This is different between ISP2401 and ISP2400. Place both at the same struct, at the global header file. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: don't check for ISP version for includesMauro Carvalho Chehab
As there aren't duplicated names anymore, and the end goal is to do runtime checks between ISP2400 and ISP2401, remove the part of the Makefile which changes the include places based on the compile-time version. This shouldn't cause any effect, but it will make easier for further patches meant to remove conditional compiler decisions between ISP versions to be replaced by runtime ones. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: get rid of ibuf_ctrl abstractionMauro Carvalho Chehab
Just move the stuff there to the places where this header is included. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: get rid of isys_dma.h and isys_dma_local.hMauro Carvalho Chehab
There aren't much on this abstraction. Just move the defines to isys_dma_private.h and isys_dma_public.h, cleaning up the includes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: get rid of version-dependent globalsMauro Carvalho Chehab
Replace all occurrences along the atomisp tree for the conditional compilation macros found at system_global.h, replacing them by tests wheather ISP2401 is defined or not. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: cleanup ifdefs from ia_css_debug.cMauro Carvalho Chehab
There are lots of code dependency there. Get rid of most of them. We can't remove everything, as there are some structs that are conditionally built if ISP2401. So, keep ifdefs only on such cases. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: get rid of some unused codeMauro Carvalho Chehab
Now that the defines which are common for both ISP2400 and ISP2401 are at system_global.h, we can get rid of the code not used by those versions. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03MIPS: SNI: Fix SCSI interruptThomas Bogendoerfer
On RM400(a20r) machines ISA and SCSI interrupts share the same interrupt line. Commit 49e6e07e3c80 ("MIPS: pass non-NULL dev_id on shared request_irq()") accidently dropped the IRQF_SHARED bit, which breaks registering SCSI interrupt. Put back IRQF_SHARED and add dev_id for ISA interrupt. Fixes: 49e6e07e3c80 ("MIPS: pass non-NULL dev_id on shared request_irq()") Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-09-03MIPS: add missing MSACSR and upper MSA initializationHuang Pei
In cc97ab235f3f ("MIPS: Simplify FP context initialization), init_fp_ctx just initialize the fp/msa context, and own_fp_inatomic just restore FCSR and 64bit FP regs from it, but miss MSACSR and upper MSA regs for MSA, so MSACSR and MSA upper regs's value from previous task on current cpu can leak into current task and cause unpredictable behavior when MSA context not initialized. Fixes: cc97ab235f3f ("MIPS: Simplify FP context initialization") Signed-off-by: Huang Pei <huangpei@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-09-03Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled"Josh Poimboeuf
Use of the new -flive-patching flag was introduced with the following commit: 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled") This flag has several drawbacks: - It disables some optimizations, so it can have a negative effect on performance. - According to the GCC documentation it's not compatible with LTO, which will become a compatibility issue as LTO support gets upstreamed in the kernel. - It was intended to be used for source-based patch generation tooling, as opposed to binary-based patch generation tooling (e.g., kpatch-build). It probably should have at least been behind a separate config option so as not to negatively affect other livepatch users. - Clang doesn't have the flag, so as far as I can tell, this method of generating patches is incompatible with Clang, which like LTO is becoming more mainstream. - It breaks GCC's implicit noreturn detection for local functions. This is the cause of several "unreachable instruction" objtool warnings. - The broken noreturn detection is an obvious GCC regression, but we haven't yet gotten GCC developers to acknowledge that, which doesn't inspire confidence in their willingness to keep the feature working as optimizations are added or changed going forward. - While there *is* a distro which relies on this flag for their distro livepatch module builds, there's not a publicly documented way to create safe livepatch modules with it. Its use seems to be based on tribal knowledge. It serves no benefit to those who don't know how to use it. (In fact, I believe the current livepatch documentation and samples are misleading and dangerous, and should be corrected. Or at least amended with a disclaimer. But I don't feel qualified to make such changes.) Also, we have an idea for using objtool to detect function changes, which could potentially obsolete the need for this flag anyway. At this point the flag has no benefits for upstream which would counteract the above drawbacks. Revert it until it becomes more ready. This reverts commit 43bd3a95c98e1a86b8b55d97f745c224ecff02b9. Fixes: 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com
2020-09-03x86/mm/32: Bring back vmalloc faulting on x86_32Joerg Roedel
One can not simply remove vmalloc faulting on x86-32. Upstream commit: 7f0a002b5a21 ("x86/mm: remove vmalloc faulting") removed it on x86 alltogether because previously the arch_sync_kernel_mappings() interface was introduced. This interface added synchronization of vmalloc/ioremap page-table updates to all page-tables in the system at creation time and was thought to make vmalloc faulting obsolete. But that assumption was incredibly naive. It turned out that there is a race window between the time the vmalloc or ioremap code establishes a mapping and the time it synchronizes this change to other page-tables in the system. During this race window another CPU or thread can establish a vmalloc mapping which uses the same intermediate page-table entries (e.g. PMD or PUD) and does no synchronization in the end, because it found all necessary mappings already present in the kernel reference page-table. But when these intermediate page-table entries are not yet synchronized, the other CPU or thread will continue with a vmalloc address that is not yet mapped in the page-table it currently uses, causing an unhandled page fault and oops like below: BUG: unable to handle page fault for address: fe80c000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 33183067 *pte = a8648163 Oops: 0002 [#1] SMP CPU: 1 PID: 13514 Comm: cve-2017-17053 Tainted: G ... Call Trace: ldt_dup_context+0x66/0x80 dup_mm+0x2b3/0x480 copy_process+0x133b/0x15c0 _do_fork+0x94/0x3e0 __ia32_sys_clone+0x67/0x80 __do_fast_syscall_32+0x3f/0x70 do_fast_syscall_32+0x29/0x60 do_SYSENTER_32+0x15/0x20 entry_SYSENTER_32+0x9f/0xf2 EIP: 0xb7eef549 So the arch_sync_kernel_mappings() interface is racy, but removing it would mean to re-introduce the vmalloc_sync_all() interface, which is even more awful. Keep arch_sync_kernel_mappings() in place and catch the race condition in the page-fault handler instead. Do a partial revert of above commit to get vmalloc faulting on x86-32 back in place. Fixes: 7f0a002b5a21 ("x86/mm: remove vmalloc faulting") Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200902155904.17544-1-joro@8bytes.org
2020-09-03media: atomisp: csi_rx.c: add missing includesMauro Carvalho Chehab
Due to that, smatch warns with: drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:18:11: warning: symbol 'N_SHORT_PACKET_LUT_ENTRIES' was not declared. Should it be static? drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:24:11: warning: symbol 'N_LONG_PACKET_LUT_ENTRIES' was not declared. Should it be static? drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:30:11: warning: symbol 'N_CSI_RX_FE_CTRL_DLANES' was not declared. Should it be static? drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:37:11: warning: symbol 'N_CSI_RX_BE_SID_WIDTH' was not declared. Should it be static? drivers/staging/media/atomisp/pci/css_2401_system/host/ibuf_ctrl.c:19:11: warning: symbol 'N_IBUF_CTRL_PROCS' was not declared. Should it be static? Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: atomisp: atomisp_gmin_platform: check before useMauro Carvalho Chehab
solve this smatch warning: drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:842 gmin_v1p8_ctrl() warn: variable dereferenced before check 'gs' (see line 832) By moving the check to happen before its usage. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03locking/lockdep: Fix "USED" <- "IN-NMI" inversionspeterz@infradead.org
During the LPC RCU BoF Paul asked how come the "USED" <- "IN-NMI" detector doesn't trip over rcu_read_lock()'s lockdep annotation. Looking into this I found a very embarrasing typo in verify_lock_unused(): - if (!(class->usage_mask & LOCK_USED)) + if (!(class->usage_mask & LOCKF_USED)) fixing that will indeed cause rcu_read_lock() to insta-splat :/ The above typo means that instead of testing for: 0x100 (1 << LOCK_USED), we test for 8 (LOCK_USED), which corresponds to (1 << LOCK_ENABLED_HARDIRQ). So instead of testing for _any_ used lock, it will only match any lock used with interrupts enabled. The rcu_read_lock() annotation uses .check=0, which means it will not set any of the interrupt bits and will thus never match. In order to properly fix the situation and allow rcu_read_lock() to correctly work, split LOCK_USED into LOCK_USED and LOCK_USED_READ and by having .read users set USED_READ and test USED, pure read-recursive locks are permitted. Fixes: f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI" inversions") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Paul E. McKenney <paulmck@kernel.org> Link: https://lore.kernel.org/r/20200902160323.GK1362448@hirez.programming.kicks-ass.net
2020-09-03media: atomisp: fix casts at atomisp_compat_ioctl32.cMauro Carvalho Chehab
There are several warnings reported by sparse with regards to wrong typecasts: drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13: expected void *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13: expected unsigned int [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13: expected unsigned int [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13: expected unsigned int [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13: expected unsigned int [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30: warning: incorrect type in argument 2 (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30: expected void const *from drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30: got struct atomisp_3a_statistics [noderef] __user *kp drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13: expected unsigned int [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13: expected void [noderef] __user *effective_width drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13: got unsigned int [usertype] * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13: expected void [noderef] __user *effective_width drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13: got unsigned int [usertype] * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13: expected unsigned int [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13: expected struct v4l2_framebuffer *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13: expected void [noderef] __user *frame drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13: got struct v4l2_framebuffer * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13: expected unsigned short *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13: expected void [noderef] __user *calb_grp_values drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13: got unsigned short * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21: expected unsigned short [usertype] *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27: warning: cast removes address space '__user' of expression drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27: warning: incorrect type in initializer (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27: expected struct <noident> [noderef] __user *karg drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27: got void * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:721:39: warning: cast removes address space '__user' of expression drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21: warning: incorrect type in argument 1 (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21: expected void const volatile [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21: got unsigned int [usertype] *src drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43: expected void *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43: got void [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21: expected struct atomisp_shading_table *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21: got struct atomisp_shading_table [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21: expected struct atomisp_morph_table *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21: got struct atomisp_morph_table [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21: expected struct atomisp_dis_coefficients *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21: got struct atomisp_dis_coefficients [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14: expected struct atomisp_dvs_6axis_config *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14: got struct atomisp_dvs_6axis_config [noderef] __user * drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13: warning: incorrect type in assignment (different address spaces) drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13: expected struct atomisp_sensor_ae_bracketing_lut_entry *__pu_val drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13: got void [noderef] __user * Use the same strategies used at v4l2-compat32.c, in order to solve them and avoid warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: saa7134: avoid a shift overflowMauro Carvalho Chehab
As reported by smatch: drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn: should 'reg << 2' be a 64 bit type? On a 64-bits Kernel, the shift might be bigger than 32 bits. In real, this should never happen, but let's shut up the warning. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: dvb-ttusb-budget: cleanup printk logicMauro Carvalho Chehab
Instead of calling printk(), use pr_foo() macros. While here, do some cleanup at the printed messages, as some has __func__, while others have the module name (sometimes spelled as "ttusb_dvb"). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: dvb-ttusb-budget: don't use stack for USB transfersMauro Carvalho Chehab
As reported by smatch: drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:311 ttusb_boot_dsp() error: doing dma on the stack (b) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:321 ttusb_boot_dsp() error: doing dma on the stack (b) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:330 ttusb_boot_dsp() error: doing dma on the stack (b) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:351 ttusb_set_channel() error: doing dma on the stack (b) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:361 ttusb_del_channel() error: doing dma on the stack (b) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:412 ttusb_init_controller() error: doing dma on the stack (b0) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:416 ttusb_init_controller() error: doing dma on the stack (b1) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:422 ttusb_init_controller() error: doing dma on the stack (b2) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:425 ttusb_init_controller() error: doing dma on the stack (b3) drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:430 ttusb_init_controller() error: doing dma on the stack (get_version) This driver still uses the USB stack for DMA transfers, which is broken for a long time. I almost dropped this driver, as there's a high chance that nobody is using it with upstream Kernels, as we didn't receive any bug reports. As fixing this won't be hard, I ended opting to fix. While here, I dropped an ugly hack that implemented read via a separate function that was just doing a memcpy(). It should be noticed that, during the init phase, there's a "b4" register that were never initialized, as its buffer were used just to store the results of "b3" initialization. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: saa7134-alsa.c: number of pages should be unsigned longMauro Carvalho Chehab
As reported by smatch: drivers/media/pci/saa7134/saa7134-alsa.c:267 saa7134_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type? the number of patches should be unsigned long. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: cx88-alsa: number of pages should be unsigned longMauro Carvalho Chehab
As reported by smatch: drivers/media/pci/cx88/cx88-alsa.c:286 cx88_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type? the number of patches should be unsigned long. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: cx23885-alsa: number of pages should be unsigned longMauro Carvalho Chehab
As reported by smatch: drivers/media//pci/cx23885/cx23885-alsa.c:83 cx23885_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type? the number of patches should be unsigned long. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-16 02:40:48 +0000