Re: loading firmware while usermodehelper disabled.

[Marek Vasut]

> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/