linux-stable.git, branch v5.8.3 Linux kernel stable tree Linux 5.8.3 2020-08-21T11:15:22+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-08-21T11:15:22+00:00 a1101e94767e2d5da5bcbee12573d96a1c8be5bb Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/amd/display: dchubbub p-state warning during surface planes switch 2020-08-21T11:15:22+00:00 hersen wu hersenxs.wu@amd.com 2020-07-19T21:21:59+00:00 60db6233fcdb19689037daa6610518360946a20a commit 8b0379a85762b516c7b46aed7dbf2a4947c00564 upstream. [Why] ramp_up_dispclk_with_dpp is to change dispclk, dppclk and dprefclk according to bandwidth requirement. call stack: rv1_update_clocks --> update_clocks --> dcn10_prepare_bandwidth / dcn10_optimize_bandwidth --> prepare_bandwidth / optimize_bandwidth. before change dcn hw, prepare_bandwidth will be called first to allow enough clock, watermark for change, after end of dcn hw change, optimize_bandwidth is executed to lower clock to save power for new dcn hw settings. below is sequence of commit_planes_for_stream: step 1: prepare_bandwidth - raise clock to have enough bandwidth step 2: lock_doublebuffer_enable step 3: pipe_control_lock(true) - make dchubp register change will not take effect right way step 4: apply_ctx_for_surface - program dchubp step 5: pipe_control_lock(false) - dchubp register change take effect step 6: optimize_bandwidth --> dc_post_update_surfaces_to_stream for full_date, optimize clock to save power at end of step 1, dcn clocks (dprefclk, dispclk, dppclk) may be changed for new dchubp configuration. but real dcn hub dchubps are still running with old configuration until end of step 5. this need clocks settings at step 1 should not less than that before step 1. this is checked by two conditions: 1. if (should_set_clock(safe_to_lower , new_clocks->dispclk_khz, clk_mgr_base->clks.dispclk_khz) || new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz) 2. request_dpp_div = new_clocks->dispclk_khz > new_clocks->dppclk_khz the second condition is based on new dchubp configuration. dppclk for new dchubp may be different from dppclk before step 1. for example, before step 1, dchubps are as below: pipe 0: recout=(0,40,1920,980) viewport=(0,0,1920,979) pipe 1: recout=(0,0,1920,1080) viewport=(0,0,1920,1080) for dppclk for pipe0 need dppclk = dispclk new dchubp pipe split configuration: pipe 0: recout=(0,0,960,1080) viewport=(0,0,960,1080) pipe 1: recout=(960,0,960,1080) viewport=(960,0,960,1080) dppclk only needs dppclk = dispclk /2. dispclk, dppclk are not lock by otg master lock. they take effect after step 1. during this transition, dispclk are the same, but dppclk is changed to half of previous clock for old dchubp configuration between step 1 and step 6. This may cause p-state warning intermittently. [How] for new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz, we need make sure dppclk are not changed to less between step 1 and 6. for new_clocks->dispclk_khz > clk_mgr_base->clks.dispclk_khz, new display clock is raised, but we do not know ratio of new_clocks->dispclk_khz and clk_mgr_base->clks.dispclk_khz, new_clocks->dispclk_khz /2 does not guarantee equal or higher than old dppclk. we could ignore power saving different between dppclk = displck and dppclk = dispclk / 2 between step 1 and step 6. as long as safe_to_lower = false, set dpclk = dispclk to simplify condition check. CC: Stable <stable@vger.kernel.org> Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8b0379a85762b516c7b46aed7dbf2a4947c00564 upstream.

[Why]
ramp_up_dispclk_with_dpp is to change dispclk, dppclk and dprefclk
according to bandwidth requirement. call stack: rv1_update_clocks -->
update_clocks --> dcn10_prepare_bandwidth / dcn10_optimize_bandwidth
--> prepare_bandwidth / optimize_bandwidth. before change dcn hw,
prepare_bandwidth will be called first to allow enough clock,
watermark for change, after end of dcn hw change, optimize_bandwidth
is executed to lower clock to save power for new dcn hw settings.

