>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
