[lkml]   [2012]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A workaround for request_firmware() stuck in module_init
    At Wed, 5 Sep 2012 14:03:04 +0100,
    Alan Cox wrote:
    > > If the driver is built in kernel, the request_firmware in .probe() may
    > > prolong kernel init, and it might be a problem. But looks it is not a
    > > big deal since most of drivers are built as module.
    > Doing it by deferring the load also fixes that. The built in ones will
    > defer their final probe until the firmware appears and all will be well.
    > If your rootfs needs firmware not in your initrd you already broke it and
    > there is a certain level beyond which you just have to give up trying to
    > save people from themselves.
    > It may actually make sense to push more of it into the core driver layer
    > and take some of the ability to make mistakes away from driver authors.
    > For the general case of "load firmware if we see one" there isn't really
    > any reason we can't have a firmware_name entry in the probe table
    > entries themselves. If that was present the core bus probe would kick a
    > firmware load off and only when the firmware had loaded would it call
    > ->probe with dev->firmware pointing at a refcounted firmware struct.
    > At that point it should be much faster to fix existing drivers and much
    > harder for a random device driver to get it wrong. We can even add
    > helpers which manage dev->firmware, and free the relevant objects when
    > needed, plus doing automatic ref/deref on probe/remove so that for a
    > typical driver the author only has to do
    > {PCI_blah , ... .firmware_name="wibble500.xcr", }
    > and all the loading, unloading, not loading twice happens by "magic" for
    > the driver author.
    > Add a dev_discard_firmware() for drivers that do this and know they can
    > then dump the file and all is good 8)

    This sounds like an interesting idea. I guess majority of drivers can
    be covered by this scenario. Of course, there are a few drivers that
    need more complex handling (e.g. iwlwifi handles fallback fw loading),
    but they can be implemented manually if needed anyway.


     \ /
      Last update: 2012-09-05 16:43    [W:0.025 / U:1.748 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site