class, but there just can not be any dependencies between the two.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
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.