linux-kernel - Re: [PATCH v3] drm/mediatek: mtk_dsi: Avoid EPROBE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Jan 2022 10:13:32 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Chun-Kuang Hu <chunkuang.hu@...nel.org>
Cc:     DRI Development <dri-devel@...ts.freedesktop.org>,
        David Airlie <airlied@...ux.ie>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        andrzej.hajda@...el.com,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Collabora Kernel ML <kernel@...labora.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3] drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with
 external bridge

Il 27/01/22 16:46, AngeloGioacchino Del Regno ha scritto:
> Il 27/01/22 16:21, Chun-Kuang Hu ha scritto:
>> Hi, Angelo:
>>
>> AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com> 於
>> 2022年1月27日 週四 下午10:36寫道：
>>>
>>> DRM bridge drivers are now attaching their DSI device at probe time,
>>> which requires us to register our DSI host in order to let the bridge
>>> to probe: this recently started producing an endless -EPROBE_DEFER
>>> loop on some machines that are using external bridges, like the
>>> parade-ps8640, found on the ACER Chromebook R13.
>>>
>>> Now that the DSI hosts/devices probe sequence is documented, we can
>>> do adjustments to the mtk_dsi driver as to both fix now and make sure
>>> to avoid this situation in the future: for this, following what is
>>> documented in drm_bridge.c, move the mtk_dsi component_add() to the
>>> mtk_dsi_ops.attach callback and delete it in the detach callback;
>>> keeping in mind that we are registering a drm_bridge for our DSI,
>>> which is only used/attached if the DSI Host is bound, it wouldn't
>>> make sense to keep adding our bridge at probe time (as it would
>>> be useless to have it if mtk_dsi_ops.attach() fails!), so also move
>>> that one to the dsi host attach function (and remove it in detach).
>>>
>>> Fixes: 209264a85707 ("drm/bridge: Document the probe issue with MIPI-DSI bridges")
>>
>> The fixed tag should indicate the patch which cause the bug, but why a
>> patch just adding document would cause bug?
>> So no any patch cause bug? This patch just want to prevent a possible bug?
>>
> 
> I think you've missed my previous message on v2, so I will paste it here:
> 
> unfortunately I couldn't find a valid commit for a Fixes tag. This
> started being an issue at some point, when the DRM was changed to
> adhere to the documented probe sequence: the MediaTek DSI driver was
> not the only one that got broken/affected by these changes.
> 
> If you have any advice on which commit should be tagged, I'm open for
> any kind of suggestion.
> 
> 
> I tried to check on other drivers which got fixed for the same behavior,
> for example drm/msm, but none of them had a Fixes tag.
> When the DRM got changed to adhere to this sequence, some drm/bridge
> drivers were also changed; this has created some incompatibilities with
> some drm drivers, including drm/msm and drm/mediatek.
> 
> This commit is not fixing a latent bug that was introduced in drm/mediatek
> but rather one that was induced by the new, fixed, probe flow that got
> recently documented - and to which drivers should adhere; failing to adhere
> to that will produce an endless -EPROBE_DEFER loop, due to other drivers
> (as mentioned, for example drm/bridge drivers) having been changed to use
> that probe sequence.
> 
> 
> Regards,
> Angelo
> 

I've been thinking about another solution to this issue.

Would it be fine if I send a v4 that removes the Fixes tag, but adds the following?

Cc: stable@...nel.org # v5.15+

>> Regards,
>> Chun-Kuang.
>>
>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>>> Reviewed-by: Andrzej Hajda <andrzej.hajda@...el.com>
>>> Reviewed-by: Jagan Teki <jagan@...rulasolutions.com>
>>>
>>> ---
>>>   drivers/gpu/drm/mediatek/mtk_dsi.c | 167 +++++++++++++++--------------
>>>   1 file changed, 84 insertions(+), 83 deletions(-)
>>>


-- 
AngeloGioacchino Del Regno
Software Engineer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718