On Tue, 29 Oct 2013, Dan Williams wrote: > >> With the device model change and no longer telling the hub interface > >> device to pm_suspend_ignore_children() the pm subsystem will manage > >> this wake up for us. > > > > Provided you don't try to make any power changes while the port is > > suspended. > > > > For example, consider the case where a new SuperSpeed device is plugged > > into a USB-3 port. The peer USB-2 port has been suspended at full > > power. Now you will want to power it off. You can't just change its > > power level directly; you have to resume it and suspend it again. > > > > Yes, that's handled by the PM core since it resumes devices before > updating the flags. I'll update the policy to always What flags are you talking about? No flags get changed in this scenario; all that happens is that a SuperSpeed device is plugged into the peer of the port that you want to change. > > In the case of tier mismatches or other weirdness, there is no choice > > but to rely on the platform information. > > Yes, to seed the initial peers. No, you can seed initial peers just fine without platform information (if the platform isn't playing silly tricks). xhci-hcd has all the data necessary to match up peer ports between its two root hubs. > > When there is no platform information (for example, in the case of a > > hotplugged hub), the process is simpler. Support hub H is plugged into > > parent port P, and you want to find the peer to port Q on the hub. > > Start by looking at P's peer -- call it P'. There should be a hub H' > > attached to P'. Then Q' (the peer to Q) is the port on H' having the > > same port number as Q. If either H' or Q' doesn't exist then there is > > no peer. (For example, H' might not exist if H is a USB-2 hub. If H' > > exists but Q' doesn't then something is wrong somewhere.) > > ...like mistmatched debounce timing on the respective ports, but this > should settle eventually. I think using the autosuspend timer fits > nicely for this case. What does debounce timing have to do with it? If H' exists but Q' doesn't, it means the external hub claims to have differing numbers of USB-2 and USB-3 ports. This would be a violation of the USB-3 spec. 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
