[lkml]   [2012]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: loading firmware while usermodehelper disabled.
    > 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 <> 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?


    > Thanks,
    > Jack

     \ /
      Last update: 2012-01-02 23:33    [W:0.023 / U:2.304 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site