The percpu_rw_semaphore is not currently freed, and this leads to
a crash when the stale rcu callback is invoked.  DEBUG_OBJECTS
detects this.

 ODEBUG: free active (active state 1) object type: rcu_head hint: (null)
 ------------[ cut here ]------------
 WARNING: CPU: 1 PID: 2024 at debug_print_object+0xac/0xc8
 PC is at debug_print_object+0xac/0xc8
 LR is at debug_print_object+0xac/0xc8
 Call trace:
 [<ffffff80082e2c2c>] debug_print_object+0xac/0xc8
 [<ffffff80082e40b0>] debug_check_no_obj_freed+0x1e8/0x228
 [<ffffff8008191254>] kfree+0x1cc/0x250
 [<ffffff80083cc03c>] hci_uart_tty_close+0x54/0x108
 [<ffffff800832e118>] tty_ldisc_close.isra.1+0x40/0x58
 [<ffffff800832e14c>] tty_ldisc_kill+0x1c/0x40
 [<ffffff800832e3dc>] tty_ldisc_release+0x94/0x170
 [<ffffff8008325554>] tty_release_struct+0x1c/0x58
 [<ffffff8008326400>] tty_release+0x3b0/0x490
 [<ffffff80081a3fe8>] __fput+0x88/0x1d0
 [<ffffff80081a418c>] ____fput+0xc/0x18
 [<ffffff80080c0624>] task_work_run+0x9c/0xc0
 [<ffffff80080a9e24>] do_exit+0x24c/0x8a0
 [<ffffff80080aa4e0>] do_group_exit+0x38/0xa0
 [<ffffff80080aa558>] __wake_up_parent+0x0/0x28
 [<ffffff8008082c00>] el0_svc_naked+0x34/0x38
 ---[ end trace bfe08cbd89098cdf ]---
Signed-off-by: NHermes Zhang <chenhuiz@axis.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In case memory resources for *fw* were allocated, release them before
return.

Addresses-Coverity-ID: 1472611 ("Resource leak")
Fixes: 7237c4c9 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

At the moment we only support ACPI enumeration for serial port attached
RTL bluetooth controllers.

This commit adds a dependency on ACPI to the BT_HCIUART_RTL configuration
option, fixing the following warning when ACPI is not enabled:

drivers/bluetooth/hci_h5.c:920:22: warning: 'rtl_vnd' defined but not used

Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

We're supposed to pass the number of elements in the mtk_recv_pkts, not
the number of bytes.

Fixes: 7237c4c9 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Like all the other UART protocols, introduce a configuration option for
Realtek based serial devices.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

This adds a driver based on serdev driver for the MediaTek serial protocol
based on running H:4, which can enable the built-in Bluetooth device inside
MT7622 SoC.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Using HCI_VENDOR_PKT for vendor specific events does work since it has
also the value 0xff, but it is actually the packet type indicator
constant and not the event constant. So introduce HCI_EV_VENDOR and
use it.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

This driver was recently updated to use serdev, so add the appropriate
dependency. Without this one can get compiler warnings like this if
CONFIG_SERIAL_DEV_BUS is not enabled:

  CC [M]  drivers/bluetooth/hci_h5.o
