Return-path: Received: from out5.smtp.messagingengine.com ([66.111.4.29]:52224 "EHLO out5.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753052Ab2AAWpT (ORCPT ); Sun, 1 Jan 2012 17:45:19 -0500 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 082A420C6C for ; Sun, 1 Jan 2012 17:45:19 -0500 (EST) Message-ID: <4F00E1FB.9060507@fastmail.fm> (sfid-20120101_234607_753054_E475D101) Date: Sun, 01 Jan 2012 22:45:15 +0000 From: Jack Stone MIME-Version: 1.0 To: Linus Torvalds CC: Dave Jones , Linux Kernel , Larry Finger , Chaoming Li , "John W. Linville" , Matthew Garrett , Greg Kroah-Hartman , USB list , Linux Wireless List Subject: Re: loading firmware while usermodehelper disabled. References: <20111230235421.GA6054@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 request_firmware_nowait. 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, Jack