commit 85560c4a828ec9c8573840c9b66487b6ae584768 upstream. Suspend could fail for some platforms because btusb_suspend==> btusb_stop_traffic ==> usb_kill_anchored_urbs. When btusb_bulk_complete returns before system suspend and resubmits an URB, the system cannot enter suspend state. Signed-off-by: Champion Chen <champion_chen@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4807b51895dce8aa650ebebc51fa4a795ed6b8b8 upstream. In this expression: seq = (seq - 1) % 8 seq (u8) is implicitly converted to an int in the arithmetic operation. So if seq value is 0, operation is ((0 - 1) % 8) => (-1 % 8) => -1. The new seq value is 0xff which is an invalid ACK value, we expect 0x07. It leads to frequent dropped ACK and retransmission. Fix this by using '&' binary operator instead of '%'. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 396e04f4bb9afefb0744715dc76d9abe18ee5fb0 upstream. After BT_CMD_HOST_SLEEP_ENABLE command finishes, driver should wait until getting BT_EVENT_HOST_SLEEP_ENABLE event to complete suspend procedure. Without this patch the suspend handler would return success earlier. By the time when the BT_EVENT_HOST_SLEEP_ENABLE event comes in the controller driver could have already turned off the bus clock. This causes kernel crash or system reboot eventually. Signed-off-by: Chin-Ran Lo <crlo@marvell.com> Signed-off-by: Jeff CF Chen <jeffc@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 48439d501e3d9e8634bdc0c418e066870039599d upstream. When detecting a non-link packet, h5_reset_rx() frees the Rx skb. Not returning after that will cause the upcoming h5_rx_payload() call to dereference a now NULL Rx skb and trigger a kernel oops. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da64c27d3c93ee9f89956b9de86c4127eb244494 upstream. LDISCs shouldn't call tty->ops->write() from within ->write_wakeup(). ->write_wakeup() is called with port lock taken and IRQs disabled, tty->ops->write() will try to acquire the same port lock and we will deadlock. Acked-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Reported-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Tested-by: Andreas Bießmann <andreas@biessmann.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c49aa852e00978ba2f1a4d1e4598a0c669a5347 upstream. This reverts commit d2bee8fb6e18f6116aada39851918473761f7ab1. Enabling autosuspend for Intel Bluetooth devices has been shown to not work reliable. It does work for some people with certain combinations of USB host controllers, but for others it puts the device to sleep and it will not wake up for any event. These events can be important ones like HCI Inquiry Complete or HCI Connection Request. The events will arrive as soon as you poke the device with a new command, but that is not something we can do in these cases. Initially there were patches to the xHCI USB controller that fixed this for some people, but not for all. This could be well a problem somewhere in the USB subsystem or in the USB host controllers or just plain a hardware issue somewhere. At this moment we just do not know and the only safe action is to revert this patch. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream. Add support for the AR9462 chip T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3007 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Mohammed Habibulla <moch@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There exists a set of Bluetooth USB devices that show up on the USB
bus as 0a12:0001 and identify themselves as devices from CSR. However
they are not. When sending Read Local Version command they now have
a split personality and say they are from Broadcom.
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 2.0 (0x3) HCI Revision: 0x3000
LMP Version: 2.0 (0x3) LMP Subversion: 0x420b
Manufacturer: Broadcom Corporation (15)
The assumption is that they are neither CSR nor Broadcom based devices
and that they are designed and manufactured by someone else.
For the most parts they follow the Bluetooth HCI specification and
can be used as standard Bluetooth devices. However they have the
minor problem that the Delete Stored Link Key command is not working
as it should.
During the Bluetooth controller setup, this command is needed if
stored link keys are supported. For these devices it has to be
assumed that this is broken and so just set a quirk to clearly
indicate the behavior. After that the setup can just proceed.
Now the trick part is to detect these faulty devices since we do
not want to punish all CSR and all Broadcom devices. The original
devices do actually work according to the specification.
What is known so far is that these broken devices set the USB bcdDevice
revision information to 1.0 or less.
T: Bus=02 Lev=01 Prnt=01 Port=08 Cnt=03 Dev#= 9 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a12 ProdID=0001 Rev= 1.00
S: Manufacturer=Bluetooth v2.0
S: Product=Bluetooth V2.0 Dongle
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a12 ProdID=0001 Rev= 0.07
In case of CSR devices, the bcdDevice revision contains the firmware
build ID and that is normally a higher value. If the bcdDevice revision
is 1.0 or less, then an extra setup stage is checking if Read Local
Version returns CSR manufacturer information. If not then it will be
assumed that this is a broken device and the Delete Stored Link Key
command will be marked as broken.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>