On 02/01/12 21:52, Marek Vasut wrote: >> On 02/01/12 21:23, Linus Torvalds wrote: >>> On Mon, Jan 2, 2012 at 1:09 PM, Jack Stone <jwjstone@xxxxxxxxxxx> wrote: >>>> 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. >>> >>> I'd hope that the generic driver just expose enough interfaces that >>> you could basically do a "firmware-load" driver that just loads the >>> firmware and then attaches the device to the generic driver. >> >> Sounds workable. >> >> To make the firmware caching easier I would propose one extra function >> in addition to the aforemensioned get_firmware / put_firmware - a >> find_firmware function to search the cache and return the appropriate >> firmware blob. It should only be called if the caller already has a >> refcount to the firmware, it's only use is to save every driver saving a >> pointer to the firmware. >> >> If noone beats me to it I will try and put together an RFC for a new >> version. > > The problem is on systems with limited resources, most notably RAM. If you plug > in many devices at once, many firmwares will be cached at one point, efectivelly > doing DoS attach on the machine? > > Also, how will this solve the suspect-resume issue? What if the device suspends > only occasionally -- like every 24 hours -- then you'd have the FW cached all > the time too? Yes, at least to begin with. If we can come up with a robust scheme which doesn't require the firmware to be kept in memory then that would also be workable. For example, drivers which know they don't ever need the firmware again wouldn't need to cache it. That would probably be quite a small list - there are systems that cut power to USB devices over suspend and so those devices would need the firmware reloading. I don't think there is anyway to avoid the memory requirement if we want to be able to resume transparently to user-space (or even resume at all in some setups). 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
