Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642AbbETG3m (ORCPT ); Wed, 20 May 2015 02:29:42 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43782 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752502AbbETG3i (ORCPT ); Wed, 20 May 2015 02:29:38 -0400 Date: Wed, 20 May 2015 08:29:33 +0200 Message-ID: From: Takashi Iwai To: Oliver Neukum Cc: Alan Stern , Laura Abbott , Marcel Holtmann , Laura Abbott , "Gustavo F. Padovan" , Johan Hedberg , "David S. Miller" , "bluez mailin list (linux-bluetooth@vger.kernel.org)" , netdev , Linux Kernel Mailing List , Ming Lei , "Rafael J. Wysocki" , linux-usb@vger.kernel.org Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable In-Reply-To: <1432057375.3970.4.camel@suse.com> References: <1432057375.3970.4.camel@suse.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.5 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1945 Lines: 47 At Tue, 19 May 2015 19:42:55 +0200, Oliver Neukum wrote: > > On Tue, 2015-05-19 at 19:13 +0200, Takashi Iwai wrote: > > At Tue, 19 May 2015 10:26:46 -0400 (EDT), > > Alan Stern wrote: > > > > > > > > > Of just have request_firmware() > > > > > > actually sleep until userspace is ready. Seriously, why is > > > > > > request_firmware not just sleeping for us. > > > > > > It won't work. The request_firmware call is part of the probe > > > sequence, which in turn is part of the resume sequence. Userspace > > > doesn't start running again until the resume sequence is finished. If > > > request_firmware waited for userspace, it would hang. > > > > Note that the recent request_firmware() doesn't need the user-space > > invocation (unless the fallback is explicitly enabled) but loads the > > That is a dangerous approach. You cannot be sure you can do file IO. > It depends on the exact shape of the device tree. It's the reason why firmware loader still takes UMH lock (thus we're seeing this very problem). > > file directly. And, request_firmware() for the cached data is valid > > to be called in the resume path. > > Well, yes, if your data is cached in RAM, all is well. But that leads > to the same problem one step further. What must be cached? 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. The question is then why the cached data isn't used. I have no concrete answer to it for now, need more investigation, but my wild guess is that it's because the device itself is being renewed. Or, something wrong in firmware_class.c. Takashi -- 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/