Return-path: Received: from mail-wi0-f174.google.com ([209.85.212.174]:33434 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751454Ab2ABUtK (ORCPT ); Mon, 2 Jan 2012 15:49:10 -0500 MIME-Version: 1.0 In-Reply-To: <4F02165C.1060400@fastmail.fm> References: <4F02165C.1060400@fastmail.fm> From: Linus Torvalds Date: Mon, 2 Jan 2012 12:48:48 -0800 Message-ID: (sfid-20120102_214915_952974_81DF91A8) Subject: Re: loading firmware while usermodehelper disabled. To: Jack Stone Cc: Alan Stern , Oliver Neukum , Matthew Garrett , Dave Jones , Linux Kernel , Larry Finger , Chaoming Li , "John W. Linville" , Greg Kroah-Hartman , USB list , Linux Wireless List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Jan 2, 2012 at 12:41 PM, Jack Stone wrote: > > What about the case where the firmware that needs to be loaded is on the > USB device that needs the firmware. This can be resolved at boot using > an initrd but at resume time we don't have that. Quite frankly, caching the firmware will just automagically fix this. I don't understand why people even bother to talk about USB ID's etc changing - that is totally irrelevant. We don't look up firmware by USB ID's anyway. So the *only* thing you need is: - don't have the firmware loaded by some special user space helper - use "load_firmware()" (which in turn then will use a user-space helper to load it, but that's a separate issue) - make sure "load_firmware()" caches the firmware by firmware name. You can even make the caching be some simple "cache for at least 10 seconds after the last 'put' operation", and you'll be able to trivially handle the case of a device "going away" only to be immediately reconnected due to some electrical issue or whatever (including changing USB ID's). Even if the ID's change, the driver should damn well react to the new ID and load the same damn firmware, because it's the same damn physical device. Why are you guys making it any more complicated than that? Sure, if you have a user-space driver and you load the firmware magically from user space too, and never use "request_firmware()" in a real kernel driver, then you can never handle suspend/resume correctly, BUT WHO THE F*CK CARES? At that point it's a "the kernel cannot do it, because the kernel has nothing to do with it", but exactly for the same reason it is TOTALLY POINTLESS to even bring it up as an issue. It's not an issue - it's a broken user-space driver that has nothing to do with the kernel, and shouldn't be discussed on kernel lists as a kernel issue. So the only thing we need is to fix the braindamaged firmware interfaces. We need caching, and we need to replace (or at least extend) "load_firware()" with "[get|put]_firmware()". Linus