below is sequence of commit_planes_for_stream:
step 1: prepare_bandwidth - raise clock to have enough bandwidth
step 2: lock_doublebuffer_enable
step 3: pipe_control_lock(true) - make dchubp register change will
not take effect right way
step 4: apply_ctx_for_surface - program dchubp
step 5: pipe_control_lock(false) - dchubp register change take effect
step 6: optimize_bandwidth --> dc_post_update_surfaces_to_stream
for full_date, optimize clock to save power

at end of step 1, dcn clocks (dprefclk, dispclk, dppclk) may be
changed for new dchubp configuration. but real dcn hub dchubps are
still running with old configuration until end of step 5. this need
clocks settings at step 1 should not less than that before step 1.
this is checked by two conditions: 1. if (should_set_clock(safe_to_lower
, new_clocks->dispclk_khz, clk_mgr_base->clks.dispclk_khz) ||
new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz)
2. request_dpp_div = new_clocks->dispclk_khz > new_clocks->dppclk_khz

the second condition is based on new dchubp configuration. dppclk
for new dchubp may be different from dppclk before step 1.
for example, before step 1, dchubps are as below:
pipe 0: recout=(0,40,1920,980) viewport=(0,0,1920,979)
pipe 1: recout=(0,0,1920,1080) viewport=(0,0,1920,1080)
for dppclk for pipe0 need dppclk = dispclk

new dchubp pipe split configuration:
pipe 0: recout=(0,0,960,1080) viewport=(0,0,960,1080)
pipe 1: recout=(960,0,960,1080) viewport=(960,0,960,1080)
dppclk only needs dppclk = dispclk /2.

dispclk, dppclk are not lock by otg master lock. they take effect
after step 1. during this transition, dispclk are the same, but
dppclk is changed to half of previous clock for old dchubp
configuration between step 1 and step 6. This may cause p-state
warning intermittently.

[How]
for new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz, we
need make sure dppclk are not changed to less between step 1 and 6.
for new_clocks->dispclk_khz > clk_mgr_base->clks.dispclk_khz,
new display clock is raised, but we do not know ratio of
new_clocks->dispclk_khz and clk_mgr_base->clks.dispclk_khz,
new_clocks->dispclk_khz /2 does not guarantee equal or higher than
old dppclk. we could ignore power saving different between
dppclk = displck and dppclk = dispclk / 2 between step 1 and step 6.
as long as safe_to_lower = false, set dpclk = dispclk to simplify
condition check.

CC: Stable <stable@vger.kernel.org>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Eryk Brol <eryk.brol@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/amd/display: Fix dmesg warning from setting abm level 2020-08-21T11:15:22+00:00 Stylon Wang stylon.wang@amd.com 2020-06-30T09:55:29+00:00 f80a0daa7f0ac0fa932cbff970d7756d9f7413f1 commit c5892a10218214d729699ab61bad6fc109baf0ce upstream. [Why] Setting abm level does not correctly update CRTC state. As a result no surface update is added to dc stream state and triggers warning. [How] Correctly update CRTC state when setting abm level property. CC: Stable <stable@vger.kernel.org> Signed-off-by: Stylon Wang <stylon.wang@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c5892a10218214d729699ab61bad6fc109baf0ce upstream.

[Why]
Setting abm level does not correctly update CRTC state. As a result
no surface update is added to dc stream state and triggers warning.

[How]
Correctly update CRTC state when setting abm level property.

