On Tue, Dec 23, 2014 at 11:40:23AM -0800, David Cohen wrote: > Hi Peter, > > Thanks for the review. > > On Tue, Dec 23, 2014 at 09:25:18AM +0800, Peter Chen wrote: > > On Mon, Dec 22, 2014 at 02:43:37PM -0800, David Cohen wrote: > > > Some platforms have an USB OTG port fully (or partially) controlled by > > > GPIOs: > > > > > > (1) USB ID is connected directly to GPIO > > > > > > Optionally: > > > (2) VBUS is enabled by a GPIO (when ID is grounded) > > > (3) Platform has 2 USB controllers connected to same port: one for > > > device and one for host role. D+/- are switched between phys > > > by GPIO. > > > > Would you explain how it works? Choosing controller runtime? > > Both controllers are (indirectly) connected to the same micro B port. > The D+/- goes from the port to a switch operated by a GPIO. From the > switch, D+/- may go to Host controller's phy or Device controller's phy. > Depends on the GPIO level. >
Get it, why the design like that? If your controller supports both roles, the software can do role switch by ID pin (through gpio in your case). > > > > > > > > As per initial version, this driver has the duty to control whether > > > USB-Host cable is plugged in or not: > > > > You mean Micro-AB cable, right? > > > > + > > > + vup->gpio_usb_mux = devm_gpiod_get_index(dev, "usb mux", > > > + VUPORT_GPIO_USB_MUX); > > > + if (IS_ERR(vup->gpio_usb_mux)) > > > + dev_info(dev, "cannot request USB USB MUX, skipping it.\n"); > > > > Using dev_err > > That's not really an error, although the IS_ERR() suggests otherwise. > The driver works well if a board doesn't need this mux (I'll add a > comment to state that clear). IMHO either keep dev_info or use dev_dgb > instead? > If that, dev_dbg may be suitable. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
