[lkml]   [2012]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: loading firmware while usermodehelper disabled.
    On 31/12/11 00:22, Linus Torvalds wrote:
    > It's also possible that we should blame the firmware code, which is
    > expressly written to encourage these kinds of bugs. It may be that i
    > tshould be the firmware code that has a "get_firmware()" +
    > "put_firmware()" model, and it should cache the firmware explicitly if
    > the config supports suspend, so that a firmware read at resume time
    > would actually work. The whole "request_firmware()" interface really
    > is very prone to these kinds of bugs.

    How about these semantics for get_firmware / put_firmware:

    get_firmware -> checks for a cached copy of the firmware and returns
    that if it exists otherwise calls _get_firmware (i.e.
    _request_firmware). Either way we get a refcount to the firmware blob.
    This requires adding 3 members to struct firmware: the refcount, the
    name of the firmware (see @name in request_firmware) and a list head to
    cache with. We could also add and async version of this to match

    put_firmware -> Removes a refcount from the firmware and frees if there
    are no more users.

    put_firmware is called when we are sure that we no longer need to reload
    the firmware for that device - device close time for most drivers.

    USB is a more difficult case as devices can change ID but the firmware
    blob still needs to be associated with them. I don't know USB at all so
    I have no idea if we can track this. Some PCI devices may also suffer
    the same problem.

    Hope this is useful,


     \ /
      Last update: 2012-01-01 23:49    [W:0.021 / U:8.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site