Return-Path: <cyrus@holtmann.org>
Date: Wed, 26 Nov 2014 11:31:43 +0100
Message-ID: <s5hlhmyxng0.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Oliver Neukum <oneukum@suse.de>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	pgynther@google.com,
	linux-bluetooth@vger.kernel.org
Subject: Re: bluetooth related firmware loader spew on resume.
In-Reply-To: <1416996623.3171.7.camel@linux-0dmf.site>
References: <20141111181228.GA27815@redhat.com>
	<s5hsih7xmgg.wl-tiwai@suse.de>
	<D19A9DA1-3706-4351-B2E9-25D5ABA662E7@holtmann.org>
	<s5h7fyijqc9.wl-tiwai@suse.de>
	<1416996623.3171.7.camel@linux-0dmf.site>
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
List-ID: <linux-bluetooth.vger.kernel.org>

At Wed, 26 Nov 2014 11:10:23 +0100,
Oliver Neukum wrote:
> 
> On Wed, 2014-11-26 at 09:52 +0100, Takashi Iwai wrote:
> > At Wed, 26 Nov 2014 14:15:27 +0900,
> 
> > In order to paper over this, we may also remember the failing firmware
> > and avoid loading it.  This might be an easer way than the endless
> > fight against UMH race...
> 
> Hi,
> 
> the full fix would be to implement reset_resume() for btusb.
> It seems to me that setup() should be split in two methods,
> one to request the firmware from user space and the second
> to transfer it to the device. reset_resume() would just need
> to repeat the second operation.

I'm not against it, but one slight drawback is that you'll have to
remember the firmware content to transfer by the driver itself in this
scenario.   In the firmware loader framework, the content is re-read
at resume so that the largish content isn't kept unnecessarily during
the whole operation. 


Takashi