aboutsummaryrefslogtreecommitdiff
path: root/drivers/bluetooth
AgeCommit message (Collapse)AuthorFilesLines
2018-04-01Bluetooth: hci_bcm: Add 6 new ACPI HIDsHans de Goede1-0/+6
Add 6 new ACPI HIDs to enable bluetooth on devices using these HIDs, I've tested the following HIDs / devices: BCM2E74: Jumper ezPad mini 3 BCM2E83: Acer Iconia Tab8 w1-810 BCM2E90: Meegopad T08 BCM2EAA: Chuwi Vi8 plus (CWI519) The reporter of Red Hat bugzilla 1554835 has tested: BCM2E84: Lenovo Yoga2 The reporter of kernel bugzilla 274481 has tested: BCM2E38: Toshiba Encore Note the Lenovo Yoga2 and Toshiba Encore also needs the earlier patch to treat all Interrupt ACPI resources as active low. Cc: [email protected] Buglink: https://bugzilla.kernel.org/attachment.cgi?id=274481 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Reported-and-tested-by: Robert R. Howell <[email protected]> Reported-and-tested-by: Christian Herzog <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-lowHans de Goede1-17/+3
Older devices with a serdev attached bcm bt hci, use an Interrupt ACPI resource to describe the IRQ (rather then a GpioInt resource). These device seem to all claim the IRQ is active-high and seem to all need a DMI quirk to treat it as active-low. Instead simply always assume that Interrupt resource specified IRQs are always active-low. This fixes the bt device not being able to wake the host from runtime- suspend on the: Asus T100TAM, Asus T200TA, Lenovo Yoga2 and the Toshiba Encore, without the need to add 4 new DMI quirks for these models. This also allows us to remove 2 DMI quirks for the Asus T100TA and Asus T100CHI series. Likely the 2 remaining quirks can also be removed but I could not find a DSDT of these devices to verify this. Cc: [email protected] Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=198953 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_bcm: Add irq_polarity module optionHans de Goede1-5/+15
Add irq_polarity module option for easier troubleshooting of irq-polarity issues. Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: btusb: Add USB ID 7392:a611 for Edimax EW-7611ULBVicente Bergas1-0/+3
This WiFi/Bluetooth USB dongle uses a Realtek chipset, so, use btrtl for it. Product information: https://wikidevi.com/wiki/Edimax_EW-7611ULB From /sys/kernel/debug/usb/devices T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=7392 ProdID=a611 Rev= 2.00 S: Manufacturer=Realtek S: Product=Edimax Wi-Fi N150 Bluetooth4.0 USB Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 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= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 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 I:* If#= 2 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723bu E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Tested-by: Vicente Bergas <[email protected]> Signed-off-by: Vicente Bergas <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_ll: Use skb_put_u8 instead of struct hcill_cmdMarcel Holtmann1-7/+1
The struct hcill_cmd to create an skb with a single u8 is pointless. So just use skb_put_u8 instead. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2018-04-01Bluetooth: btmrvl: Delete an unnecessary variable initialisation in ↵Markus Elfring1-1/+1
btmrvl_sdio_card_to_host() The variable "payload" will eventually be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: btmrvl: Delete an unnecessary variable initialisation in ↵Markus Elfring1-1/+1
btmrvl_sdio_register_dev() The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_bcm: Use default baud rate if missing shutdown GPIOMarcel Holtmann1-0/+6
In case the shutdown GPIO is not wired up, it is impossible to reset the Bluetooth controller to its original state. This include the initial default baud rate which leads to issues when reloading the module or when something unexpected happens. To avoid any kind of runtime deadlocks, stick with the initial default baud rate. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2018-04-01Bluetooth: hci_bcm: use gpiod cansleep versionLoic Poulain1-2/+2
Some GPIO controller drivers request sleepable context and so can't be accessed from IRQ context. Using gpiod_set/get_value accessors with such controller leads to a kernel warning since they are reserved for atomic context (according to the documentation). Use the postfixed _cansleep version instead, indicating that context is safe for sleeping if necessary. Note that this is the case here since we never toggle the gpio neither from IRQ nor from a spinlocked section. Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-03-27Bluetooth: btrsi: rework dependenciesArnd Bergmann1-3/+1
The linkage between the bluetooth driver and the wireless driver is not defined properly, leading to build problems such as: warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt': (.text+0x205): undefined reference to `rsi_bt_ops' As the dependency is actually the reverse (RSI_91X uses the BT_RSI driver, not the other way round), this changes the dependency to match, and enables the bluetooth driver from the RSI_COEX symbol. Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver") Acked-by; Marcel Holtmann <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2018-03-25Merge tag 'wireless-drivers-next-for-davem-2018-03-24' of ↵David S. Miller3-0/+202
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.17 The biggest changes are the bluetooth related patches to the rsi driver. It adds a new bluetooth driver which communicates directly with the wireless driver and the interface is defined in include/net/rsi_91x.h. Major changes: wl1251 * read the MAC address from the NVS file rtlwifi * enable mac80211 fast-tx support mt76 * add capability to select tx/rx antennas mt7601 * let mac80211 validate rx CCMP Packet Number (PN) rsi * bluetooth: add new btrsi driver * btcoex support with the new btrsi driver ==================== Signed-off-by: David S. Miller <[email protected]>
2018-03-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2-8/+13
Fun set of conflict resolutions here... For the mac80211 stuff, these were fortunately just parallel adds. Trivially resolved. In drivers/net/phy/phy.c we had a bug fix in 'net' that moved the function phy_disable_interrupts() earlier in the file, whilst in 'net-next' the phy_error() call from this function was removed. In net/ipv4/xfrm4_policy.c, David Ahern's changes to remove the 'rt_table_id' member of rtable collided with a bug fix in 'net' that added a new struct member "rt_mtu_locked" which needs to be copied over here. The mlxsw driver conflict consisted of net-next separating the span code and definitions into separate files, whilst a 'net' bug fix made some changes to that moved code. The mlx5 infiniband conflict resolution was quite non-trivial, the RDMA tree's merge commit was used as a guide here, and here are their notes: ==================== Due to bug fixes found by the syzkaller bot and taken into the for-rc branch after development for the 4.17 merge window had already started being taken into the for-next branch, there were fairly non-trivial merge issues that would need to be resolved between the for-rc branch and the for-next branch. This merge resolves those conflicts and provides a unified base upon which ongoing development for 4.17 can be based. Conflicts: drivers/infiniband/hw/mlx5/main.c - Commit 42cea83f9524 (IB/mlx5: Fix cleanup order on unload) added to for-rc and commit b5ca15ad7e61 (IB/mlx5: Add proper representors support) add as part of the devel cycle both needed to modify the init/de-init functions used by mlx5. To support the new representors, the new functions added by the cleanup patch needed to be made non-static, and the init/de-init list added by the representors patch needed to be modified to match the init/de-init list changes made by the cleanup patch. Updates: drivers/infiniband/hw/mlx5/mlx5_ib.h - Update function prototypes added by representors patch to reflect new function names as changed by cleanup patch drivers/infiniband/hw/mlx5/ib_rep.c - Update init/de-init stage list to match new order from cleanup patch ==================== Signed-off-by: David S. Miller <[email protected]>
2018-03-15Bluetooth: hci_bcm: Set pulsed_host_wake flag in sleep parametersHans de Goede1-1/+1
The IRQ output of the bcm bt-device is really a level IRQ signal, which signals a logical high as long as the device's buffer contains data. Since the draining in the buffer is done in the tty driver, we cannot (easily) wait in a threaded interrupt handler for the draining, after which the IRQ should go low again. So instead we treat the IRQ as an edge interrupt. This opens the window for a theoretical race where we wakeup, read some data and then autosuspend *before* the IRQ has gone (logical) low, followed by the device just at that moment receiving more data, causing the IRQ to stay high and we never see an edge. Since we call pm_runtime_mark_last_busy() on every received byte, there should be plenty time for the IRQ to go (logical) low before we ever suspend, so this should never happen, but after commit 43fff7683468 ("Bluetooth: hci_bcm: Streamline runtime PM code"), which has been reverted since, this was actually happening causing the device to get stuck in runtime suspend. The bcm bt-device actually has a workaround for this, if we set the pulsed_host_wake flag in the sleep parameters, then the device monitors if the host is draining the buffer and if not then after a timeout the device will pulse the IRQ line, causing us to see an edge, fixing the stuck in suspend condition. This commit sets the pulsed_host_wake flag to fix the (mostly theoretical) race caused by us treating the IRQ as an edge IRQ. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-03-15Revert "Bluetooth: hci_bcm: Streamline runtime PM code"Hans de Goede1-3/+8
This reverts commit 43fff7683468 ("Bluetooth: hci_bcm: Streamline runtime PM code"). The commit msg for this commit states "No functional change intended.", but replacing: pm_runtime_get(); pm_runtime_mark_last_busy(); pm_runtime_put_autosuspend(); with: pm_request_resume(); Does result in a functional change, pm_request_resume() only calls pm_runtime_mark_last_busy() if the device was suspended before the call. This results in the following happening: 1) Device is runtime suspended 2) Device drives host_wake IRQ logically high as it starts receiving data 3) bcm_host_wake() gets called, causes the device to runtime-resume, current time gets marked as last_busy time 4) After 5 seconds the autosuspend timer expires and the dev autosuspends as no one has been calling pm_runtime_mark_last_busy(), the device was resumed during those 5 seconds, so all the pm_request_resume() calls while receiving data and/or bcm_host_wake() calls were nops 5) If 4) happens while the device has (just received) data in its buffer to be read by the host the IRQ line is *already* / still logically high when we autosuspend and since we use an edge triggered IRQ, the IRQ will never trigger, causing the device to get stuck in suspend Therefor this commit has to be reverted, so that we avoid the device getting stuck in suspend. Signed-off-by: Hans de Goede <[email protected]> Acked-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-03-15Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174Takashi Iwai1-1/+1
The Atheros 1525/QCA6174 BT doesn't seem working properly on the recent kernels, as it tries to load a wrong firmware ar3k/AthrBT_0x00000200.dfu and it fails. This seems to have been a problem for some time, and the known workaround is to apply BTUSB_QCA_ROM quirk instead of BTUSB_ATH3012. The device in question is: T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=3004 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 Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 Reported-by: Ivan Levshin <[email protected]> Tested-by: Ivan Levshin <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-03-13Bluetooth: btrsi: add new rsi bluetooth driverPrameela Rani Garnepudi3-0/+202
Redpine bluetooth driver is a thin driver which depends on 'rsi_91x' driver for transmitting and receiving packets to/from device. It creates hci interface when attach() is called from 'rsi_91x' module. Signed-off-by: Prameela Rani Garnepudi <[email protected]> Signed-off-by: Siva Rebbagondla <[email protected]> Acked-by: Marcel Holtmann <[email protected]> Reviewed-by: Marcel Holtmann <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2018-03-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2-9/+23
All of the conflicts were cases of overlapping changes. In net/core/devlink.c, we have to make care that the resouce size_params have become a struct member rather than a pointer to such an object. Signed-off-by: David S. Miller <[email protected]>
2018-03-01Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_tableKai-Heng Feng1-0/+7
The issue can be reproduced before commit fd865802c66b ("Bluetooth: btusb: fix QCA Rome suspend/resume") gets introduced, so the reset resume quirk is still needed for this system. T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e007 Rev=00.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 I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Cc: [email protected] Cc: Brian Norris <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-03-01Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_tableHans de Goede1-7/+0
Commit 1fdb92697469 ("Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking"), added the Lenovo Yoga 920 to the btusb_needs_reset_resume_table. Testing has shown that this is a false positive and the problems where caused by issues with the initial fix: commit fd865802c66b ("Bluetooth: btusb: fix QCA Rome suspend/resume"), which has already been reverted. So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at all and this commit removes it from the btusb_needs_reset_resume_table. Note that after this commit the btusb_needs_reset_resume_table is now empty. It is kept around on purpose, since this whole series of commits started for a reason and there are actually broken platforms around, which need to be added to it. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Fixes: 1fdb92697469 ("Bluetooth: btusb: Use DMI matching for QCA ...") Cc: [email protected] Cc: Brian Norris <[email protected]> Cc: Kai-Heng Feng <[email protected]> Tested-by: Kevin Fenzi <[email protected]> Suggested-by: Brian Norris <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Brian Norris <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-25Bluetooth: hci_bcm: Make shutdown and device wake GPIO optionalStefan Wahren1-3/+4
According to the devicetree binding the shutdown and device wake GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO") this driver won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO connected). So fix this regression by reverting this commit partially. Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO") Signed-off-by: Stefan Wahren <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-25Bluetooth: btusb: Use DMI matching for QCA reset_resume quirkingHans de Goede1-6/+19
Commit 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version") applied the USB_QUIRK_RESET_RESUME to all QCA USB Bluetooth modules. But it turns out that the resume problems are not caused by the QCA Rome chipset, on most platforms it resumes fine. The resume problems are actually a platform problem (likely the platform cutting all power when suspended). The USB_QUIRK_RESET_RESUME quirk also disables runtime suspend, so by matching on usb-ids, we're causing all boards with these chips to use extra power, to fix resume problems which only happen on some boards. This commit fixes this by applying the quirk based on DMI matching instead of on usb-ids, so that we match the platform and not the chipset. Here is the /sys/kernel/debug/usb/devices for the Bluetooth module: T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e300 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 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Fixes: 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume..") Cc: [email protected] Cc: Brian Norris <[email protected]> Cc: Kai-Heng Feng <[email protected]> Reported-and-tested-by: Kevin Fenzi <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-15Merge branch 'for-upstream' of ↵David S. Miller6-50/+115
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2018-02-15 Here's the first bluetooth-next pull request targetting the 4.17 kernel release. - Fixes & cleanups to Atheros and Marvell drivers - Support for two new Realtek controllers - Support for new Intel Bluetooth controller - Fix for supporting multiple slave-role Bluetooth LE connections ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-11vfs: do bulk POLL* -> EPOLL* replacementLinus Torvalds1-2/+2
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-02-11Bluetooth: btrtl: Add RTL8723D and RTL8821C devicesAlex Lu1-34/+85
The Bluetooth parts of RTL8723D and RTL8723B share the same lmp subversion, thus we need to check both lmp subversion and hci revision to distinguish the two. The same situation is true for RTL8821A and RTL8821C. Accordingly, the selection code is revised. To improve maintainability, a new id_table struct is defined, and an array of such structs is constructed. Adding a new device can thus be as simple as adding another value to the table. Signed-off-by: Alex Lu <[email protected]> Signed-off-by: Larry Finger <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-11Bluetooth: btusb: Add device ID for RTL8822BELarry Finger1-0/+3
The Asus Z370-I contains a Realtek RTL8822BE device with an associated BT chip using a USB ID of 0b05:185c. This device is added to the driver. Signed-off-by: Hon Weng Chong <[email protected]> Signed-off-by: Larry Finger <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: hci_ll: Replace mdelay with msleep in download_firmwareJia-Ju Bai1-1/+1
download_firmware() is never called from atomic context. It is only called by ll_setup() that is called only via function pointer "->setup" used in hci_uart_setup() in drivers/bluetooth/hci_serdev.c and drivers/bluetooth/hci_ldisc.c. hci_uart_setup() is called only via function pointer "->setup" used in hci_dev_do_open() in net/bluetooth/hci_core.c. All of the above functions do not enter atomic context. Besides, ll_setup() calls msleep() and hci_dev_do_open calls mutex_lock(). So it indicates that all the above functions call functions that can sleep. Despite never getting called from atomic context, download_firmware() calls mdelay() for busy wait. That is not necessary and can be replaced with msleep to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: btmrvl_main: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
btmrvl_send_sync_cmd After checking all possible call chains to btmrvl_send_sync_cmd(), my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. And it calls wait_event_interruptible_timeout() after bt_skb_alloc(), so it indicates that btmrvl_send_sync_cmd() can call function which can sleep. Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: hci_ath: Replace mdelay with msleep in ath_wakeup_ar3kJia-Ju Bai1-2/+2
ath_wakeup_ar3k() is never called from atomic context. It is only called by ath_hci_uart_work() that is only called in ath_open() via INIT_WORK(). All of the above functions do not enter atomic context along the way. Despite never getting called from atomic context, ath_wakeup_ar3k() calls mdelay() for busy wait. That is not necessary and can be replaced with msleep to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: ath3k: fix checkpatch warningMaxim Zhukov1-1/+1
This patch fixed warning: WARNING: Prefer using '"%s...", __func__' to using 'ath3k_disconnect', this function's name, in a string #568: FILE: drivers/bluetooth/ath3k.c:568: + BT_DBG("ath3k_disconnect intf %p", intf); Signed-off-by: Maxim Zhukov <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: ath3k: Fix warning: quoted string split across linesMaxim Zhukov1-4/+8
This patch avoided the warning: WARNING: quoted string split across lines #355: FILE: drivers/bluetooth/ath3k.c:355: + BT_ERR("Error in firmware loading err = %d," + "len = %d, size = %d", err, len, size); This patch fix this issue. Signed-off-by: Maxim Zhukov <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: ath3k: remove blank line after ifMaxim Zhukov1-1/+0
Removed blank line after if. Signed-off-by: Maxim Zhukov <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: ath3k: do not init variablesMaxim Zhukov1-2/+2
Do not need to initialize variables, because further on the code they fall into the snprintf. Signed-off-by: Maxim Zhukov <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: ath3k: replace hardcode numbers with defineMaxim Zhukov1-4/+5
Replaced the numbers with a readable define. Signed-off-by: Maxim Zhukov <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-02-07Bluetooth: btusb: Add support for Intel Bluetooth device 22560 [8087:0026]Tedd Ho-Jeong An1-0/+7
The Intel Bluetooth device 22560 family (HarrisonPeak, QnJ, and IcyPeak) use the same firmware loading mechanism as previous generation, so include new USB product ID and whitelist the hardware variant. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0026 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= 64 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 I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-31Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds15-307/+624
Pull networking updates from David Miller: 1) Significantly shrink the core networking routing structures. Result of http://vger.kernel.org/~davem/seoul2017_netdev_keynote.pdf 2) Add netdevsim driver for testing various offloads, from Jakub Kicinski. 3) Support cross-chip FDB operations in DSA, from Vivien Didelot. 4) Add a 2nd listener hash table for TCP, similar to what was done for UDP. From Martin KaFai Lau. 5) Add eBPF based queue selection to tun, from Jason Wang. 6) Lockless qdisc support, from John Fastabend. 7) SCTP stream interleave support, from Xin Long. 8) Smoother TCP receive autotuning, from Eric Dumazet. 9) Lots of erspan tunneling enhancements, from William Tu. 10) Add true function call support to BPF, from Alexei Starovoitov. 11) Add explicit support for GRO HW offloading, from Michael Chan. 12) Support extack generation in more netlink subsystems. From Alexander Aring, Quentin Monnet, and Jakub Kicinski. 13) Add 1000BaseX, flow control, and EEE support to mvneta driver. From Russell King. 14) Add flow table abstraction to netfilter, from Pablo Neira Ayuso. 15) Many improvements and simplifications to the NFP driver bpf JIT, from Jakub Kicinski. 16) Support for ipv6 non-equal cost multipath routing, from Ido Schimmel. 17) Add resource abstration to devlink, from Arkadi Sharshevsky. 18) Packet scheduler classifier shared filter block support, from Jiri Pirko. 19) Avoid locking in act_csum, from Davide Caratti. 20) devinet_ioctl() simplifications from Al viro. 21) More TCP bpf improvements from Lawrence Brakmo. 22) Add support for onlink ipv6 route flag, similar to ipv4, from David Ahern. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1925 commits) tls: Add support for encryption using async offload accelerator ip6mr: fix stale iterator net/sched: kconfig: Remove blank help texts openvswitch: meter: Use 64-bit arithmetic instead of 32-bit tcp_nv: fix potential integer overflow in tcpnv_acked r8169: fix RTL8168EP take too long to complete driver initialization. qmi_wwan: Add support for Quectel EP06 rtnetlink: enable IFLA_IF_NETNSID for RTM_NEWLINK ipmr: Fix ptrdiff_t print formatting ibmvnic: Wait for device response when changing MAC qlcnic: fix deadlock bug tcp: release sk_frag.page in tcp_disconnect ipv4: Get the address of interface correctly. net_sched: gen_estimator: fix lockdep splat net: macb: Handle HRESP error net/mlx5e: IPoIB, Fix copy-paste bug in flow steering refactoring ipv6: addrconf: break critical section in addrconf_verify_rtnl() ipv6: change route cache aging logic i40e/i40evf: Update DESC_NEEDED value to reflect larger value bnxt_en: cleanup DIM work on device shutdown ...
2018-01-25Bluetooth: btintel: Create common function for firmware downloadTedd Ho-Jeong An4-154/+99
The firmware download flow for RAM SKU is same for both USB and UART and this patch creates a common function for both driver. Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-24Bluetooth: btintel: Create common Intel Read Boot Params functionTedd Ho-Jeong An4-84/+76
The Intel_Read_Boot_Params command is used to read boot parameters from the bootloader and this is Intel generic command used in USB and UART drivers. Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-24Bluetooth: btintel: Use boot parameter from firmware fileTedd Ho-Jeong An2-4/+39
Each RAM SKU has a different boot parameter which is used in HCI_Intel_Reset command after downloading the firmware. The boot parameter is embedded in the firmware data and to support multiple SKUs, driver reads the boot parameter while downloading the firmware instead of using static values per SKU. Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-24Bluetooth: btintel: Create common function for Intel ResetTedd Ho-Jeong An4-16/+49
The Intel_Reset command is used to reset the device after downloading the firmware and this is Intel generic command used in both USB and UART. Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-24Bluetooth: hci_intel: Update firmware filename for Intel 9x60 and laterTedd Ho-Jeong An1-7/+49
The format of Intel Bluetooth firmware for bootloader product is ibt-<hw_variant>-<device_revision_id>.sfi and .ddc. But for the 9x60 SKU, there are three variants of FW, which cannot be differenticate just with hw_variant and device_revision_id. So, to pick the appropriate FW file for 9x60 SKU, three fields, hw_variant, hw_revision, and fw_revision, needs to be used rather than hw_variant and device_revision_id. Format will be like this: ibt-<hw_variant>-<hw_revision>-<fw_revision>.sfi and .ddc Signed-off-by: Tedd Ho-Jeong An <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-22Bluetooth: hci_bcm: For serdev case close serdev on failure to set powerHans de Goede1-1/+4
Commit 8bfa7e1e03ac ("Bluetooth: hci_bcm: Handle errors properly") introduced error checking for the bcm_gpio_set_power() call in bcm_open() but the error-path it introduces unsets dev->hu, which is correct for platform_device instantiated bcm_dev-s but not for serdev instantiated devs. For serdev instantiated devs serdev_device_close() should be called instead (and dev->hu should be left set). Cc: Lukas Wunner <[email protected]> Fixes: 8bfa7e1e03ac ("Bluetooth: hci_bcm: Handle errors properly") Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-18Bluetooth: btbcm: Add entry for BCM4343A0 UART bluetoothJörg Krause1-0/+1
This patch adds the device ID for the bluetooth chip used in the AMPAK AP6212 WiFi+Bluetooth module. The AP6212 is used on several BananaPi boards, e.g. M2-Ultra. The AP6212 is a combo module, where the WiFi chip is identified as BCM43430A0 whereas the Bluetooth chip identifies itself as 4343A0. Note, the missing '0' before the 'A0'. The AP6212 needs a firmware blob. Loading the provided firmware file from the BananaPi vendor, the adapter name is printed as 'BCM4343A0 26MHz AP6212_CL1-0061': ''' hci0: Type: Primary Bus: UART BD Address: 43:43:A0:12:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:3076 acl:0 sco:0 events:278 errors:0 TX bytes:39726 acl:0 sco:0 commands:279 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'BCM4343A0 26MHz AP6212_CL1-0061' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.1 (0x7) Revision: 0xf2 LMP Version: 4.1 (0x7) Subversion: 0x2122 Manufacturer: Broadcom Corporation (15) ''' Signed-off-by: Jörg Krause <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: btbcm: Fix sleep mode struct orderingLukas Wunner2-2/+2
According to the documentation for Laird SD40 radio modules (which use the BCM4329 chipset), the order of the Enable_BREAK_To_Host and Pulsed_HOST_WAKE parameters in the sleep mode struct is reversed vis-à-vis our struct declaration. See page 46 of this PDF: http://cdn.lairdtech.com/home/brandworld/files/Application%20Note%20-%2040%20Series%20Bluetooth.pdf The documentation is dated Oct 2015, so fairly recent, making it appear more likely that the documentation is correct and our code is wrong. Amend our code to be in congruence with the documentation. Cc: Sue White <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Sleep instead of spinningLukas Wunner1-2/+2
The driver calls mdelay(15) in the ->suspend, ->resume, ->runtime_suspend and ->runtime_resume hook, however spinning for such a long period of time is discouraged as per Documentation/timers/timers-howto.txt. The use of mdelay() seems unnecessary, it is allowed to sleep in the system sleep and runtime PM hooks (with the exception of ->suspend_noirq and ->resume_noirq) and the driver itself also does not rely on a non-sleeping ->runtime_resume as the only place where a synchronous resume is performed, in bcm_dequeue(), is called from a work item in hci_ldisc.c and hci_serdev.c. So replace the mdelay(15) with msleep(15). Note that the delay is inserted after asserting or deasserting the device wake pin, but in bcm_gpio_set_power() that pin is asserted or deasserted *without* observing a delay. It is thus unclear if the delay is necessary at all. It is likewise unclear why it is exactly 15 ms, the commit introducing it, 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions"), does not provide a rationale. Cc: Frédéric Danis <[email protected]> Suggested-and-reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Silence IRQ printkLukas Wunner1-1/+1
The host wake IRQ is optional, but if none is found, "BCM irq: -22" is logged which may irritate users. This is really a debug message, so use dev_dbg() instead of dev_info(). If users are interested in the IRQ, they can always consult /proc/interrupts. Cc: Frédéric Danis <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Support Apple GPIO handlingLukas Wunner1-0/+55
Enable Bluetooth on the following Macs which provide custom ACPI methods to toggle the GPIOs for device wake and shutdown instead of accessing the pins directly: MacBook8,1 2015 12" MacBook9,1 2016 12" MacBook10,1 2017 12" MacBookPro13,1 2016 13" MacBookPro13,2 2016 13" with Touch Bar MacBookPro13,3 2016 15" with Touch Bar MacBookPro14,1 2017 13" MacBookPro14,2 2017 13" with Touch Bar MacBookPro14,3 2017 15" with Touch Bar On the MacBook8,1 Bluetooth is muxed with a second device (a debug port on the SSD) under the control of PCH GPIO 36. Because serdev cannot deal with multiple slaves yet, it is currently necessary to patch the DSDT and remove the SSDC device. The custom ACPI methods are called: BTLP (Low Power) takes one argument, toggles device wake GPIO BTPU (Power Up) tells SMC to drive shutdown GPIO high BTPD (Power Down) tells SMC to drive shutdown GPIO low BTRS (Reset) calls BTPD followed by BTPU BTRB unknown, not present on all MacBooks Search for the BTLP, BTPU and BTPD methods on ->probe and cache them in struct bcm_device if the machine is a Mac. Additionally, set the init_speed based on a custom device property provided by Apple in lieu of _CRS resources. The Broadcom UART's speed is fixed on Apple Macs: Any attempt to change it results in Bluetooth status code 0x0c and bcm_set_baudrate() thus always returns -EBUSY. By setting only the init_speed and leaving oper_speed at zero, we can achieve that the host UART's speed is adjusted but the Broadcom UART's speed is left as is. The host wake pin goes into the SMC which handles it independently of the OS, so there's no IRQ for it. Thanks to Ronald Tschalär who did extensive debugging and testing of this patch and contributed fixes. ACPI snippet containing the custom methods and device properties (taken from a MacBook8,1): Method (BTLP, 1, Serialized) { If (LEqual (Arg0, 0x00)) { Store (0x01, GD54) /* set PCH GPIO 54 direction to input */ } If (LEqual (Arg0, 0x01)) { Store (0x00, GD54) /* set PCH GPIO 54 direction to output */ Store (0x00, GP54) /* set PCH GPIO 54 value to low */ } } Method (BTPU, 0, Serialized) { Store (0x01, \_SB.PCI0.LPCB.EC.BTPC) Sleep (0x0A) } Method (BTPD, 0, Serialized) { Store (0x00, \_SB.PCI0.LPCB.EC.BTPC) Sleep (0x0A) } Method (BTRS, 0, Serialized) { BTPD () BTPU () } Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b"))) { Store (Package (0x08) { "baud", Buffer (0x08) { 0xC0, 0xC6, 0x2D, 0x00, 0x00, 0x00, 0x00, 0x00 }, "parity", Buffer (0x08) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }, "dataBits", Buffer (0x08) { 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }, "stopBits", Buffer (0x08) { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } Return (0x00) } Link: https://github.com/Dunedan/mbp-2016-linux/issues/29 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110901 Reported-by: Leif Liddy <[email protected]> Cc: Mika Westerberg <[email protected]> Cc: Frédéric Danis <[email protected]> Cc: Loic Poulain <[email protected]> Cc: Hans de Goede <[email protected]> Tested-by: Max Shavrick <[email protected]> [MacBook8,1] Tested-by: Leif Liddy <[email protected]> [MacBook9,1] Tested-by: Daniel Roschka <[email protected]> [MacBookPro13,2] Tested-by: Ronald Tschalär <[email protected]> [MacBookPro13,3] Tested-by: Peter Y. Chuang <[email protected]> [MacBookPro14,1] Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ronald Tschalär <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Handle errors properlyLukas Wunner1-16/+75
A significant portion of this driver lacks error handling. As a first step, add error paths to bcm_gpio_set_power(), bcm_open(), bcm_close(), bcm_suspend_device(), bcm_resume_device(), bcm_resume(), bcm_probe() and bcm_serdev_probe(). (I've also scrutinized bcm_suspend() but think it's fine as is.) Those are all the functions accessing the device wake and shutdown GPIO. On Apple Macs the pins are accessed through ACPI methods, which may fail for various reasons, hence proper error handling is necessary. Non-Macs access the pins directly, which may fail as well but the GPIO core does not yet pass back errors to consumers. Cc: Frédéric Danis <[email protected]> Cc: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Add callbacks to toggle GPIOsLukas Wunner1-4/+23
MacBooks provides custom ACPI methods to toggle the GPIOs for device wake and shutdown instead of accessing the pins directly. Prepare for their support by adding callbacks to toggle the GPIOs, which on non-Macs do nothing more but call gpiod_set_value(). No functional change intended. Suggested-and-reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Document struct bcm_deviceLukas Wunner1-2/+25
Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-10Bluetooth: hci_bcm: Invalidate IRQ on request failureLukas Wunner1-1/+3
If devm_request_irq() fails, the driver bails out of bcm_request_irq() but continues to ->setup the device (because the IRQ is optional). The driver subsequently calls devm_free_irq(), enable_irq_wake() and disable_irq_wake() on the IRQ even though requesting it failed. Avoid by invalidating the IRQ on request failure. Cc: Frédéric Danis <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.