Re: [PATCH] drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_enable

[Yongxing Mou <yongxing.mou@oss.qualcomm.com>]

On 10/21/2026 3:34 PM, Luca Ceresoli wrote:
> Hello Yongxing, Dmitry,
> 
>> If a downstream consumer (e.g. drm_bridge_connector attached by the
>> msm/dp driver) registers its HPD callback after an upstream driver
>> has already reported a HPD event through drm_aux_hpd_bridge_notify(),
>> the notification is dropped because bridge->hpd_cb is still NULL.
>> This can affect any user of drm_aux_hpd_bridge_notify() whose
>> downstream consumer arms HPD only after upstream events have started.
>>
>> The race has been observed on Qualcomm X1E-based laptops during boot,
>> when pmic_glink_altmode reports the initial USB-C DP connection state
>> before the DP driver has finished probing and enabled HPD handling on
>> the bridge. The consumer then never observes the initial connected
>> state and the external display remains dark.
>>
>> Cache the last HPD status reported through drm_aux_hpd_bridge_notify()
>> and replay it when HPD is enabled by the downstream consumer.
>>
>> The replay is deferred to a work item so that the replayed HPD
>> notification is delivered outside drm_bridge_hpd_enable()'s call
>> context.
>>
>> This follows the same pattern as display-connector, which also defers
>> an initial HPD notification from .hpd_enable(), but reuses the cached
>> status since aux-hpd-bridge cannot re-detect sink presence on its own.
>>
>> Fixes: e560518a6c2e ("drm/bridge: implement generic DP HPD bridge")
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> 
> Is this patch still current?
> 
> It looks mostly OK at quick glance, but there are issues reported by
> sashiko which look valid to me. If you could reply to those remarks, either
> confirming the issue or explaining why it isn't, it would help reviewing.
> 
Hi, thanks for reminder, will apply AI commenst later and post V2.> 
@Dmitry: I'm not familiar with this code, do you have any comment on this
> patch?
> 
> Luca
>