Quoting Tzung-Bi Shih (2024-08-22 07:37:05) > On Mon, Aug 19, 2024 at 03:38:30PM -0700, Stephen Boyd wrote: > > @@ -671,6 +674,20 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num, > > if (port->mux_flags == resp.flags && port->role == pd_ctrl->role) > > return 0; > > > > + dp_enabled = resp.flags & USB_PD_MUX_DP_ENABLED; > > + hpd_asserted = resp.flags & USB_PD_MUX_HPD_LVL; > > + /* > > + * Assume the first port to have HPD asserted is the one muxed to DP > > + * (i.e. active_port). When there's only one port this delays setting > > + * the active_port until HPD is asserted, but before that the > > + * drm_connector looks disconnected so active_port doesn't need to be > > + * set. > > + */ > > + if (dp_bridge && hpd_asserted && !dp_bridge->active_port) > > + dp_bridge->active_port = port; > > + > > + is_active_port = !dp_bridge || dp_bridge->active_port == port; > > Why `!dp_bridge`? When will `dp_bridge` be NULL? I'll add a comment. 'dp_bridge' is NULL when this driver is running on non-DT platforms, i.e. ACPI, or there isn't a graph/ports node for this device. The latter could happen if there's some AP controlled piece of hardware that is a typec switch, connected directly to a usb-c-connector. This is the case on Kukui where we send the DP lanes directly to the usb-c-connector.
