Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755731AbbEURiA (ORCPT ); Thu, 21 May 2015 13:38:00 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:55482 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753676AbbEURh5 (ORCPT ); Thu, 21 May 2015 13:37:57 -0400 Date: Thu, 21 May 2015 13:37:56 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Takashi Iwai cc: Marcel Holtmann , Laura Abbott , Oliver Neukum , Ming Lei , "David S. Miller" , Laura Abbott , Johan Hedberg , "Rafael J. Wysocki" , "Gustavo F. Padovan" , "bluez mailin list (linux-bluetooth@vger.kernel.org)" , Linux Kernel Mailing List , USB list , netdev Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable In-Reply-To: Message-ID: MIME-Version: 1.0 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: 1868 Lines: 47 On Thu, 21 May 2015, Takashi Iwai wrote: > At Thu, 21 May 2015 11:26:17 -0400 (EDT), > Alan Stern wrote: > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > At Thu, 21 May 2015 10:18:08 -0400 (EDT), > > > Alan Stern wrote: > > > > > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > > > > > Then avoiding the failed firmware is no solution, indeed. > > > > > If it's a new probe, it should be never executed during resume. > > > > > > > > Can you expand this comment? What's wrong with probing during resume? > > > > > > 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. > > > > But the same thing happens during early boot, if the driver is built > > into the kernel. When the probe occurs, userspace isn't up and running > > yet, so the firmware loader can't do anything. > > > > Why should probe during resume be any worse than probe during early > > boot? > > The early boot has initrd, so the files can be there. But the resume > has no way to fetch the file except for cached data. I suppose USB could delay re-probing until userspace is running again, if we knew when that was. But it would be awkward and prone to races. It also would leave a user-visible window of time during which the device does not exist, which we want to avoid. (This may not matter for bluetooth, but it does matter for other kinds of devices.) I would prefer to solve this problem in a different way, if possible. Alan Stern -- 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/