From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable Date: Fri, 22 May 2015 13:30:13 +0200 Message-ID: <1432294213.8255.3.camel@suse.com> References: <33C25745-6839-4858-9A3E-19EC6408ECED@holtmann.org> <555E158D.4090607@broadcom.com> <555E442A.808@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)" , Linux Kernel Mailing List , USB list , netdev To: Arend van Spriel Return-path: In-Reply-To: <555E442A.808-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> Sender: linux-bluetooth-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org 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