CC: Stable <stable@vger.kernel.org>
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Eryk Brol <eryk.brol@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/amdgpu: Fix bug where DPM is not enabled after hibernate and resume 2020-08-21T11:15:22+00:00 Sandeep Raghuraman sandy.8925@gmail.com 2020-08-06T17:22:20+00:00 ca4c7f2d2f3ec364fba80b90c3f93f99cdd7340a commit f87812284172a9809820d10143b573d833cd3f75 upstream. Reproducing bug report here: After hibernating and resuming, DPM is not enabled. This remains the case even if you test hibernate using the steps here: https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html I debugged the problem, and figured out that in the file hardwaremanager.c, in the function, phm_enable_dynamic_state_management(), the check 'if (!hwmgr->pp_one_vf && smum_is_dpm_running(hwmgr) && !amdgpu_passthrough(adev) && adev->in_suspend)' returns true for the hibernate case, and false for the suspend case. This means that for the hibernate case, the AMDGPU driver doesn't enable DPM (even though it should) and simply returns from that function. In the suspend case, it goes ahead and enables DPM, even though it doesn't need to. I debugged further, and found out that in the case of suspend, for the CIK/Hawaii GPUs, smum_is_dpm_running(hwmgr) returns false, while in the case of hibernate, smum_is_dpm_running(hwmgr) returns true. For CIK, the ci_is_dpm_running() function calls the ci_is_smc_ram_running() function, which is ultimately used to determine if DPM is currently enabled or not, and this seems to provide the wrong answer. I've changed the ci_is_dpm_running() function to instead use the same method that some other AMD GPU chips do (e.g Fiji), which seems to read the voltage controller. I've tested on my R9 390 and it seems to work correctly for both suspend and hibernate use cases, and has been stable so far. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208839 Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f87812284172a9809820d10143b573d833cd3f75 upstream.

Reproducing bug report here:
After hibernating and resuming, DPM is not enabled. This remains the case
even if you test hibernate using the steps here:
https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html

I debugged the problem, and figured out that in the file hardwaremanager.c,
in the function, phm_enable_dynamic_state_management(), the check
'if (!hwmgr->pp_one_vf && smum_is_dpm_running(hwmgr) && !amdgpu_passthrough(adev) && adev->in_suspend)'
returns true for the hibernate case, and false for the suspend case.

This means that for the hibernate case, the AMDGPU driver doesn't enable DPM
(even though it should) and simply returns from that function.
In the suspend case, it goes ahead and enables DPM, even though it doesn't need to.

I debugged further, and found out that in the case of suspend, for the
CIK/Hawaii GPUs, smum_is_dpm_running(hwmgr) returns false, while in the case of
hibernate, smum_is_dpm_running(hwmgr) returns true.

For CIK, the ci_is_dpm_running() function calls the ci_is_smc_ram_running() function,
which is ultimately used to determine if DPM is currently enabled or not,
and this seems to provide the wrong answer.

I've changed the ci_is_dpm_running() function to instead use the same method that
some other AMD GPU chips do (e.g Fiji), which seems to read the voltage controller.
I've tested on my R9 390 and it seems to work correctly for both suspend and
hibernate use cases, and has been stable so far.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208839
Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm: fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi 2020-08-21T11:15:21+00:00 Xin Xiong xiongx18@fudan.edu.cn 2020-07-19T15:45:45+00:00 81dfb2e6cef196645bb9365fbaa1c21f1a2be88c commit a34a0a632dd991a371fec56431d73279f9c54029 upstream. drm_dp_mst_allocate_vcpi() invokes drm_dp_mst_topology_get_port_validated(), which increases the refcount of the "port". These reference counting issues take place in two exception handling paths separately. Either when “slots” is less than 0 or when drm_dp_init_vcpi() returns a negative value, the function forgets to reduce the refcnt increased drm_dp_mst_topology_get_port_validated(), which results in a refcount leak. Fix these issues by pulling up the error handling when "slots" is less than 0, and calling drm_dp_mst_topology_put_port() before termination when drm_dp_init_vcpi() returns a negative value. Fixes: 1e797f556c61 ("drm/dp: Split drm_dp_mst_allocate_vcpi") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200719154545.GA41231@xin-virtual-machine Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a34a0a632dd991a371fec56431d73279f9c54029 upstream.

drm_dp_mst_allocate_vcpi() invokes
drm_dp_mst_topology_get_port_validated(), which increases the refcount
of the "port".

