Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make a decision, it is better to cover most of the cases, and using device tree (or platform data) to cover exceptions if they exist. 1. USB Mode Problem How can we decide USB mode (gadget, host and otg) at driver, and how to read OTGSC register? Below is my pinion. - We get gadget or host support from CAP_DCCPARAMS(DCCPARAMS_DC or DCCPARAMS_HC), If both DCCPARAMS_DC and DCCPARAMS_HC are 1, then the mode is "otg". If DCCPARAMS_DC = 1 and DCCPARAMS_HC = 0, the mode is "gadget". If DCCPARAMS_DC = 0 and DCCPARAMS_HC = 1, the mode is "host". If DCCPARAMS_DC = 0 and DCCPARAMS_HC = 0, prompt an error and try to get it from DT. - Override the value using DT, please do not consider too much between dule_role and otg. We just consider all controllers which supports host and gadget at the same time as otg device. The exception may not be existed or be too long to use. - For how to read OTGSC register, we need another flag to indicate it is otg capable (DCCPARAMS_DC = 1 and DCCPARAMS_HC = 1), if it is otg capable, read OTGSC is allowed. Here, OTG capable device can work as gadget only mode. 2. Chipidea Core Driver DT Support I agree we move some core things, like vbus, operation_mode, phy to core driver using DT. But for clock, it is better still exist at glue layer, clock is input for chipidea core, chipidea core doesn't need to know its clock from IC point. Like clock, the wakeup setting, low power sequence are platform specific, they are designed by individual companies. Let me know your opinion about these two problems and your plan for them. Thanks. -- Best Regards, Peter Chen -- 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
