From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755984AbbEUOjW (ORCPT ); Thu, 21 May 2015 10:39:22 -0400 Received: from senator.holtmann.net ([87.106.208.187]:55891 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753638AbbEUOjU convert rfc822-to-8bit (ORCPT ); Thu, 21 May 2015 10:39:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable From: Marcel Holtmann In-Reply-To: Date: Thu, 21 May 2015 16:39:16 +0200 Cc: Takashi Iwai , 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 Content-Transfer-Encoding: 8BIT Message-Id: <33C25745-6839-4858-9A3E-19EC6408ECED@holtmann.org> References: To: Alan Stern X-Mailer: Apple Mail (2.2098) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alan, >> 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? > > The USB stack does carry out probes during resume under certain > circumstances. A driver lacking a reset_resume callback is one of > those circumstances. in case the platform kills the power to the USB lines, we can never do anything about this. I do not want to hack around this in the driver. What are the cases where we should implement reset_resume and would it really help here. Since the btusb.ko driver implements suspend/resume support, would reset_resume ever be called? However I get the feeling someone needs to go back and see if the device is the same one and just gets probed again or if it is a new one from the USB host stack perspective. Regards Marcel