On Tue, Jun 28, 2016 at 6:40 PM, Chanwoo Choi <cwchoi00 at gmail.com> wrote: > Hi Guenter, > > 2016? 6? 29? ???, Guenter Roeck<groeck at google.com>?? ??? ???: >> >> On Tue, Jun 28, 2016 at 5:26 AM, Chanwoo Choi <cwchoi00 at gmail.com> wrote: >> > Hi Chris, >> > >> > I agree to add the new EXTCON_DISP_DP connector. >> > But, other new definition should be discussed. >> > - EXTCON_DISP_DP_ALT >> > - EXTCON_TYPEC_POLARITY >> > - EXTCON_TYPEC_PIN_ASSIGN >> > >> > I think that TYPEC_POLARITY and TYPEC_PIN_ASSING are not appropriate >> > as the new external connector definition. These are the property or >> > attribute of >> > USB connector with C-type. >> > >> > Also, EXTCON_DISP_DP_ALT is not a new type of connector. >> > It is just one of the mode for DP connector. >> > >> > As I knew, DP alternative mode use the USB connector with C-type. >> > So, DP alternative mode can be expressed on following: >> > = EXTCON_DISP_DP + EXTCON_USB + some property of USB c-type >> > >> >> Problem is that extcon doesn't support exchanging cable properties >> between cable providers (extcon drivers) and consumers, other than >> cable states. In order to exchange properties such as polarity and pin >> assignments, we would need a separate infrastructure. But then the >> question would be why to use extcon in the first place. >> >> If you have a solution for that puzzle, please let us know. >> > > You're right. > Current extcon don't support the cable properties. > The requirement about cables properties occur such as USB ID and VBUS pin. > So, I'll support the cable properties in extcon framework and send the > patches within this week. > > Maybe, the function definitions are following: > (But, these may be changed on real patches) > - extcon_set_cable_property(struct extcon_dev *edev, unsigned int id, enum > extcon_property prop, unsigned in prop_val) > - extcon_get_cable_property(struct extcon_dev *edev, unsigned int id, enum > extcon_property prop) > Excellent idea. Couple of thoughts: - We might need notifiers for property events. Not sure if the state notifiers are sufficient (properties might change independently of state). Or maybe state events could be used if a cable property (but not the state) changes ? - It might possibly make sense to make the prop argument opaque (such as u32). Properties would still be defined in extcon (such as EXTCON_PROP_TYPEC_POLARITY), but this would leave more room for cable type specific properties. After all, the properties would be cable type specific. Thanks, Guenter