drivers/bluetooth/hci_h5.c:934:36: warning: ‘h5_serdev_driver’ defined but not used [-Wunused-variable]
 static struct serdev_device_driver h5_serdev_driver = {
                                    ^~~~~~~~~~~~~~~~
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Add support to set voltage/current of various regulators
to power up/down Bluetooth chip wcn3990.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch enables the RAM and NV patch download for wcn3990.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Enable Qualcomm chips to operate at 3.2Mbps.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In function qca_setup, we set initial and operating speeds for Qualcomm
Bluetooth SoC's. This block of code is common across different
Qualcomm Bluetooth SoC's. Instead of duplicating the code, created
a wrapper function to set the speeds. So that future coming SoC's
can use these wrapper functions to set speeds.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Redefinition of qca_uart_setup will help future Qualcomm Bluetooth
SoC, to use the same function instead of duplicating the function.
Added new arguments soc_type and soc_ver to the functions.

These arguments will help to decide type of firmware files
to be loaded into Bluetooth chip.
soc_type holds the Bluetooth chip connected to APPS processor.
soc_ver holds the Bluetooth chip version.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Some of the QCA BTSoC ROME functions, are used for different versions
or different make of BTSoC's. Instead of duplicating the same functions
for new chip, update names of the functions that are used for both
chips to keep this generic and would help in future when we would have
new BT SoC. To have generic text in logs updated from ROME to QCA where
ever possible. This avoids confusion to user, when using the future
Qualcomm Bluetooth SoC's. Updated BT_DBG, BT_ERR and BT_INFO with
bt_dev_dbg, bt_dev_err and bt_dev_info where ever applicable.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Add support for the enable and device-wake GPIOs used on ACPI enumerated
RTL8723BS devices.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Implement support for the RTL8723BS chip.
Signed-off-by: NJeremy Cline <jeremy@jcline.org>
[hdegoede@redhat.com: Port from bt3wire.c to hci_h5.c, drop broken GPIO code]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Allow vendor-specific setup, open, and close functions to be defined.
Signed-off-by: NJeremy Cline <jeremy@jcline.org>
[hdegoede@redhat.com: Port from bt3wire.c to hci_h5.c, drop dt support]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Add basic support for serdev enumerated devices, note sine this does
not (yet) declare any of / ACPI ids to bind to atm this is a nop.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The contents of the rtl_bt/rtlXXXX_config.bin file may be board specific
allow the caller of btrtl_initialize to specify a postfix identifying
the board, which if specified will make btrtl_initialize look for
rtl_bt/rtlXXXX_config-<postfix>.bin instead.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Realtek RTL8723BS and RTL8723DS chipsets are SDIO wifi chips. They
also contain a Bluetooth module which is connected via UART to the host.

Realtek's userspace initialization tool (rtk_hciattach) differentiates
these two via the HCI version and revision returned by the
HCI_OP_READ_LOCAL_VERSION command.
Additionally we apply these checks only the for UART devices. Everything
else is assumed to be a "RTL8723B" which was originally supported by the
driver (communicating via USB).
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NJeremy Cline <jeremy@jcline.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The UART settings are embedded in the config blob. This has to be parsed
to successfully initialize the Bluetooth part of the RTL8723BS (which is
an SDIO chip, but the Bluetooth part is connected via UART).

The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
initialization tools (rtk_hciattach) use the following sequence:
- send H5 sync pattern (already supported by hci_h5)
- get LMP version (already supported by btrtl)
- get ROM version (already supported by btrtl)
- load the firmware and config for the current chipset (already
  supported by btrtl)
- read UART settings from the config blob (part of this patch)
- send UART settings via a vendor command to the device (which changes
  the baudrate of the device and enables or disables flow control
  depending on the config)
- change the baudrate and flow control settings on the host
- send the firmware and config blob to the device (already supported by
  btrtl)

Sending the last firmware and config blob download command
(rtl_download_cmd) fails if the UART settings are not updated
beforehand. This is presumably because the device applies the config
right after the firmware and config blob download - which means that at
this point the host is using different UART settings than the device
(which will obviously result in non-working communication).
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NJeremy Cline <jeremy@jcline.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Consistently use rtl_dev_err and rtl_dev_info everywhere for messages.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This prepares the btrtl code so it can be used to initialize Bluetooth
modules connected via UART (these are found for example on the RTL8723BS
and RTL8723DS SDIO chips, which come with an embedded UART Bluetooth
module).

The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
initialization tools (rtk_hciattach) use the following sequence:
1) send H5 sync pattern (already supported by hci_h5)
2) get LMP version (already supported by btrtl)
3) get ROM version (already supported by btrtl)
4) load the firmware and config for the current chipset (already
   supported by btrtl)
5) read UART settings from the config blob (currently not supported)
6) send UART settings via a vendor command to the device (which changes
   the baudrate of the device and enables or disables flow control
   depending on the config)
7) change the baudrate and flow control settings on the host
8) send the firmware and config blob to the device (already supported by
   btrtl)

The main reason why the initialization has to be split is step #7. This
requires changes to the underlying "bus", which should be kept outside
of the "generic" btrtl driver.
The idea for this split is borrowed from the btbcm driver but adjusted
where needed (the btrtl driver for example needs two blobs: firmware and
config, while the btbcm only needs one).

