On 10/21/2025 4:48 PM, Heikki Krogerus wrote:
Hi,
On Mon, Oct 20, 2025 at 07:07:46PM +0800, Chaoyi Chen wrote:
Hi Heikki,
On 10/20/2025 6:02 PM, Heikki Krogerus wrote:
On Thu, Oct 16, 2025 at 10:27:34AM +0800, Chaoyi Chen wrote:
From: Chaoyi Chen <[email protected]>
Add default DRM AUX HPD bridge device when register DisplayPort
altmode. That makes it redundant for each Type-C driver to implement
a similar registration process in embedded scenarios.
Signed-off-by: Chaoyi Chen <[email protected]>
---
Changes in v6:
- Fix depend in Kconfig.
Changes in v5:
- Remove the calls related to `drm_aux_hpd_bridge_notify()`.
- Place the helper functions in the same compilation unit.
- Add more comments about parent device.
drivers/usb/typec/Kconfig | 2 ++
drivers/usb/typec/class.c | 26 ++++++++++++++++++++++++++
include/linux/usb/typec_altmode.h | 2 ++
3 files changed, 30 insertions(+)
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 2f80c2792dbd..a6730fbb576b 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -2,6 +2,8 @@
menuconfig TYPEC
tristate "USB Type-C Support"
+ depends on DRM || DRM=n
+ select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
This is wrong. DRM should not dictate how this entire subsystem core
is configured. The dependency needs to be on the DRM bridge side.
You can for example use the bus notification there to see when a new
alternate mode is being registered, or use some other notification
mechanism.
Is it a good idea to implement notification functions like
drivers/usb/core/notify.c in TCPM, and then let other subsystems (such as DRM)
listen to these notifications?
Don't limit this to tcpm only. I would suggest something similar what
we have for usb bus: drivers/usb/core/notify.c
So that, but for the typec bus. Then in DRM bridge code you just use
typec_register/unregister_notify().
I will try to add drivers/usb/typec/notify.c in v7 to implement this. Thank you.
thanks,
--
Best,
Chaoyi
