Werner Sembach [Wed, 17 Mar 2021 15:13:48 +0000 (16:13 +0100)]
drm/amd/display: Try YCbCr420 color when YCbCr444 fails
[ Upstream commit
68eb3ae3c63708f823aeeb63bb15197c727bd9bf ]
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Mon, 22 Mar 2021 11:54:42 +0000 (12:54 +0100)]
amdgpu: avoid incorrect %hu format string
[ Upstream commit
7d98d416c2cc1c1f7d9508e887de4630e521d797 ]
clang points out that the %hu format string does not match the type
of the variables here:
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:7: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat]
version_major, version_minor);
^~~~~~~~~~~~~
include/drm/drm_print.h:498:19: note: expanded from macro 'DRM_ERROR'
__drm_err(fmt, ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
Change it to a regular %u, the same way a previous patch did for
another instance of the same warning.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qu Huang [Sun, 21 Mar 2021 08:28:18 +0000 (16:28 +0800)]
drm/amdkfd: Fix cat debugfs hang_hws file causes system crash bug
[ Upstream commit
d73610211eec8aa027850982b1a48980aa1bc96e ]
Here is the system crash log:
[ 1272.884438] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1272.884444] IP: [< (null)>] (null)
[ 1272.884447] PGD
825b09067 PUD
8267c8067 PMD 0
[ 1272.884452] Oops: 0010 [#1] SMP
[ 1272.884509] CPU: 13 PID: 3485 Comm: cat Kdump: loaded Tainted: G
[ 1272.884515] task:
ffff9a38dbd4d140 ti:
ffff9a37cd3b8000 task.ti:
ffff9a37cd3b8000
[ 1272.884517] RIP: 0010:[<
0000000000000000>] [< (null)>]
(null)
[ 1272.884520] RSP: 0018:
ffff9a37cd3bbe68 EFLAGS:
00010203
[ 1272.884522] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
0000000000014d5f
[ 1272.884524] RDX:
fffffffffffffff4 RSI:
0000000000000001 RDI:
ffff9a38aca4d200
[ 1272.884526] RBP:
ffff9a37cd3bbed0 R08:
ffff9a38dcd5f1a0 R09:
ffff9a31ffc07300
[ 1272.884527] R10:
ffff9a31ffc07300 R11:
ffffffffaddd5e9d R12:
ffff9a38b4e0fb00
[ 1272.884529] R13:
0000000000000001 R14:
ffff9a37cd3bbf18 R15:
ffff9a38aca4d200
[ 1272.884532] FS:
00007feccaa67740(0000) GS:
ffff9a38dcd40000(0000)
knlGS:
0000000000000000
[ 1272.884534] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 1272.884536] CR2:
0000000000000000 CR3:
00000008267c0000 CR4:
00000000003407e0
[ 1272.884537] Call Trace:
[ 1272.884544] [<
ffffffffade68940>] ? seq_read+0x130/0x440
[ 1272.884548] [<
ffffffffade40f8f>] vfs_read+0x9f/0x170
[ 1272.884552] [<
ffffffffade41e4f>] SyS_read+0x7f/0xf0
[ 1272.884557] [<
ffffffffae374ddb>] system_call_fastpath+0x22/0x27
[ 1272.884558] Code: Bad RIP value.
[ 1272.884562] RIP [< (null)>] (null)
[ 1272.884564] RSP <
ffff9a37cd3bbe68>
[ 1272.884566] CR2:
0000000000000000
Signed-off-by: Qu Huang <jinsdb@126.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anson Jacob [Mon, 1 Mar 2021 19:25:44 +0000 (14:25 -0500)]
drm/amd/display: Fix UBSAN: shift-out-of-bounds warning
[ Upstream commit
54718747a6e1037317a8b3610c3be40621b2b75e ]
[Why]
On NAVI14 CONFIG_UBSAN reported shift-out-of-bounds at
display_rq_dlg_calc_20v2.c:304:38
rq_param->misc.rq_c.blk256_height is 0 when chroma(*_c) is invalid.
dml_log2 returns -1023 for log2(0), although log2(0) is undefined.
Which ended up as:
rq_param->dlg.rq_c.swath_height = 1 << -1023
[How]
Fix applied on all dml versions.
1. Ensure dml_log2 is only called if the argument is greater than 0.
2. Subtract req128_l/req128_c from log2_swath_height_l/log2_swath_height_c
only when it is greater than 0.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fangzhi Zuo [Tue, 9 Mar 2021 16:22:36 +0000 (11:22 -0500)]
drm/amd/display: Fix debugfs link_settings entry
[ Upstream commit
c006a1c00de29e8cdcde1d0254ac23433ed3fee9 ]
1. Catch invalid link_rate and link_count settings
2. Call dc interface to overwrite preferred link settings, and wait
until next stream update to apply the new settings.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Gomez [Thu, 18 Mar 2021 08:32:36 +0000 (09:32 +0100)]
drm/radeon/ttm: Fix memory leak userptr pages
[ Upstream commit
5aeaa43e0ef1006320c077cbc49f4a8229ca3460 ]
If userptr pages have been pinned but not bounded,
they remain uncleared.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Gomez <daniel@qtec.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Gomez [Wed, 17 Mar 2021 16:08:37 +0000 (17:08 +0100)]
drm/amdgpu/ttm: Fix memory leak userptr pages
[ Upstream commit
0f6f9dd490d524930081a6ef1d60171ce39220b9 ]
If userptr pages have been pinned but not bounded,
they remain uncleared.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Gomez <daniel@qtec.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Tue, 6 Apr 2021 21:47:25 +0000 (23:47 +0200)]
drm/msm/mdp5: Do not multiply vclk line count by 100
[ Upstream commit
377569f82ea8228c421cef4da33e056a900b58ca ]
Neither vtotal nor drm_mode_vrefresh contain a value that is
premultiplied by 100 making the x100 variable name incorrect and
resulting in vclks_line to become 100 times larger than it is supposed
to be. The hardware counts 100 clockticks too many before tearcheck,
leading to severe panel issues on at least the Sony Xperia lineup.
This is likely an artifact from the original MDSS DSI panel driver where
the calculation [1] corrected for a premultiplied reference framerate by
100 [2]. It does not appear that the above values were ever
premultiplied in the history of the DRM MDP5 driver.
With this change applied the value written to the SYNC_CONFIG_VSYNC
register is now identical to downstream kernels.
[1]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_mdp_intf_cmd.c?h=LA.UM.8.6.c26-02400-89xx.0#n288
[2]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_dsi_panel.c?h=LA.UM.8.6.c26-02400-89xx.0#n1648
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Link: https://lore.kernel.org/r/20210406214726.131534-3-marijn.suijten@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Tue, 6 Apr 2021 21:47:24 +0000 (23:47 +0200)]
drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal
[ Upstream commit
2ad52bdb220de5ab348098e3482b01235d15a842 ]
Leaving this at a close-to-maximum register value 0xFFF0 means it takes
very long for the MDSS to generate a software vsync interrupt when the
hardware TE interrupt doesn't arrive. Configuring this to double the
vtotal (like some downstream kernels) leads to a frame to take at most
twice before the vsync signal, until hardware TE comes up.
In this case the hardware interrupt responsible for providing this
signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at
all. This solves severe panel update issues observed on at least the
Xperia Loire and Tone series, until said gpio is properly hooked up to
an irq.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210406214726.131534-2-marijn.suijten@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lingutla Chandrasekhar [Wed, 7 Apr 2021 22:06:26 +0000 (23:06 +0100)]
sched/fair: Ignore percpu threads for imbalance pulls
[ Upstream commit
9bcb959d05eeb564dfc9cac13a59843a4fb2edf2 ]
During load balance, LBF_SOME_PINNED will be set if any candidate task
cannot be detached due to CPU affinity constraints. This can result in
setting env->sd->parent->sgc->group_imbalance, which can lead to a group
being classified as group_imbalanced (rather than any of the other, lower
group_type) when balancing at a higher level.
In workloads involving a single task per CPU, LBF_SOME_PINNED can often be
set due to per-CPU kthreads being the only other runnable tasks on any
given rq. This results in changing the group classification during
load-balance at higher levels when in reality there is nothing that can be
done for this affinity constraint: per-CPU kthreads, as the name implies,
don't get to move around (modulo hotplug shenanigans).
It's not as clear for userspace tasks - a task could be in an N-CPU cpuset
with N-1 offline CPUs, making it an "accidental" per-CPU task rather than
an intended one. KTHREAD_IS_PER_CPU gives us an indisputable signal which
we can leverage here to not set LBF_SOME_PINNED.
Note that the aforementioned classification to group_imbalance (when
nothing can be done) is especially problematic on big.LITTLE systems, which
have a topology the likes of:
DIE [ ]
MC [ ][ ]
0 1 2 3
L L B B
arch_scale_cpu_capacity(L) < arch_scale_cpu_capacity(B)
Here, setting LBF_SOME_PINNED due to a per-CPU kthread when balancing at MC
level on CPUs [0-1] will subsequently prevent CPUs [2-3] from classifying
the [0-1] group as group_misfit_task when balancing at DIE level. Thus, if
CPUs [0-1] are running CPU-bound (misfit) tasks, ill-timed per-CPU kthreads
can significantly delay the upgmigration of said misfit tasks. Systems
relying on ASYM_PACKING are likely to face similar issues.
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
[Use kthread_is_per_cpu() rather than p->nr_cpus_allowed]
[Reword changelog]
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20210407220628.3798191-2-valentin.schneider@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans Verkuil [Thu, 8 Apr 2021 10:31:20 +0000 (12:31 +0200)]
media: gscpa/stv06xx: fix memory leak
[ Upstream commit
4f4e6644cd876c844cdb3bea2dd7051787d5ae25 ]
For two of the supported sensors the stv06xx driver allocates memory which
is stored in sd->sensor_priv. This memory is freed on a disconnect, but if
the probe() fails, then it isn't freed and so this leaks memory.
Add a new probe_error() op that drivers can use to free any allocated
memory in case there was a probe failure.
Thanks to Pavel Skripkin <paskripkin@gmail.com> for discovering the cause
of the memory leak.
Reported-and-tested-by: syzbot+e7f4c64a4248a0340c37@syzkaller.appspotmail.com
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Sun, 28 Mar 2021 19:32:19 +0000 (21:32 +0200)]
media: dvb-usb: fix memory leak in dvb_usb_adapter_init
[ Upstream commit
b7cd0da982e3043f2eec7235ac5530cb18d6af1d ]
syzbot reported memory leak in dvb-usb. The problem was
in invalid error handling in dvb_usb_adapter_init().
for (n = 0; n < d->props.num_adapters; n++) {
....
if ((ret = dvb_usb_adapter_stream_init(adap)) ||
(ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs)) ||
(ret = dvb_usb_adapter_frontend_init(adap))) {
return ret;
}
...
d->num_adapters_initialized++;
...
}
In case of error in dvb_usb_adapter_dvb_init() or
dvb_usb_adapter_dvb_init() d->num_adapters_initialized won't be
incremented, but dvb_usb_adapter_exit() relies on it:
for (n = 0; n < d->num_adapters_initialized; n++)
So, allocated objects won't be freed.
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Reported-by: syzbot+3c2be7424cea3b932b0e@syzkaller.appspotmail.com
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinghao Liu [Wed, 7 Apr 2021 05:46:06 +0000 (07:46 +0200)]
media: sun8i-di: Fix runtime PM imbalance in deinterlace_start_streaming
[ Upstream commit
f1995d5e43cf897f63b4d7a7f84a252d891ae820 ]
pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinghao Liu [Wed, 7 Apr 2021 05:43:13 +0000 (07:43 +0200)]
media: platform: sti: Fix runtime PM imbalance in regs_show
[ Upstream commit
69306a947b3ae21e0d1cbfc9508f00fec86c7297 ]
pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 6 Apr 2021 13:50:53 +0000 (15:50 +0200)]
media: i2c: adv7842: fix possible use-after-free in adv7842_remove()
[ Upstream commit
4a15275b6a18597079f18241c87511406575179a ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 6 Apr 2021 13:49:45 +0000 (15:49 +0200)]
media: i2c: tda1997: Fix possible use-after-free in tda1997x_remove()
[ Upstream commit
7f820ab5d4eebfe2d970d32a76ae496a6c286f0f ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 6 Apr 2021 13:48:12 +0000 (15:48 +0200)]
media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove()
[ Upstream commit
2c9541720c66899adf6f3600984cf3ef151295ad ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 6 Apr 2021 13:42:46 +0000 (15:42 +0200)]
media: adv7604: fix possible use-after-free in adv76xx_remove()
[ Upstream commit
fa56f5f1fe31c2050675fa63b84963ebd504a5b3 ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 6 Apr 2021 13:39:29 +0000 (15:39 +0200)]
media: tc358743: fix possible use-after-free in tc358743_remove()
[ Upstream commit
6107a4fdf8554a7aa9488bdc835bb010062fa8a9 ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Apr 2021 09:19:03 +0000 (17:19 +0800)]
power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove()
[ Upstream commit
68ae256945d2abe9036a7b68af4cc65aff79d5b7 ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Apr 2021 09:17:06 +0000 (17:17 +0800)]
power: supply: generic-adc-battery: fix possible use-after-free in gab_remove()
[ Upstream commit
b6cfa007b3b229771d9588970adb4ab3e0487f49 ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Tue, 6 Apr 2021 17:01:15 +0000 (18:01 +0100)]
clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return
[ Upstream commit
657d4d1934f75a2d978c3cf2086495eaa542e7a9 ]
There is an error return path that is not kfree'ing socfpga_clk leading
to a memory leak. Fix this by adding in the missing kfree call.
Addresses-Coverity: ("Resource leak")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210406170115.430990-1-colin.king@canonical.com
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Abhinav Kumar [Fri, 5 Mar 2021 19:17:18 +0000 (11:17 -0800)]
drm/msm/dp: Fix incorrect NULL check kbot warnings in DP driver
[ Upstream commit
7d649cfe0314aad2ba18042885ab9de2f13ad809 ]
Fix an incorrect NULL check reported by kbot in the MSM DP driver
smatch warnings:
drivers/gpu/drm/msm/dp/dp_hpd.c:37 dp_hpd_connect()
error: we previously assumed 'hpd_priv->dp_cb' could be null
(see line 37)
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1614971839-2686-2-git-send-email-abhinavk@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans Verkuil [Thu, 25 Mar 2021 07:48:21 +0000 (08:48 +0100)]
media: vivid: update EDID
[ Upstream commit
443ec4bbc6116f6f492a7a1282bfd8422c862158 ]
The EDID had a few mistakes as reported by edid-decode:
Block 1, CTA-861 Extension Block:
Video Data Block: For improved preferred timing interoperability, set 'Native detailed modes' to 1.
Video Capability Data Block: S_PT is equal to S_IT and S_CE, so should be set to 0 instead.
Fixed those.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Muhammad Usama Anjum [Wed, 24 Mar 2021 18:07:53 +0000 (19:07 +0100)]
media: em28xx: fix memory leak
[ Upstream commit
0ae10a7dc8992ee682ff0b1752ff7c83d472eef1 ]
If some error occurs, URB buffers should also be freed. If they aren't
freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB
buffers as dvb is set to NULL. The function in which error occurs should
do all the cleanup for the allocations it had done.
Tested the patch with the reproducer provided by syzbot. This patch
fixes the memleak.
Reported-by: syzbot+889397c820fa56adf25d@syzkaller.appspotmail.com
Signed-off-by: Muhammad Usama Anjum <musamaanjum@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ewan D. Milne [Wed, 31 Mar 2021 20:11:54 +0000 (16:11 -0400)]
scsi: scsi_dh_alua: Remove check for ASC 24h in alua_rtpg()
[ Upstream commit
bc3f2b42b70eb1b8576e753e7d0e117bbb674496 ]
Some arrays return ILLEGAL_REQUEST with ASC 00h if they don't support the
RTPG extended header so remove the check for INVALID FIELD IN CDB.
Link: https://lore.kernel.org/r/20210331201154.20348-1-emilne@redhat.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kevin Barnett [Thu, 11 Mar 2021 20:17:48 +0000 (14:17 -0600)]
scsi: smartpqi: Add new PCI IDs
[ Upstream commit
75fbeacca3ad30835e903002dba98dd909b4dfff ]
Add support for newer hardware.
Link: https://lore.kernel.org/r/161549386882.25025.2594251735886014958.stgit@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Acked-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Murthy Bhat [Thu, 11 Mar 2021 20:15:03 +0000 (14:15 -0600)]
scsi: smartpqi: Correct request leakage during reset operations
[ Upstream commit
b622a601a13ae5974c5b0aeecb990c224b8db0d9 ]
While failing queued I/Os in TMF path, there was a request leak and hence
stale entries in request pool with ref count being non-zero. In shutdown
path we have a BUG_ON to catch stuck I/O either in firmware or in the
driver. The stale requests caused a system crash. The I/O request pool
leakage also lead to a significant performance drop.
Link: https://lore.kernel.org/r/161549370379.25025.12793264112620796062.stgit@brunhilda
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Murthy Bhat <Murthy.Bhat@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Don Brace [Thu, 11 Mar 2021 20:14:57 +0000 (14:14 -0600)]
scsi: smartpqi: Use host-wide tag space
[ Upstream commit
c6d3ee209b9e863c6251f72101511340451ca324 ]
Correct SCSI midlayer sending more requests than exposed host queue depth
causing firmware ASSERT and lockup issues by enabling host-wide tags.
Note: This also results in better performance.
Link: https://lore.kernel.org/r/161549369787.25025.8975999483518581619.stgit@brunhilda
Suggested-by: Ming Lei <ming.lei@redhat.com>
Suggested-by: John Garry <john.garry@huawei.com>
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Carl Philipp Klemm [Sun, 17 Jan 2021 21:48:53 +0000 (22:48 +0100)]
power: supply: cpcap-charger: Add usleep to cpcap charger to avoid usb plug bounce
[ Upstream commit
751faedf06e895a17e985a88ef5b6364ffd797ed ]
Adds 80000 us sleep when the usb cable is plugged in to hopefully avoid
bouncing contacts.
Upon pluging in the usb cable vbus will bounce for some time, causing cpcap to
dissconnect charging due to detecting an undervoltage condition. This is a
scope of vbus on xt894 while quickly inserting the usb cable with firm force,
probed at the far side of the usb socket and vbus loaded with approx 1k:
http://uvos.xyz/maserati/usbplug.jpg.
As can clearly be seen, vbus is all over the place for the first 15 ms or so
with a small blip at ~40 ms this causes the cpcap to trip up and disable
charging again.
The delay helps cpcap_usb_detect avoid the worst of this. It is, however, still
not ideal as strong vibrations can cause the issue to reapear any time during
charging. I have however not been able to cause the device to stop charging due
to this in practice as it is hard to vibrate the device such that the vbus pins
start bouncing again but cpcap_usb_detect is not called again due to a detected
disconnect/reconnect event.
Signed-off-by: Carl Philipp Klemm <philipp@uvos.xyz>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:54 +0000 (02:22 +0000)]
selftests/resctrl: Fix checking for < 0 for unsigned values
[ Upstream commit
1205b688c92558a04d8dd4cbc2b213e0fceba5db ]
Dan reported following static checker warnings
tools/testing/selftests/resctrl/resctrl_val.c:545 measure_vals()
warn: 'bw_imc' unsigned <= 0
tools/testing/selftests/resctrl/resctrl_val.c:549 measure_vals()
warn: 'bw_resc_end' unsigned <= 0
These warnings are reported because
1. measure_vals() declares 'bw_imc' and 'bw_resc_end' as unsigned long
variables
2. Return value of get_mem_bw_imc() and get_mem_bw_resctrl() are assigned
to 'bw_imc' and 'bw_resc_end' respectively
3. The returned values are checked for <= 0 to see if the calls failed
Checking for < 0 for an unsigned value doesn't make any sense.
Fix this issue by changing the implementation of get_mem_bw_imc() and
get_mem_bw_resctrl() such that they now accept reference to a variable
and set the variable appropriately upon success and return 0, else return
< 0 on error.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:53 +0000 (02:22 +0000)]
selftests/resctrl: Fix incorrect parsing of iMC counters
[ Upstream commit
d81343b5eedf84be71a4313e8fd073d0c510afcf ]
iMC (Integrated Memory Controller) counters are usually at
"/sys/bus/event_source/devices/" and are named as "uncore_imc_<n>".
num_of_imcs() function tries to count number of such iMC counters so that
it could appropriately initialize required number of perf_attr structures
that could be used to read these iMC counters.
num_of_imcs() function assumes that all the directories under this path
that start with "uncore_imc" are iMC counters. But, on some systems there
could be directories named as "uncore_imc_free_running" which aren't iMC
counters. Trying to read from such directories will result in "not found
file" errors and MBM/MBA tests will fail.
Hence, fix the logic in num_of_imcs() such that it looks at the first
character after "uncore_imc_" to check if it's a numerical digit or not. If
it's a digit then the directory represents an iMC counter, else, skip the
directory.
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:47 +0000 (02:22 +0000)]
selftests/resctrl: Use resctrl/info for feature detection
[ Upstream commit
ee0415681eb661efa1eb2db7acc263f2c7df1e23 ]
Resctrl test suite before running any unit test (like cmt, cat, mbm and
mba) should first check if the feature is enabled (by kernel and not just
supported by H/W) on the platform or not.
validate_resctrl_feature_request() is supposed to do that. This function
intends to grep for relevant flags in /proc/cpuinfo but there are several
issues here
1. validate_resctrl_feature_request() calls fgrep() to get flags from
/proc/cpuinfo. But, fgrep() can only return a string with maximum of 255
characters and hence the complete cpu flags are never returned.
2. The substring search logic is also busted. If strstr() finds requested
resctrl feature in the cpu flags, it returns pointer to the first
occurrence. But, the logic negates the return value of strstr() and
hence validate_resctrl_feature_request() returns false if the feature is
present in the cpu flags and returns true if the feature is not present.
3. validate_resctrl_feature_request() checks if a resctrl feature is
reported in /proc/cpuinfo flags or not. Having a cpu flag means that the
H/W supports the feature, but it doesn't mean that the kernel enabled
it. A user could selectively enable only a subset of resctrl features
using kernel command line arguments. Hence, /proc/cpuinfo isn't a
reliable source to check if a feature is enabled or not.
The 3rd issue being the major one and fixing it requires changing the way
validate_resctrl_feature_request() works. Since, /proc/cpuinfo isn't the
right place to check if a resctrl feature is enabled or not, a more
appropriate place is /sys/fs/resctrl/info directory. Change
validate_resctrl_feature_request() such that,
1. For cat, check if /sys/fs/resctrl/info/L3 directory is present or not
2. For mba, check if /sys/fs/resctrl/info/MB directory is present or not
3. For cmt, check if /sys/fs/resctrl/info/L3_MON directory is present and
check if /sys/fs/resctrl/info/L3_MON/mon_features has llc_occupancy
4. For mbm, check if /sys/fs/resctrl/info/L3_MON directory is present and
check if /sys/fs/resctrl/info/L3_MON/mon_features has
mbm_<total/local>_bytes
Please note that only L3_CAT, L3_CMT, MBA and MBM are supported. CDP and L2
variants can be added later.
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:40 +0000 (02:22 +0000)]
selftests/resctrl: Fix missing options "-n" and "-p"
[ Upstream commit
d7af3d0d515cbdf63b6c3398a3c15ecb1bc2bd38 ]
resctrl test suite accepts command line arguments (like -b, -t, -n and -p)
as documented in the help. But passing -n and -p throws an invalid option
error. This happens because -n and -p are missing in the list of
characters that getopt() recognizes as valid arguments. Hence, they are
treated as invalid options.
Fix this by adding them to the list of characters that getopt() recognizes
as valid arguments. Please note that the main() function already has the
logic to deal with the values passed as part of these arguments and hence
no changes are needed there.
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:38 +0000 (02:22 +0000)]
selftests/resctrl: Clean up resctrl features check
[ Upstream commit
2428673638ea28fa93d2a38b1c3e8d70122b00ee ]
Checking resctrl features call strcmp() to compare feature strings
(e.g. "mba", "cat" etc). The checkings are error prone and don't have
good coding style. Define the constant strings in macros and call
strncmp() to solve the potential issues.
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:37 +0000 (02:22 +0000)]
selftests/resctrl: Fix compilation issues for other global variables
[ Upstream commit
896016d2ad051811ff9c9c087393adc063322fbc ]
Reinette reported following compilation issue on Fedora 32, gcc version
10.1.1
/usr/bin/ld: resctrl_tests.o:<src_dir>/resctrl.h:65: multiple definition
of `bm_pid'; cache.o:<src_dir>/resctrl.h:65: first defined here
Other variables are ppid, tests_run, llc_occup_path, is_amd. Compiler
isn't happy because these variables are defined globally in two .c files
but are not declared as extern.
To fix issues for the global variables, declare them as extern.
Chang Log:
- Split this patch from v4's patch 1 (Shuah).
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:36 +0000 (02:22 +0000)]
selftests/resctrl: Fix compilation issues for global variables
[ Upstream commit
8236c51d85a64643588505a6791e022cc8d84864 ]
Reinette reported following compilation issue on Fedora 32, gcc version
10.1.1
/usr/bin/ld: cqm_test.o:<src_dir>/cqm_test.c:22: multiple definition of
`cache_size'; cat_test.o:<src_dir>/cat_test.c:23: first defined here
The same issue is reported for long_mask, cbm_mask, count_of_bits etc
variables as well. Compiler isn't happy because these variables are
defined globally in two .c files namely cqm_test.c and cat_test.c and
the compiler during compilation finds that the variable is already
defined (multiple definition error).
Taking a closer look at the usage of these variables reveals that these
variables are used only locally in functions such as cqm_resctrl_val()
(defined in cqm_test.c) and cat_perf_miss_val() (defined in cat_test.c).
These variables are not shared between those functions. So, there is no
need for these variables to be global. Hence, fix this issue by making
them static variables.
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fenghua Yu [Wed, 17 Mar 2021 02:22:35 +0000 (02:22 +0000)]
selftests/resctrl: Enable gcc checks to detect buffer overflows
[ Upstream commit
a9d26a302dea29eb84f491b1340a57e56c631a71 ]
David reported a buffer overflow error in the check_results() function of
the cmt unit test and he suggested enabling _FORTIFY_SOURCE gcc compiler
option to automatically detect any such errors.
Feature Test Macros man page describes_FORTIFY_SOURCE as below
"Defining this macro causes some lightweight checks to be performed to
detect some buffer overflow errors when employing various string and memory
manipulation functions (for example, memcpy, memset, stpcpy, strcpy,
strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, gets, and
wide character variants thereof). For some functions, argument consistency
is checked; for example, a check is made that open has been supplied with a
mode argument when the specified flags include O_CREAT. Not all problems
are detected, just some common cases.
If _FORTIFY_SOURCE is set to 1, with compiler optimization level 1 (gcc
-O1) and above, checks that shouldn't change the behavior of conforming
programs are performed.
With _FORTIFY_SOURCE set to 2, some more checking is added, but some
conforming programs might fail.
Some of the checks can be performed at compile time (via macros logic
implemented in header files), and result in compiler warnings; other checks
take place at run time, and result in a run-time error if the check fails.
Use of this macro requires compiler support, available with gcc since
version 4.0."
Fix the buffer overflow error in the check_results() function of the cmt
unit test and enable _FORTIFY_SOURCE gcc check to catch any future buffer
overflow errors.
Reported-by: David Binderman <dcb314@hotmail.com>
Suggested-by: David Binderman <dcb314@hotmail.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hou Pu [Wed, 31 Mar 2021 06:52:39 +0000 (14:52 +0800)]
nvmet: return proper error code from discovery ctrl
[ Upstream commit
79695dcd9ad4463a82def7f42960e6d7baa76f0b ]
Return NVME_SC_INVALID_FIELD from discovery controller like normal
controller when executing identify or get log page command.
Signed-off-by: Hou Pu <houpu.main@gmail.com>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Carsten Haitzler [Thu, 4 Feb 2021 13:11:02 +0000 (13:11 +0000)]
drm/komeda: Fix bit check to import to value of proper type
[ Upstream commit
be3e477effba636ad25dcd244db264c6cd5c1f36 ]
KASAN found this problem. find_first_bit() expects to look at a
pointer pointing to a long, but we look at a u32 - this is going to be
an issue with endianness but, KSAN already flags this as out-of-bounds
stack reads. This fixes it by just importing inot a local long.
Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201218150812.68195-1-carsten.haitzler@foss.arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xingui Yang [Fri, 12 Mar 2021 10:24:36 +0000 (18:24 +0800)]
ata: ahci: Disable SXS for Hisilicon Kunpeng920
[ Upstream commit
234e6d2c18f5b080cde874483c4c361f3ae7cffe ]
On Hisilicon Kunpeng920, ESP is set to 1 by default for all ports of
SATA controller. In some scenarios, some ports are not external SATA ports,
and it cause disks connected to these ports to be identified as removable
disks. So disable the SXS capability on the software side to prevent users
from mistakenly considering non-removable disks as removable disks and
performing related operations.
Signed-off-by: Xingui Yang <yangxingui@huawei.com>
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com>
Reviewed-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1615544676-61926-1-git-send-email-luojiaxing@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Al Cooper [Thu, 25 Mar 2021 19:28:34 +0000 (15:28 -0400)]
mmc: sdhci-brcmstb: Remove CQE quirk
[ Upstream commit
f0bdf98fab058efe7bf49732f70a0f26d1143154 ]
Remove the CQHCI_QUIRK_SHORT_TXFR_DESC_SZ quirk because the
latest chips have this fixed and earlier chips have other
CQE problems that prevent the feature from being enabled.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20210325192834.42955-1-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Adrian Hunter [Mon, 22 Mar 2021 05:53:56 +0000 (07:53 +0200)]
mmc: sdhci-pci: Add PCI IDs for Intel LKF
[ Upstream commit
ee629112be8b4eff71d4d3d108a28bc7dc877e13 ]
Add PCI IDs for Intel LKF eMMC and SD card host controllers.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20210322055356.24923-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peng Fan [Thu, 25 Feb 2021 03:10:04 +0000 (11:10 +0800)]
mmc: sdhci-esdhc-imx: validate pinctrl before use it
[ Upstream commit
f410ee0aa2df050a9505f5c261953e9b18e21206 ]
When imx_data->pinctrl is not a valid pointer, pinctrl_lookup_state
will trigger kernel panic.
When we boot Dual OS on Jailhouse hypervisor, we let the 1st Linux to
configure pinmux ready for the 2nd OS, so the 2nd OS not have pinctrl
settings.
Similar to this commit
b62eee9f804e ("mmc: sdhci-esdhc-imx: no fail when no pinctrl available").
Reviewed-by: Bough Chen <haobo.chen@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1614222604-27066-6-git-send-email-peng.fan@oss.nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Quinn Tran [Mon, 29 Mar 2021 08:52:22 +0000 (01:52 -0700)]
scsi: qla2xxx: Fix use after free in bsg
[ Upstream commit
2ce35c0821afc2acd5ee1c3f60d149f8b2520ce8 ]
On bsg command completion, bsg_job_done() was called while qla driver
continued to access the bsg_job buffer. bsg_job_done() would free up
resources that ended up being reused by other task while the driver
continued to access the buffers. As a result, driver was reading garbage
data.
localhost kernel: BUG: KASAN: use-after-free in sg_next+0x64/0x80
localhost kernel: Read of size 8 at addr
ffff8883228a3330 by task swapper/26/0
localhost kernel:
localhost kernel: CPU: 26 PID: 0 Comm: swapper/26 Kdump:
loaded Tainted: G OE --------- - - 4.18.0-193.el8.x86_64+debug #1
localhost kernel: Hardware name: HP ProLiant DL360
Gen9/ProLiant DL360 Gen9, BIOS P89 08/12/2016
localhost kernel: Call Trace:
localhost kernel: <IRQ>
localhost kernel: dump_stack+0x9a/0xf0
localhost kernel: print_address_description.cold.3+0x9/0x23b
localhost kernel: kasan_report.cold.4+0x65/0x95
localhost kernel: debug_dma_unmap_sg.part.12+0x10d/0x2d0
localhost kernel: qla2x00_bsg_sp_free+0xaf6/0x1010 [qla2xxx]
Link: https://lore.kernel.org/r/20210329085229.4367-6-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Vyukov [Sat, 20 Mar 2021 13:28:40 +0000 (14:28 +0100)]
drm/vkms: fix misuse of WARN_ON
[ Upstream commit
b4142fc4d52d051d4d8df1fb6c569e5b445d369e ]
vkms_vblank_simulate() uses WARN_ON for timing-dependent condition
(timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used
to denote kernel bugs. Use pr_warn() instead.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+4fc21a003c8332eb0bdd@syzkaller.appspotmail.com
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Melissa Wen <melissa.srw@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320132840.1315853-1-dvyukov@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Sat, 20 Mar 2021 23:23:58 +0000 (16:23 -0700)]
scsi: qla2xxx: Always check the return value of qla24xx_get_isp_stats()
[ Upstream commit
a2b2cc660822cae08c351c7f6b452bfd1330a4f7 ]
This patch fixes the following Coverity warning:
CID 361199 (#1 of 1): Unchecked return value (CHECKED_RETURN)
3. check_return: Calling qla24xx_get_isp_stats without checking return
value (as is done elsewhere 4 out of 5 times).
Link: https://lore.kernel.org/r/20210320232359.941-7-bvanassche@acm.org
Cc: Quinn Tran <qutran@marvell.com>
Cc: Mike Christie <michael.christie@oracle.com>
Cc: Himanshu Madhani <himanshu.madhani@oracle.com>
Cc: Daniel Wagner <dwagner@suse.de>
Cc: Lee Duncan <lduncan@suse.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmytro Laktyushkin [Thu, 4 Mar 2021 16:04:26 +0000 (11:04 -0500)]
drm/amd/display: fix dml prefetch validation
[ Upstream commit
8ee0fea4baf90e43efe2275de208a7809f9985bc ]
Incorrect variable used, missing initialization during validation.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aric Cyr [Mon, 8 Mar 2021 20:43:34 +0000 (15:43 -0500)]
drm/amd/display: DCHUB underflow counter increasing in some scenarios
[ Upstream commit
4710430a779e6077d81218ac768787545bff8c49 ]
[Why]
When unplugging a display, the underflow counter can be seen to
increase because PSTATE switch is allowed even when some planes are not
blanked.
[How]
Check that all planes are not active instead of all streams before
allowing PSTATE change.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anson Jacob [Tue, 2 Mar 2021 21:16:36 +0000 (16:16 -0500)]
drm/amd/display: Fix UBSAN warning for not a valid value for type '_Bool'
[ Upstream commit
6a30a92997eee49554f72b462dce90abe54a496f ]
[Why]
dc_cursor_position do not initialise position.translate_by_source when
crtc or plane->state->fb is NULL. UBSAN caught this error in
dce110_set_cursor_position, as the value was garbage.
[How]
Initialise dc_cursor_position structure elements to 0 in handle_cursor_update
before calling get_cursor_position.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1471
Reported-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
Reviewed-by: Aurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kenneth Feng [Tue, 16 Mar 2021 02:28:00 +0000 (10:28 +0800)]
drm/amd/pm: fix workload mismatch on vega10
[ Upstream commit
0979d43259e13846d86ba17e451e17fec185d240 ]
Workload number mapped to the correct one.
This issue is only on vega10.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
shaoyunl [Tue, 9 Mar 2021 15:30:15 +0000 (10:30 -0500)]
drm/amdgpu : Fix asic reset regression issue introduce by
8f211fe8ac7c4f
[ Upstream commit
c8941550aa66b2a90f4b32c45d59e8571e33336e ]
This recent change introduce SDMA interrupt info printing with irq->process function.
These functions do not require a set function to enable/disable the irq
Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anson Jacob [Wed, 3 Mar 2021 17:33:15 +0000 (12:33 -0500)]
drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
[ Upstream commit
50e2fc36e72d4ad672032ebf646cecb48656efe0 ]
If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.
Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
Reported-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Tested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Kim [Wed, 27 Jan 2021 20:24:59 +0000 (15:24 -0500)]
drm/amdgpu: mask the xgmi number of hops reported from psp to kfd
[ Upstream commit
4ac5617c4b7d0f0a8f879997f8ceaa14636d7554 ]
The psp supplies the link type in the upper 2 bits of the psp xgmi node
information num_hops field. With a new link type, Aldebaran has these
bits set to a non-zero value (1 = xGMI3) so the KFD topology will report
the incorrect IO link weights without proper masking.
The actual number of hops is located in the 3 least significant bits of
this field so mask if off accordingly before passing it to the KFD.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com>
Reviewed-by: Amber Lin <amber.lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kiran Gunda [Thu, 18 Mar 2021 12:39:39 +0000 (18:09 +0530)]
backlight: qcom-wled: Fix FSC update issue for WLED5
[ Upstream commit
4d6e9cdff7fbb6bef3e5559596fab3eeffaf95ca ]
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adopting the common wled3_sync_toggle() for WLED5 and
introducing new code to the brightness update path to compensate.
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Obeida Shamoun [Sun, 14 Mar 2021 10:11:10 +0000 (11:11 +0100)]
backlight: qcom-wled: Use sink_addr for sync toggle
[ Upstream commit
cdfd4c689e2a52c313b35ddfc1852ff274f91acb ]
WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset.
Therefore, use the sink address as base instead of the ctrl address.
This fixes the sync toggle on wled4, which can be observed by the fact
that adjusting brightness now works.
It has no effect on wled3 because sink and ctrl base addresses are the
same. This allows adjusting the brightness without having to disable
then reenable the module.
Signed-off-by: Obeida Shamoun <oshmoun100@googlemail.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
dongjian [Mon, 22 Mar 2021 11:21:33 +0000 (19:21 +0800)]
power: supply: Use IRQF_ONESHOT
[ Upstream commit
2469b836fa835c67648acad17d62bc805236a6ea ]
Fixes coccicheck error:
drivers/power/supply/pm2301_charger.c:1089:7-27: ERROR:
drivers/power/supply/lp8788-charger.c:502:8-28: ERROR:
drivers/power/supply/tps65217_charger.c:239:8-33: ERROR:
drivers/power/supply/tps65090-charger.c:303:8-33: ERROR:
Threaded IRQ with no primary handler requested without IRQF_ONESHOT
Signed-off-by: dongjian <dongjian@yulong.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans Verkuil [Thu, 11 Mar 2021 14:46:40 +0000 (15:46 +0100)]
media: gspca/sq905.c: fix uninitialized variable
[ Upstream commit
eaaea4681984c79d2b2b160387b297477f0c1aab ]
act_len can be uninitialized if usb_bulk_msg() returns an error.
Set it to 0 to avoid a KMSAN error.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Niv [Thu, 11 Mar 2021 02:53:00 +0000 (03:53 +0100)]
media: media/saa7164: fix saa7164_encoder_register() memory leak bugs
[ Upstream commit
c759b2970c561e3b56aa030deb13db104262adfe ]
Add a fix for the memory leak bugs that can occur when the
saa7164_encoder_register() function fails.
The function allocates memory without explicitly freeing
it when errors occur.
Add a better error handling that deallocate the unused buffers before the
function exits during a fail.
Signed-off-by: Daniel Niv <danielniv3@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 7 Mar 2021 15:17:57 +0000 (16:17 +0100)]
extcon: arizona: Fix various races on driver unbind
[ Upstream commit
e5b499f6fb17bc95a813e85d0796522280203806 ]
We must free/disable all interrupts and cancel all pending works
before doing further cleanup.
Before this commit arizona_extcon_remove() was doing several
register writes to shut things down before disabling the IRQs
and it was cancelling only 1 of the 3 different works used.
Move all the register-writes shutting things down to after
the disabling of the IRQs and add the 2 missing
cancel_delayed_work_sync() calls.
This fixes various possible races on driver unbind. One of which
would always trigger on devices using the mic-clamp feature for
jack detection. The ARIZONA_MICD_CLAMP_MODE_MASK update was
done before disabling the IRQs, causing:
1. arizona_jackdet() to run
2. detect a jack being inserted (clamp disabled means jack inserted)
3. call arizona_start_mic() which:
3.1 Enables the MICVDD regulator
3.2 takes a pm_runtime_reference
And this was all happening after the ARIZONA_MICD_ENA bit clearing,
which would undo 3.1 and 3.2 because the ARIZONA_MICD_CLAMP_MODE_MASK
update was being done after the ARIZONA_MICD_ENA bit clearing.
So this means that arizona_extcon_remove() would exit with
1. MICVDD enabled and 2. The pm_runtime_reference being unbalanced.
MICVDD still being enabled caused the following oops when the
regulator is released by the devm framework:
[ 2850.745757] ------------[ cut here ]------------
[ 2850.745827] WARNING: CPU: 2 PID: 2098 at drivers/regulator/core.c:2123 _regulator_put.part.0+0x19f/0x1b0
[ 2850.745835] Modules linked in: extcon_arizona ...
...
[ 2850.746909] Call Trace:
[ 2850.746932] regulator_put+0x2d/0x40
[ 2850.746946] release_nodes+0x22a/0x260
[ 2850.746984] __device_release_driver+0x190/0x240
[ 2850.747002] driver_detach+0xd4/0x120
...
[ 2850.747337] ---[ end trace
f455dfd7abd9781f ]---
Note this oops is just one of various theoretically possible races caused
by the wrong ordering inside arizona_extcon_remove(), this fixes the
ordering fixing all possible races, including the reported oops.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 7 Mar 2021 15:17:56 +0000 (16:17 +0100)]
extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
[ Upstream commit
c309a3e8793f7e01c4a4ec7960658380572cb576 ]
When the jack is partially inserted and then removed again it may be
removed while the hpdet code is running. In this case the following
may happen:
1. The "JACKDET rise" or ""JACKDET fall" IRQ triggers
2. arizona_jackdet runs and takes info->lock
3. The "HPDET" IRQ triggers
4. arizona_hpdet_irq runs, blocks on info->lock
5. arizona_jackdet calls arizona_stop_mic() and clears info->hpdet_done
6. arizona_jackdet releases info->lock
7. arizona_hpdet_irq now can continue running and:
7.1 Calls arizona_start_mic() (if a mic was detected)
7.2 sets info->hpdet_done
Step 7 is undesirable / a bug:
7.1 causes the device to stay in a high power-state (with MICVDD enabled)
7.2 causes hpdet to not run on the next jack insertion, which in turn
causes the EXTCON_JACK_HEADPHONE state to never get set
This fixes both issues by skipping these 2 steps when arizona_hpdet_irq
runs after the jack has been unplugged.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthias Schiffer [Wed, 3 Mar 2021 09:54:19 +0000 (10:54 +0100)]
power: supply: bq27xxx: fix power_avg for newer ICs
[ Upstream commit
c4d57c22ac65bd503716062a06fad55a01569cac ]
On all newer bq27xxx ICs, the AveragePower register contains a signed
value; in addition to handling the raw value as unsigned, the driver
code also didn't convert it to µW as expected.
At least for the BQ28Z610, the reference manual incorrectly states that
the value is in units of 1mW and not 10mW. I have no way of knowing
whether the manuals of other supported ICs contain the same error, or if
there are models that actually use 1mW. At least, the new code shouldn't
be *less* correct than the old version for any device.
power_avg is removed from the cache structure, se we don't have to
extend it to store both a signed value and an error code. Always getting
an up-to-date value may be desirable anyways, as it avoids inconsistent
current and power readings when switching between charging and
discharging.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauro Carvalho Chehab [Fri, 12 Mar 2021 07:16:03 +0000 (08:16 +0100)]
atomisp: don't let it go past pipes array
[ Upstream commit
1f6c45ac5fd70ab59136ab5babc7def269f3f509 ]
In practice, IA_CSS_PIPE_ID_NUM should never be used when
calling atomisp_q_video_buffers_to_css(), as the driver should
discover the right pipe before calling it.
Yet, if some pipe parsing issue happens, it could end using
it.
So, add a WARN_ON() to prevent such case.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Laurent Pinchart [Mon, 15 Feb 2021 04:26:47 +0000 (05:26 +0100)]
media: imx: capture: Return -EPIPE from __capture_legacy_try_fmt()
[ Upstream commit
cc271b6754691af74d710b761eaf027e3743e243 ]
The correct return code to report an invalid pipeline configuration is
-EPIPE. Return it instead of -EINVAL from __capture_legacy_try_fmt()
when the capture format doesn't match the media bus format of the
connected subdev.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julian Braha [Thu, 25 Feb 2021 08:06:58 +0000 (09:06 +0100)]
media: drivers: media: pci: sta2x11: fix Kconfig dependency on GPIOLIB
[ Upstream commit
24df8b74c8b2fb42c49ffe8585562da0c96446ff ]
When STA2X11_VIP is enabled, and GPIOLIB is disabled,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for VIDEO_ADV7180
Depends on [n]: MEDIA_SUPPORT [=y] && GPIOLIB [=n] && VIDEO_V4L2 [=y] && I2C [=y]
Selected by [y]:
- STA2X11_VIP [=y] && MEDIA_SUPPORT [=y] && MEDIA_PCI_SUPPORT [=y] && MEDIA_CAMERA_SUPPORT [=y] && PCI [=y] && VIDEO_V4L2 [=y] && VIRT_TO_BUS [=y] && I2C [=y] && (STA2X11 [=n] || COMPILE_TEST [=y]) && MEDIA_SUBDRV_AUTOSELECT [=y]
This is because STA2X11_VIP selects VIDEO_ADV7180
without selecting or depending on GPIOLIB,
despite VIDEO_ADV7180 depending on GPIOLIB.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Young [Mon, 22 Feb 2021 08:08:35 +0000 (09:08 +0100)]
media: ite-cir: check for receive overflow
[ Upstream commit
28c7afb07ccfc0a939bb06ac1e7afe669901c65a ]
It's best if this condition is reported.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chaitanya Kulkarni [Sun, 28 Feb 2021 05:56:26 +0000 (21:56 -0800)]
scsi: target: pscsi: Fix warning in pscsi_complete_cmd()
[ Upstream commit
fd48c056a32ed6e7754c7c475490f3bed54ed378 ]
This fixes a compilation warning in pscsi_complete_cmd():
drivers/target/target_core_pscsi.c: In function ‘pscsi_complete_cmd’:
drivers/target/target_core_pscsi.c:624:5: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */
Link: https://lore.kernel.org/r/20210228055645.22253-5-chaitanya.kulkarni@wdc.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Uladzislau Rezki (Sony) [Fri, 29 Jan 2021 20:05:05 +0000 (21:05 +0100)]
kvfree_rcu: Use same set of GFP flags as does single-argument
[ Upstream commit
ee6ddf58475cce8a3d3697614679cd8cb4a6f583 ]
Running an rcuscale stress-suite can lead to "Out of memory" of a
system. This can happen under high memory pressure with a small amount
of physical memory.
For example, a KVM test configuration with 64 CPUs and 512 megabytes
can result in OOM when running rcuscale with below parameters:
../kvm.sh --torture rcuscale --allcpus --duration 10 --kconfig CONFIG_NR_CPUS=64 \
--bootargs "rcuscale.kfree_rcu_test=1 rcuscale.kfree_nthreads=16 rcuscale.holdoff=20 \
rcuscale.kfree_loops=10000 torture.disable_onoff_at_boot" --trust-make
<snip>
[ 12.054448] kworker/1:1H invoked oom-killer: gfp_mask=0x2cc0(GFP_KERNEL|__GFP_NOWARN), order=0, oom_score_adj=0
[ 12.055303] CPU: 1 PID: 377 Comm: kworker/1:1H Not tainted 5.11.0-rc3+ #510
[ 12.055416] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014
[ 12.056485] Workqueue: events_highpri fill_page_cache_func
[ 12.056485] Call Trace:
[ 12.056485] dump_stack+0x57/0x6a
[ 12.056485] dump_header+0x4c/0x30a
[ 12.056485] ? del_timer_sync+0x20/0x30
[ 12.056485] out_of_memory.cold.47+0xa/0x7e
[ 12.056485] __alloc_pages_slowpath.constprop.123+0x82f/0xc00
[ 12.056485] __alloc_pages_nodemask+0x289/0x2c0
[ 12.056485] __get_free_pages+0x8/0x30
[ 12.056485] fill_page_cache_func+0x39/0xb0
[ 12.056485] process_one_work+0x1ed/0x3b0
[ 12.056485] ? process_one_work+0x3b0/0x3b0
[ 12.060485] worker_thread+0x28/0x3c0
[ 12.060485] ? process_one_work+0x3b0/0x3b0
[ 12.060485] kthread+0x138/0x160
[ 12.060485] ? kthread_park+0x80/0x80
[ 12.060485] ret_from_fork+0x22/0x30
[ 12.062156] Mem-Info:
[ 12.062350] active_anon:0 inactive_anon:0 isolated_anon:0
[ 12.062350] active_file:0 inactive_file:0 isolated_file:0
[ 12.062350] unevictable:0 dirty:0 writeback:0
[ 12.062350] slab_reclaimable:2797 slab_unreclaimable:80920
[ 12.062350] mapped:1 shmem:2 pagetables:8 bounce:0
[ 12.062350] free:10488 free_pcp:1227 free_cma:0
...
[ 12.101610] Out of memory and no killable processes...
[ 12.102042] Kernel panic - not syncing: System is deadlocked on memory
[ 12.102583] CPU: 1 PID: 377 Comm: kworker/1:1H Not tainted 5.11.0-rc3+ #510
[ 12.102600] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014
<snip>
Because kvfree_rcu() has a fallback path, memory allocation failure is
not the end of the world. Furthermore, the added overhead of aggressive
GFP settings must be balanced against the overhead of the fallback path,
which is a cache miss for double-argument kvfree_rcu() and a call to
synchronize_rcu() for single-argument kvfree_rcu(). The current choice
of GFP_KERNEL|__GFP_NOWARN can result in longer latencies than a call
to synchronize_rcu(), so less-tenacious GFP flags would be helpful.
Here is the tradeoff that must be balanced:
a) Minimize use of the fallback path,
b) Avoid pushing the system into OOM,
c) Bound allocation latency to that of synchronize_rcu(), and
d) Leave the emergency reserves to use cases lacking fallbacks.
This commit therefore changes GFP flags from GFP_KERNEL|__GFP_NOWARN to
GFP_KERNEL|__GFP_NORETRY|__GFP_NOMEMALLOC|__GFP_NOWARN. This combination
leaves the emergency reserves alone and can initiate reclaim, but will
not invoke the OOM killer.
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vincent Donnefort [Thu, 25 Feb 2021 16:58:20 +0000 (16:58 +0000)]
sched/pelt: Fix task util_est update filtering
[ Upstream commit
b89997aa88f0b07d8a6414c908af75062103b8c9 ]
Being called for each dequeue, util_est reduces the number of its updates
by filtering out when the EWMA signal is different from the task util_avg
by less than 1%. It is a problem for a sudden util_avg ramp-up. Due to the
decay from a previous high util_avg, EWMA might now be close enough to
the new util_avg. No update would then happen while it would leave
ue.enqueued with an out-of-date value.
Taking into consideration the two util_est members, EWMA and enqueued for
the filtering, ensures, for both, an up-to-date value.
This is for now an issue only for the trace probe that might return the
stale value. Functional-wise, it isn't a problem, as the value is always
accessed through max(enqueued, ewma).
This problem has been observed using LISA's UtilConvergence:test_means on
the sd845c board.
No regression observed with Hackbench on sd845c and Perf-bench sched pipe
on hikey/hikey960.
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20210225165820.1377125-1-vincent.donnefort@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Emily Deng [Thu, 4 Mar 2021 11:30:51 +0000 (19:30 +0800)]
drm/amdgpu: Fix some unload driver issues
[ Upstream commit
bb0cd09be45ea457f25fdcbcb3d6cf2230f26c46 ]
When unloading driver after killing some applications, it will hit sdma
flush tlb job timeout which is called by ttm_bo_delay_delete. So
to avoid the job submit after fence driver fini, call ttm_bo_lock_delayed_workqueue
before fence driver fini. And also put drm_sched_fini before waiting fence.
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Mon, 1 Mar 2021 17:18:06 +0000 (09:18 -0800)]
scsi: lpfc: Fix pt2pt connection does not recover after LOGO
[ Upstream commit
bd4f5100424d17d4e560d6653902ef8e49b2fc1f ]
On a pt2pt setup, between 2 initiators, if one side issues a a LOGO, there
is no relogin attempt. The FC specs are grey in this area on which port
(higher wwn or not) is to re-login.
As there is no spec guidance, unconditionally re-PLOGI after the logout to
ensure a login is re-established.
Link: https://lore.kernel.org/r/20210301171821.3427-8-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Mon, 1 Mar 2021 17:18:00 +0000 (09:18 -0800)]
scsi: lpfc: Fix incorrect dbde assignment when building target abts wqe
[ Upstream commit
9302154c07bff4e7f7f43c506a1ac84540303d06 ]
The wqe_dbde field indicates whether a Data BDE is present in Words 0:2 and
should therefore should be clear in the abts request wqe. By setting the
bit we can be misleading fw into error cases.
Clear the wqe_dbde field.
Link: https://lore.kernel.org/r/20210301171821.3427-2-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lee Jones [Wed, 3 Mar 2021 13:42:36 +0000 (13:42 +0000)]
drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field overwritten' issue
[ Upstream commit
89adc10178fd6cb68c8ef1905d269070a4d3bd64 ]
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59:
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: warning: initialized field overwritten [-Woverride-init]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’)
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: warning: initialized field overwritten [-Woverride-init]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:181:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: note: (near initialization for ‘aux_mask.AUX_SW_AUTOINCREMENT_DISABLE’)
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiaogang Chen [Thu, 25 Feb 2021 17:06:34 +0000 (12:06 -0500)]
drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work
[ Upstream commit
b6f91fc183f758461b9462cc93e673adbbf95c2d ]
amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by using work
queue and uses single work_struct. If new interrupt is recevied before the
previous handler finished, new interrupts(same type) will be discarded and
driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out. If some
important hpd, hpd_rx related interrupts are missed by driver the hot (un)plug
devices may cause system hang or instability, such as issues with system
resume from S3 sleep with mst device connected.
This patch dynamically allocates new amdgpu_dm_irq_handler_data for new
interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work has not been
handled. So the new interrupt works can be queued to the same workqueue_struct,
instead of discard the new interrupts. All allocated amdgpu_dm_irq_handler_data
are put into a single linked list and will be reused after.
Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aric Cyr [Fri, 12 Feb 2021 23:13:59 +0000 (18:13 -0500)]
drm/amd/display: Don't optimize bandwidth before disabling planes
[ Upstream commit
6ad98e8aeb0106f453bb154933e8355849244990 ]
[Why]
There is a window of time where we optimize bandwidth due to no streams
enabled will enable PSTATE changing but HUBPs are not disabled yet.
This results in underflow counter increasing in some hotplug scenarios.
[How]
Set the optimize-bandwidth flag for later processing once all the HUBPs
are properly disabled.
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Bindu Ramamurthy <bindu.r@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eryk Brol [Tue, 9 Feb 2021 22:09:52 +0000 (17:09 -0500)]
drm/amd/display: Check for DSC support instead of ASIC revision
[ Upstream commit
349a19b2f1b01e713268c7de9944ad669ccdf369 ]
[why]
This check for ASIC revision is no longer useful and causes
lightup issues after a topology change in MST DSC scenario.
In this case, DSC configs should be recalculated for the new
topology. This check prevented that from happening on certain
ASICs that do, in fact, support DSC.
[how]
Change the ASIC revision to instead check if DSC is supported.
Signed-off-by: Eryk Brol <eryk.brol@amd.com>
Acked-by: Bindu Ramamurthy <bindu.r@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tong Zhang [Mon, 22 Feb 2021 02:33:22 +0000 (21:33 -0500)]
drm/ast: fix memory leak when unload the driver
[ Upstream commit
dc739820ff90acccd013f6bb420222978a982791 ]
a connector is leaked upon module unload, it seems that we should do
similar to sample driver as suggested in drm_drv.c.
Adding drm_atomic_helper_shutdown() in ast_pci_remove to prevent leaking.
[ 153.822134] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cle0
[ 153.822698] Modules linked in: ast(-) drm_vram_helper drm_ttm_helper ttm [last unloaded: ttm]
[ 153.823197] CPU: 0 PID: 173 Comm: modprobe Tainted: G W 5.11.0-03615-g55f62bc873474
[ 153.823708] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4
[ 153.824333] RIP: 0010:drm_mode_config_cleanup+0x418/0x470
[ 153.824637] Code: 0c 00 00 00 00 48 8b 84 24 a8 00 00 00 65 48 33 04 25 28 00 00 00 75 65 48 81 c0
[ 153.825668] RSP: 0018:
ffff888103c9fb70 EFLAGS:
00010212
[ 153.825962] RAX:
ffff888102b0d100 RBX:
ffff888102b0c298 RCX:
ffffffff818d8b2b
[ 153.826356] RDX:
dffffc0000000000 RSI:
000000007fffffff RDI:
ffff888102b0c298
[ 153.826748] RBP:
ffff888103c9fba0 R08:
0000000000000001 R09:
ffffed1020561857
[ 153.827146] R10:
ffff888102b0c2b7 R11:
ffffed1020561856 R12:
ffff888102b0c000
[ 153.827538] R13:
ffff888102b0c2d8 R14:
ffff888102b0c2d8 R15:
1ffff11020793f70
[ 153.827935] FS:
00007f24bff456a0(0000) GS:
ffff88815b400000(0000) knlGS:
0000000000000000
[ 153.828380] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 153.828697] CR2:
0000000001c39018 CR3:
0000000103c90000 CR4:
00000000000006f0
[ 153.829096] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 153.829486] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 153.829883] Call Trace:
[ 153.830024] ? drmm_mode_config_init+0x930/0x930
[ 153.830281] ? cpumask_next+0x16/0x20
[ 153.830488] ? mnt_get_count+0x66/0x80
[ 153.830699] ? drm_mode_config_cleanup+0x470/0x470
[ 153.830972] drm_managed_release+0xed/0x1c0
[ 153.831208] drm_dev_release+0x3a/0x50
[ 153.831420] release_nodes+0x39e/0x410
[ 153.831631] ? devres_release+0x40/0x40
[ 153.831852] device_release_driver_internal+0x158/0x270
[ 153.832143] driver_detach+0x76/0xe0
[ 153.832344] bus_remove_driver+0x7e/0x100
[ 153.832568] pci_unregister_driver+0x28/0xf0
[ 153.832821] __x64_sys_delete_module+0x268/0x300
[ 153.833086] ? __ia32_sys_delete_module+0x300/0x300
[ 153.833357] ? call_rcu+0x372/0x4f0
[ 153.833553] ? fpregs_assert_state_consistent+0x4d/0x60
[ 153.833840] ? exit_to_user_mode_prepare+0x2f/0x130
[ 153.834118] do_syscall_64+0x33/0x40
[ 153.834317] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 153.834597] RIP: 0033:0x7f24bfec7cf7
[ 153.834797] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41
[ 153.835812] RSP: 002b:
00007fff72e6cb58 EFLAGS:
00000202 ORIG_RAX:
00000000000000b0
[ 153.836234] RAX:
ffffffffffffffda RBX:
00007f24bff45690 RCX:
00007f24bfec7cf7
[ 153.836623] RDX:
00000000ffffffff RSI:
0000000000000080 RDI:
0000000001c2fb10
[ 153.837018] RBP:
0000000001c2fac0 R08:
2f2f2f2f2f2f2f2f R09:
0000000001c2fac0
[ 153.837408] R10:
fefefefefefefeff R11:
0000000000000202 R12:
0000000001c2fac0
[ 153.837798] R13:
0000000001c2f9d0 R14:
0000000000000000 R15:
0000000000000001
[ 153.838194] ---[ end trace
b92031513bbe596c ]---
[ 153.838441] [drm:drm_mode_config_cleanup] *ERROR* connector VGA-1 leaked!
Signed-off-by: Tong Zhang <ztong0001@gmail.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210222023322.984885-1-ztong0001@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Leung [Tue, 2 Feb 2021 21:28:05 +0000 (16:28 -0500)]
drm/amd/display: changing sr exit latency
[ Upstream commit
efe213e5a57e0cd92fa4f328dc1963d330549982 ]
[Why]
Hardware team remeasured, need to update timings
to increase latency slightly and avoid intermittent
underflows.
[How]
sr exit latency update.
Signed-off-by: Martin Leung <martin.leung@amd.com>
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Qingqing Zhuo <Qingqing.Zhuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thomas Zimmermann [Tue, 9 Feb 2021 13:46:24 +0000 (14:46 +0100)]
drm/ast: Fix invalid usage of AST_MAX_HWC_WIDTH in cursor atomic_check
[ Upstream commit
ee4a92d690f30f3793df942939726bec0338e65b ]
Use AST_MAX_HWC_HEIGHT for setting offset_y in the cursor plane's
atomic_check. The code used AST_MAX_HWC_WIDTH instead. This worked
because both constants has the same value.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209134632.12157-3-tzimmermann@suse.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gerd Hoffmann [Thu, 4 Feb 2021 14:57:06 +0000 (15:57 +0100)]
drm/qxl: release shadow on shutdown
[ Upstream commit
4ca77c513537700d3fae69030879f781dde1904c ]
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20210204145712.1531203-6-kraxel@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tong Zhang [Wed, 3 Feb 2021 04:07:27 +0000 (23:07 -0500)]
drm/qxl: do not run release if qxl failed to init
[ Upstream commit
b91907a6241193465ca92e357adf16822242296d ]
if qxl_device_init() fail, drm device will not be registered,
in this case, do not run qxl_drm_release()
[ 5.258534] ==================================================================
[ 5.258931] BUG: KASAN: user-memory-access in qxl_destroy_monitors_object+0x42/0xa0 [qxl]
[ 5.259388] Write of size 8 at addr
00000000000014dc by task modprobe/95
[ 5.259754]
[ 5.259842] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc6-00007-g88bb507a74ea #62
[ 5.260309] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda54
[ 5.260917] Call Trace:
[ 5.261056] dump_stack+0x7d/0xa3
[ 5.261245] kasan_report.cold+0x10c/0x10e
[ 5.261475] ? qxl_destroy_monitors_object+0x42/0xa0 [qxl]
[ 5.261789] check_memory_region+0x17c/0x1e0
[ 5.262029] qxl_destroy_monitors_object+0x42/0xa0 [qxl]
[ 5.262332] qxl_modeset_fini+0x9/0x20 [qxl]
[ 5.262595] qxl_drm_release+0x22/0x30 [qxl]
[ 5.262841] drm_dev_release+0x32/0x50
[ 5.263047] release_nodes+0x39e/0x410
[ 5.263253] ? devres_release+0x40/0x40
[ 5.263462] really_probe+0x2ea/0x420
[ 5.263664] driver_probe_device+0x6d/0xd0
[ 5.263888] device_driver_attach+0x82/0x90
[ 5.264116] ? device_driver_attach+0x90/0x90
[ 5.264353] __driver_attach+0x60/0x100
[ 5.264563] ? device_driver_attach+0x90/0x90
[ 5.264801] bus_for_each_dev+0xe1/0x140
[ 5.265014] ? subsys_dev_iter_exit+0x10/0x10
[ 5.265251] ? klist_node_init+0x61/0x80
[ 5.265464] bus_add_driver+0x254/0x2a0
[ 5.265673] driver_register+0xd3/0x150
[ 5.265882] ? 0xffffffffc0048000
[ 5.266064] do_one_initcall+0x84/0x250
[ 5.266274] ? trace_event_raw_event_initcall_finish+0x150/0x150
[ 5.266596] ? unpoison_range+0xf/0x30
[ 5.266801] ? ____kasan_kmalloc.constprop.0+0x84/0xa0
[ 5.267082] ? unpoison_range+0xf/0x30
[ 5.267287] ? unpoison_range+0xf/0x30
[ 5.267491] do_init_module+0xf8/0x350
[ 5.267697] load_module+0x3fe6/0x4340
[ 5.267902] ? vm_unmap_ram+0x1d0/0x1d0
[ 5.268115] ? module_frob_arch_sections+0x20/0x20
[ 5.268375] ? __do_sys_finit_module+0x108/0x170
[ 5.268624] __do_sys_finit_module+0x108/0x170
[ 5.268865] ? __ia32_sys_init_module+0x40/0x40
[ 5.269111] ? file_open_root+0x200/0x200
[ 5.269330] ? do_sys_open+0x85/0xe0
[ 5.269527] ? filp_open+0x50/0x50
[ 5.269714] ? exit_to_user_mode_prepare+0xfc/0x130
[ 5.269978] do_syscall_64+0x33/0x40
[ 5.270176] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 5.270450] RIP: 0033:0x7fa3f685bcf7
[ 5.270646] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d1
[ 5.271634] RSP: 002b:
00007ffca83048d8 EFLAGS:
00000246 ORIG_RAX:
0000000000000139
[ 5.272037] RAX:
ffffffffffffffda RBX:
0000000001e94a70 RCX:
00007fa3f685bcf7
[ 5.272416] RDX:
0000000000000000 RSI:
0000000001e939e0 RDI:
0000000000000003
[ 5.272794] RBP:
0000000000000003 R08:
0000000000000000 R09:
0000000000000001
[ 5.273171] R10:
00007fa3f68bf300 R11:
0000000000000246 R12:
0000000001e939e0
[ 5.273550] R13:
0000000000000000 R14:
0000000001e93bd0 R15:
0000000000000001
[ 5.273928] ==================================================================
Signed-off-by: Tong Zhang <ztong0001@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210203040727.868921-1-ztong0001@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jared Baldridge [Wed, 20 Jan 2021 20:56:26 +0000 (12:56 -0800)]
drm: Added orientation quirk for OneGX1 Pro
[ Upstream commit
81ad7f9f78e4ff80e95be8282423f511b84f1166 ]
The OneGX1 Pro has a fairly unique combination of generic strings,
but we additionally match on the BIOS date just to be safe.
Signed-off-by: Jared Baldridge <jrb@expunge.us>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41288ccb-1012-486b-81c1-a24c31850c91@www.fastmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Josef Bacik [Fri, 12 Mar 2021 20:25:21 +0000 (15:25 -0500)]
btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s
[ Upstream commit
7a9213a93546e7eaef90e6e153af6b8fc7553f10 ]
A few BUG_ON()'s in replace_path are purely to keep us from making
logical mistakes, so replace them with ASSERT()'s.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Josef Bacik [Fri, 12 Mar 2021 20:25:20 +0000 (15:25 -0500)]
btrfs: do proper error handling in btrfs_update_reloc_root
[ Upstream commit
592fbcd50c99b8adf999a2a54f9245caff333139 ]
We call btrfs_update_root in btrfs_update_reloc_root, which can fail for
all sorts of reasons, including IO errors. Instead of panicing the box
lets return the error, now that all callers properly handle those
errors.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Josef Bacik [Fri, 12 Mar 2021 20:25:14 +0000 (15:25 -0500)]
btrfs: do proper error handling in create_reloc_root
[ Upstream commit
84c50ba5214c2f3c1be4a931d521ec19f55dfdc8 ]
We do memory allocations here, read blocks from disk, all sorts of
operations that could easily fail at any given point. Instead of
panicing the box, simply return the error back up the chain, all callers
at this point have proper error handling.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Bauer [Fri, 16 Apr 2021 19:59:56 +0000 (21:59 +0200)]
spi: sync up initial chipselect state
[ Upstream commit
d347b4aaa1a042ea528e385d9070b74c77a14321 ]
When initially probing the SPI slave device, the call for disabling an
SPI device without the SPI_CS_HIGH flag is not applied, as the
condition for checking whether or not the state to be applied equals the
one currently set evaluates to true.
This however might not necessarily be the case, as the chipselect might
be active.
Add a force flag to spi_set_cs which allows to override this
early exit condition. Set it to false everywhere except when called
from spi_setup to sync up the initial CS state.
Fixes commit
d40f0b6f2e21 ("spi: Avoid setting the chip select if we don't
need to")
Signed-off-by: David Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210416195956.121811-1-mail@david-bauer.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David E. Box [Sat, 17 Apr 2021 03:12:44 +0000 (20:12 -0700)]
platform/x86: intel_pmc_core: Don't use global pmcdev in quirks
[ Upstream commit
c9f86d6ca6b5e23d30d16ade4b9fff5b922a610a ]
The DMI callbacks, used for quirks, currently access the PMC by getting
the address a global pmc_dev struct. Instead, have the callbacks set a
global quirk specific variable. In probe, after calling dmi_check_system(),
pass pmc_dev to a function that will handle each quirk if its variable
condition is met. This allows removing the global pmc_dev later.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210417031252.3020837-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shixin Liu [Thu, 8 Apr 2021 07:18:39 +0000 (15:18 +0800)]
crypto: omap-aes - Fix PM reference leak on omap-aes.c
[ Upstream commit
1f34cc4a8da34fbb250efb928f9b8c6fe7ee0642 ]
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shixin Liu [Thu, 8 Apr 2021 07:18:37 +0000 (15:18 +0800)]
crypto: sa2ul - Fix PM reference leak in sa_ul_probe()
[ Upstream commit
13343badae093977295341d5a050f51ef128821c ]
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shixin Liu [Thu, 8 Apr 2021 07:18:36 +0000 (15:18 +0800)]
crypto: stm32/cryp - Fix PM reference leak on stm32-cryp.c
[ Upstream commit
747bf30fd944f02f341b5f3bc7d97a13f2ae2fbe ]
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shixin Liu [Thu, 8 Apr 2021 07:18:35 +0000 (15:18 +0800)]
crypto: stm32/hash - Fix PM reference leak on stm32-hash.c
[ Upstream commit
1cb3ad701970e68f18a9e5d090baf2b1b703d729 ]
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shixin Liu [Thu, 8 Apr 2021 07:18:33 +0000 (15:18 +0800)]
crypto: sun8i-ce - Fix PM reference leak in sun8i_ce_probe()
[ Upstream commit
cc987ae9150c255352660d235ab27c834aa527be ]
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shixin Liu [Thu, 8 Apr 2021 07:18:32 +0000 (15:18 +0800)]
crypto: sun8i-ss - Fix PM reference leak when pm_runtime_get_sync() fails
[ Upstream commit
06cd7423cf451d68bfab289278d7890c9ae01a14 ]
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Apr 2021 09:27:16 +0000 (17:27 +0800)]
phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove()
[ Upstream commit
e1723d8b87b73ab363256e7ca3af3ddb75855680 ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210407092716.3270248-1-yangyingliang@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Machek [Wed, 14 Apr 2021 17:12:49 +0000 (20:12 +0300)]
intel_th: Consistency and off-by-one fix
[ Upstream commit
18ffbc47d45a1489b664dd68fb3a7610a6e1dea3 ]
Consistently use "< ... +1" in for loops.
Fix of-by-one in for_each_set_bit().
Signed-off-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/lkml/20190724095841.GA6952@amd/
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210414171251.14672-6-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hillf Danton [Mon, 12 Apr 2021 03:57:58 +0000 (11:57 +0800)]
tty: n_gsm: check error while registering tty devices
[ Upstream commit
0a360e8b65d62fe1a994f0a8da4f8d20877b2100 ]
Add the error path for registering tty devices and roll back in case of error
in bid to avoid the UAF like the below one reported.
Plus syzbot reported general protection fault in cdev_del() on Sep 24, 2020
and both cases are down to the kobject_put() in tty_cdev_add().
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 1 PID: 8923 at lib/refcount.c:28
refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28
Modules linked in:
CPU: 1 PID: 8923 Comm: executor Not tainted 5.12.0-rc5+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28
Code: 4f ff ff ff e8 32 fa b5 fe 48 c7 c7 3d f8 f6 86 e8 d6 ab c6 fe
c6 05 7c 34 67 04 01 48 c7 c7 68 f8 6d 86 31 c0 e8 81 2e 9d fe <0f> 0b
e9 22 ff ff ff e8 05 fa b5 fe 48 c7 c7 3e f8 f6 86 e8 a9 ab
RSP: 0018:
ffffc90001633c60 EFLAGS:
00010246
RAX:
15d08b2e34b77800 RBX:
0000000000000003 RCX:
ffff88804c056c80
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000000000000
RBP:
0000000000000003 R08:
ffffffff813767aa R09:
0001ffffffffffff
R10:
0001ffffffffffff R11:
ffff88804c056c80 R12:
ffff888040b7d000
R13:
ffff88804c206938 R14:
ffff88804c206900 R15:
ffff888041b18488
FS:
00000000022c9940(0000) GS:
ffff88807ec00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f9f9b122008 CR3:
0000000044b4b000 CR4:
0000000000750ee0
PKRU:
55555554
Call Trace:
__refcount_sub_and_test -origin/./include/linux/refcount.h:283 [inline]
__refcount_dec_and_test -origin/./include/linux/refcount.h:315 [inline]
refcount_dec_and_test -origin/./include/linux/refcount.h:333 [inline]
kref_put -origin/./include/linux/kref.h:64 [inline]
kobject_put+0x17b/0x180 -origin/lib/kobject.c:753
cdev_del+0x4b/0x50 -origin/fs/char_dev.c:597
tty_unregister_device+0x99/0xd0 -origin/drivers/tty/tty_io.c:3343
gsmld_detach_gsm -origin/drivers/tty/n_gsm.c:2409 [inline]
gsmld_close+0x6c/0x140 -origin/drivers/tty/n_gsm.c:2478
tty_ldisc_close -origin/drivers/tty/tty_ldisc.c:488 [inline]
tty_ldisc_kill -origin/drivers/tty/tty_ldisc.c:636 [inline]
tty_ldisc_release+0x1b6/0x400 -origin/drivers/tty/tty_ldisc.c:809
tty_release_struct+0x19/0xb0 -origin/drivers/tty/tty_io.c:1714
tty_release+0x9ad/0xa00 -origin/drivers/tty/tty_io.c:1885
__fput+0x260/0x4e0 -origin/fs/file_table.c:280
____fput+0x11/0x20 -origin/fs/file_table.c:313
task_work_run+0x8e/0x110 -origin/kernel/task_work.c:140
tracehook_notify_resume -origin/./include/linux/tracehook.h:189 [inline]
exit_to_user_mode_loop -origin/kernel/entry/common.c:174 [inline]
exit_to_user_mode_prepare+0x16b/0x1a0 -origin/kernel/entry/common.c:208
__syscall_exit_to_user_mode_work -origin/kernel/entry/common.c:290 [inline]
syscall_exit_to_user_mode+0x20/0x40 -origin/kernel/entry/common.c:301
do_syscall_64+0x45/0x80 -origin/arch/x86/entry/common.c:56
entry_SYSCALL_64_after_hwframe+0x44/0xae
Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com
Reported-and-tested-by: Hao Sun <sunhao.th@gmail.com>
Signed-off-by: Hillf Danton <hdanton@sina.com>
Link: https://lore.kernel.org/r/20210412035758.1974-1-hdanton@sina.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thinh Nguyen [Wed, 14 Apr 2021 02:13:18 +0000 (19:13 -0700)]
usb: dwc3: gadget: Check for disabled LPM quirk
[ Upstream commit
475e8be53d0496f9bc6159f4abb3ff5f9b90e8de ]
If the device doesn't support LPM, make sure to disable the LPM
capability and don't advertise to the host that it supports it.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/9e68527ff932b1646f92a7593d4092a903754666.1618366071.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bixuan Cui [Thu, 8 Apr 2021 13:08:31 +0000 (21:08 +0800)]
usb: core: hub: Fix PM reference leak in usb_port_resume()
[ Upstream commit
025f97d188006eeee4417bb475a6878d1e0eed3f ]
pm_runtime_get_sync will increment pm usage counter even it failed.
thus a pairing decrement is needed.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Link: https://lore.kernel.org/r/20210408130831.56239-1-cuibixuan@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bixuan Cui [Thu, 8 Apr 2021 09:18:36 +0000 (17:18 +0800)]
usb: musb: fix PM reference leak in musb_irq_work()
[ Upstream commit
9535b99533904e9bc1607575aa8e9539a55435d7 ]
pm_runtime_get_sync will increment pm usage counter even it failed.
thus a pairing decrement is needed.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Link: https://lore.kernel.org/r/20210408091836.55227-1-cuibixuan@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Apr 2021 09:29:47 +0000 (17:29 +0800)]
usb: gadget: tegra-xudc: Fix possible use-after-free in tegra_xudc_remove()
[ Upstream commit
a932ee40c276767cd55fadec9e38829bf441db41 ]
This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210407092947.3271507-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>