These reference counting issues take place in two exception handling
paths separately. Either when “slots” is less than 0 or when
drm_dp_init_vcpi() returns a negative value, the function forgets to
reduce the refcnt increased drm_dp_mst_topology_get_port_validated(),
which results in a refcount leak.

Fix these issues by pulling up the error handling when "slots" is less
than 0, and calling drm_dp_mst_topology_put_port() before termination
when drm_dp_init_vcpi() returns a negative value.

Fixes: 1e797f556c61 ("drm/dp: Split drm_dp_mst_allocate_vcpi")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200719154545.GA41231@xin-virtual-machine
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm: Added orientation quirk for ASUS tablet model T103HAF 2020-08-21T11:15:21+00:00 Marius Iacob themariusus@gmail.com 2020-08-01T12:34:46+00:00 c4dc000bdef4616028a1718182c3fa7bca08fbe5 commit b5ac98cbb8e5e30c34ebc837d1e5a3982d2b5f5c upstream. Signed-off-by: Marius Iacob <themariusus@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200801123445.1514567-1-themariusus@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b5ac98cbb8e5e30c34ebc837d1e5a3982d2b5f5c upstream.

Signed-off-by: Marius Iacob <themariusus@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200801123445.1514567-1-themariusus@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/tidss: fix modeset init for DPI panels 2020-08-21T11:15:21+00:00 Tomi Valkeinen tomi.valkeinen@ti.com 2020-06-04T08:02:14+00:00 516bbc000e24201ae409007d3b5bfdb58b7dc407 commit a72a6a16d51034045cb6355924b62221a8221ca3 upstream. The connector type for DISPC's DPI videoport was set the LVDS instead of DPI. This causes any DPI panel setup to fail with tidss, making all DPI panels unusable. Fix this by using correct connector type. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Fixes: 32a1795f57eecc39749017 ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Cc: stable@vger.kernel.org # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20200604080214.107159-1-tomi.valkeinen@ti.com Reviewed-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a72a6a16d51034045cb6355924b62221a8221ca3 upstream.

The connector type for DISPC's DPI videoport was set the LVDS instead of
DPI. This causes any DPI panel setup to fail with tidss, making all DPI
panels unusable.

Fix this by using correct connector type.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fixes: 32a1795f57eecc39749017 ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
Cc: stable@vger.kernel.org # v5.7+
Link: https://patchwork.freedesktop.org/patch/msgid/20200604080214.107159-1-tomi.valkeinen@ti.com
Reviewed-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/omap: force runtime PM suspend on system suspend 2020-08-21T11:15:21+00:00 Tomi Valkeinen tomi.valkeinen@ti.com 2020-06-18T09:51:52+00:00 efe06a004622d95145a27b3eeb98e82033c24117 commit ecfdedd7da5d54416db5ca0f851264dca8736f59 upstream. Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM suspend and resume. We use suspend late version so that omapdrm's system suspend callback is called first, as that will disable all the display outputs after which it's safe to force DSS into suspend. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200618095153.611071-1-tomi.valkeinen@ti.com Acked-by: Tony Lindgren <tony@atomide.com> Fixes: cef766300353 ("drm/omap: Prepare DSS for probing without legacy platform data") Cc: stable@vger.kernel.org # v5.7+ Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ecfdedd7da5d54416db5ca0f851264dca8736f59 upstream.

Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM
suspend and resume.

