From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Several USB-C controller drivers have already implemented the DP HPD
bridge function provided by aux-hpd-bridge.c, but there are still
some USB-C controller driver that have not yet implemented it.
This patch implements a generic DP HPD bridge based on aux-hpd-bridge.c,
so that other USB-C controller drivers don't need to implement it again.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
---
drivers/gpu/drm/bridge/Kconfig | 11 ++++
drivers/gpu/drm/bridge/Makefile | 1 +
.../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 51 +++++++++++++++++++
3 files changed, 63 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 b9e0ca85226a..9f31540d3ad8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -33,6 +33,17 @@ config DRM_AUX_HPD_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
+config DRM_AUX_TYPEC_DP_HPD_BRIDGE
+ tristate "TypeC DP HPD bridge"
+ depends on DRM_BRIDGE && OF && TYPEC
+ select DRM_AUX_HPD_BRIDGE
+ help
+ Simple USB Type-C DP bridge that terminates the bridge chain and
+ provides HPD support.
+
+ If the USB-C controller driver has not implemented this and you need
+ the DP HPD support, say "Y" or "m" here.
+
config DRM_CHIPONE_ICN6211
tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 245e8a27e3fc..e91736829167 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_TYPEC_DP_HPD_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..2235b7438fe9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include <linux/of.h>
+#include <linux/usb/typec_altmode.h>
+#include <linux/usb/typec_dp.h>
+#include <linux/usb/typec_notify.h>
+
+#include <drm/bridge/aux-bridge.h>
+
+static int drm_typec_bus_event(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct typec_altmode *alt = (struct typec_altmode *)data;
+
+ if (action != TYPEC_ALTMODE_REGISTERED)
+ goto done;
+
+ if (alt->svid != USB_TYPEC_DP_SID)
+ goto done;
+
+ /*
+ * alt->dev.parent->parent : USB-C controller device
+ * alt->dev.parent : USB-C connector device
+ */
+ drm_dp_hpd_bridge_register(alt->dev.parent->parent,
+ to_of_node(alt->dev.parent->fwnode));
+
+done:
+ return NOTIFY_OK;
+}
+
+static struct notifier_block drm_typec_event_nb = {
+ .notifier_call = drm_typec_bus_event,
+};
+
+static void drm_aux_hpd_typec_dp_bridge_module_exit(void)
+{
+ typec_unregister_notify(&drm_typec_event_nb);
+}
+
+static int __init drm_aux_hpd_typec_dp_bridge_module_init(void)
+{
+ typec_register_notify(&drm_typec_event_nb);
+
+ return 0;
+}
+
+module_init(drm_aux_hpd_typec_dp_bridge_module_init);
+module_exit(drm_aux_hpd_typec_dp_bridge_module_exit);
+
+MODULE_DESCRIPTION("DRM TYPEC DP HPD BRIDGE");
+MODULE_LICENSE("GPL");
--
2.49.0On Thu, Oct 23, 2025 at 11:30:02AM +0800, Chaoyi Chen wrote:
> +static int drm_typec_bus_event(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct typec_altmode *alt = (struct typec_altmode *)data;
> +
> + if (action != TYPEC_ALTMODE_REGISTERED)
> + goto done;
> +
> + if (alt->svid != USB_TYPEC_DP_SID)
> + goto done;
> +
> + /*
> + * alt->dev.parent->parent : USB-C controller device
> + * alt->dev.parent : USB-C connector device
> + */
> + drm_dp_hpd_bridge_register(alt->dev.parent->parent,
> + to_of_node(alt->dev.parent->fwnode));
Okay, this explains it. So you do need the port altmode.
So you'll need to export the device types and check that the parent of
the altmode is the port instead of partner.
if (!is_typec_port(alt->dev.parent) || alt->svid != USB_TYPEC_DP_SID)
return NOTIFY_DONE;
I think we might as well export all the types while at it. Check the
attachment.
thanks,
--
heikki
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 9b2647cb199b..f0704d605595 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -790,6 +790,7 @@ const struct device_type typec_partner_dev_type = {
.groups = typec_partner_groups,
.release = typec_partner_release,
};
+EXPORT_SYMBOL_GPL(typec_partner_dev_type);
static void typec_partner_link_device(struct typec_partner *partner, struct device *dev)
{
@@ -1144,6 +1145,7 @@ const struct device_type typec_plug_dev_type = {
.groups = typec_plug_groups,
.release = typec_plug_release,
};
+EXPORT_SYMBOL_GPL(typec_plug_dev_type);
/**
* typec_plug_set_num_altmodes - Set the number of available plug altmodes
@@ -1292,6 +1294,7 @@ const struct device_type typec_cable_dev_type = {
.groups = typec_cable_groups,
.release = typec_cable_release,
};
+EXPORT_SYMBOL_GPL(typec_cable_dev_type);
/**
* typec_cable_get - Get a reference to the USB Type-C cable
@@ -2031,6 +2034,7 @@ const struct device_type typec_port_dev_type = {
.uevent = typec_uevent,
.release = typec_release,
};
+EXPORT_SYMBOL_GPL(typec_port_dev_type);
/* --------------------------------------- */
/* Driver callbacks to report role updates */
diff --git a/drivers/usb/typec/class.h b/drivers/usb/typec/class.h
index db2fe96c48ff..f04f6987bed8 100644
--- a/drivers/usb/typec/class.h
+++ b/drivers/usb/typec/class.h
@@ -87,16 +87,6 @@ struct typec_port {
#define to_typec_cable(_dev_) container_of(_dev_, struct typec_cable, dev)
#define to_typec_partner(_dev_) container_of(_dev_, struct typec_partner, dev)
-extern const struct device_type typec_partner_dev_type;
-extern const struct device_type typec_cable_dev_type;
-extern const struct device_type typec_plug_dev_type;
-extern const struct device_type typec_port_dev_type;
-
-#define is_typec_partner(dev) ((dev)->type == &typec_partner_dev_type)
-#define is_typec_cable(dev) ((dev)->type == &typec_cable_dev_type)
-#define is_typec_plug(dev) ((dev)->type == &typec_plug_dev_type)
-#define is_typec_port(dev) ((dev)->type == &typec_port_dev_type)
-
extern const struct class typec_mux_class;
extern const struct class retimer_class;
extern const struct class typec_class;
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 309251572e2e..02fed8293415 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -56,6 +56,16 @@ enum typec_role {
TYPEC_SOURCE,
};
+extern const struct device_type typec_partner_dev_type;
+extern const struct device_type typec_cable_dev_type;
+extern const struct device_type typec_plug_dev_type;
+extern const struct device_type typec_port_dev_type;
+
+#define is_typec_partner(dev) ((dev)->type == &typec_partner_dev_type)
+#define is_typec_cable(dev) ((dev)->type == &typec_cable_dev_type)
+#define is_typec_plug(dev) ((dev)->type == &typec_plug_dev_type)
+#define is_typec_port(dev) ((dev)->type == &typec_port_dev_type)
+
static inline int is_sink(enum typec_role role)
{
return role == TYPEC_SINK;
On 10/24/2025 4:01 PM, Heikki Krogerus wrote:
> On Thu, Oct 23, 2025 at 11:30:02AM +0800, Chaoyi Chen wrote:
>> +static int drm_typec_bus_event(struct notifier_block *nb,
>> + unsigned long action, void *data)
>> +{
>> + struct typec_altmode *alt = (struct typec_altmode *)data;
>> +
>> + if (action != TYPEC_ALTMODE_REGISTERED)
>> + goto done;
>> +
>> + if (alt->svid != USB_TYPEC_DP_SID)
>> + goto done;
>> +
>> + /*
>> + * alt->dev.parent->parent : USB-C controller device
>> + * alt->dev.parent : USB-C connector device
>> + */
>> + drm_dp_hpd_bridge_register(alt->dev.parent->parent,
>> + to_of_node(alt->dev.parent->fwnode));
> Okay, this explains it. So you do need the port altmode.
>
> So you'll need to export the device types and check that the parent of
> the altmode is the port instead of partner.
>
> if (!is_typec_port(alt->dev.parent) || alt->svid != USB_TYPEC_DP_SID)
> return NOTIFY_DONE;
>
> I think we might as well export all the types while at it. Check the
> attachment.
Oh, I did miss the existence of partner. Thank you for your code!
>
> thanks,
>
--
Best,
Chaoyi
On Thu, Oct 23, 2025 at 11:30:02AM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> Several USB-C controller drivers have already implemented the DP HPD
> bridge function provided by aux-hpd-bridge.c, but there are still
> some USB-C controller driver that have not yet implemented it.
>
> This patch implements a generic DP HPD bridge based on aux-hpd-bridge.c,
> so that other USB-C controller drivers don't need to implement it again.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
> drivers/gpu/drm/bridge/Kconfig | 11 ++++
> drivers/gpu/drm/bridge/Makefile | 1 +
> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 51 +++++++++++++++++++
> 3 files changed, 63 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 b9e0ca85226a..9f31540d3ad8 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -33,6 +33,17 @@ config DRM_AUX_HPD_BRIDGE
> menu "Display Interface Bridges"
> depends on DRM && DRM_BRIDGE
>
> +config DRM_AUX_TYPEC_DP_HPD_BRIDGE
> + tristate "TypeC DP HPD bridge"
> + depends on DRM_BRIDGE && OF && TYPEC
> + select DRM_AUX_HPD_BRIDGE
> + help
> + Simple USB Type-C DP bridge that terminates the bridge chain and
> + provides HPD support.
> +
> + If the USB-C controller driver has not implemented this and you need
> + the DP HPD support, say "Y" or "m" here.
You don't need to depend on DRM_BRIDGE separately, but do you really
need a separate module for this in the first place?
> config DRM_CHIPONE_ICN6211
> tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 245e8a27e3fc..e91736829167 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_TYPEC_DP_HPD_BRIDGE) += aux-hpd-typec-dp-bridge.o
Instead, why not just make that a part of aux-hpd-bridge
conditionally:
ifneq ($(CONFIG_TYPEC),)
aux-hpd-bridge-y += aux-hpd-typec-dp-bridge.o
endif
thanks,
--
heikki
Hi Heikki, On 10/23/2025 4:45 PM, Heikki Krogerus wrote: > On Thu, Oct 23, 2025 at 11:30:02AM +0800, Chaoyi Chen wrote: >> From: Chaoyi Chen <chaoyi.chen@rock-chips.com> >> >> Several USB-C controller drivers have already implemented the DP HPD >> bridge function provided by aux-hpd-bridge.c, but there are still >> some USB-C controller driver that have not yet implemented it. >> >> This patch implements a generic DP HPD bridge based on aux-hpd-bridge.c, >> so that other USB-C controller drivers don't need to implement it again. >> >> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> >> --- >> drivers/gpu/drm/bridge/Kconfig | 11 ++++ >> drivers/gpu/drm/bridge/Makefile | 1 + >> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 51 +++++++++++++++++++ >> 3 files changed, 63 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 b9e0ca85226a..9f31540d3ad8 100644 >> --- a/drivers/gpu/drm/bridge/Kconfig >> +++ b/drivers/gpu/drm/bridge/Kconfig >> @@ -33,6 +33,17 @@ config DRM_AUX_HPD_BRIDGE >> menu "Display Interface Bridges" >> depends on DRM && DRM_BRIDGE >> >> +config DRM_AUX_TYPEC_DP_HPD_BRIDGE >> + tristate "TypeC DP HPD bridge" >> + depends on DRM_BRIDGE && OF && TYPEC >> + select DRM_AUX_HPD_BRIDGE >> + help >> + Simple USB Type-C DP bridge that terminates the bridge chain and >> + provides HPD support. >> + >> + If the USB-C controller driver has not implemented this and you need >> + the DP HPD support, say "Y" or "m" here. > You don't need to depend on DRM_BRIDGE separately, but do you really > need a separate module for this in the first place? > >> config DRM_CHIPONE_ICN6211 >> tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge" >> depends on OF >> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile >> index 245e8a27e3fc..e91736829167 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_TYPEC_DP_HPD_BRIDGE) += aux-hpd-typec-dp-bridge.o > Instead, why not just make that a part of aux-hpd-bridge > conditionally: > > ifneq ($(CONFIG_TYPEC),) > aux-hpd-bridge-y += aux-hpd-typec-dp-bridge.o > endif Oh, I did consider that! But I noticed that aux-hpd-bridge.c contains the following statement module_auxiliary_driver(drm_aux_hpd_bridge_drv), which already includes a module_init. In the newly added file, in order to call the register function, another module_init was also added. If the two files are each made into a module separately, would there be a problem? > > > thanks, > -- Best, Chaoyi
> > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> > > index 245e8a27e3fc..e91736829167 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_TYPEC_DP_HPD_BRIDGE) += aux-hpd-typec-dp-bridge.o
> > Instead, why not just make that a part of aux-hpd-bridge
> > conditionally:
> >
> > ifneq ($(CONFIG_TYPEC),)
> > aux-hpd-bridge-y += aux-hpd-typec-dp-bridge.o
> > endif
>
> Oh, I did consider that! But I noticed that aux-hpd-bridge.c contains the
> following statement module_auxiliary_driver(drm_aux_hpd_bridge_drv), which
> already includes a module_init. In the newly added file, in order to call the
> register function, another module_init was also added. If the two files are
> each made into a module separately, would there be a problem?
You would not call module_init() from the new file. Instead you would
call drm_aux_hpd_typec_dp_bridge_init() and what ever directly from
aux-hpd-bridge.c:
diff --git a/drivers/gpu/drm/bridge/aux-bridge.h b/drivers/gpu/drm/bridge/aux-bridge.h
new file mode 100644
index 000000000000..ae689a7778fa
--- /dev/null
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef AUX_HPD_BRIDGE_H
+#define AUX_HPD_BRIDGE_H
+
+#if IS_ENABLED(CONFIG_TYPEC)
+int drm_aux_hpd_typec_dp_bridge_init(void);
+void drm_aux_hpd_typec_dp_bridge_exit(void);
+#else
+static inline int drm_aux_hpd_typec_dp_bridge_init(void) { return 0; }
+static inline void drm_aux_hpd_typec_dp_bridge_exit(void) { }
+#endif /* IS_ENABLED(CONFIG_TYPEC) */
+
+#endif /* AUX_HPD_BRIDGE_H */
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index 2e9c702c7087..3578df1df78a 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -12,6 +12,8 @@
#include <drm/drm_bridge.h>
#include <drm/bridge/aux-bridge.h>
+#include "aux-hpd-bridge.h"
+
static DEFINE_IDA(drm_aux_hpd_bridge_ida);
struct drm_aux_hpd_bridge_data {
@@ -190,9 +192,16 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
auxiliary_set_drvdata(auxdev, data);
+ drm_aux_hpd_typec_dp_bridge_init();
+
return devm_drm_bridge_add(data->dev, &data->bridge);
}
+static void drm_aux_hpd_bridge_remove(struct auxiliary_device *auxdev)
+{
+ drm_aux_hpd_typec_dp_bridge_exit();
+}
+
static const struct auxiliary_device_id drm_aux_hpd_bridge_table[] = {
{ .name = KBUILD_MODNAME ".dp_hpd_bridge", .driver_data = DRM_MODE_CONNECTOR_DisplayPort, },
{},
@@ -203,6 +212,7 @@ static struct auxiliary_driver drm_aux_hpd_bridge_drv = {
.name = "aux_hpd_bridge",
.id_table = drm_aux_hpd_bridge_table,
.probe = drm_aux_hpd_bridge_probe,
+ .remove = drm_aux_hpd_bridge_remove,
};
module_auxiliary_driver(drm_aux_hpd_bridge_drv);
--
heikki
Hi Heikki,
On 10/23/2025 8:03 PM, Heikki Krogerus wrote:
>>>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>>>> index 245e8a27e3fc..e91736829167 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_TYPEC_DP_HPD_BRIDGE) += aux-hpd-typec-dp-bridge.o
>>> Instead, why not just make that a part of aux-hpd-bridge
>>> conditionally:
>>>
>>> ifneq ($(CONFIG_TYPEC),)
>>> aux-hpd-bridge-y += aux-hpd-typec-dp-bridge.o
>>> endif
>> Oh, I did consider that! But I noticed that aux-hpd-bridge.c contains the
>> following statement module_auxiliary_driver(drm_aux_hpd_bridge_drv), which
>> already includes a module_init. In the newly added file, in order to call the
>> register function, another module_init was also added. If the two files are
>> each made into a module separately, would there be a problem?
> You would not call module_init() from the new file. Instead you would
> call drm_aux_hpd_typec_dp_bridge_init() and what ever directly from
> aux-hpd-bridge.c:
>
> diff --git a/drivers/gpu/drm/bridge/aux-bridge.h b/drivers/gpu/drm/bridge/aux-bridge.h
> new file mode 100644
> index 000000000000..ae689a7778fa
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef AUX_HPD_BRIDGE_H
> +#define AUX_HPD_BRIDGE_H
> +
> +#if IS_ENABLED(CONFIG_TYPEC)
> +int drm_aux_hpd_typec_dp_bridge_init(void);
> +void drm_aux_hpd_typec_dp_bridge_exit(void);
> +#else
> +static inline int drm_aux_hpd_typec_dp_bridge_init(void) { return 0; }
> +static inline void drm_aux_hpd_typec_dp_bridge_exit(void) { }
> +#endif /* IS_ENABLED(CONFIG_TYPEC) */
> +
> +#endif /* AUX_HPD_BRIDGE_H */
> diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> index 2e9c702c7087..3578df1df78a 100644
> --- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> @@ -12,6 +12,8 @@
> #include <drm/drm_bridge.h>
> #include <drm/bridge/aux-bridge.h>
>
> +#include "aux-hpd-bridge.h"
> +
> static DEFINE_IDA(drm_aux_hpd_bridge_ida);
>
> struct drm_aux_hpd_bridge_data {
> @@ -190,9 +192,16 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
>
> auxiliary_set_drvdata(auxdev, data);
>
> + drm_aux_hpd_typec_dp_bridge_init();
> +
> return devm_drm_bridge_add(data->dev, &data->bridge);
> }
>
> +static void drm_aux_hpd_bridge_remove(struct auxiliary_device *auxdev)
> +{
> + drm_aux_hpd_typec_dp_bridge_exit();
> +}
> +
> static const struct auxiliary_device_id drm_aux_hpd_bridge_table[] = {
> { .name = KBUILD_MODNAME ".dp_hpd_bridge", .driver_data = DRM_MODE_CONNECTOR_DisplayPort, },
> {},
> @@ -203,6 +212,7 @@ static struct auxiliary_driver drm_aux_hpd_bridge_drv = {
> .name = "aux_hpd_bridge",
> .id_table = drm_aux_hpd_bridge_table,
> .probe = drm_aux_hpd_bridge_probe,
> + .remove = drm_aux_hpd_bridge_remove,
> };
> module_auxiliary_driver(drm_aux_hpd_bridge_drv);
Yes, if we don't distinguish them through Kconfig, we need to use the IS_ENABLED macro in the code. Thanks again for you code.
Another thing is that CONFIG_DRM_AUX_HPD_BRIDGE originally needed to be selected by other modules. With this change, we also need to expose it in Kconfig.
>
>
--
Best,
Chaoyi
> Another thing is that CONFIG_DRM_AUX_HPD_BRIDGE originally needed to be > selected by other modules. With this change, we also need to expose it in > Kconfig. Sorry, I don't understand the problem here? What do you need to expose in Kconfig? thanks, -- heikki
On 10/24/2025 3:36 PM, Heikki Krogerus wrote: >> Another thing is that CONFIG_DRM_AUX_HPD_BRIDGE originally needed to be >> selected by other modules. With this change, we also need to expose it in >> Kconfig. > Sorry, I don't understand the problem here? What do you need to expose > in Kconfig? config DRM_AUX_HPD_BRIDGE tristate depends on DRM_BRIDGE && OF select AUXILIARY_BUS help Simple bridge that terminates the bridge chain and provides HPD support. The tristate here is empty, so now it can only be selected by some TypeC controller drivers. I think it's not a big deal, just expose this item. > > thanks, > -- Best, Chaoyi
On Fri, Oct 24, 2025 at 04:12:47PM +0800, Chaoyi Chen wrote: > On 10/24/2025 3:36 PM, Heikki Krogerus wrote: > > > > Another thing is that CONFIG_DRM_AUX_HPD_BRIDGE originally needed to be > > > selected by other modules. With this change, we also need to expose it in > > > Kconfig. > > Sorry, I don't understand the problem here? What do you need to expose > > in Kconfig? > > config DRM_AUX_HPD_BRIDGE > tristate > depends on DRM_BRIDGE && OF > select AUXILIARY_BUS > help > Simple bridge that terminates the bridge chain and provides HPD > support. > > The tristate here is empty, so now it can only be selected by some TypeC > controller drivers. I think it's not a big deal, just expose this item. Ah, got it. thanks, -- heikki
© 2016 - 2026 Red Hat, Inc.