Return-Path: MIME-Version: 1.0 In-Reply-To: <1432111237.8287.3.camel@suse.com> References: <1432057375.3970.4.camel@suse.com> <1432111237.8287.3.camel@suse.com> Date: Wed, 20 May 2015 18:02:35 +0800 Message-ID: Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable From: Ming Lei To: Oliver Neukum Cc: Takashi Iwai , "David S. Miller" , Laura Abbott , Johan Hedberg , Marcel Holtmann , "Rafael J. Wysocki" , "Gustavo F. Padovan" , Laura Abbott , Alan Stern , "bluez mailin list (linux-bluetooth@vger.kernel.org)" , Linux Kernel Mailing List , linux-usb , netdev Content-Type: text/plain; charset=UTF-8 List-ID: On Wed, May 20, 2015 at 4:40 PM, Oliver Neukum wrote: > On Wed, 2015-05-20 at 08:29 +0200, Takashi Iwai wrote: >> 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? Yes, the firmware loader records that as device resource. In reality, there won't be lots of devices requiring firmware in one running system, so the idea of caching for every successful loading is workable. > 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. The caching can't cover the case which starts to load fw during resume in the 1st time. > > Regards > Oliver > >