A couple of minor fixes to the display changes that went in for 5.9.
The most important of which is a workaround for a HW bug that was
exposed by better push buffer space management, leading to
random(ish...) display engine hangs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv5QDxyMihrxbPk+-sORnaYtjR6_dbM68gEhb2wxht_G1w@mail.gmail.com
Karsten Graul says:
====================
net/smc: fixes 2020-09-03
Please apply the following patch series for smc to netdev's net tree.
Patch 1 fixes the toleration of older SMC implementations. Patch 2
takes care of a problem that happens when SMCR is used after SMCD
initialization failed. Patch 3 fixes a problem with freed send buffers,
and patch 4 corrects refcounting when SMC terminates due to device
removal.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When an ISM device is removed, all its linkgroups are terminated,
i.e. all the corresponding connections are killed.
Connection killing invokes smc_close_active_abort(), which decreases
the sock refcount for certain states to simulate passive closing.
And it cancels the close worker and has to give up the sock lock for
this timeframe. This opens the door for a passive close worker or a
socket close to run in between. In this case smc_close_active_abort() and
passive close worker resp. smc_release() might do a sock_put for passive
closing. This causes:
[ 1323.315943] refcount_t: underflow; use-after-free.
[ 1323.316055] WARNING: CPU: 3 PID: 54469 at lib/refcount.c:28 refcount_warn_saturate+0xe8/0x130
[ 1323.316069] Kernel panic - not syncing: panic_on_warn set ...
[ 1323.316084] CPU: 3 PID: 54469 Comm: uperf Not tainted 5.9.0-20200826.rc2.git0.46328853ed20.300.fc32.s390x+debug #1
[ 1323.316096] Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0)
[ 1323.316108] Call Trace:
[ 1323.316125] [<00000000c0d4aae8>] show_stack+0x90/0xf8
[ 1323.316143] [<00000000c15989b0>] dump_stack+0xa8/0xe8
[ 1323.316158] [<00000000c0d8344e>] panic+0x11e/0x288
[ 1323.316173] [<00000000c0d83144>] __warn+0xac/0x158
[ 1323.316187] [<00000000c1597a7a>] report_bug+0xb2/0x130
[ 1323.316201] [<00000000c0d36424>] monitor_event_exception+0x44/0xc0
[ 1323.316219] [<00000000c195c716>] pgm_check_handler+0x1da/0x238
[ 1323.316234] [<00000000c151844c>] refcount_warn_saturate+0xec/0x130
[ 1323.316280] ([<00000000c1518448>] refcount_warn_saturate+0xe8/0x130)
[ 1323.316310] [<000003ff801f2e2a>] smc_release+0x192/0x1c8 [smc]
[ 1323.316323] [<00000000c169f1fa>] __sock_release+0x5a/0xe0
[ 1323.316334] [<00000000c169f2ac>] sock_close+0x2c/0x40
[ 1323.316350] [<00000000c1086de0>] __fput+0xb8/0x278
[ 1323.316362] [<00000000c0db1e0e>] task_work_run+0x76/0xb8
[ 1323.316393] [<00000000c0d8ab84>] do_exit+0x26c/0x520
[ 1323.316408] [<00000000c0d8af08>] do_group_exit+0x48/0xc0
[ 1323.316421] [<00000000c0d8afa8>] __s390x_sys_exit_group+0x28/0x38
[ 1323.316433] [<00000000c195c32c>] system_call+0xe0/0x2b4
[ 1323.316446] 1 lock held by uperf/54469:
[ 1323.316456] #0: 0000000044125e60 (&sb->s_type->i_mutex_key#9){+.+.}-{3:3}, at: __sock_release+0x44/0xe0
The patch rechecks sock state in smc_close_active_abort() after
smc_close_cancel_work() to avoid duplicate decrease of sock
refcount for the same purpose.
Fixes: 611b63a127 ("net/smc: cancel tx worker in case of socket aborts")
Reviewed-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
SMC tries to make use of SMCD first. If a problem shows up,
it tries to switch to SMCR. If the SMCD initializing problem shows
up after the SMCD connection has already been initialized, field
rx_off keeps the wrong SMCD value for SMCR, which results in corrupted
data at the receiver.
This patch adds an explicit (re-)setting of field rx_off to zero if the
connection uses SMCR.
Fixes: be244f28d2 ("net/smc: add SMC-D support in data transfer")
Reviewed-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Older SMCR implementations had no link failover support and used one
link only. Because the handshake protocol requires to try the
establishment of a second link the old code sent a fake add_link message
and declined any server response afterwards.
The current code supports multiple links and inspects the received fake
add_link message more closely. To tolerate the fake add_link messages
smc_llc_is_local_add_link() needs an improved check of the message to
be able to separate between locally enqueued and fake add_link messages.
And smc_llc_cli_add_link() needs to check if the provided qp_mtu size is
invalid and reject the add_link request in that case.
Fixes: c48254fa48 ("net/smc: move add link processing for new device into llc layer")
Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: db21997379 ("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>
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: 3c29d4483e ("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>
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: 2055fdaf87 ("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>
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: 13edc23720 ("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>
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>
The new string should have enough space for the original string and the
back slashes IMHO.
Fixes: fbc2844e84 ("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>
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: cabbf26821 ("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>
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>
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.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEeOVYVaWZL5900a/pOQOGJssO/ZEFAl9RAB8THHJwcHRAbGlu
dXguaWJtLmNvbQAKCRA5A4Ymyw79kaw9B/9icBkgDj/KQKnD5y5PgDis4AIHZ59d
X2pIKk43sXB2xBQmtBxRkTrxHbBkNLOc81BaJJjkkVXEqGbtiYHHVgDFrazwFNwZ
q480Ha8CP4mNyR3JZ/sI0npdqX/BQxLJPa5v6hAa+UZExFCbNnPpcam/GsJIw7T4
Gd9caXJ3WE6uPrxjkdo6kthihfOxgSXX1cLIyMkFDZdhGbsBipm60+JScgk3f/cX
77qggeJ/2f7HDSoBCsPcxqBxqdlQ6J5P5L2gNEN67GgSegNBs/GAs7xDbTx2XuFv
9vTwZ8bTatkgLtnch5yQR/ul01DmgPZJUBQPYlLd7y+dfB5AgTBvNkby
=oS5W
-----END PGP SIGNATURE-----
Merge tag 'fixes-2020-09-03' of 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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAl9Qx/MACgkQxWXV+ddt
WDvT8g//bO9+xB3dRYLVl5FWur826Zz/dmzpp+A3QCI0er1+zh8/3FHD6dvGyBQu
CHQE1GFTdewry1usuGu08WopGiywnCa1svmp+qCJDugiDAG/ciTq2zQWemV2gRXU
1/9yZ62B3eBKuiL+lFNPYFzqWhsX0zP21nxHEkTJi2d8enJDNcmrrWjBrVHUVa1o
D0al0zPvaXpcknadhsNSkJnvgMeTcSz89AEIEC5OVfitbaIX09UAadG9kjPLlGJN
KNL+/vmAARNe1ze5qjTf3++E1LH28CdJ7rrlhAqyR4L4rApCQw8ZQv3h8EbnidSy
VJgDQCk35Z6IxVwbUKYEGiperV2dnsZHukzPT/sqjGrHO0Ct+Fy+YeK+4aw9yaof
mWG7RGeczj9t/FbKEGmELlEOHKmJw+PHi5byTokPfsA8smrfaPKNJKlb5bbjALni
hOThGiYr18n3RrSidpZ0GVxRcl8j3OwHSVDS/9U3eAF7Z31QtTDoX0MHbK6PrbvW
KvGkqIwyLknshS868lyAzXSdg6K4wYqvuh2Z/TuFFPV2MGbsXxHEFgM7M1wueV6x
iLhqUDYn2ki79FqqCYsUqWzDMc8m/4v//T4KPTj+BN9H8ij9bdzTXpaHrZAqLX0Y
ielkB51hdAlCML/Ctd5xojn5YOXgo5TkSC32QOHvxovSI1qJCIo=
=lVnf
-----END PGP SIGNATURE-----
Merge tag 'affs-for-5.9-tag' of 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
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: 30b0984d91 ("xfs: refactor bmap record validation")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAl9Qh2sACgkQCF8+vY7k
4RV+7Q/8D7Aj/6YArMxR2MvRhQt8tEoY1NgeP96JWagdklqJZH9jCXwW8h+/UOjw
Sg7x3PP7kIKD5VtrY/zQz9m+B3+c8K1BM71IzEY5vzJR4UPYrPsqENw0+320rgjA
Tnxu/P4bxbUOdP6fYbzdSLAZcvKfBOUDSiy6Cm9rw7e42XKi5F8ud1eqs5D/jViA
8bbu5shdgeLOqCAbneu8gw3dP7+H47wcKX/FRF5QXRDzFj9BaCYZSiZKqEBgxXyc
TOr6pM6evpc9TOP/H9G7d+kZSglPV7HzfehA/+c9d7kzmzexDztdPeJrN7P8Sl84
MXs5ZClhYYqwf3ZpQT6abQZXG+N8xHu1TwSoMeZSrfzHJX+r61lMjt9GpdEvFif+
U2Fv3mdKXWpYuUpSlWwy8QJLCnmuGgbc959eJ+CDkgkZT/twrDaXHqaG9emWErEs
10znIW7FT8QiAHtkVADFYWj9JDiG+6q+lG94Jz/wjtfndk5aKdqm5jKIT6HI97h5
5yMY4sS2m4RQKlwSFCQI1Fz3fSonvFmqBFaYXuP9xk+i7yAPa/owByLNttqwocVf
N1UcLGFWJ684mHzQkgSQI6OiLTXP7NazK/N6CVVIy6Iaj/Cx2djVK9Y4gcYTKfgs
HDKZbyUkhkFrU9kFYRlsdGf/VRqrjndHL4ySAWG/Gyl79/EGzHA=
=OwNa
-----END PGP SIGNATURE-----
Merge tag 'media/v5.9-2' of 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
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>
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>
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>
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 d2cd795c4e ("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: d2cd795c4e ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
On RM400(a20r) machines ISA and SCSI interrupts share the same interrupt
line. Commit 49e6e07e3c ("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: 49e6e07e3c ("MIPS: pass non-NULL dev_id on shared request_irq()")
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
In cc97ab235f ("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: cc97ab235f ("MIPS: Simplify FP context initialization")
Signed-off-by: Huang Pei <huangpei@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
One can not simply remove vmalloc faulting on x86-32. Upstream
commit: 7f0a002b5a ("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: 7f0a002b5a ("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
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>
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>
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>
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>
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>
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>
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>
Dave Airlie