> 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. That's the problem -- there are devices that can suspend, but in the end, the port turns of the power to those devices and they loose fw anyway. > > 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). Well ... injecting firmware into kernel with some userland helper just before suspend is no-go? M > > Thanks, > > Jack -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
