On Wed, 15 Jan 2014, Dan Williams wrote: > When the usb_device stays bound we do attempt recovery, fail, and > properly trigger a disconnect of the device as expected. > > Question for Alan: I'm thinking we need a hub_port_logical_disconnect() > when the usb_device becomes unbound. Otherwise the port state will > remain stale until the next khubd event on that port. I'll give it some > more thought, but curious what is the expected recovery from that state.
No, we don't call hub_port_logical_disconnect merely because of drivers getting bound or unbound. We call it only when there has been an external change, either in the device itself or its descriptors -- something that should cause the kernel to act as though the old device has been unplugged (and possibly a new device plugged in). The kernel's assumption is that a usb_device will always have a driver. Originally I thought there would be alternative drivers to the standard one (for example, a driver that would export access to the device over the network), but things haven't worked out that way. If somebody unbinds the usb_device's driver, they should be aware that things won't work right. The expected recovery is that the user rebinds the driver. (But would the rebind work if the device is suspended? I don't remember ever testing it...) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
