Re: [PATCH v3 1/5] drm/bridge: Implement generic USB Type-C DP HPD bridge

[Chaoyi Chen <chaoyi.chen@rock-chips.com>]

Hi Sebastian,

On 7/21/2026 1:59 AM, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Jul 17, 2026 at 07:19:29PM +0200, Sebastian Reichel wrote:
>> On Fri, Jul 17, 2026 at 03:23:19PM +0800, Chaoyi Chen wrote:
>>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>>
>>> The HPD function of Type-C DP is implemented through
>>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>>
>>> To describe the relationship between the DP controller and the Type-C
>>> port device, we usually using drm_bridge to build a bridge chain.
>>>
>>> Now several USB-C controller drivers have already implemented the DP
>>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>>> HPD bridge on USB-C connector port device.
>>>
>>> But this requires the USB-C controller driver to manually register the
>>> HPD bridge. If the driver does not implement this feature, the bridge
>>> will not be create.
>>>
>>> So this patch implements a generic DP HPD bridge based on
>>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>>> Type-C port device containing the DP svid is registered, it will
>>> create an HPD bridge for it without the need for the USB-C controller
>>> driver to implement it.
>>>
>>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>> ---
>>
>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> # ArmSom Sige5
>>
>> I gave this a test together with the RK3588/RK3576 USB-C DP AltMode
>> patches I'm working on. As the fusb302 does a manual registration
>> for the DRM bridge in its probe function, the bridge is registered
>> twice:
>>
>> root@sige5 # cat /sys/kernel/debug/dri/bridges
>> ...
>> bridge[1]: drm_aux_hpd_bridge_funcs
>> 	refcount: 4
>> 	type: [10] DP
>> 	OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
>> 	ops: [0x4] hpd
>> bridge[2]: drm_aux_hpd_bridge_funcs
>> 	refcount: 2
>> 	type: [10] DP
>> 	OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
>> 	ops: [0x4] hpd
>> ...
>>
>> Apparently the USB-C DP AltMode keeps working, so this just wastes
>> a few CPU cycles and some memory. So this can land and then we can
>> remove the manual code from the driver as a follow-up step. I also
>> gave that a try and things keep working. I won't send the fusb302
>> patch for now to ensure its not applied before this patch lands.
> 
> The above test was done with a kernel having all config options
> built-in (i.e. no modules). Using arm64 defconfig one ends up with
> 
> CONFIG_DRM_AUX_HPD_TYPEC_BRIDGE=m
> 
> But the resulting 'aux-hpd-typec-dp-bridge' module is not loaded
> automatically resulting in missing bridge registration. Running
> 'modprobe aux-hpd-typec-dp-bridge' manually in the booted system
> does not work either as the TypeC controller has already been
> registered and no new BUS_NOTIFY_ADD_DEVICE is generated.
>

Oh, we indeed didn't consider that such a probe ordering issue exists.

The approach I came up with is to iterate through the &typec_bus after
registering the notifier, to ensure we don't miss any events that 
occurred prior:

 static int __init drm_aux_hpd_typec_dp_bridge_module_init(void)
 {
        bus_register_notifier(&typec_bus, &drm_typec_event_nb);
-
+       bus_for_each_dev(&typec_bus, NULL, NULL,
+                        check_altmode_dev_and_register_hpd_bridge);
        return 0;
 }


But I'm not sure if there are potential race conditions involved.
Perhaps @Heikki and others have better ideas? Thanks.

> Greetings,
> 
> -- Sebastian

-- 
Best, 
Chaoyi