[..]
> 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!
Eeek. That must not be allowed. You are right. Hubs are a special case.
> > > 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.
Yes, unfortunately. But, as discussed below, you must test for suspended
devices in many cases, so testing for hubness is little added burden.
[..]
> > 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.
Then we must refuse any sleep states that want to power down the bus.
This strikes me as unelegant.
> > > 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...
Either it is possible or it is not possible. If it is possible you must have
a plan B.
> > 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?
Regards
Oliver
-------------------------------------------------------
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
