Hi Laurent,
On Sun, 2020-06-28 at 11:22 +0300, Laurent Pinchart wrote:
Hi Liu,
(CC'ing Sam)
Thank you for the patch.
Thanks for your review.
On Tue, Jun 16, 2020 at 05:04:52PM +0800, Liu Ying wrote:
It doesn't hurt to add the bridge in the global bridge list also for platform specific dw-hdmi drivers which are based on the component framework. This can be achieved by moving the drm_bridge_add() function call from dw_hdmi_probe() to __dw_hdmi_probe(). Moreover, putting the drm_bridge_add() function call prior to the interrupt registration and enablement ensures that the mutex hpd_mutex embedded in the structure drm_bridge can be initialized in drm_bridge_add() beforehand, which avoids accessing the uninitialized mutex in case people want to call function drm_bridge_hpd_notify() with the mutex locked internally to handle hot plug detection event in the interrupt handler dw_hdmi_irq().
Cc: Andrzej Hajda a.hajda@samsung.com Cc: Neil Armstrong narmstrong@baylibre.com Cc: Laurent Pinchart Laurent.pinchart@ideasonboard.com Cc: Jonas Karlman jonas@kwiboo.se Cc: Jernej Skrabec jernej.skrabec@siol.net Cc: David Airlie airlied@linux.ie Cc: Daniel Vetter daniel@ffwll.ch Cc: Boris Brezillon boris.brezillon@collabora.com Cc: Jerome Brunet jbrunet@baylibre.com Cc: Cheng-Yi Chiang cychiang@chromium.org Cc: Dariusz Marcinkiewicz darekm@google.com Cc: Archit Taneja architt@codeaurora.org Cc: Jose Abreu joabreu@synopsys.com Cc: dri-devel@lists.freedesktop.org Cc: NXP Linux Team linux-imx@nxp.com Signed-off-by: Liu Ying victor.liu@nxp.com
Laurent,
I may see the uninitialized mutex accessing issue with i.MX dw-hdmi after applying your below patch set[1]. I think patch '[22/27] drm: bridge: dw-hdmi: Make connector creation optional' triggers the issue.
[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork....
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 34 ++++++++++++++-----
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index da84a91..4711700 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -3247,17 +3247,25 @@ __dw_hdmi_probe(struct platform_device *pdev,
dw_hdmi_init_hw(hdmi);
- hdmi->bridge.driver_private = hdmi;
- hdmi->bridge.funcs = &dw_hdmi_bridge_funcs;
+#ifdef CONFIG_OF
- hdmi->bridge.of_node = pdev->dev.of_node;
+#endif
- drm_bridge_add(&hdmi->bridge);
This would introduce a race condition where a display driver could get hold of the bridge before it is fully initialized.
Yes, it seems it's a bit too early to add the bridge in the global bridge list.
I fear the right fix for this may be to add a drm_bridge_init() function to move mutex initialization away from drm_bridge_add(). That's a rather intrusive change I'm afraid :-(
Looking into the issue more closely, it may be solved by moving drm_bridge_add() from dw_hdmi_probe() to __dw_hdmi_probe() just before __dw_hdmi_probe() returns successfully and a counterpart movement for drm_bridge_remove(). The key is that hdmi->bridge.dev must be !NULL when drm_bridge_hpd_notify() is called in dw_hdmi_irq() and hdmi->bridge.dev is set in drm_bridge_attach() after drm_bridge_add() is called.
This looks more safe because there is no logic change as dw_hdmi_probe()/dw_hdmi_remove() see and just an additional drm_bridge_add()/drm_bridge_remove() call as dw_hdmi_bind()/dw_hdmi_unbind() see.
I plan to test this with i.MX dw-hdmi tomorrow.
- irq = platform_get_irq(pdev, 0); if (irq < 0) { ret = irq;
goto err_iahb;
goto err_irq;}
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq, dw_hdmi_irq, IRQF_SHARED, dev_name(dev), hdmi); if (ret)
goto err_iahb;
goto err_irq;/*
- To prevent overflows in HDMI_IH_FC_STAT2, set the clk
regenerator @@ -3290,12 +3298,6 @@ __dw_hdmi_probe(struct platform_device *pdev, hdmi->ddc = NULL; }
- hdmi->bridge.driver_private = hdmi;
- hdmi->bridge.funcs = &dw_hdmi_bridge_funcs;
-#ifdef CONFIG_OF
- hdmi->bridge.of_node = pdev->dev.of_node;
-#endif
- if (hdmi->version >= 0x200a) hdmi->connector.ycbcr_420_allowed = hdmi->plat_data->ycbcr_420_allowed;
@@ -3357,6 +3359,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
return hdmi;
+err_irq:
- drm_bridge_remove(&hdmi->bridge);
err_iahb: clk_disable_unprepare(hdmi->iahb_clk); if (hdmi->cec_clk) @@ -3371,6 +3375,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
static void __dw_hdmi_remove(struct dw_hdmi *hdmi) {
- drm_bridge_remove(&hdmi->bridge);
- if (hdmi->audio && !IS_ERR(hdmi->audio)) platform_device_unregister(hdmi->audio); if (!IS_ERR(hdmi->cec))
@@ -3396,22 +3402,12 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi) struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, const struct dw_hdmi_plat_data *plat_data) {
- struct dw_hdmi *hdmi;
- hdmi = __dw_hdmi_probe(pdev, plat_data);
- if (IS_ERR(hdmi))
return hdmi;- drm_bridge_add(&hdmi->bridge);
- return hdmi;
- return __dw_hdmi_probe(pdev, plat_data);
} EXPORT_SYMBOL_GPL(dw_hdmi_probe);
Do we need to keep __dw_hdmi_probe() and dw_hdmi_probe(), can't we rename __dw_hdmi_probe() to dw_hdmi_probe() ? Same for the remove functions.
Yes, the renaming makes sense. Will do that in V2 if the above new solution stands.
Regards, Liu Ying
void dw_hdmi_remove(struct dw_hdmi *hdmi) {
- drm_bridge_remove(&hdmi->bridge);
- __dw_hdmi_remove(hdmi);
} EXPORT_SYMBOL_GPL(dw_hdmi_remove);