Return-path: Received: from out5.smtp.messagingengine.com ([66.111.4.29]:50285 "EHLO out5.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753001Ab2ABVJL (ORCPT ); Mon, 2 Jan 2012 16:09:11 -0500 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1C59F2113E for ; Mon, 2 Jan 2012 16:09:11 -0500 (EST) Message-ID: <4F021CF4.9050205@fastmail.fm> (sfid-20120102_220929_847841_09CD6C1E) Date: Mon, 02 Jan 2012 21:09:08 +0000 From: Jack Stone MIME-Version: 1.0 To: Linus Torvalds 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 Subject: Re: loading firmware while usermodehelper disabled. References: <4F02165C.1060400@fastmail.fm> <4F0219AB.6010505@fastmail.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 02/01/12 21:00, Linus Torvalds wrote: > On Mon, Jan 2, 2012 at 12:55 PM, Jack Stone wrote: >> >> The problem comes with knowing when to put the firmware - how do we tell >> the generic driver that that device has firmware that might need to be >> freed on disconnect. I don't know enough about USB to know if we can >> tell if the same device has reconnected due to firmware being loaded or >> if it was simply unplugged and a new device plugged in. > > Well, if we just have a 10-second timeout for the firmware flushing > after the last "put" operation, we don't even care. > > It doesn't even *matter* if the device is a physically different > device - if the driver loads the same firmware, it will be cached, and > it will still be correct for that (physically different, but with the > same firmware requirements) device. So even the whole "user switched > devices around" issue is irrelevant. > > Of course, if the driver is some piece-of-crap that explicitly loads > the wrong firmware for the device it manages, the firmware will be > wrong, but hey, "Don't do that then". The drivers job very much > includes being able to look at the device ID (whether USB or PCIe or > PCMCIA) and figure out which firmware image it needs to load. What about USB "class" drivers e.g. usb-storage. They handle any device that reports itself as a usb mass storage device. There could be a device that needs to be bootstrapped before it becomes a generic usb mass storage device. Do we really want to have to write a new driver that is almost identical to the generic driver but handles the USB firmware correctly. The other option is to extend the class drivers to understand that a certain device needs this piece of firmware and to handle it but that will bloat the generic drivers with lots of vendor stuff. We could do this by lists of USB ids or something similar. Thanks, Jack