We use suspend late version so that omapdrm's system suspend callback is
called first, as that will disable all the display outputs after which
it's safe to force DSS into suspend.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200618095153.611071-1-tomi.valkeinen@ti.com
Acked-by: Tony Lindgren <tony@atomide.com>
Fixes: cef766300353 ("drm/omap: Prepare DSS for probing without legacy platform data")
Cc: stable@vger.kernel.org # v5.7+
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/dp_mst: Fix the DDC I2C device unregistration of an MST port 2020-08-21T11:15:21+00:00 Imre Deak imre.deak@intel.com 2020-06-07T21:25:20+00:00 c37097f533d849bd5be6f31f81a6fb879cd0f8ec commit 7d11507605a75fcb2159b93d1fe8213b363a2c20 upstream. The WARN below triggers during the removal of an MST port. The problem is that the parent device's (the connector's kdev) sysfs directory is removed recursively when the connector is unregistered (even though the I2C device holds a reference on the parent device). To fix this set first the Peer Device Type to none which will remove the I2C device. Note that atm, inconsistently, the parent of the I2C device is initially set to the DRM kdev and after a Connection Status Notification the parent may be reset to be the connector's kdev. This problem is addressed by the next patch. [ 4462.989299] ------------[ cut here ]------------ [ 4463.014940] sysfs group 'power' not found for kobject 'i2c-24' [ 4463.034664] WARNING: CPU: 0 PID: 970 at fs/sysfs/group.c:281 sysfs_remove_group+0x71/0x80 [ 4463.044357] Modules linked in: snd_hda_intel i915 drm_kms_helper(O) drm netconsole snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_intel_dspcf g crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core asix usbnet kvm_intel mii i2c_algo_bit snd_pcm syscopyarea sysfillrect e1000e sysimgblt fb_sys_fops prim e_numbers ptp pps_core i2c_i801 r8169 mei_me realtek mei [last unloaded: drm] [ 4463.044399] CPU: 0 PID: 970 Comm: kworker/0:2 Tainted: G O 5.7.0+ #172 [ 4463.044402] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP [ 4463.044423] Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper] [ 4463.044428] RIP: 0010:sysfs_remove_group+0x71/0x80 [ 4463.044431] Code: 48 89 df 5b 5d 41 5c e9 cd b6 ff ff 48 89 df e8 95 b4 ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 20 0f 3f 82 e8 9f c5 d7 ff <0f> 0b 5b 5d 41 5c c3 0f 1f 84 00 00 00 00 00 48 85 f6 74 31 41 54 [ 4463.044433] RSP: 0018:ffffc900018bfbf0 EFLAGS: 00010282 [ 4463.044436] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 4463.044439] RDX: 0000000080000001 RSI: ffff88849e828f38 RDI: 00000000ffffffff [ 4463.052970] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:100:plane 2B] 00000000c2160caa state to 00000000d172564a [ 4463.070533] RBP: ffffffff820cea20 R08: ffff88847f4b8958 R09: 0000000000000000 [ 4463.070535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848a725018 [ 4463.070537] R13: 0000000000000000 R14: ffffffff827090e0 R15: 0000000000000002 [ 4463.070539] FS: 0000000000000000(0000) GS:ffff88849e800000(0000) knlGS:0000000000000000 [ 4463.070541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4463.070543] CR2: 00007fdf8a756538 CR3: 0000000489684001 CR4: 0000000000760ef0 [ 4463.070545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4463.070547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4463.070549] PKRU: 55555554 [ 4463.070551] Call Trace: [ 4463.070560] device_del+0x84/0x400 [ 4463.070571] cdev_device_del+0x10/0x30 [ 4463.070578] put_i2c_dev+0x69/0x80 [ 4463.070584] i2cdev_detach_adapter+0x2e/0x60 [ 4463.070591] notifier_call_chain+0x34/0x90 [ 4463.070599] blocking_notifier_call_chain+0x3f/0x60 [ 4463.070606] device_del+0x7c/0x400 [ 4463.087817] ? lockdep_init_map_waits+0x57/0x210 [ 4463.087825] device_unregister+0x11/0x60 [ 4463.087829] i2c_del_adapter+0x249/0x310 [ 4463.087846] drm_dp_port_set_pdt+0x6b/0x2c0 [drm_kms_helper] [ 4463.087862] drm_dp_delayed_destroy_work+0x2af/0x350 [drm_kms_helper] [ 4463.087876] process_one_work+0x268/0x600 [ 4463.105438] ? __schedule+0x30c/0x920 [ 4463.105451] worker_thread+0x37/0x380 [ 4463.105457] ? process_one_work+0x600/0x600 [ 4463.105462] kthread+0x140/0x160 [ 4463.105466] ? kthread_park+0x80/0x80 [ 4463.105474] ret_from_fork+0x24/0x50 Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200607212522.16935-1-imre.deak@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7d11507605a75fcb2159b93d1fe8213b363a2c20 upstream.

