baldrick at free.fr
Fri Apr 8 08:57:31 EDT 2005
> 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
Here's a stack trace for a logical disconnect:
[pg0+543465430/1070015488] usbatm_usb_disconnect+0x34/0x227 [usbatm]
[pg0+543518886/1070015488] usb_unbind_interface+0x38/0x69 [usbcore]
[pg0+543519110/1070015488] usb_deregister+0x26/0x34 [usbcore]
[pg0+546144885/1070015488] testatm_exit+0x19/0x1d [testatm]
The disconnect for the interface is called from device_release_driver,
which has cleaned out dev->driver_list before the call. So when, from
the disconnect, usb_device_release_driver is now called for the same
interface, the test triggers and usb_device_release_driver bails out.
At least that's how it's supposed to work. Anyway, from my tests it
does indeed work: device_release_driver is only called once.
More information about the Usbatm