lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 23 Dec 2017 17:14:28 +0100
From:   "" <>
To:     "Ghorai, Sukumar" <>
Cc:     Brian Norris <>,
        Guenter Roeck <>,
        Matthias Kaehlcke <>,
        "" <>,
        "" <>,
        "Bag, Amit K" <>,
        Oliver Neukum <>,
        Marcel Holtmann <>,
        Todd Broch <>,
        Rajat Jain <>,
        Miao Chou <>,
        "Rao Pv, Sadashiva" <>
Subject: Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the
 usb-wakeup feature

On Sat, Dec 23, 2017 at 03:53:57PM +0000, Ghorai, Sukumar wrote:
> >> > 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.
> >>
> >> Well, I wouldn't object to reverting it in Linus' tree too, since
> >> AFAIK, this is something that can be configured by user-space policy,
> >> no? And that way, no user space is surprised by the sudden additional
> >> requirements on managing bluetooth wakeup.
> Wakeup from Bluetooth will be observed as long as USB wakeup is configured from 
> user space or kernel space or connected to any Bluetooth HID devices. 
> And we don't want to support the wakeup from BT HID devide.
> The solution looks like disable Bluetooth in S3 entry?
> Looks we are trying to hide the other problems in a system, and reverting this patch.
> >
> >I agree, please work with the bluetooth developers to make this happen.
> >They seem to be ignoring patches right now, so you might have to kick them a few
> >times :(
> Do you suggest submitter to send the revert request to 4.12 and 4.14 kernel?

4.12 is long end-of-life, I don't know what you expect to happen there.

4.14 is already released, this needs to be done for 4.15 first, right?


greg k-h

Powered by blists - more mailing lists