> > Absolutely right. And IMHO to a device driver that state is reached after
> > it returns from disconnect().
>
> I don't see why that is advantageous.
>
> It sounds like it would just complicate the code even more.
How so, this is the current rule, isn't it?
> > > > > I actually don't have a problem with submitting a request for a
> > > > > device that's gone. It'll timeout. Big deal.
> > > >
> > > > Provided that the HCD doesn't keep state for devices.
> > >
> > > I don't see why that's a problem.
> >
> > The problem is the transition period.
> > 1. disconnect()
> > 2. driver does usb_submit_urb() nevertheless
> > 3. deallocate -> HCD drops all device state
> > 4. the URB from (2) completes -> BOOM
> >
> > If you reverse the order of (2) and (3) the HCD can return -ENODEV,
> > but you can't guarantee that at least on SMP.
> > To beat that we'd need an awful amount of refcounting and locking.
>
> The refcounting already occurs atleast in 2.4:
It doesn't help. usb_inc_dev_use() can come to late. In fact, given
sufficient bad luck it can hang, if you depend on it in this way.
>
> if (atomic_dec_and_test(&dev->refcnt)) {
> dev->bus->op->deallocate(dev);
> usb_destroy_configuration(dev);
>
> usb_bus_put(dev->bus);
>
> kfree(dev);
> }
>
> At step 2 in your example, the reference count increments and step 3
> never happens because the reference count > 0.
>
> > > The borderline case with PCMCIA host controllers is that the HC
> > > disappered, and as a result it should throw all of the existing pending
> > > URBs into error?
> >
> > Right. I haven't checked that code path yet.
>
> So, this is a situation where the HCD, or possibly the core, needs to track
> all of the URBs.
Depends on what you want. You could call disconnect for all devices on the
bus, and just don't care for the URBs in flight. From a HCD viewpoint, this
is the simplest solution.
> > > > No it cannot, disconnect() has to wait for the unlink to complete.
> > >
> > > Why is that?
> >
> > 1. Module unload
>
> The module unload path is required to make sure all of the resources are
> freed and not referenced, not necessarily disconnect() (although
> disconnect() could ensure that happens with little or no code in the module
> unload path)
Hm, I have to think about that. Theoretically you are probably right.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
