On Tue, Oct 29, 2013 at 8:05 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > Yes, that's handled by the PM core since it resumes devices before updating the flags. I'll update the policy to always >> > 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? Right, the patches in this series create a list of "ports with platform data" at usb_acpi_find_device() time. Rather than maintain a separate list we can just use device_find_child() for the matching port. >> 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. Yes, to seed the initial peers. > 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. > > 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? Nothing wrong with that, I was just thinking out loud about the case where external hub peers are not being identified... but I'll include that implementation in the series so the point is moot. -- 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
