> > > > The reason why I raise this issue is want to see if PHY's code must be > combined > > with controller's (host or device), or PHY's code can be put at some > glue layer, > > like at otg driver, this otg driver like bus driver for gadget and host, > > (here, otg, host, gadget driver shares the same register mapping) > > it manages the share resources, like PHY, controller clock, pinmux, > register mapping > > etc. > > Well, we can indeed do this if you figure out a good way to interface > ehci-hcd with the PHY code. For example, the OTG/PHY layer could > export routines to control the power mode, and these routines could be > implemented by empty inline routines on platforms that don't need > them. > > I would prefer that approach over merging the PHY's code into > ehci-hub.c or ehci-hcd.c. But if you need to, you could put the code > into a platform driver like ehci-fsl.c. > Add Felipe. At Synopsis(chipidea) core, the port has otg function, both device and host use the same PHY. Current, there are two ways to manage PHY: 1. Manage the PHY at glue layer, like otg driver, and both host and device works at active mode. 2. Manage the resources PHY at host and device driver separately. If we have managed the PHY at ehci layer, we must also add the same code at device driver, but otg driver should not manage the PHY anymore, or the thing will be complicated. We are thinking which ways to manage PHY (and other resources) is better, if you think such corner case should be taken into consideration, we have to use method 2. Else, the method 1 is better from the point of managing resources together. Or, we should leave door for corner case and using method 2. > Alan Stern > -- 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
