On Mon, 28 Oct 2013, Dan Williams wrote: > > In fact, the reason for calling usb_autopm_get_interface was to prevent > > the hub from being suspended while we change the port's power state. > > Something like this may still be needed. > > > > 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. > > Since a port never needs to be connected to more than one other port, > > you could implement connectors simply by storing a "peer" pointer in > > the usb_port structure. > > Yes, no need to design for the non-existent 3 connection types in a > port case now. > > Another simplification is that a "struct usb_domain" is currently > known to never span a controller boundary. So, rather than adding > ports to a usb_connector / usb_domain container hierarchy I think we > can simply scan the child devices under the xhci device and look for > is_usb_port() instances. I'm not sure why you would want to do this. In order to identify which usb_port device matches a particular ACPI identifier? > In the meantime I am still thinking of the approach to reliably link > USB3 hub ports to their peers. The spec mandates that they be > labelled the same for this purpose (USB3 spec section 10.3.3). > However, to determine peer relationships for downstream hubs I think > we will need walk the hierarchy back to the root connector and compare > paths. Tier mismatch makes it so we can not look at the path back to > the root port. Unless there is some unique way to identify a hub? > Also need to think about what to do in the case a hub implementation > does not label its ports per the spec In the case of tier mismatches or other weirdness, there is no choice but to rely on the platform information. 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.) As for hubs with improper port labelling... We'll worry about that when we run across it. > All the questions about peering hub ports goes away if the policy on > those is forced to hotplug only. I think the patch that allows the > policy (connect_type) to be updated from userspace should also take > care to error out on hub ports. Follow-on patches can tackle the > external hub case. I'm not sure I follow. What's wrong with allowing the user to change the connect-type for a port on an external hub? At any rate, I suggest you do this by working on only one of the categories I listed earlier at a time. So, begin by submitting a patch series that redefines the meaning of putting a port into runtime suspend. Once that is accepted, move on. 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
