On Sat, 26 Jun 2004, Oliver Neukum wrote: > [..] > > If the hub driver is unbound, then the system won't be able to use the > > hub very well. In particular, connect changes won't be detected. On > > the other hand, devices that were plugged into the hub may still be > > electronically accessible. The cleanest way to handle this is to > > disable all the in-use ports and call usb_disconnect() for their > > No, disconnect() must not differentiate between soft and hard unplug. > Just disconnect() the children.
You mean, don't disable the ports as well? Disabling the in-use ports doesn't constitute differentiating between soft and hard unplug, because with a hard unplug no ports will be in-use. But if you don't disable them for a soft disconnect then the child devices will remain on the bus and electrically active, while usbcore will deallocate their addresses and maybe try to reuse the same addresses later on! > > children. However, it's a little questionable how we can do this. > > Once a driver's disconnect() is called, the driver isn't supposed to > > communicate with the device any more. By a quirk of the > > implementation we don't enforce this restriction for endpoint 0, which > > is all the hub driver needs for disabling all the ports. Relying on > > such quirks generally isn't a good idea, although this could > > reasonably be considered a special case. > > If you feel that the hub driver needs to be special cased at all, > then disallow soft disconnect entirely for hubs. That's the cleanest > thing to do. 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. > > Of course, we can't disable the ports if the hub is suspended. I > > think the only way to deal with this complication is to check > > initially whether a device is suspended, and if it is, disallow > > unbinding or configuration changes. That's for all devices, not just > > config changes, definitely yes. Unbinding, no. Maybe you're right. > > hubs. As an additional complication, we _can't_ disallow unbinding > > when a driver is being unloaded. We have to let it unbind from its > > interface -- even though we won't be able to set the interface back to > > altsetting 0 afterwards. (Luckily this part of the problem doesn't > > affect the hub driver; it can't be unloaded unless all the usb_devices > > are already gone.) > > Isn't a driver that's not switching to altsetting 0 in its suspend() buggy? 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. > > Now let's discuss error recovery. First, consider what sorts of > > errors might occur. One that the hub driver already checks for is 10 > > or more consecutive failures of the status interrupt URB (period is > > 256 ms). Another, highly critical sort of error (not currently > > handled) is failure of a hub to disable a port upon request. Finally, > > Retry, reset, power down. If need be, recursively. > Not that it is a high priority. Under what circumstances exactly would you power down a hub for error recovery? Remember that it's very hard for reset to fail... > 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! 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
