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:   Thu, 21 Dec 2017 19:23:27 +0000
From:   "Ghorai, Sukumar" <>
To:     Brian Norris <>,
        "" <>,
        "" <>,
        Marcel Holtmann <>,
        "Oliver Neukum" <>,
        Guenter Roeck <>,
        "" <>
CC:     "Bag, Amit K" <>,
        Matthias Kaehlcke <>,
        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

>> >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 more
>quickly? I thought that's what Linaro was for, or something like that.
>Besides the poor reasoning of the above (IMO): isn't that something you can also
>configure in user space? So, upgrade user space (e.g., BlueZ) to resolve the
>regressions that have been reported, then write the appropriate udev rules to
>turn this on? Or is that too "slow" for you?
Free to take decision..

I understand this feature is creating instability in other area. However -
1. the  problem will remain same when enable the usb-wakeup feature form
kernel or user-space or udev rule, and as long LE device is connected.
2. Even the behavior is same in existing stable code, when connect the
Bluetooth BR/EDR mouse (io device), as It will enable the usb-wakeup feature/flag,


Powered by blists - more mailing lists