rkagan at mail.ru
Fri Apr 8 08:48:34 EDT 2005
On Fri, Apr 08, 2005 at 02:39:16PM +0200, Duncan Sands wrote:
> > > And you
> > > don't recurse into disconnect for the interface disconnect was called
> > > on: the usb_driver_release_interface code ignores the release in this
> > > case.
> > I don't see how... usb_driver_release_interface checks if the
> > dev->driver_list is empty for this, but it is emptied only in
> > device_release_driver called after this check. This sorta limits the
> > recursion depth to 2, but doesn't exclude it.
> I'm only talking about the following: you get a disconnect on
> a certain interface, say interface number 1. If you call
> usb_driver_release_interface for interface 1 from the disconnect
Me too, I already figured that with other interfaces it's OK.
> then it bails out at this line:
> if (!klist_node_attached(&dev->knode_driver) && !klist_node_attached(&dev->knode_bus))
Umm, klist? You must be on the bleeding edge... The one I'm looking
at now, 2.6.12-rc1, reads
/* don't disconnect from disconnect(), or before dev_add() */
if (!list_empty (&dev->driver_list) && !list_empty (&dev->bus_list))
but dev->driver_list gets emptied _by_ device_release_driver(dev), which
then calls disconnect(), in this case for the second level of recursion.
I'll take a look at a more recent version. Is klist stuff in
More information about the Usbatm