[lkml]   [2008]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.
    From: Andrew Morton <>
    Date: Mon, 14 Jul 2008 16:41:19 -0700

    > On Mon, 14 Jul 2008 16:23:26 -0700
    > David Woodhouse <> wrote:
    > > Linus, please pull from the for-2.6.27 branch of:
    > > git:// for-2.6.27
    > The firmware flamewars seem to have subsided lately. Is everyone happy
    > with this now?

    I'm not happy for network drivers, although I'm happy to see that
    David respected out NACKs on tg3/bnx2/etc. and didn't include those

    I still haven't seen an answer to the chip reset issues. The argument
    has been that this stuff is going to save kernel memory when the
    driver isn't loading firmware, but that's not really possible.

    When a lot of these network drivers reset, due to a transmit timeout
    or other exception, we need to load the firmware again.

    So this means, that if request_firmware() dies or fails for some
    reason in these scenerios, we can't reset the network card. Something
    as simple as a memory or other allocation failure deep inside of
    request_firmware() means we lose the networking interface.

    To me this seems like a very non-resilient setup. It makes sense
    to just keep the firmware in-core so we can load it without having
    to even think about possible failures.

    And that to me basically makes this transformation pointless. It's
    in fact a regression.

    Furthermore, the issue of suspend and resume was brought up. What if
    request_firmware() fails then? And can request_firmware() even be
    allowed in that context? What if the disk on which the firmware
    resides hasn't been resumed yet?

    In response to the suspend/resume queries, a lot of special voodoo was
    mentioned that perhaps would allow request_firmware() to get invoked
    in the correct context and with the firmware partition's block device
    resumed already.

    But who the heck is going to write all of that code and fix up all
    of these drivers so that they can resume reliably again?

    And for what?

    None of the people who wrote and maintain these effected networking
    drivers want these changes installed. And they are the ones who will
    have to diagnose strange request_firmware() failures that lead to
    non-functioning devices during resume or after a transmit timeout.

     \ /
      Last update: 2008-07-15 03:47    [W:0.020 / U:115.688 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site