speedtch testatm.c,1.4,1.5

[Duncan Sands]

> 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))
> 		device_release_driver(dev);
> 
> 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
> 2.6.12-rc2?

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]
[device_release_driver+80/92] device_release_driver+0x50/0x5c
[driver_detach+27/42] driver_detach+0x1b/0x2a
[bus_remove_driver+38/82] bus_remove_driver+0x26/0x52
[driver_unregister+11/24] driver_unregister+0xb/0x18
[pg0+543519110/1070015488] usb_deregister+0x26/0x34 [usbcore]
[pg0+546144885/1070015488] testatm_exit+0x19/0x1d [testatm]
[sys_delete_module+298/340] sys_delete_module+0x12a/0x154
[do_munmap+289/301] do_munmap+0x121/0x12d
[sys_munmap+59/65] sys_munmap+0x3b/0x41
[sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75

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.

Ciao,

D.