RE: [PATCH v17 2/3] usb: USB Type-C connector class

[Peter Chen]

>>> You mean type-C trigger an ACPI event, and this ACPI event can notify
>>> related USB controller driver doing role switch?
>>
>> No (firmware programs the dual-role hw/registers), but never mind.
>> That could be the case.
>>
>>> If it is correct, there is a notifier between type-C and USB
>>> controller driver, how to define this notifier for non-ACPI platform?
>>
>> Once there is a platform with Type-C like that, the problem needs to
>> be solved. However..
>>
>>>> I'm not commenting on Roger's dual role patch series, but I don't
>>>> really think it should be mixed with Type-C. USB Type-C and USB
>>>> Power Delivery define their own ways of handling the roles, and they
>>>> are not limited to the data role only. Things like OTG for example
>>>> will, and actually can not be supported. With Type-C we will have
>>>> competing state machines compared to OTG. The dual-role framework
>>>> may be useful on systems that provide more traditional connectors,
>>>> which possibly have the ID-pin like micro-AB, and possibly also
>>>> support OTG. It can also be something that exist in parallel with the Type-C
>class, but there just can not be any dependencies between the two.
>>>>
>>>
>>> Yes, there are two independent things. But if the kernel doesn't have
>>> a notifier between type-C message sender (type-c class) and message
>>> receiver (like USB controller driver for role switch or other drivers
>>> for alternate mode message), we had to find some ways at userspace.
>>
>> ..what ever the solution is, it really can't rely on user space.
>>
>
>... and, at least for our application, using extcon for the necessary notifications works
>just fine.
>

I see, that means you have a hardware signal to notify role switch.

Peter