On 02/01/12 21:00, Linus Torvalds wrote: > On Mon, Jan 2, 2012 at 12:55 PM, Jack Stone <jwjstone@xxxxxxxxxxx> wrote: >> >> The problem comes with knowing when to put the firmware - how do we tell >> the generic driver that that device has firmware that might need to be >> freed on disconnect. I don't know enough about USB to know if we can >> tell if the same device has reconnected due to firmware being loaded or >> if it was simply unplugged and a new device plugged in. > > Well, if we just have a 10-second timeout for the firmware flushing > after the last "put" operation, we don't even care. > > It doesn't even *matter* if the device is a physically different > device - if the driver loads the same firmware, it will be cached, and > it will still be correct for that (physically different, but with the > same firmware requirements) device. So even the whole "user switched > devices around" issue is irrelevant. > > Of course, if the driver is some piece-of-crap that explicitly loads > the wrong firmware for the device it manages, the firmware will be > wrong, but hey, "Don't do that then". The drivers job very much > includes being able to look at the device ID (whether USB or PCIe or > PCMCIA) and figure out which firmware image it needs to load. What about USB "class" drivers e.g. usb-storage. They handle any device that reports itself as a usb mass storage device. There could be a device that needs to be bootstrapped before it becomes a generic usb mass storage device. Do we really want to have to write a new driver that is almost identical to the generic driver but handles the USB firmware correctly. The other option is to extend the class drivers to understand that a certain device needs this piece of firmware and to handle it but that will bloat the generic drivers with lots of vendor stuff. We could do this by lists of USB ids or something similar. Thanks, Jack -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
