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

Chaoyi Chen <[email protected]>
Newsgroups gmane.linux.kernel,gmane.comp.video.dri.devel,gmane.linux.ports.arm.kernel,gmane.linux.ports.arm.rockchip
Message-ID <[email protected]>
Hi Sebastian,

On 7/31/2026 10:20 PM, Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Jul 30, 2026 at 09:33:44AM +0800, Chaoyi Chen wrote:
>> From: Chaoyi Chen <[email protected]>
>>
>> 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 <[email protected]>
>> Reviewed-by: Heikki Krogerus <[email protected]>
>> Reviewed-by: Nicolas Frattaroli <[email protected]>
>> ---
>>
>> (no changes since v5)
>>
>> Changes in v4:
>> - Scan the entire typec_bus and attempt to register the hpd bridge,
>>   so as not to miss devices that were already added during initialization.
>>
>> (no changes since v3)
>>
>> Changes in v2:
>> - Add copyright text.
>> - Remove useless goto.
>> ---
>>  drivers/gpu/drm/bridge/Kconfig                | 10 +++
>>  drivers/gpu/drm/bridge/Makefile               |  1 +
>>  .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c  | 64 +++++++++++++++++++
>>  3 files changed, 75 insertions(+)
>>  create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 4a57d49b4c6d..9739b2a19758 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
>>  	  Simple bridge that terminates the bridge chain and provides HPD
>>  	  support.
>>  
>> +if DRM_AUX_HPD_BRIDGE
>> +config DRM_AUX_HPD_TYPEC_BRIDGE
>> +	tristate
>> +	depends on TYPEC || !TYPEC
>> +	default TYPEC
>> +	help
>> +	  Simple bridge that terminates the bridge chain and provides HPD
>> +	  support. It build bridge on each USB-C connector device node.
>> +endif
>> +
>>  menu "Display Interface Bridges"
>>  	depends on DRM && DRM_BRIDGE
>>  
>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>> index 15cc821d85b7..d88a9e1ccc9a 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -1,6 +1,7 @@
>>  # SPDX-License-Identifier: GPL-2.0
>>  obj-$(CONFIG_DRM_AUX_BRIDGE) += aux-bridge.o
>>  obj-$(CONFIG_DRM_AUX_HPD_BRIDGE) += aux-hpd-bridge.o
>> +obj-$(CONFIG_DRM_AUX_HPD_TYPEC_BRIDGE) += aux-hpd-typec-dp-bridge.o
>>  obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
>>  obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>>  obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
>> diff --git a/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>> new file mode 100644
>> index 000000000000..43af3ea20f20
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>> @@ -0,0 +1,64 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2026 Rockchip Electronics Co., Ltd.
>> + *
>> + * Author: Chaoyi Chen <[email protected]>
>> + */
>> +#include <linux/of.h>
>> +#include <linux/usb/typec_altmode.h>
>> +#include <linux/usb/typec_dp.h>
>> +
>> +#include <drm/bridge/aux-bridge.h>
>> +
>> +static int drm_typec_bus_event(struct notifier_block *nb,
>> +			       unsigned long action, void *data)
>> +{
>> +	struct device *dev = (struct device *)data;
>> +	struct typec_altmode *alt = to_typec_altmode(dev);
>> +
>> +	if (action != BUS_NOTIFY_ADD_DEVICE)
>> +		return NOTIFY_OK;
>> +
>> +	/*
>> +	 * alt->dev.parent->parent : USB-C controller device
>> +	 * alt->dev.parent         : USB-C connector device
>> +	 */
>> +	if (is_typec_port_altmode(&alt->dev) && alt->svid == USB_TYPEC_DP_SID)
>> +		drm_dp_hpd_bridge_register(alt->dev.parent->parent,
>> +					   to_of_node(alt->dev.parent->fwnode));
> 
> So there are 3 ways to end up with duplicated hpd bridges now:
> 
> 1. TypeC controller driver already registered one manually
> 2. There is a race in drm_aux_hpd_typec_dp_bridge_module_init, if a
>    device appears between registering the notifier and looping
>    through all pre-existing devices
> 3. Reloading the aux-hpd-typec-dp-bridge module re-registers the
>    bridges
> 
> It's not a huge problem as the system works with the duplicated HPD
> bridges, but it's also quite ugly.
> 
> I think it can be trivially avoided by adding this function to
> drivers/gpu/drm/bridge/aux-hpd-bridge.c and then making use of it
> here as an additional check (code untested):
> 
> bool drm_device_has_dp_hpd_bridge(struct device *parent)
> {
> 	struct device *hpd_bridge = device_find_child_by_name(parent, "dp_hpd_bridge");
> 
> 	if (!hpd_bridge)
> 		return false;
> 
> 	put_device(hpd_bridge);
> 	return true;
> }
> EXPORT_SYMBOL_GPL(drm_dev_has_dp_hpd_bridge);
>

I think deduplication during registration is a good idea. Detecting it
during alloc seems a bit premature.

Thanks again for your suggestion. I'll try to add it in the next version.

> That would solve all of the above, but leaves one problem when this
> module races against manual device creation in a TypeC controller
> driver. That could be avoided by doing the check in
> devm_drm_dp_hpd_bridge_alloc() under a lock, but that's probably not
> worth the trouble (it would require updating all users to handle a
> new error code like -EEXIST) considering manual registration can be
> removed from all drivers anyways.
> 
> Greetings,
> 
> -- Sebastian
> 
>> +
>> +	return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block drm_typec_event_nb = {
>> +	.notifier_call = drm_typec_bus_event,
>> +};
>> +
>> +static int check_device_already_added(struct device *dev, void *data)
>> +{
>> +	drm_typec_bus_event(NULL, BUS_NOTIFY_ADD_DEVICE, dev);
>> +	return 0;
>> +}
>> +
>> +static void drm_aux_hpd_typec_dp_bridge_module_exit(void)
>> +{
>> +	bus_unregister_notifier(&typec_bus, &drm_typec_event_nb);
>> +}
>> +
>> +static int __init drm_aux_hpd_typec_dp_bridge_module_init(void)
>> +{
>> +	bus_register_notifier(&typec_bus, &drm_typec_event_nb);
>> +	/*
>> +	 * Before module initialization, some devices may have already been added.
>> +         * Register the HPD bridge for these devices.
>> +	 */
>> +	bus_for_each_dev(&typec_bus, NULL, NULL, check_device_already_added);
>> +	return 0;
>> +}
>> +
>> +module_init(drm_aux_hpd_typec_dp_bridge_module_init);
>> +module_exit(drm_aux_hpd_typec_dp_bridge_module_exit);
>> +
>> +MODULE_AUTHOR("Chaoyi Chen <[email protected]>");
>> +MODULE_DESCRIPTION("DRM TYPEC DP HPD BRIDGE");
>> +MODULE_LICENSE("GPL");
>> -- 
>> 2.53.0
>>

-- 
Best, 
Chaoyi
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.