On Sun, 27 Jun 2004, Oliver Neukum wrote: > > Is it? It would require changes to the write method for the > > "configuration" attribute in sysfs, and the USBDEVFS_SETCONFIGURATION > > and USBDEVFS_DISCONNECT ioctls in usbfs. Plus continued vigilance to make > > sure that no other backdoors arise. > > Yes, unfortunately. But, as discussed below, you must test for suspended > devices in many cases, so testing for hubness is little added burden.
True enough. > > No. When the device resumes it will be in the same altsetting as it was > > when it suspended. The driver doesn't need to switch altsettings. > > Then we must refuse any sleep states that want to power down the bus. > This strikes me as unelegant. I don't have a clear picture of how _any_ driver (not just a USB driver) is supposed to cope with sleep states that power down the bus its device is on. When power is restored all sorts of things would need to happen. There's a big difference between initialization code and resume code. > > Under what circumstances exactly would you power down a hub for error > > recovery? Remember that it's very hard for reset to fail... > > Either it is possible or it is not possible. If it is possible you must have > a plan B. Depending on how the implementation is written, it may turn out that failed resets will propagate all the way up to the root hub. If we deal with failure to reset or disable a root-hub port by stopping the HCD then it is ultimately impossible for a reset to fail. However it may end up succeeding in a very destructive way, i.e., getting rid of an entire bus. > > > But hubs can develop malfunctions. Reset can fail. > > > It can even fail with ENOMEM. > > > > That's not true any more. If the port reset itself fails, for any reason, > > the port will be marked for a logical connect-change. Khubd will disable > > the port later on, and if _that_ fails then error recovery will be invoked > > on the parent automatically -- once the error recovery code is written! > > Good. But don't you have to power down at some point, once all else has > failed? Not necessarily, since we can always stop the root hub. Furthermore, lots of host controllers don't have the capability of powering down their ports. UHCI doesn't. Still, it wouldn't hurt for the error recovery procedure to try powering down a port after disabling it fails, before trying to reset the whole hub. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
