From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752200AbdIKNqt (ORCPT ); Mon, 11 Sep 2017 09:46:49 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:34856 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbdIKNqs (ORCPT ); Mon, 11 Sep 2017 09:46:48 -0400 Date: Mon, 11 Sep 2017 06:46:47 -0700 From: Greg Kroah-Hartman To: Marcel Holtmann Cc: Linus Torvalds , Gabriel C , "Luis R. Rodriguez" , Tejun Heo , "Gustavo F. Padovan" , Sukumar Ghorai , "Rafael J. Wysocki" , Linux Kernel Mailing List , "bluez mailin list (linux-bluetooth@vger.kernel.org)" Subject: Re: btusb "firmware request while host is not available" at resume Message-ID: <20170911134647.GA3980@kroah.com> References: <20170911012508.GA17754@kroah.com> <9bc9cc83-212a-b39c-75af-b94fe6cab9f4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 11, 2017 at 07:12:44AM +0200, Marcel Holtmann wrote: > Hi Linus, > > >> Yes 81f95076281f is to blame.. After reverting it all is fine again. > >> > >> 15 resume cycles on the one laptop , 10 on the other without to hit the > >> trace. > > > > Yeah, I think that disable/enable_firmware in the suspend/resume path > > is basically just completely random code. There is nothing that > > serializes with anything else, and it has no actual basis for saying > > "I am now disabled/enabled" except for some entirely random time of > > whenever the suspend/resume callbacks happen. > > > > I'm going to revert it. > > > > I wonder why 4.13 seemed to work for me. Or maybe it didn't, and I > > just didn't notice, because I didn't use bluetooth and I wasn't > > traveling. I test my laptop every release, but I don't necessarily > > always _use_ it. > > we have a bug report that might go into the similar direction. So the > problem is that modern Bluetooth controller require full firmware > loading (not just ROM patching) and if the controller has the firmware > somehow already loaded, but then looses power and needs a reload, then > it is not cached (since it was never requested in the first place). > > Of course if the reload triggers during resume when not file system is > available, it can not request the firmware. That will just fail and > thus you might see this issue. We have a few RFC patches on the > mailing list that I have to review. It is however not that easy all > the time to find the right firmware file (at least not for Intel > hardware) since the boot loader provides different information than > the fully operational firmware. So I need to make sure that request > the right firmware (if we do not need it initially) so that it gets > cached. To confirm, reverting this fixes the problem I was seeing in 4.13. I've queued it up for the next 4.13-stable release as well. thanks, greg k-h