This also prepares the code for step #5 (parsing the config blob) by
centralizing the code which loads the firmware and config blobs and
storing the result in the new struct btrtl_device_info.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NJeremy Cline <jeremy@jcline.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This makes the firmware names show up in modinfo.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NJeremy Cline <jeremy@jcline.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Replace the BT_ERR functions with bt_dev_err to get a consistent error
printout that always prefixes the HCI device identifier.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Issue description: Intel 7265 shares the same RF with Wifi and BT.
In the shutdown scenario turn off BT, followed by turn WiFi off
and on causing error in RF calibration in WiFi Module

Solution: before shutdown BT ensure any RF activity to clear by
HCI reset command.

Reference Logs:
ERR kernel: [ 386.193284] iwlwifi 0000:01:00.0: Failed to run INIT calibrations: -5
ERR kernel: [ 386.193298] iwlwifi 0000:01:00.0: Failed to run INIT ucode: -5
ERR kernel: [ 386.193309] iwlwifi 0000:01:00.0: Failed to start RT ucode: -5
Signed-off-by: NAmit K Bag <amit.k.bag@intel.com>
Singed-off-by: NChethan T N <chethan.tumkur.narayan@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

qca_open() and qca_set_baudrate() are never called in atomic context.

They call kzalloc() and bt_skb_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

inject_cmd_complete() is only called by intel_dequeue(),
which is never called in atomic context.

inject_cmd_complete() calls bt_skb_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

inject_cmd_complete() is only called by btusb_send_frame_intel(),
which is set to hdev->send, and hdev->send() is never
called in atomic context.

inject_cmd_complete() calls bt_skb_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

btmrvl_sdio_card_to_host() is never called in atomic context.
It calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

bpa10x_send_frame() is only set to hdev->send, and hdev->send() is never
called in atomic context.

bpa10x_send_frame() calls usb_alloc_urb(), kmalloc() and usb_submit_urb()
with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

bluecard_hci_set_baud_rate() is never called in atomic context.

bluecard_hci_set_baud_rate() is only by bluecard_hci_open(), which is
set to hdev->open, and hdev->open() is never called in atomic context.

bluecard_hci_set_baud_rate() calls bt_skb_alloc() with GFP_ATOMIC,
which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

bfusb_send_frame() is only set to hdev->send, and hdev->send() is never
called in atomic context.

bfusb_send_frame() calls bt_skb_alloc() with GFP_ATOMIC, which is not
necessary. GFP_ATOMIC can be replaced with GFP_KERNEL.

This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The USB completion callback does not disable interrupts while acquiring
the ->lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave variant of the locking primitives.

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Without this patch we cannot turn on the Bluethooth adapter on HP
14-bs007la.

T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=b009 Rev= 2.00
S:  Manufacturer=Realtek
S:  Product=802.11n WLAN Adapter
S:  SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
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=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
Signed-off-by: NJian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This breaks the build as this header is not meant to be used in this
way.

./include/linux/unaligned/access_ok.h:8:28: error: redefinition of ‘get_unaligned_le16’
 static __always_inline u16 get_unaligned_le16(const void *p)
                            ^~~~~~~~~~~~~~~~~~
In file included from drivers/bluetooth/hci_nokia.c:32:
./include/linux/unaligned/le_struct.h:7:19: note: previous definition of ‘get_unaligned_le16’ was here
 static inline u16 get_unaligned_le16(const void *p)

Use asm/unaligned.h instead.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Asus ROG GL702ZC laptop contains a Realtek RTL8822BE device with
an associated BT chip using a USB ID of 13d3:3526. This ID is added
to the driver.

The /sys/kernel/debug/usb/devices portion for this device is:

T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3526 Rev= 1.10
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
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=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
Signed-off-by: NArtiom Vaskov <velemas@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Init hci_uart->init_ready so that hci_uart_init_ready() works properly.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Make hci_uart_register_device() and hci_uart_unregister_device() call
serdev_device_close()/open() themselves instead of relying on the various
hci_uart drivers to do this for them.

Besides reducing code complexity, this also ensures correct error checking
of serdev_device_open(), which was missing in a few drivers.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

For reasons explained in detail in commit 3611f4d2 ("hci_ldisc:
fix null pointer deref") the hci_uart_close() functions sets
hci_dev->flush to NULL.

But the device may be re-opened after a close, this commit restores the
hci_dev->flush callback on open().

Note this commit also moves the nearly empty defition of hci_uart_open()
a bit down in the file to avoid the need for forward declaring
hci_uart_flush().
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>