Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752916AbbETJqc (ORCPT ); Wed, 20 May 2015 05:46:32 -0400 Received: from senator.holtmann.net ([87.106.208.187]:45714 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751126AbbETJqa convert rfc822-to-8bit (ORCPT ); Wed, 20 May 2015 05:46:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable From: Marcel Holtmann In-Reply-To: <1432111237.8287.3.camel@suse.com> Date: Wed, 20 May 2015 11:46:31 +0200 Cc: Takashi Iwai , Ming Lei , "David S. Miller" , Laura Abbott , Johan Hedberg , "Rafael J. Wysocki" , "Gustavo F. Padovan" , Laura Abbott , Alan Stern , "bluez mailin list (linux-bluetooth@vger.kernel.org)" , Linux Kernel Mailing List , USB list , netdev Content-Transfer-Encoding: 8BIT Message-Id: <9BCD6CFF-0356-4A0F-97D4-776C0A2E436A@holtmann.org> References: <1432057375.3970.4.camel@suse.com> <1432111237.8287.3.camel@suse.com> To: Oliver Neukum X-Mailer: Apple Mail (2.2098) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1355 Lines: 28 Hi Oliver, >> The data is cached in RAM. More specifically, the former loaded >> firmware files are reloaded and saved at suspend for each device >> object. See fw_pm_notify() in firmware_class.c. > > OK, this may be a stupid idea, but do we know the firmware > was successfully loaded in the first place? > Also btusb is in the habit of falling back to a generic > firmware in some places. It seems to me that caching > firmware is conceptually not enough, but we'd also need > to record the absence of firmware images. in a lot of cases the firmware is optional. The device will operate fine without the firmware. There are a few devices where the firmware is required, but for many it just contains patches. It would be nice if we could tell request_firmware() if it is optional or mandatory firmware. Or if it should just cache the status of a missing firmware as well. As long as the device in question gets disconnected and we run through the USB driver probe() callback again, the btusb.ko driver can not do anything smart in this case. It has to be done in request_firmware(). Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/