- 13 May, 2020 2 commits
-
-
Abhishek Pandit-Subedi authored
When a device is suspended, it doesn't need to be as responsive to connection events. Increase the interval to 640ms (creating a duty cycle of roughly 1.75%) so that passive scanning uses much less power (vs previous duty cycle of 18.75%). The new window + interval combination has been tested to work with HID devices (which are currently the only devices capable of wake up). Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Abhishek Pandit-Subedi authored
The types for window and interval should be uint16, not uint8. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 11 May, 2020 11 commits
-
-
Marcel Holtmann authored
In case dynamic debug is disabled, this feature allows a vendor platform to provide debug statement printing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
To enable platform specific experimental features, introduce this new set of management commands and events. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The security manager operates on a specific controller and thus use bt_dev_dbg to indetify the controller for each debug message. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
When setting HCI_MGMT_HDEV_OPTIONAL it is possible to target a specific conntroller or a global interface. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The majority of management interaction are based on a controller index and have a hci_dev associated with it. So use bt_dev_dbg to have a clean way of indentifying the controller the debug message belongs to. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The event MGMT_EV_PHY_CONFIGURATION_CHANGED wasn't listed in the list of supported events. So add it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Konstantin Forostyan authored
Fix 2 typos in L2CAP_CREDIT_BASED_CONNECTION_REQ (0x17) handling function, that cause BlueZ answer with L2CAP_CR_LE_INVALID_PARAMS or L2CAP_CR_LE_INVALID_SCID error on a correct ECRED connection request. Enchanced Credit Based Mode support was recently introduced with the commit 15f02b91 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode"). Signed-off-by: Konstantin Forostyan <konstantin.forostyan@peiker-cee.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Tedd Ho-Jeong An authored
This patch fix the advertising handle is set to 0 regardless of actual instance value. The affected commands are LE Set Advertising Set Random Address, LE Set Extended Advertising Data, and LE Set Extended Scan Response Data commands. Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Vasily Khoruzhick authored
RTL8723BS is often used in ARM boards, so add ability to bind it using device tree. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Alistair Francis <alistair@alistair23.me> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Vasily Khoruzhick authored
Add binding document for bluetooth part of RTL8723BS/RTL8723CS Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Alistair Francis <alistair@alistair23.me> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 28 Apr, 2020 6 commits
-
-
Christian Hewitt authored
Move the read of max-speed from device-tree out of the qca_is_wcn399x if block so oper_speed can be set for QCA9377 devices as well. Suggested-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Christian Hewitt authored
Add a compatible so QCA9377 devices can be defined in device-tree. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Christian Hewitt authored
QCA9377 is a QCA ROME device frequently found in Android TV boxes. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Alain Michaud authored
This change adds support for LE scatternet connections to Intel's JfP and ThP controllers. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Alain Michaud authored
This change allows scatternet connections to be created if the controller reports support and the HCI_QUIRK_VALID_LE_STATES indicates that the reported LE states can be trusted. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Alain Michaud authored
This change adds the relevant driver and quirk to allow drivers to report the le_states as being trustworthy. This has historically been disabled as controllers did not reliably support this. In particular, this will be used to relax this condition for controllers that have been well tested and reliable. /* Most controller will fail if we try to create new connections * while we have an existing one in slave role. */ if (hdev->conn_hash.le_num_slave > 0) return NULL; Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 22 Apr, 2020 8 commits
-
-
Hans de Goede authored
Currently the bcm_uart_subver_ and bcm_usb_subver_table-s lack entries for the BCM4324B5 and BCM20703A1 chipsets. This makes the code use just "BCM" as prefix for the filename to pass to request-firmware, making it harder for users to figure out which firmware they need. This especially is problematic with the UART attached BCM4324B5 where this leads to the filename being just "BCM.hcd". Add the 2 missing devices to subver tables. This has been tested on: 1. A Dell XPS15 9550 where this makes btbcm.c try to load "BCM20703A1-0a5c-6410.hcd" before it tries to load "BCM-0a5c-6410.hcd". 2. A Thinkpad 8 where this makes btbcm.c try to load "BCM4324B5.hcd" before it tries to load "BCM.hcd" Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
Currently the bcm_uart_subver_ and bcm_usb_subver_table-s lack entries for various newer chipsets. This makes the code use just "BCM" as prefix for the filename to pass to request-firmware, making it harder for users to figure out which firmware they need. This especially a problem with UART attached devices where this leads to the filename being "BCM.hcd". If we add new entries to the subver-tables now, then this will change what firmware file the kernel looks for, e.g. currently linux-firmware contains a brcm/BCM-0bb4-0306.hcd file. If we add the info for the BCM20703A1 to the subver table, then this will change to brcm/BCM20703A1-0bb4-0306.hcd. This will cause the file to no longer get loaded breaking Bluetooth for existing users, going against the no regressions policy. To avoid this regression make the btbcm code try multiple filenames, first try the fullname, e.g. BCM20703A1-0bb4-0306.hcd and if that is not found, then fallback to the name with just BCM as prefix. This commit also adds an info message which filename was used, this makes the output look like this for example: [ 57.387867] Bluetooth: hci0: BCM20703A1 [ 57.387870] Bluetooth: hci0: BCM20703A1 (001.001.005) build 0000 [ 57.389438] Bluetooth: hci0: BCM20703A1 'brcm/BCM20703A1-0a5c-6410.hcd' Patch [ 58.681769] Bluetooth: hci0: BCM20703A1 Generic USB 20Mhz fcbga_BU [ 58.681772] Bluetooth: hci0: BCM20703A1 (001.001.005) build 0481 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
If we have already loaded the firmware/patchram and btbcm_initialize() is called to re-init the HCI after this then there is no need to get the USB device-ids and build a firmware-filename out of these. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
On UART attached devices we do: 1. btbcm_initialize() 2. Setup UART baudrate, etc. 3. btbcm_finalize() After our previous changes we can now also use btbcm_finalize() from the btbcm_setup_patchram() function used on USB devices without any functional changes. This completes unifying the USB and UART paths as much as possible. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
Make btbcm_initialize() get and print the device's local-name on re-init too, this will make us also print the local-name after loading the Patch on UART attached devices making things more consistent. This also removes some code duplication from btbcm_setup_patchram() and allows more code duplication removal there in a follow-up patch. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
Instead of having btbcm_initialize() fill a passed in fw_name buffer and then have its callers use that to request the firmware + load it into the HCI, make btbcm_initialize() do this itself the first time it is called (its get called a second time to reset the HCI after the firmware has been loaded). This removes some code duplication and makes it easier for further patches in this series to try more then 1 firmware filename. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
btbcm_finalize() is currently only used by UART attached BCM devices. Move the setting of the USE_BDADDR_PROPERTY quirk, which we only want for UART attached devices to hci_bcm in preparation for using btbcm_finalize() for USB attached devices too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
btbcm_initialize() must either return an error; or fill the passed in fw_name, otherwise we end up passing uninitialized stack memory to request_firmware(). Since we have a fallback hw_name of "BCM" not having a known version in the subver field does not matter, drop the check so that we always fill the passed in fw_name. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 21 Apr, 2020 13 commits
-
-
David S. Miller authored
Yangbo Lu says: ==================== Support programmable pins for Ocelot PTP driver The Ocelot PTP clock driver had been embedded into ocelot.c driver. It had supported basic gettime64/settime64/adjtime/adjfine functions by now which were used by both Ocelot switch and Felix switch. This patch-set is to move current ptp clock code out of ocelot.c driver maintaining as a single ocelot_ptp.c driver, and to implement 4 programmable pins with only PTP_PF_PEROUT function for now. The PTP_PF_EXTTS function will be supported in the future, and it should be implemented separately for Felix and Ocelot, because of different hardware interrupt implementation in them. Changes for v2: - Put PTP driver under drivers/net/ethernet/mscc/. - Dropped MAINTAINERS patch. Kept original maintaining. - Initialized PTP separately in ocelot/felix platforms. - Supported PPS case in programmable pin. - Supported disabling pin function since deadlock is fixed by Richard. - Returned -EBUSY if not finding pin available. Changes for v3: - Re-sent. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
Enable PTP programmable pin. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
Enable PTP programmable pin. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
Support 4 PTP programmable pins with only PTP_PF_PEROUT function for now. The PTP_PF_EXTTS function will be supported in the future, and it should be implemented separately for Felix and Ocelot, because of different hardware interrupt implementation in them. Since the hardware is not able to support absolute start time, the periodic clock request only allows start time 0 0. But nsec could be accepted for PPS case for phase adjustment. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
Add wave programming registers definitions for Ocelot platforms. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
There are 5 PTP_PINS register groups on Ocelot switch. Except the one used for TOD operations, there are still 4 register groups for programmable pins. So redefine the 4 programmable pins. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
The timestamp info should be only software timestamp capabilities if ptp clock does not work. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangbo Lu authored
The Ocelot PTP clock driver had been embedded into ocelot.c driver. It had supported basic gettime64/settime64/adjtime/adjfine functions by now which were used by both Ocelot switch and Felix switch. This patch is to move current ptp clock code out of ocelot.c driver maintaining as a single ocelot_ptp.c. For futher new features implementation, the common code could be put in ocelot_ptp.c and the switch specific code should be in specific switch driver. The interrupt implementation in SoC is different between Ocelot and Felix. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Leon Romanovsky says: ==================== Remove vermagic header from global include folder Changelog: v2: * Changed the implementation of patch #4 to be like Masahiro wants. I personally don't like this implementation and changing it just to move forward this this patchset. v1: https://lore.kernel.org/lkml/20200415133648.1306956-1-leon@kernel.org * Added tags * Updated patch #4 with test results * Changed scripts/mod/modpost.c to create inclusion of vermagic.h from kernel folder and not from general include/linux. This is needed to generate *.mod.c files, while building modules. v0: https://lore.kernel.org/lkml/20200414155732.1236944-1-leon@kernel.org This is followup to the failure reported by Borislav [1] and suggested fix later on [2]. The series removes all includes of linux/vermagic.h, updates hns and nfp to use same kernel versioning scheme (exactly like we did for other drivers in previous cycle) and removes vermagic.h from global include folder. [1] https://lore.kernel.org/lkml/20200411155623.GA22175@zn.tnic [2] https://lore.kernel.org/lkml/20200413080452.GA3772@zn.tnic ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
VERMAGIC* definitions are not supposed to be used by the drivers, see this [1] bug report, so introduce special define to guard inclusion of this header file and define it in kernel/modules.h and in internal script that generates *.mod.c files. In-tree module build: ➜ kernel git:(vermagic) ✗ make clean ➜ kernel git:(vermagic) ✗ make M=drivers/infiniband/hw/mlx5 ➜ kernel git:(vermagic) ✗ modinfo drivers/infiniband/hw/mlx5/mlx5_ib.ko filename: /images/leonro/src/kernel/drivers/infiniband/hw/mlx5/mlx5_ib.ko <...> vermagic: 5.6.0+ SMP mod_unload modversions Out-of-tree module build: ➜ mlx5 make -C /images/leonro/src/kernel clean M=/tmp/mlx5 ➜ mlx5 make -C /images/leonro/src/kernel M=/tmp/mlx5 ➜ mlx5 modinfo /tmp/mlx5/mlx5_ib.ko filename: /tmp/mlx5/mlx5_ib.ko <...> vermagic: 5.6.0+ SMP mod_unload modversions [1] https://lore.kernel.org/lkml/20200411155623.GA22175@zn.tnicReported-by: Borislav Petkov <bp@suse.de> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Jessica Yu <jeyu@kernel.org> Co-developed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Change nfp driver to use globally defined kernel version. Reported-by: Borislav Petkov <bp@suse.de> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Use globally defined kernel version instead of custom driver variant. Reported-by: Borislav Petkov <bp@suse.de> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Get rid of linux/vermagic.h includes, so that MODULE_ARCH_VERMAGIC from the arch header arch/x86/include/asm/module.h won't be redefined. In file included from ./include/linux/module.h:30, from drivers/net/ethernet/3com/3c515.c:56: ./arch/x86/include/asm/module.h:73: warning: "MODULE_ARCH_VERMAGIC" redefined 73 | # define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY | In file included from drivers/net/ethernet/3com/3c515.c:25: ./include/linux/vermagic.h:28: note: this is the location of the previous definition 28 | #define MODULE_ARCH_VERMAGIC "" | Fixes: 6bba2e89 ("net/3com: Delete driver and module versions from 3com drivers") Co-developed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Shannon Nelson <snelson@pensando.io> # ionic Acked-by: Sebastian Reichel <sre@kernel.org> # power Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-