[v3 PATCH 1/5] extcon: Add Type-C and DP support

[Guenter Roeck]

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