> > If only individual port is suspend, but bus does not go to suspend, it > is > > no problem as the controller is at run mode and the PHY is active, this > > resume signal is just port change for hub. > > I don't think you are right. Suppose an individual port is suspended, > and then some minutes later the bus is suspended. Let's say the PHY is > set to low power only 2 ms after the bus stops sending SOF packets. > Nevertheless, the device attached to the suspended port could send a > wakeup signal while the PHY is entering low-power mode. After all, the > device has already been suspended for much more than 5 ms. > Does your case like below: Assume there is a intermediate hub which has two-port, and the hub connects to roothub (controller), one port is connecting 3G modem, another port is connect u-disk. 3G is auto-suspend at runtime, when we plug out u-disk from another port, the bus will go to suspend, later the PHY is going to enter low power mode, at that time, remote wakeup occurs, the resume signal will go to intermediate hub, then go to roothub. Please attention here, the intermediate hub must not send resume to roothub until the bus enters idle 5ms later. So, the resume signal will not go to roothub within 5ms after we set PORT_SUSPEND, then the resume signal will not go to roothub while the PHY is entering low power mode if we put set PORT_SUSPEND and PHY enters low power mode code together. > This is very unlikely to happen, but it isn't impossible. Therefore > the hardware needs to be able to handle it. > After discussing with IC (Synopsis-chipidea core)guys, the possibilities for making hardware abnormal is low at this corner case, just having potential problem after below conditions are met: - The device only sends about 1ms resume signal - Software haven't seen portsc.fpr = 1, and goes on putting PHY to low power mode, the time between device issues resume to PHY have entered low power mode is larger than 1ms. Combining the PHY operation with hcd can avoid this potential risk. 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. > 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
