I think further discussion on these points probably belongs in some thread with a relevant title ... :)
> > That is: HCs are black boxes with two interfaces: (A) is upstream, covered > > by a spec like PCI bus or the SOC power/interconnect/clocking/...; while > > (C) is a set of downstream links, covered by the USB spec. > > They may be black boxes, but we treat them as though they contain a hub. > We communicate with them via usb_submit_urb and friends, we expect to get > back 16-bit port status and port change values, we expect them to respond > to Set-Feature and Clear-Feature, and so on. While a device's upstream link is active, yes: URBs can go to/from the device. That's basic usb_device semantics. But the driver for any usb_interface is suspended before that would happen. Those interface drivers are the ones managing device resources, and suspend() blocks all (managed) access to those resources. That means that suspending the hub interface driver should affect all of the downstream ports on that hub. A different driver controls the upstream link ... maybe a different instance of the hub driver (for USB links), maybe an HCD (for links using some other bus). > So why shouldn't we have > them to respond to usb_suspend_device and hub.c:hub_suspend the same way > as other hubs? (Apart from the issues involving USB_SUSPEND, of course.) You suggest I was arguing they shouldn't ... NOT at all what I was saying! By and large they _should_ react the same. For the usb_suspend_device() -- internal to usbcore!! -- that means usbcore won't accept URBs for devices in USB_STATE_SUSPENDED. For hubs it also guarantees that all the child ports are in that same state. (But that last was already established when the hub interface was suspended ...) However, it's important to remember that root hubs really are NOT the same as other hubs. There may be several places where reality demands recognition, beyond the fundamental one that the upstream data and signal links use PCI (or some other non-USB bus). > After all, for an external hub, suspending the interface doesn't affect > the hardware. It doesn't communicate with the device at all. Why should > it do so for a root hub? The notion of "suspending an interface" is a Linux-internal software abstraction. It's implemented by the hub driver: the mechanism by which Linux manages the downstream ports. But it doesn't correspond to a USB wire-protocol state ... the protocol it obeys is more just the way Linux-USB uses the driver model, the same as for any USB device. That means it would be nonsensical (illogical, inconsistent) to support access to *any* downstream ports/devices when the hub driver is suspended. Because such access would mean it's not the hub driver which is actually managing those ports ... and if it isn't, who is? And why do we have a hub driver then? Something would need to vainish in a puff of illogic!! > With your new patches, calling usb_suspend_device(rhdev) does practically > nothing besides maybe setting a power_state value. It doesn't even affect > remote wakeup settings! Well, there's no remote wakeup signaling to affect, either; no "K" possibility, since it's not a four-wire link using USB signaling. For that matter, there's no requirement so _support_ "system" wakeup! (Where remote wakeup mechanisms are only one part of the stack that needs to work. On PCs, it needs to cascade through S1/S3/... through ACPI to Linux. I've seen the wakeups arriving, but then ACPI borks; that's actually progress from the last time I tested this.) Don't think so much about usb_suspend_device(); a call to that isn't a very interesting event. We want it *not to matter* very much if a usb link is suspended or not ... because the minute it has Real Work to do, it should wake right back up. Only people running around with USB bus monitor hardware should need to notice when a link suspends. > What happens with an external hub if I first > suspend the interface, then turn off the wakeup_enable flag, and then call > usb_suspend_device for the hub? Compare that to what happens with a root > hub. All USB links behave the same. Non-USB links *can't* follow USB rules; they probably even have their own state machines. Maybe the fact that every usb_device _except_ root hubs has an upstream USB link creates some confusion?? Pay attention to the links, not usb_device objects, when thinking about what USB_STATE_SUSPENDED represents. There's no way you can monitor the D+ and D- signals upstream of any root hub. Since the definition of the USB suspend state is in terms of those signals (within a VBUS power session), usb_suspend_device() can't do that to a root hub. > I would be a lot happier if you renamed hcd->hub_suspend to > hcd->bus_suspend and explicitly defined it as leaving remote wakeup turned > off. Then there would have to be a new callback, hcd->rh_suspend, which > would do nothing but enable remote wakeup, I guess I don't see any confusion. The hub driver's suspend method works only on the resources it manages: downstream ports. Same for all hubs (root or external). As part of entering USB_STATE_SUSPEND, the device on the other end of that link may be told to enable remote wakeup. > and would be called from > usb_suspend_device. But this seems silly when you could just as easily do > both from usb_suspend_device. And for USB links, that's sort of how it's done. Modulo where our descriptions don't match, as above. - Dave ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
