aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/bluetooth
AgeCommit message (Collapse)AuthorFilesLines
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 <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 <tedd.an@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <tedd.an@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <tedd.an@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <tedd.an@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <tedd.an@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <lukas@wunner.de> Fixes: 8bfa7e1e03ac ("Bluetooth: hci_bcm: Handle errors properly") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <joerg.krause@embedded.rocks> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <sue.white@lairdtech.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <frederic.danis.oss@gmail.com> Suggested-and-reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <leif.liddy@gmail.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Hans de Goede <hdegoede@redhat.com> Tested-by: Max Shavrick <mxms@me.com> [MacBook8,1] Tested-by: Leif Liddy <leif.liddy@gmail.com> [MacBook9,1] Tested-by: Daniel Roschka <danielroschka@phoenitydawn.de> [MacBookPro13,2] Tested-by: Ronald Tschalär <ronald@innovation.ch> [MacBookPro13,3] Tested-by: Peter Y. Chuang <peteryuchuang@gmail.com> [MacBookPro14,1] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ronald Tschalär <ronald@innovation.ch> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <frederic.danis.oss@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Document struct bcm_deviceLukas Wunner1-2/+25
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Fix unbalanced pm_runtime_disable()Lukas Wunner1-1/+1
On ->setup, pm_runtime_enable() is only called if a valid IRQ was found, but on ->close(), pm_runtime_disable() is called unconditionally. Disablement of runtime PM is recorded in a counter, so every pm_runtime_disable() needs to be balanced. Fix it. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reported-and-reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Fix race on closeLukas Wunner1-4/+4
Upon ->close, the driver powers the Bluetooth controller down, deasserts the device wake pin, updates the runtime PM status to "suspended" and finally frees the IRQ. Because the IRQ is freed last, a runtime resume can take place after the controller was powered down. The impact is not grave, the worst thing that can happen is that the device wake pin is reasserted (should have no effect while the regulator is off) and that setting the runtime PM status to "suspended" does not reflect reality. Still, it's wrong, so free the IRQ first. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Clean up unnecessary #ifdefLukas Wunner1-3/+1
pm_runtime_disable() and pm_runtime_set_suspended() are replaced with empty inlines if CONFIG_PM is disabled, so there's no need to #ifdef them. device_init_wakeup() is likewise replaced with an inline, though it's not empty, but it and devm_free_irq() can be made conditional on IS_ENABLED(CONFIG_PM), which is preferable to #ifdef as per section 20 of Documentation/process/coding-style.rst. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Validate IRQ before using itRonald Tschalär1-3/+3
The ->close, ->suspend and ->resume hooks assume presence of a valid IRQ if the device is wakeup capable. However it's entirely possible that wakeup was enabled by some other entity besides this driver and in this case the user will get a WARN splat if no valid IRQ was found. Avoid by checking if the IRQ is valid, i.e. > 0. Case in point: On recent MacBook Pros, the Bluetooth device lacks an IRQ (because host wakeup is handled by the SMC, independently of the operating system), but it does possess a _PRW method (which specifies the SMC's GPE as wake event). The ACPI core therefore automatically marks the physical Bluetooth device wakeup capable upon binding it to its ACPI companion: device_set_wakeup_capable+0x96/0xb0 acpi_bind_one+0x28a/0x310 acpi_platform_notify+0x20/0xa0 device_add+0x215/0x690 serdev_device_add+0x57/0xf0 acpi_serdev_add_device+0xc9/0x110 acpi_ns_walk_namespace+0x131/0x280 acpi_walk_namespace+0xf5/0x13d serdev_controller_add+0x6f/0x110 serdev_tty_port_register+0x98/0xf0 tty_port_register_device_attr_serdev+0x3a/0x70 uart_add_one_port+0x268/0x500 serial8250_register_8250_port+0x32e/0x490 dw8250_probe+0x46c/0x720 platform_drv_probe+0x35/0x90 driver_probe_device+0x300/0x450 bus_for_each_drv+0x67/0xb0 __device_attach+0xde/0x160 bus_probe_device+0x9c/0xb0 device_add+0x448/0x690 platform_device_add+0x10e/0x260 mfd_add_device+0x392/0x4c0 mfd_add_devices+0xb1/0x110 intel_lpss_probe+0x2a9/0x610 [intel_lpss] intel_lpss_pci_probe+0x7a/0xa8 [intel_lpss_pci] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ronald Tschalär <ronald@innovation.ch> [lukas: fix up ->suspend and ->resume as well, add commit message] Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIOLukas Wunner1-15/+9
Commit 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices") amended this driver to request a shutdown and device wake GPIO on probe, but mandated that only one of them need to be present: /* Make sure at-least one of the GPIO is defined and that * a name is specified for this instance */ if ((!dev->device_wakeup && !dev->shutdown) || !dev->name) { dev_err(&pdev->dev, "invalid platform data\n"); return -EINVAL; } However the same commit added a call to bcm_gpio_set_power() to the ->probe hook, which unconditionally accesses *both* GPIOs. Luckily, the resulting NULL pointer deref was never reported, suggesting there's no machine where either GPIO is missing. Commit 8a92056837fd ("Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driver") removed the check whether at least one of the GPIOs is present without specifying a reason. Because commit 62aaefa7d038 ("Bluetooth: hci_bcm: improve use of gpios API") refactored the driver to use devm_gpiod_get_optional() instead of devm_gpiod_get(), one is now tempted to believe that the driver doesn't require *any* of the two GPIOs. Which is wrong, the driver still requires both GPIOs to avoid a NULL pointer deref. To this end, establish the status quo ante and request the GPIOs with devm_gpiod_get() again. Bail out of ->probe if either of them is missing. Oddly enough, whereas bcm_gpio_set_power() accesses the device wake pin unconditionally, bcm_suspend_device() and bcm_resume_device() do check for its presence before accessing it. Those checks are superfluous, so remove them. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-08Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" versionHans de Goede1-12/+10
Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"") removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices, instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c. This was done because the DIY BTUSB_RESET_RESUME reset-resume handling has several issues (see the original commit message). An added advantage of moving over to the USB-core reset-resume handling is that it also disables autosuspend for these devices, which is similarly broken on these. But there are 2 issues with this approach: 1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek devices. 2) Sofar only 2 of the 10 QCA devices known to the btusb code have been added to usb/core/quirks.c and if we fix the Realtek case the same way we need to add an additional 14 entries. So in essence we need to duplicate a large part of the usb_device_id table in btusb.c in usb/core/quirks.c and manually keep them in sync. This commit instead restores setting a reset-resume quirk for QCA devices in the btusb.c code, avoiding the duplicate usb_device_id table problem. This commit avoids the problems with the original DIY BTUSB_RESET_RESUME code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the usb_device. This commit also moves the BTUSB_REALTEK case over to directly setting the USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused BTUSB_RESET_RESUME code. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"") Cc: stable@vger.kernel.org Cc: Leif Liddy <leif.linux@gmail.com> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Daniel Drake <drake@endlessm.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-08Bluetooth: btintel: make array 'param' static, shrinks object sizeColin Ian King1-1/+1
Don't populate the const read-only array 'param' on the stack but instead make it static. Makes the object code smaller by nearly 20 bytes: Before: text data bss dec hex filename 11605 2629 64 14298 37da linux/drivers/bluetooth/btintel.o After: text data bss dec hex filename 11531 2685 64 14280 37c8 linux/drivers/bluetooth/btintel.o (gcc version 7.2.0 x86_64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-08Bluetooth: bpa10x: make array 'req' static, shrinks object sizeColin Ian King1-1/+1
Don't populate the const read-only array 'req' on the stack but instead make it static. Makes the object code smaller by over 40 bytes: Before: text data bss dec hex filename 8497 3408 128 12033 2f01 linux/drivers/bluetooth/bpa10x.o After: text data bss dec hex filename 8366 3496 128 11990 2ed6 linux/drivers/bluetooth/bpa10x.o (gcc version 7.2.0 x86_64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-08Bluetooth: Depend on rather than select GPIOLIBLukas Wunner1-3/+3
Commit 27378f4c1b92 ("Bluetooth: Avoid WARN splat due to missing GPIOLIB") amended Kconfig to select GPIOLIB if BT_HCIUART_NOKIA, BT_HCIUART_INTEL or BT_HCIUART_BCM is enabled since all three drivers require it to function. The diagnosis was correct but the treatment was not. As stated in Documentation/gpio/consumer.txt: Guidelines for GPIOs consumers ============================== Drivers that can't work without standard GPIO calls should have Kconfig entries that depend on GPIOLIB. ^^^^^^^^^ Fix it. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-08Bluetooth: hciuart: add nvmem dependencyArnd Bergmann1-0/+1
When the hci support is built-in, but mvmem is a loadable module, we get a link failure: drivers/bluetooth/hci_ll.o: In function `hci_ti_probe': hci_ll.c:(.text+0x226): undefined reference to `nvmem_cell_get' hci_ll.c:(.text+0x238): undefined reference to `nvmem_cell_read' hci_ll.c:(.text+0x244): undefined reference to `nvmem_cell_put' This adds another Kconfig dependency to enforce valid configurations. Fixes: 0e58d0cdb3eb ("Bluetooth: hci_ll: Add optional nvmem BD address source") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-08Bluetooth: btusb: Add support for 0cf3:e010AceLan Kao1-0/+1
Device 0cf3:e010 is one of the QCA ROME family. T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=03 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=e010 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 Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-26Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"Kai-Heng Feng1-6/+0
This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56. This commit causes a regression on some QCA ROME chips. The USB device reset happens in btusb_open(), hence firmware loading gets interrupted. Furthermore, this commit stops working after commit ("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in btusb_suspend() when it's not a wakeup source. If we really want to reset the USB device, we need to do it before btusb_open(). Let's handle it in drivers/usb/core/quirks.c. Cc: stable@vger.kernel.org Cc: Leif Liddy <leif.linux@gmail.com> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Daniel Drake <drake@endlessm.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-26Bluetooth: hci_bcm: Streamline runtime PM codeLukas Wunner1-8/+3
This driver seeks to force the Bluetooth device on for the duration of 5 seconds when the Bluetooth device has woken the host and after a complete packet has been received. It does that by calling: pm_runtime_get(); pm_runtime_mark_last_busy(); pm_runtime_put_autosuspend(); The same can be achieved more succinctly with: pm_request_resume(); That's because after runtime resuming the device, rpm_resume() invokes pm_runtime_mark_last_busy() followed by rpm_idle(), which will cause the device to be suspended after expiration of the autosuspend_delay. No functional change intended. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-26Bluetooth: Avoid WARN splat due to missing GPIOLIBLukas Wunner1-0/+3
Loading hci_bcm with CONFIG_GPIOLIB=n results in the following splat when calling gpiod_to_irq() from bcm_get_resources(): WARNING: CPU: 0 PID: 1006 at ./include/linux/gpio/consumer.h:450 bcm_get_resources+0x50/0x80 CPU: 0 PID: 1006 Comm: kworker/u8:4 Tainted: G A 4.15.0-rc4custom+ #4 Hardware name: Apple Inc. MacBook8,1/Mac-BE0E8AC46FE800CC, BIOS MB81.88Z.0168.B00.1708080033 08/08/2017 Call Trace: bcm_serdev_probe+0x8b/0xc0 driver_probe_device+0x202/0x310 __driver_attach+0x85/0x90 ? driver_probe_device+0x310/0x310 bus_for_each_dev+0x57/0x80 async_run_entry_fn+0x2c/0xd0 process_one_work+0x1d2/0x3d0 worker_thread+0x26/0x3c0 ? process_one_work+0x3d0/0x3d0 kthread+0x10c/0x130 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x1f/0x30 We could call gpiod_to_irq() only if IS_ENABLED(CONFIG_GPIOLIB) but without GPIOLIB, the driver's power saving features can't be used, so selecting GPIOLIB seems more appropriate. The same issue is present in hci_intel.c and hci_nokia.c, fix those up as well. Reported-by: Max Shavrick <mxms@me.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-26Bluetooth: Add a new 04ca:3015 QCA_ROME deviceIoan Moldovan1-0/+1
This patch adds the 04ca:3015 (from a QCA9377 board) Bluetooth device to the btusb blacklist and makes the kernel use the btqca module instead of btusb. The patch is necessary because, without it the 04ca:3015 device defaults to using the btusb driver, which makes the WIFI side of the QCA9377 board unusable (obtains 0 MBps in speedtest, when the 04ca:3015 bluetooth is used with an audio headset). /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3015 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: Ioan Moldovan <ioan.moldovan1999@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-12-13Bluetooth: Fix a possible sleep-in-atomic bug in bluecard_write_wakeupJia-Ju Bai1-6/+2
The driver may sleep in the interrupt handler. The function call path is: bluecard_interrupt (interrupt handler) bluecard_write_wakeup schedule_timeout --> may sleep To fix it, schedule_timeout is replaced with mdelay. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_ll: add "ti,cc2560" compatible stringDavid Lechner1-0/+1
This adds the "ti,cc2560" compatible string for a TI CC2560 chip. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_ll: Add optional nvmem BD address sourceDavid Lechner1-0/+61
This adds an optional nvmem consumer to get a BD address from an external source. The BD address is then set in the Bluetooth chip after the firmware has been loaded. This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS EV3). Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_ll: add support for setting public addressDavid Lechner1-0/+21
This adds support for setting the public address on Texas Instruments Bluetooth chips using a vendor-specific command. This has been tested on a CC2560A chip. The TI wiki also indicates that this command should work on TI WL17xx/WL18xx Bluetooth chips. During review, there was some question as to the correctness of the byte swapping since TI's documentation is not clear on this matter. This can be tested with the btmgmt utility from bluez. The adapter must be powered off to change the address. If the baswap() is omitted, address is reversed. In case there is a issue in the future, here is the output of btmon during the command `btmgmt public-addr 00:11:22:33:44:55`: Bluetooth monitor ver 5.43 = Note: Linux version 4.15.0-rc2-08561-gcb132a1-dirty (armv5tejl) 0.707043 = Note: Bluetooth subsystem version 2.22 0.707091 = New Index: 00:17:E7:BD:1C:8E (Primary,UART,hci0) [hci0] 0.707106 @ MGMT Open: btmgmt (privileged) version 1.14 {0x0002} 0.707124 @ MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.707137 @ MGMT Open: btmon (privileged) version 1.14 {0x0003} 0.707540 @ MGMT Command: Set Public Address (0x0039) plen 6 {0x0002} [hci0] 11.167991 Address: 00:11:22:33:44:55 (CIMSYS Inc) @ MGMT Event: Command Complete (0x0001) plen 7 {0x0002} [hci0] 11.175681 Set Public Address (0x0039) plen 4 Status: Success (0x00) Missing options: 0x00000000 @ MGMT Event: Index Removed (0x0005) plen 0 {0x0003} [hci0] 11.175757 @ MGMT Event: Index Removed (0x0005) plen 0 {0x0002} [hci0] 11.175757 @ MGMT Event: Index Removed (0x0005) plen 0 {0x0001} [hci0] 11.175757 = Open Index: 00:17:E7:BD:1C:8E [hci0] 11.176807 < HCI Command: Vendor (0x3f|0x0006) plen 6 [hci0] 11.176975 00 11 22 33 44 55 .."3DU > HCI Event: Command Complete (0x0e) plen 4 [hci0] 11.188260 Vendor (0x3f|0x0006) ncmd 1 Status: Success (0x00) ... < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 11.189859 > HCI Event: Command Complete (0x0e) plen 12 [hci0] 11.190732 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 2.1 (0x04) - Revision 0 (0x0000) LMP version: Bluetooth 2.1 (0x04) - Subversion 6431 (0x191f) Manufacturer: Texas Instruments Inc. (13) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 11.191027 > HCI Event: Command Complete (0x0e) plen 10 [hci0] 11.192101 Read BD ADDR (0x04|0x0009) ncmd 1 Status: Success (0x00) Address: 00:11:22:33:44:55 (CIMSYS Inc) ... Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_ll: Add endianness conversion when setting baudrateDavid Lechner1-1/+3
This adds an endianness conversion when setting the baudrate using a vendor-specific command. Otherwise, bad things might happen on a big- endian system. Suggested-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_ll: add constant for vendor-specific commandDavid Lechner1-2/+8
This adds a #define for the vendor-specific HCI command to set the baudrate instead of using the bare 0xff36 multiple times. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: serdev: hci_ll: Wait for CTS instead of using msleepDavid Lechner1-2/+6
When a TI Bluetooth chip is reset, it takes about 100ms for the RTS line of the chip to deassert. For my use case with a TI CC2560A chip, this delay was not long enough and caused the local UART to never transmit at all (TI AM1808 SoC UART2). We can wait for the CTS signal using serdev_device_wait_for_cts() instead of trying to guess using msleep(). Also changed the comment to be more informative while we are touching this code. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_ll: remove \n from kernel messagesDavid Lechner1-2/+2
The bt_* printk macros include a \n already, so we don't need extra ones here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: btsdio: Do not bind to non-removable BCM43341Hans de Goede1-0/+9
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT) use an UART connection for bluetooth. But they also advertise btsdio support on their 3th sdio function, this causes 2 problems: 1) A non functioning BT HCI getting registered 2) Since the btsdio driver does not have suspend/resume callbacks, mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify() to react as if the SDIO-card is removed and since the slot is marked as non-removable it will never get detected as inserted again. Which results in wifi no longer working after a suspend/resume. This commit fixes both by making btsdio ignore BCM43341 devices when connected to a slot which is marked non-removable. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_bcm: Add support for BCM2E72Hans de Goede1-0/+1
The Asus T100HA laptop uses an ACPI HID of BCM2E72 for the bluetooth part of the SDIO bcm43340 wifi/bt combo chip. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: btqcomsmd: Fix skb double free corruptionLoic Poulain1-1/+2
In case of hci send frame failure, skb is still owned by the caller (hci_core) and then should not be freed. This fixes crash on dragonboard-410c when sending SCO packet. skb is freed by both btqcomsmd and hci_core. Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oopsLukas Wunner1-0/+1
John Stultz reports a boot time crash with the HiKey board (which uses hci_serdev) occurring in hci_uart_tx_wakeup(). That function is contained in hci_ldisc.c, but also called from the newer hci_serdev.c. It acquires the proto_lock in struct hci_uart and it turns out that we forgot to init the lock in the serdev code path, thus causing the crash. John bisected the crash to commit 67d2f8781b9f ("Bluetooth: hci_ldisc: Allow sleeping while proto locks are held"), but the issue was present before and the commit merely exposed it. (Perhaps by luck, the crash did not occur with rwlocks.) Init the proto_lock in the serdev code path to avoid the oops. Stack trace for posterity: Unable to handle kernel read from unreadable memory at 406f127000 [000000406f127000] user address but active_mm is swapper Internal error: Oops: 96000005 [#1] PREEMPT SMP Hardware name: HiKey Development Board (DT) Call trace: hci_uart_tx_wakeup+0x38/0x148 hci_uart_send_frame+0x28/0x38 hci_send_frame+0x64/0xc0 hci_cmd_work+0x98/0x110 process_one_work+0x134/0x330 worker_thread+0x130/0x468 kthread+0xf8/0x128 ret_from_fork+0x10/0x18 Link: https://lkml.org/lkml/2017/11/15/908 Reported-and-tested-by: John Stultz <john.stultz@linaro.org> Cc: Ronald Tschalär <ronald@innovation.ch> Cc: Rob Herring <rob.herring@linaro.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: btusb: Fix BT_HCIBTUSB_AUTOSUSPEND Kconfig option nameHans de Goede1-1/+1
Fix: drivers/bluetooth/Kconfig:35:warning: multi-line strings not supported warning. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: btusb: Add a Kconfig option to enable USB autosuspend by defaultHans de Goede2-0/+17
On many laptops the btusb device is the only USB device not having USB autosuspend enabled, this causes not only the HCI but also the USB controller to stay awake, together using aprox. 0.4W of power. Modern ultrabooks idle around 6W (at 50% screen brightness), 3.5W for Apollo Lake devices. 0.4W is a significant chunk of this (7 / 11%). The btusb driver already contains code to allow enabling USB autosuspend, but currently leaves it up to the user / userspace to enable it. This means that for most people it will not be enabled, leading to an unnecessarily high power consumption. Since enabling it is not entirely without risk of regressions, this commit adds a Kconfig option so that Linux distributions can choose to enable it by default. This commit also adds a module option so that when distros receive bugs they can easily ask the user to disable it again for easy debugging. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_qca: Avoid setup failure on missing rampatchLoic Poulain1-0/+3
Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found. This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller: hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000044 Since there is no rampatch for this controller revision, just make it work as is. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-11-28the rest of drivers/*: annotate ->poll() instancesAl Viro2-2/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-11-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2-0/+2
Files removed in 'net-next' had their license header updated in 'net'. We take the remove from 'net-next'. Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2-0/+2
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Privacy Policy