Comment 7 for bug 228746

This bug can be reproduced by a USB to SD/MMC/MS/CF adaptor that cannot handle SDHC. The failure of the adaptor to recognize/connect the SDHC which uses a slightly different protocol, triggers the error by looping the probe/reset/probe long enough to get messages and state out of sync.

After further investigation, what appeared to be a recursive call that attempted to device_del twice, it turns out that the problem is that the device_add never happened because the adaptor did a reset (and sent a message back) before the initialization was complete. It seems that the device_add in question, the top scsi device is last and the disconnect/reset occurs before we get that far. I cleaned up the power structures init only to fall into the sysfs cleanup of its uninit'ed structures (this moves the null deref from device_del->device_pm_remove to device_del->dpm_sysfs_remove, essentially the next line in device_del.

The problem (and its solution) is that usb_disable_device has to be held off until the initialization is complete. There is a race here in that the failure->reset->reconnect sequence loops around a number of times before it eventually fails. If the setup completes (even in error), the disconnect "does the right thing". There are a number of other open bugs that show a similar signature even though they may be serial or other usb type devs.