On Tue, Sep 03, 2024 at 06:20:14PM -0400, Stephen Boyd wrote: > Quoting Andy Shevchenko (2024-09-02 04:35:46) > > On Sat, Aug 31, 2024 at 09:06:44PM -0700, Stephen Boyd wrote: > > > Extend the aux-hpd bridge driver to support assigning DP lanes to USB > > > type-c pins based on typec mux state entry. Existing users of this > > > driver only need the HPD signaling support, so leave that in place and > > > wrap the code with a variant that supports more features of USB type-c > > > > Isn't the proper spelling "USB Type-C"? > > Perhaps in a title? I am talking about the commit message :-) > > > DP altmode, i.e. pin configurations. Prefix that code with > > > 'drm_dp_typec_bridge' to differentiate it from the existing > > > 'drm_aux_hpd_bridge' code. > > > > > > Parse the struct typec_mux_state members to determine if DP altmode has > > > been entered and if HPD is asserted or not. Signal HPD to the drm bridge > > > chain when HPD is asserted. Similarly, parse the pin assignment and map > > > the DP lanes to the usb-c output lanes, taking into account any lane > > > remapping from the data-lanes endpoint property. Pass that lane mapping > > > to the previous drm_bridge in the bridge chain during the atomic check > > > phase. ... > > > + adev->dev.of_node = of_node_get(parent->of_node); > > > > device_set_node() ? > > Or device_set_of_node_from_dev()? This is quite unclear to me. The second one bumps the reference count IIRC for no reason (in usual cases). Also only few drivers use that, I would hear what OF people can tell about this API and its usage scope. ... > > > +static int dp_lane_to_typec_lane(enum dp_lane lane) > > > +{ > > > + switch (lane) { > > > + case DP_ML0: > > > + return USB_SSTX2; > > > + case DP_ML1: > > > + return USB_SSRX2; > > > + case DP_ML2: > > > + return USB_SSTX1; > > > + case DP_ML3: > > > + return USB_SSRX1; > > > + } > > > > > + return -EINVAL; > > > > Hmm... This can be simply made as default case. > > And then the enum is always "covered" and the compiler doesn't complain > about missing cases (I don't think we have -Wswitch-enum)? Seems worse. Hmm... You mean if I remove one of the above cases I will get the warning? > > > +} -- With Best Regards, Andy Shevchenko