> > > > It's very difficult for a general-purpose operating system like Linux > > > (without the RT patch set) to guarantee that a certain action will be > > > taken within a specific time limit. If the delay between port > suspend > > > and putting the PHY in low power needs to be less than 5 ms then it > > > ought to be handled in hardware, not in software. > > > > > > > To implement this, it needs to add the code like ehci->has_hostpc at > > ehci_bus_suspend and ehci_hub_control, it puts phy to low power mode > > just after bus goes to suspend. > > Even if we do that, it's still possible for ehci_bus_suspend to be > preempted before the PHY is set to low power. The preemption could > last longer than 5 ms. > > Your suggestion will make the problem less likely to occur, but the > problem will still be possible. > No, at both ehci_bus_suspend and ehci_hub_control, the writing PORT_SUSPEND is in_irq disabled context. It can put PHY to low power mode just after bus has suspended (no spin_unlock_irqrestore need to be called after setting bus enters low power mode). > 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
