Return-Path: Message-ID: <1432294213.8255.3.camel@suse.com> Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable From: Oliver Neukum To: Arend van Spriel Cc: Takashi Iwai , Ming Lei , "David S. Miller" , Laura Abbott , JohanHedberg , Marcel Holtmann , "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 Date: Fri, 22 May 2015 13:30:13 +0200 In-Reply-To: <555E442A.808@broadcom.com> References: <33C25745-6839-4858-9A3E-19EC6408ECED@holtmann.org> <555E158D.4090607@broadcom.com> <555E442A.808@broadcom.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-ID: On Thu, 2015-05-21 at 22:46 +0200, Arend van Spriel wrote: > On 05/21/15 19:32, Takashi Iwai wrote: > >>>>> Well, if the probe requires the access to a user-space file, it can't > >>>>> be done during resume. That's the very problem we're seeing now. > >>>>> The firmware loader can't help much alone if it's a new device > >>>>> object. > > So you are saying each device driver should come up with some retry > mechanism. Would make more sense to come up with something like that > behind the scenes in the firmware loader so all device drivers can rely > on one and the same solution. There is already a notifier for this. I don't see why the firmware layer couldn't retrigger a match for all unbound devices, just like we do when a new driver is loaded. Regards Oliver