summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>2022-07-28 03:40:57 +0200
committerRobert Foss <robert.foss@linaro.org>2022-09-01 13:43:46 +0200
commit0538fa09bb1073b19b197509c51c55496091d125 (patch)
treeaea46d797c08ed35151ba8cfcf344a2cd5f49d59
parentdrm/panfrost: Update io-pgtable API (diff)
downloadlinux-0538fa09bb1073b19b197509c51c55496091d125.tar.xz
linux-0538fa09bb1073b19b197509c51c55496091d125.zip
gpu/drm/bridge/cadence: avoid flush_scheduled_work() usage
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a macro") says, flush_scheduled_work() is dangerous and will be forbidden. We are on the way for removing all flush_scheduled_work() callers from the kernel, and this patch is for removing flush_scheduled_work() call from cadence driver. Since cdns-mhdp8546 driver uses 4 works mhdp->modeset_retry_work mhdp->hpd_work mhdp->hdcp.check_work mhdp->hdcp.prop_work I assume that flush_scheduled_work() in cdns_mhdp_remove() needs to wait for only these 4 works. Since mhdp->modeset_retry_work already uses cancel_work_sync(), I assume that flush_scheduled_work() needs to wait for only 3 works. But I came to wonder whether mhdp->hdcp.check_work should be flushed or cancelled. While flush_scheduled_work() waits for completion of works which were already queued to system_wq, mhdp->hdcp.check_work is a delayed work. That is, this work won't be queued to system_wq unless timeout expires. Current code will wait for mhdp->hdcp.check_work only if timeout already expired. If timeout is not expired yet, flush_scheduled_work() will fail to cancel mhdp->hdcp.check_work, and cdns_mhdp_hdcp_check_work() which is triggered by mhdp->hdcp.check_work will schedule hdcp->check_work, which is too late for flush_scheduled_work() to wait for completion of cdns_mhdp_hdcp_prop_work(). But since I couldn't get comments on how do we want to handle this race window [1], this patch chose "do nothing" for mhdp->hdcp.check_work and mhdp->hdcp.prop_work. That is, I assume that flush_scheduled_work() in cdns_mhdp_remove() needs to wait for only mhdp->hpd_work work. Link: https://lkml.kernel.org/r/943273cb-c2ec-24e3-5edb-64eacc6e2d30@I-love.SAKURA.ne.jp [1] Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/216591bc-28bb-0453-10bb-59e268dff540@I-love.SAKURA.ne.jp
-rw-r--r--drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index ab63e7b11944..31442a922502 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2605,7 +2605,8 @@ static int cdns_mhdp_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
cancel_work_sync(&mhdp->modeset_retry_work);
- flush_scheduled_work();
+ flush_work(&mhdp->hpd_work);
+ /* Ignoring mhdp->hdcp.check_work and mhdp->hdcp.prop_work here. */
clk_disable_unprepare(mhdp->clk);