From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756003AbbESRnr (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 May 2015 13:43:47 -0400
Received: from cantor2.suse.de ([195.135.220.15]:42286 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755809AbbESRnp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 May 2015 13:43:45 -0400
Message-ID: <1432057375.3970.4.camel@suse.com>
Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
From: Oliver Neukum <oneukum@suse.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>, Laura Abbott <labbott@redhat.com>,
        Marcel Holtmann <marcel@holtmann.org>,
        Laura Abbott <labbott@fedoraproject.org>,
        "Gustavo F. Padovan" <gustavo@padovan.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        "bluez mailin list (linux-bluetooth@vger.kernel.org)" 
	<linux-bluetooth@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Ming Lei <ming.lei@canonical.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        linux-usb@vger.kernel.org
Date: Tue, 19 May 2015 19:42:55 +0200
In-Reply-To: <s5hpp5wtrrp.wl-tiwai@suse.de>
References: <s5hwq04zypv.wl-tiwai@suse.de>
	 <Pine.LNX.4.44L0.1505191017460.1453-100000@iolanthe.rowland.org>
	 <s5hpp5wtrrp.wl-tiwai@suse.de>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.11 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

> 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?

	Regards
		Oliver