speedtch testatm.c,1.4,1.5

Roman Kagan 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
> call,

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 mailing list