On Thu, Dec 21, 2017 at 01:39:41PM -0800, Guenter Roeck wrote:
> 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.
Ok, thanks for the explaination, it makes more sense now.
I've reverted this from 4.4 and 4.9-stable, but note that this was
included in 4.14-rc1, so something needs to be done in Linus's tree to
resolve this issue, otherwise people will hit this as a regression when
moving to 4.14 or newer.
thanks,
greg k-h