The WARN below triggers during the removal of an MST port. The problem
is that the parent device's (the connector's kdev) sysfs directory is
removed recursively when the connector is unregistered (even though the
I2C device holds a reference on the parent device). To fix this set
first the Peer Device Type to none which will remove the I2C device.

Note that atm, inconsistently, the parent of the I2C device is initially set to
the DRM kdev and after a Connection Status Notification the parent may be reset
to be the connector's kdev. This problem is addressed by the next patch.

[ 4462.989299] ------------[ cut here ]------------
[ 4463.014940] sysfs group 'power' not found for kobject 'i2c-24'
[ 4463.034664] WARNING: CPU: 0 PID: 970 at fs/sysfs/group.c:281 sysfs_remove_group+0x71/0x80
[ 4463.044357] Modules linked in: snd_hda_intel i915 drm_kms_helper(O) drm netconsole snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_intel_dspcf
g crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core asix usbnet kvm_intel mii i2c_algo_bit snd_pcm syscopyarea sysfillrect e1000e sysimgblt fb_sys_fops prim
e_numbers ptp pps_core i2c_i801 r8169 mei_me realtek mei [last unloaded: drm]
[ 4463.044399] CPU: 0 PID: 970 Comm: kworker/0:2 Tainted: G           O      5.7.0+ #172
[ 4463.044402] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP
[ 4463.044423] Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper]
[ 4463.044428] RIP: 0010:sysfs_remove_group+0x71/0x80
[ 4463.044431] Code: 48 89 df 5b 5d 41 5c e9 cd b6 ff ff 48 89 df e8 95 b4 ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 20 0f 3f 82 e8 9f c5 d7 ff <0f> 0b 5b 5d 41 5c c3 0f 1f
84 00 00 00 00 00 48 85 f6 74 31 41 54
[ 4463.044433] RSP: 0018:ffffc900018bfbf0 EFLAGS: 00010282
[ 4463.044436] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
[ 4463.044439] RDX: 0000000080000001 RSI: ffff88849e828f38 RDI: 00000000ffffffff
[ 4463.052970] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:100:plane 2B] 00000000c2160caa state to 00000000d172564a
[ 4463.070533] RBP: ffffffff820cea20 R08: ffff88847f4b8958 R09: 0000000000000000
[ 4463.070535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848a725018
[ 4463.070537] R13: 0000000000000000 R14: ffffffff827090e0 R15: 0000000000000002
[ 4463.070539] FS:  0000000000000000(0000) GS:ffff88849e800000(0000) knlGS:0000000000000000
[ 4463.070541] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4463.070543] CR2: 00007fdf8a756538 CR3: 0000000489684001 CR4: 0000000000760ef0
[ 4463.070545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4463.070547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4463.070549] PKRU: 55555554
[ 4463.070551] Call Trace:
[ 4463.070560]  device_del+0x84/0x400
[ 4463.070571]  cdev_device_del+0x10/0x30
[ 4463.070578]  put_i2c_dev+0x69/0x80
[ 4463.070584]  i2cdev_detach_adapter+0x2e/0x60
[ 4463.070591]  notifier_call_chain+0x34/0x90
[ 4463.070599]  blocking_notifier_call_chain+0x3f/0x60
[ 4463.070606]  device_del+0x7c/0x400
[ 4463.087817]  ? lockdep_init_map_waits+0x57/0x210
[ 4463.087825]  device_unregister+0x11/0x60
[ 4463.087829]  i2c_del_adapter+0x249/0x310
[ 4463.087846]  drm_dp_port_set_pdt+0x6b/0x2c0 [drm_kms_helper]
[ 4463.087862]  drm_dp_delayed_destroy_work+0x2af/0x350 [drm_kms_helper]
[ 4463.087876]  process_one_work+0x268/0x600
[ 4463.105438]  ? __schedule+0x30c/0x920
[ 4463.105451]  worker_thread+0x37/0x380
[ 4463.105457]  ? process_one_work+0x600/0x600
[ 4463.105462]  kthread+0x140/0x160
[ 4463.105466]  ? kthread_park+0x80/0x80
[ 4463.105474]  ret_from_fork+0x24/0x50

Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200607212522.16935-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/dp_mst: Fix timeout handling of MST down messages 2020-08-21T11:15:20+00:00 Imre Deak imre.deak@intel.com 2020-05-13T10:31:55+00:00 392379d6933a097f23a9ca224ac9e69be9c24812 commit 58c1721787be8a6ff28b4e5b6ce395915476871e upstream. This fixes the following use-after-free problem in case an MST down message times out, while waiting for the response for it: [ 449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send 0000000080ba7fa2 2 0 [ 449.022898] ------------[ cut here ]------------ [ 449.022903] list_add corruption. prev->next should be next (ffff88847dae32c0), but was 6b6b6b6b6b6b6b6b. (prev=ffff88847db1c140). [ 449.022931] WARNING: CPU: 2 PID: 22 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 [ 449.022935] Modules linked in: asix usbnet mii snd_hda_codec_hdmi mei_hdcp i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm pps_core mei_me mei intel_lpss_pci prime_numbers [ 449.022966] CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.7.0-rc3-CI-Patchwork_17536+ #1 [ 449.022970] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019 [ 449.022976] Workqueue: events_long drm_dp_mst_link_probe_work [ 449.022982] RIP: 0010:__list_add_valid+0x4d/0x70 [ 449.022987] Code: c3 48 89 d1 48 c7 c7 f0 e7 32 82 48 89 c2 e8 3a 49 b7 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 40 e8 32 82 e8 23 49 b7 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 90 e8 32 82 e8 [ 449.022991] RSP: 0018:ffffc900001abcb0 EFLAGS: 00010286 [ 449.022995] RAX: 0000000000000000 RBX: ffff88847dae2d58 RCX: 0000000000000001 [ 449.022999] RDX: 0000000080000001 RSI: ffff88849d914978 RDI: 00000000ffffffff [ 449.023002] RBP: ffff88847dae32c0 R08: ffff88849d914978 R09: 0000000000000000 [ 449.023006] R10: ffffc900001abcb8 R11: 0000000000000000 R12: ffff888490d98400 [ 449.023009] R13: ffff88847dae3230 R14: ffff88847db1c140 R15: ffff888490d98540 [ 449.023013] FS: 0000000000000000(0000) GS:ffff88849ff00000(0000) knlGS:0000000000000000 [ 449.023017] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.023021] CR2: 00007fb96fafdc63 CR3: 0000000005610004 CR4: 0000000000760ee0 [ 449.023025] PKRU: 55555554 [ 449.023028] Call Trace: [ 449.023034] drm_dp_queue_down_tx+0x59/0x110 [ 449.023041] ? rcu_read_lock_sched_held+0x4d/0x80 [ 449.023050] ? kmem_cache_alloc_trace+0x2a6/0x2d0 [ 449.023060] drm_dp_send_link_address+0x74/0x870 [ 449.023065] ? __slab_free+0x3e1/0x5c0 [ 449.023071] ? lockdep_hardirqs_on+0xe0/0x1c0 [ 449.023078] ? lockdep_hardirqs_on+0xe0/0x1c0 [ 449.023097] drm_dp_check_and_send_link_address+0x9a/0xc0 [ 449.023106] drm_dp_mst_link_probe_work+0x9e/0x160 [ 449.023117] process_one_work+0x268/0x600 [ 449.023124] ? __schedule+0x307/0x8d0 [ 449.023139] worker_thread+0x37/0x380 [ 449.023149] ? process_one_work+0x600/0x600 [ 449.023153] kthread+0x140/0x160 [ 449.023159] ? kthread_park+0x80/0x80 [ 449.023169] ret_from_fork+0x24/0x50 Fixes: d308a881a591 ("drm/dp_mst: Kill the second sideband tx slot, save the world") Cc: Lyude Paul <lyude@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513103155.12336-1-imre.deak@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 58c1721787be8a6ff28b4e5b6ce395915476871e upstream.

This fixes the following use-after-free problem in case an MST down
message times out, while waiting for the response for it:

[  449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send 0000000080ba7fa2 2 0
[  449.022898] ------------[ cut here ]------------
[  449.022903] list_add corruption. prev->next should be next (ffff88847dae32c0), but was 6b6b6b6b6b6b6b6b. (prev=ffff88847db1c140).
[  449.022931] WARNING: CPU: 2 PID: 22 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70
[  449.022935] Modules linked in: asix usbnet mii snd_hda_codec_hdmi mei_hdcp i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm pps_core mei_me mei intel_lpss_pci prime_numbers
[  449.022966] CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.7.0-rc3-CI-Patchwork_17536+ #1
[  449.022970] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019
[  449.022976] Workqueue: events_long drm_dp_mst_link_probe_work
[  449.022982] RIP: 0010:__list_add_valid+0x4d/0x70
[  449.022987] Code: c3 48 89 d1 48 c7 c7 f0 e7 32 82 48 89 c2 e8 3a 49 b7 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 40 e8 32 82 e8 23 49 b7 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 90 e8 32 82 e8
[  449.022991] RSP: 0018:ffffc900001abcb0 EFLAGS: 00010286
[  449.022995] RAX: 0000000000000000 RBX: ffff88847dae2d58 RCX: 0000000000000001
[  449.022999] RDX: 0000000080000001 RSI: ffff88849d914978 RDI: 00000000ffffffff
[  449.023002] RBP: ffff88847dae32c0 R08: ffff88849d914978 R09: 0000000000000000
[  449.023006] R10: ffffc900001abcb8 R11: 0000000000000000 R12: ffff888490d98400
[  449.023009] R13: ffff88847dae3230 R14: ffff88847db1c140 R15: ffff888490d98540
[  449.023013] FS:  0000000000000000(0000) GS:ffff88849ff00000(0000) knlGS:0000000000000000
[  449.023017] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  449.023021] CR2: 00007fb96fafdc63 CR3: 0000000005610004 CR4: 0000000000760ee0
[  449.023025] PKRU: 55555554
[  449.023028] Call Trace:
[  449.023034]  drm_dp_queue_down_tx+0x59/0x110
[  449.023041]  ? rcu_read_lock_sched_held+0x4d/0x80
[  449.023050]  ? kmem_cache_alloc_trace+0x2a6/0x2d0
[  449.023060]  drm_dp_send_link_address+0x74/0x870
[  449.023065]  ? __slab_free+0x3e1/0x5c0
[  449.023071]  ? lockdep_hardirqs_on+0xe0/0x1c0
[  449.023078]  ? lockdep_hardirqs_on+0xe0/0x1c0
[  449.023097]  drm_dp_check_and_send_link_address+0x9a/0xc0
[  449.023106]  drm_dp_mst_link_probe_work+0x9e/0x160
[  449.023117]  process_one_work+0x268/0x600
[  449.023124]  ? __schedule+0x307/0x8d0
[  449.023139]  worker_thread+0x37/0x380
[  449.023149]  ? process_one_work+0x600/0x600
[  449.023153]  kthread+0x140/0x160
[  449.023159]  ? kthread_park+0x80/0x80
[  449.023169]  ret_from_fork+0x24/0x50

Fixes: d308a881a591 ("drm/dp_mst: Kill the second sideband tx slot, save the world")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200513103155.12336-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>