On Thu, Dec 21, 2017 at 09:50:57PM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> On Thu, Dec 21, 2017 at 09:46:18PM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> > On Thu, Dec 21, 2017 at 12:04:57PM -0800, Guenter Roeck wrote:
> > > On Thu, Dec 21, 2017 at 11:10:58AM -0800, Brian Norris wrote:
> > > > On Thu, Dec 21, 2017 at 07:05:03PM +0000, Ghorai, Sukumar wrote:
> > > > > >>On Thu, Dec 21, 2017 at 06:52:31PM +0000, Ghorai, Sukumar wrote:
> > > > > >> Bug: platform can't wake using LE mouse/ keyboatd or any other LE I/O
> > > > > >> device connected.
> > > > > >
> > > > > >Could you ever? If not, that looks like a feature request to me...
> > > > > Agree, feature request... however we need this feature for rapid use of Bluetooth LE devices.
> > > >
> > > > Is that what -stable is for now? For getting your pet feature enabled
> > >
> > > I sincerely hope not. If -stable now officially supports adding new
> > > features, we'll have to revisit our strategy for merging stable releases.
> >
> > I'm not trying to add any new features at all, this was added because I
> > was told it resolved an issue that people had with their hardware.
>
> Wait, I was told by a chromeos developer to do this! Matthias asked for
> this patch to be merged to resolve a regression you all found on your
> systems. For it to now cause problems seems really "odd" to me...
>
Matthias reacted on the impression that the patch would solve the problem
based on his testing (and based on me providing the sha as the one major
difference between upstream and chromeos-4.4). Unfortunately, that was
not really the case; it turned out that it just hides the bug depending
on the test methology used. Brian had tried to point that out earlier.
Since then, Brian spent a lot of time on the issue, confirming that
both patches are problematic. Here is the comment associated with
the revert of $subject in chromeos-4.4 (sha 629db59a0f14b):
"This reverts commit 74f911a25030 ("UPSTREAM: Bluetooth: btusb: driver to
enable the usb-wakeup feature"). The reason is that this causes any inband
communication from the btusb device to cause the system to wake up. We
know that the BT controller could be scanning when we decide to suspend
and will send in the results once the scan is complete, thus failing the
suspend entry. This is a temporary work around until the bug 67489211
is solved. We can put this back once the bluetoothd starts to listen to
powerd for suspend requests and do the right thing.
(Reverting this commit has the side effect that BLE mouse clicks do not
wake up the system from suspend, but that is lesser price to pay than no
going to suspend)."
You can find a more details at the above mentioned bug in buganizer.
Again, Brian has confirmed that this problem is also seen upstream.
In other words, you get wakeup or (reliable) suspend, but not both.
> So you all need to get your story straight here :)
>
> I want all 3 of you (Guenter, Brian, and Matthias) to figure out what is
> going on here please before I do _anything_ in the stable trees with
> this patch.
>
Well, we do. I talked with Brian several times today. Matthias is on vacation,
so if you want to wait for his feedback you'll have to wait until January.
Thanks,
Guenter