All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Gabriel C <nix.or.die@gmail.com>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	"Gustavo F. Padovan" <gustavo@padovan.org>,
	Sukumar Ghorai <sukumar.ghorai@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"bluez mailin list (linux-bluetooth@vger.kernel.org)"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: btusb "firmware request while host is not available" at resume
Date: Mon, 11 Sep 2017 06:46:47 -0700	[thread overview]
Message-ID: <20170911134647.GA3980@kroah.com> (raw)
In-Reply-To: <E31F8274-519A-4ED7-90C0-2BB71C9CC3ED@holtmann.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

  reply	other threads:[~2017-09-11 13:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-10 19:26 btusb "firmware request while host is not available" at resume Linus Torvalds
2017-09-11  1:25 ` Greg Kroah-Hartman
2017-09-11  3:15   ` Gabriel C
2017-09-11  3:49     ` Gabriel C
2017-09-11  4:25       ` Linus Torvalds
2017-09-11  5:12         ` Marcel Holtmann
2017-09-11 13:46           ` Greg Kroah-Hartman [this message]
2017-09-11 17:11             ` Luis R. Rodriguez
2017-09-11 19:29               ` Greg Kroah-Hartman
2017-09-11 20:06                 ` Luis R. Rodriguez
2017-09-12  0:13                   ` Gabriel C
2017-09-12  0:33                     ` Luis R. Rodriguez
2017-09-12  0:48                   ` Greg Kroah-Hartman
2017-09-12 16:52                     ` Luis R. Rodriguez
2017-09-12  5:13                   ` Marcel Holtmann
2017-09-12 16:27                     ` Luis R. Rodriguez
2017-09-13  6:52                       ` Marcel Holtmann
2017-09-13 17:39                         ` Luis R. Rodriguez
2017-10-02  8:34                           ` Kai-Heng Feng
2017-10-04  0:20                             ` Luis R. Rodriguez
2017-10-04  1:21                               ` Luis R. Rodriguez
2017-10-06  4:42                               ` Kai-Heng Feng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170911134647.GA3980@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=gustavo@padovan.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mcgrof@kernel.org \
    --cc=nix.or.die@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=sukumar.ghorai@intel.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.