Quoting Stephen Boyd (2024-08-14 17:34:05) > > I'm thinking of working in changes so that the drm_dp_typec_bridge > registers a 'struct typec_mux_dev' as well. If that is done then we can > register a drm_dp_typec_bridge from the port manager and let the type-c > framework drive the pin assignment and orientation directly instead of > calling it from the port manager layer. To get there I need to add the > ability for a 'struct typec_mux_dev' to associate with more than one > typec_port (technically already done) and then make sure that the > cros_ec_typec driver doesn't try to enable DP altmode on the type-c port > that isn't muxed for DP. I'm working on this now but I'm sending this > out to get some feedback because I've reached a good stopping place. > I've done this now, and it works well. I've extended the usb-switch.yaml file to support a third graph endpoint for DP. And I've moved the hpd notifying and lane remapping to be internal to the drm_dp_typec_bridge code so that any device that registers the auxiliary device can follow the usb-switch binding and connect the endpoint to the usb-c-connector to get hpd notifications and pin assignment basically for free. I'll send a v3 next week.