Hi Sukumar,
> We need an option to reset Bluetooth using GPIO toggle for a Linux product
> when
> BT connected over USB (HCI interface). i.e I need out of band(OOB) signal for
> USB to control/reset the BT. hence I opt to add ACPI device in RfKill gpio
> driver(rfkill-gpio.c).
>
> localhost /sys
Hi Corentin,
> Nothing in tree use this header which seems a remains of a staging
> driver.
> This patch remove it.
>
> Signed-off-by: Corentin Labbe
> ---
> include/linux/platform_data/bt-nokia-h4p.h | 38 --
> 1 file changed, 38 deletions(-)
> delete mode 100644 incl
uiring the lock.
> The callback may be invoked either in IRQ or BH context depending on the
> USB host controller.
> Use the _irqsave variant of the locking primitives.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Seb
Hi Jian-Hong,
> Without this patch we cannot turn on the Bluethooth adapter on HP
> 14-bs007la.
>
> T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0bda ProdID=b009 Rev= 2.00
> S: Manufacturer=Realtek
uiring the lock.
> The callback may be invoked either in IRQ or BH context depending on the
> USB host controller.
> Use the _irqsave variant of the locking primitives.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Seb
ad.
>
> Signed-off-by: David S. Miller
> ---
> drivers/bluetooth/hci_nokia.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Marcel Holtmann
Regards
Marcel
Hi Ricardo,
the commit message is misleading me. If I build something with ACPI or DT
support, then modinfo will show all modalias information for ACPI and DT
compatible strings. What else does udev/modprobe actually need? Is
something broken with the modalias export?
>>>
>
Hi Ricardo,
the commit message is misleading me. If I build something with ACPI or DT
support, then modinfo will show all modalias information for ACPI and DT
compatible strings. What else does udev/modprobe actually need? Is
something broken with the modalias export?
>>>
>
Hi Rob,
Added support to automatically configure the SCO packet routing at the
device setup. The SCO packets are used with the HSP / HFP profiles, but in
some devices (ex. CYW43438) they are routed to a PCM output by default.
This
change allows sending the vendor specific
Hi Rob,
Added support to automatically configure the SCO packet routing at the
device setup. The SCO packets are used with the HSP / HFP profiles, but in
some devices (ex. CYW43438) they are routed to a PCM output by default.
This
change allows sending the vendor specific
Hi Marcel,
>> the commit message is misleading me. If I build something with ACPI or DT
>> support, then modinfo will show all modalias information for ACPI and DT
>> compatible strings. What else does udev/modprobe actually need? Is something
>> broken with the modalias export?
>
> The main p
Hi Marcel,
>> the commit message is misleading me. If I build something with ACPI or DT
>> support, then modinfo will show all modalias information for ACPI and DT
>> compatible strings. What else does udev/modprobe actually need? Is something
>> broken with the modalias export?
>
> The main p
Hi Andy,
>> Rave-sp behaves differently based on the device variant.
>
>
>>sp->variant = of_device_get_match_data(dev);
>> + if (!sp->variant) {
>> + id = serdev_match_id(rave_sp_serdev_id, serdev);
>
> I think you may leave the ID table where it is in the code and u
Hi Ricardo,
> Export serdev table to the module header, allowing module autoload via
> udev/modprobe.
>
> Cc: Lee Jones
> Cc: Rob Herring
> Cc: Johan Hovold
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/mfd/rave-sp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/d
Hi Ricardo,
> Export serdev table to the module header, allowing module autoload via
> udev/modprobe.
>
> Cc: Lino Sanfilippo
> Cc: David S. Miller
> Cc: Stefan Wahren
> Cc: Rob Herring
> Cc: Johan Hovold
> Cc: netdev@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/
Hi Ricardo,
> Export serdev table to the module header, allowing module autoload via
> udev/modprobe.
>
> Cc: Lino Sanfilippo
> Cc: David S. Miller
> Cc: Stefan Wahren
> Cc: Rob Herring
> Cc: Johan Hovold
> Cc: net...@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/
Hi Ricardo,
> Export serdev table to the module header, allowing module autoload via
> udev/modprobe.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: Rob Herring
> Cc: Johan Hovold
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado
Hi Ricardo,
> Describe which hardware is supported by the current driver.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: Rob Herring
> Cc: Johan Hovold
> Cc: Andy Shevchenko
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado
Hi Attila,
please include a commit message explains the changes.
> Signed-off-by: Attila Tőkés
> ---
> drivers/bluetooth/hci_bcm.c | 61 +
> 1 file changed, 61 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
> index ddb
Hi Pavel,
>>> Describe which hardware is supported by the current driver.
>>>
>>> Cc: Marcel Holtmann
>>> Cc: Johan Hedberg
>>> Cc: Rob Herring
>>> Cc: Johan Hovold
>>> Cc: linux-blueto...@vger.kernel.org
>>> Signed-of
Hi Ricardo,
> Describe which hardware is supported by the current driver.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: Rob Herring
> Cc: Johan Hovold
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/bluetooth/h
Hi Artiom,
> The Asus ROG GL702ZC laptop contains a Realtek RTL8822BE device with
> an associated BT chip using a USB ID of 13d3:3526. This ID is added
> to the driver.
>
> The /sys/kernel/debug/usb/devices portion for this device is:
>
> T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 5 Spd=12
Hi Sean,
>>
>> [ ... ]
>
> [ ... ]
>
>>> I post it as plain text as below
>>>
>>>
>>> Bluetooth monitor ver 5.37
>>> = Note: Linux version 4.16.0-rc1+ (aarch64)
>>> 0.641494
>>> = Note: Bluetooth subsystem version 2.22
>>> 0.
Hi Artiom,
> The Asus ROG GL702ZC laptop contains a Realtek RTL8822BE device with
> an associated BT chip using a USB ID of 13d3:3526. This ID is added
> to the driver.
please include the /sys/kernel/debug/usb/devices portion for this device in the
commit messages.
Regards
Marcel
Hi Thierry,
> This patch fixes the following warning during boot:
>
> do not call blocking ops when !TASK_RUNNING; state=1 set at
> [<(ptrval)>] qca_setup+0x194/0x750 [hci_uart]
> WARNING: CPU: 2 PID: 1878 at kernel/sched/core.c:6135
> __might_sleep+0x7c/0x88
>
> In qca_set_baudrate(), the curre
Hi Sean,
[ ... ]
>> -if (hci_dev_test_flag(hdev, HCI_SETUP)) {
>> +if (hci_dev_test_flag(hdev, HCI_SETUP) ||
>> +test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
>> hci_sock_dev_event(hdev, HCI_DEV_SETUP);
>
>
Hi Sean,
>>
>> [ ... ]
>>
- if (hci_dev_test_flag(hdev, HCI_SETUP)) {
+ if (hci_dev_test_flag(hdev, HCI_SETUP) ||
+ test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
hci_sock_dev_event(hdev, HCI_DEV_SETUP);
>>>
>>> I am not 100% sure that we want t
Hi Vaibhav,
> checkpatch.pl shows a warning for these unnecessary curly braces.
> so just removed those curly braces.
>
> Signed-off-by: Vaibhav Murkute
> ---
> drivers/bluetooth/hci_serdev.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
patch has been applied to bluetooth-next tree.
Hi Sean,
> Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
> runs setup() after every open() and not just after the first open().
>
> Signed-off-by: Sean Wang
> ---
> include/net/bluetooth/hci.h | 9 +
> net/bluetooth/hci_core.c| 3 ++-
> 2 files changed, 11 i
Hi Jian-Hong,
> Without this patch we cannot turn on the Bluethooth adapter on ASUS
> E406MA.
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=2ff8 ProdID=b011 Rev= 2.00
> S: Manufacturer=Realtek
>
Hi Takashi,
> In commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros
> 1525/QCA6174") we tried to address the non-working Atheros BT devices
> by changing the quirk from BTUSB_ATH3012 to BTUSB_QCA_ROME. This made
> such devices working while it turned out to break other existing chips
>
Hi Joey,
> nice to hear, somebody else is using it.
>
> The voicecall driver needs to be refactored as Denis already pointed
> out on the mailinglist before it can go upstream.
>
> The original idea of the voice_generated.c/h files was to create a
> prototype how qmi generated files should look
Hi Jian-Hong,
> A Low-Power Wide-Area Network (LPWAN) is a type of wireless
> telecommunication wide area network designed to allow long range
> communications at a low bit rate among things (connected objects), such
> as sensors operated on a battery. It can be used widely in IoT area.
> LoRaWAN
Hi Jian-Hong,
> A Low-Power Wide-Area Network (LPWAN) is a type of wireless
> telecommunication wide area network designed to allow long range
> communications at a low bit rate among things (connected objects), such
> as sensors operated on a battery. It can be used widely in IoT area.
> LoRaWAN
Hi Pavel,
If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
not like that, either, but with +CMS ERROR: 500.
>>>
>>> CNMA=1 is required to work in PDU mode according to 27.005 btw. How
>>> about:
>>>
>>> window.open();
>>> window.t
Hi Pavel,
>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
>> not like that, either, but with +CMS ERROR: 500.
>
> CNMA=1 is required to work in PDU mode according to 27.005 btw. How
> about:
>
> window.open();
> window.throw(modem);
>>>
Hi Pavel,
>> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
>>> AT+CNMI=?
>> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
>> < OK
>> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
>> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
>>> AT+CNMI=1,2,2,1,0
>>
Hi Johan,
>> I have one concern, though. While providing raw data by
>> default is fine generally, it is a problem with device
>> auto-discovery. I think there should be some IOCTL from
>> the start, that can be used to inform userspace about
>> the raw protocol being used (i.e
Hi Sean,
> +
> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16
> plen,
> + const void *param)
> +{
> + struct mtk_bt_dev *btdev = hu->priv;
> + struct hci_command_hdr *hhdr;
> + struct hci_acl_hdr *ahdr;
> + struct
Hi Johan,
I have one concern, though. While providing raw data by
default is fine generally, it is a problem with device
auto-discovery. I think there should be some IOCTL from
the start, that can be used to inform userspace about
the raw protocol being used (i.e. "NMEA").
Hi Sean,
>>> +
>>> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16
>>> plen,
>>> + const void *param)
>>> +{
>>> + struct mtk_bt_dev *btdev = hu->priv;
>>> + struct hci_command_hdr *hhdr;
>>> + struct hci_acl_hdr *ahdr;
>>> + struct mtk_wmt_
Hi Johan,
>>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>>> receivers).
>>>
>>> While GNSS receivers are typically accessed using a UART interface they
>>> often also support other I/O interfaces such as I2C, SPI and USB, while
>>> yet other devices use iomem or even some form
Hi Pavel,
(*) I have those in mind:
Nokia N900: The phone has GPS integrated into the modem and uses
ISI encapsulated data. The protocol has been reverse engineered
and it should be possible to write a kernel driver for handling
the GPS packets and dumping the raw da
Hi Joao Paulo,
> Without this patch we can't establish a SCO connection with this
> adapter.
>
> This adapter is named "IMC Networks" under lsusb.
>
> T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=13
Hi Sean,
>>> This adds a driver for the MediaTek serial protocol based on H4
>>> protocol,
>>> which can enable the built-in Bluetooth device inside MT7622 SoC.
>>>
>>> Signed-off-by: Sean Wang
>>> ---
>>>
>
> [... snip ...]
>
>>>
>>> where could I find the newest bt
Hi Sean,
> This adds a driver for the MediaTek serial protocol based on H4 protocol,
> which can enable the built-in Bluetooth device inside MT7622 SoC.
>
> Signed-off-by: Sean Wang
> ---
>
> [... snip ...]
>
> +
> + /* Start to build a WMT header and its actual pay
Hi Sean,
>>> This adds a driver for the MediaTek serial protocol based on H4 protocol,
>>> which can enable the built-in Bluetooth device inside MT7622 SoC.
>>>
>>> Signed-off-by: Sean Wang
>>> ---
>>> drivers/bluetooth/Kconfig| 12 +
>>> drivers/bluetooth/Makefile | 1 +
>>> driv
Hi Pavel,
>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>> receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
> right? We'd like to QZSS to use similar interface, too…
GNSS is th
Hi Matthias,
> Contains a QCA6174A chipset, with USB BT. Let's support loading
> firmware on it.
>
> From usb-devices:
> T: Bus=02 Lev=01 Prnt=01 Port=00 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=301a Rev= 0.01
> C:*
Hi John,
> I've seen timeout errors from HCI commands where it looks like
> schedule_timeout() has returned immediately; additional logging for the
> error case gives:
>
> req_status=1 req_result=0 remaining=1 jiffies
>
> so the device is still in state HCI_REQ_PEND and the value retur
Hi John,
> I've seen timeout errors from HCI commands where it looks like
> schedule_timeout() has returned immediately; additional logging for the
> error case gives:
>
> req_status=1 req_result=0 remaining=1 jiffies
>
> so the device is still in state HCI_REQ_PEND and the value retur
Hi Jiri,
>> [ 2891.586061]
>> [ 2891.586063] WARNING: possible recursive locking detected
>> [ 2891.586065] 4.16.2-10.ge881e16-default #1 Not tainted
>> [ 2891.586067]
>> [ 2891.586068] kworker/u9:3/873 is tr
Hi Thierry,
> This patchset enables the Qualcomm BT controller QCA6174 node in the
> device tree of the db820c board. This allows the bluetooth chipset to
> be probed and registered against the hci layer by using the serdev
> framework.
>
> This patchset also contains the documentation for the co
icolas Dechesne
> CC: Marcel Holtmann
> CC: Johan Hedberg
> CC: Stable
> Signed-off-by: Amit Pundir
> ---
> drivers/bluetooth/hci_qca.c | 6 ++
> 1 file changed, 6 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
Hi Joey,
>> I would still fix this upstream and only workaround devices blacklisted with
>> a quirk.
>
> I don't see how this would be possible. The issue with poll() lies in the
> kernel, not the device. I guess a patched kernel could somehow indicate that
> it supports poll() for writing, li
Hi Joey,
> These add support for Qualcomm-based smartphone modems.
>
> The first is fairly straightforward: searching for "rpmsg"-subsystem devices
> and supporting them in gobi as a serial device. A friend has tested it on the
> mainline kernel, with the help of something like `rpmsgexport
>
Hi Gustavo,
>> so I took this patch back out of bluetooth-next before sending the pull
>> request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro
>> needs to complete first. Once that has concluded we can revisit if this
>> patch is still needed or if another solution has been f
Hi Gustavo,
>> so I took this patch back out of bluetooth-next before sending the pull
>> request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro
>> needs to complete first. Once that has concluded we can revisit if this
>> patch is still needed or if another solution has been f
Hi Gustavo,
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in gener
Hi Gustavo,
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in gener
Hi Sean,
> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe phase.
>
> Similarly, the relevant dettach functio
Hi Sean,
> This adds a driver for the MediaTek serial protocol based on H4 protocol,
> which can enable the built-in Bluetooth device inside MT7622 SoC.
>
> Signed-off-by: Sean Wang
> ---
> drivers/bluetooth/Kconfig| 12 +
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/hc
Hi Gustavo,
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> net/bluetooth/mgmt.c| 1 +
> net/bluetooth/rfcomm/sock.c | 1 +
> 2 files changed, 2 insertions(+)
patch has been app
Hi Gustavo,
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> net/bluetooth/mgmt.c| 1 +
> net/bluetooth/rfcomm/sock.c | 1 +
> 2 files changed, 2 insertions(+)
patch has been app
Hi Gustavo,
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in gener
Hi Gustavo,
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in gener
Hi Dave,
>> any issue with this pull request? I ask since it seems to have
>> disappeared from patchwork.
>
> Should be pulled in now, don't know how that happened ;-)
awesome. Thanks.
Any chance you can pull net into net-next once you send it off to Linus? We
have a few further Broadcom drive
Hi Thierry,
> Add binding document for serial bluetooth chips using Qualcomm protocol.
>
> Signed-off-by: Thierry Escande
> ---
>
> v5:
> - Rename 'bt-disable-n' gpio as 'enable'
>
> v4:
> - Move bt-disable-n-gpios to required properties section
> - Add clocks and pinctrl-0 as required propert
Hi Thierry,
> Add support for Qualcomm serial slave devices. Probe the serial device,
> retrieve its maximum speed and register a new hci uart device.
>
> Signed-off-by: Thierry Escande
> ---
>
> v5:
> - Use gpio new name 'enable'
>
> v4:
> - Rename divclk4 as susclk (its name in the bt chip)
Hi Dave,
> Here are a few more important Bluetooth driver fixes for the 4.16
> kernel.
>
> Please let me know if there are any issues pulling. Thanks.
>
> Johan
>
> ---
> The following changes since commit 3d502067599f0db12e74e6646aee8728efe3e5be:
>
> net/smc: simplify wait when closing liste
Hi Paul,
> trailing statements should be on next line
>
> Signed-off-by: Paul McQuade
> ---
> drivers/bluetooth/hci_ll.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 1b4417a623a4..06d859d82de8 100644
>
Hi Paul,
> Removed whitespace
>
> Signed-off-by: Paul McQuade
> ---
> drivers/bluetooth/bfusb.c | 2 +-
> drivers/bluetooth/btuart_cs.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
> index ab090a313a5f..0d5
Hi Takashi,
>> we've got a but report about the broken Atheros BT on the recent
>> kernels:
>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
>>
>> In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and
>> this could be worked ar
Hi Takashi,
> The Atheros 1525/QCA6174 BT doesn't seem working properly on the
> recent kernels, as it tries to load a wrong firmware
> ar3k/AthrBT_0x0200.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
etooth/Kconfig| 4 +---
> drivers/net/wireless/rsi/Kconfig | 4 +++-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Marcel Holtmann
Since I think Kalle still has to take it through his tree until the btrsi
driver makes it into net-next.
Regards
Marcel
etooth/Kconfig| 4 +---
> drivers/net/wireless/rsi/Kconfig | 4 +++-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Marcel Holtmann
Since I think Kalle still has to take it through his tree until the btrsi
driver makes it into net-next.
Regards
Marcel
etooth/Kconfig| 4 +---
> drivers/net/wireless/rsi/Kconfig | 4 +++-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Marcel Holtmann
Since I think Kalle still has to take it through his tree until the btrsi
driver makes it into net-next.
Regards
Marcel
Hi Arnd,
>>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>>> index 03cfc1b20c4a..9e8d22712ff3 100644
>>> --- a/drivers/bluetooth/Makefile
>>> +++ b/drivers/bluetooth/Makefile
>>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o
>>>
>>> obj-$(CONFIG_BT_HCIU
Hi Arnd,
>>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>>> index 03cfc1b20c4a..9e8d22712ff3 100644
>>> --- a/drivers/bluetooth/Makefile
>>> +++ b/drivers/bluetooth/Makefile
>>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o
>>>
>>> obj-$(CONFIG_BT_HCIU
Hi Arnd,
>>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>>> index 03cfc1b20c4a..9e8d22712ff3 100644
>>> --- a/drivers/bluetooth/Makefile
>>> +++ b/drivers/bluetooth/Makefile
>>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o
>>>
>>> obj-$(CONFIG_BT_HCIU
Hi Arnd,
> 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/ne
Hi Arnd,
> 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/ne
Hi Arnd,
> 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/ne
Hi Sebastian,
BT_DISABLE_N is the name of this pin in the datasheet of the QCA chip,
not on the board, so this name is the same regardless of what you name
the line or gpio your board connect it to.
>>>
>>> and QCA chip v1 and QCA chip v2 will use the same driver and
>>> same firmw
Hi Thierry,
> Add support for Qualcomm serial slave devices. Probe the serial device,
> retrieve its maximum speed and register a new hci uart device.
>
> Signed-off-by: Thierry Escande
> ---
>
> v4:
> - Rename divclk4 as susclk (its name in the bt chip)
> - Use gpiod_set_value_cansleep()
> - R
Hi Bjorn,
> + bt-disable-n-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
can we use a common name here. I think that Nokia and Broadcom drivers
define one. And if this is the enable/shutdown GPIO, we should name it
consistently across all manufacturers. It essential
Hi Bjoern,
>>> + bt-disable-n-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
>>
>> can we use a common name here. I think that Nokia and Broadcom drivers
>> define one. And if this is the enable/shutdown GPIO, we should name it
>> consistently across all manufacturers. It essentially does
Hi Thierry,
> Add binding document for serial bluetooth chips using Qualcomm protocol.
>
> Signed-off-by: Thierry Escande
> ---
>
> v4:
> - Move bt-disable-n-gpios to required properties section
> - Add clocks and pinctrl-0 as required properties
>
> v3: no change
> v2: no change
>
> .../devi
Hi Arend,
> Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
> it is possible to initiate a device coredump from user-space. This
> patch adds support for it adding the .coredump() driver callback.
> As there is no longer a need to initiate it through debugfs re
Hi Arend,
> Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
> it is possible to initiate a device coredump from user-space. This
> patch adds support for it adding the .coredump() driver callback.
> As there is no longer a need to initiate it through debugfs re
Hi Takashi,
we've got a but report about the broken Atheros BT on the recent
kernels:
http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and
this could be worked around by the
Hi Takashi,
>> we've got a but report about the broken Atheros BT on the recent
>> kernels:
>> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
>>
>> In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and
>> this could be worked around by the patch to mov
Hi Takashi,
we've got a but report about the broken Atheros BT on the recent
kernels:
http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and
this could be worked around by the patch to move 0cf3:3004
Hi Markus,
> Adjust a jump target so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/bluetooth/btmrvl_sdio.c | 50
Hi Markus,
> One check could be repeated by the btmrvl_sdio_card_to_host() function
> during error handling even if the relevant properties can be determined
> for the involved variables before by source code analysis.
>
> * Adjust jump targets so that an extra check can be omitted at the end.
>
Hi Markus,
> 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
> ---
> drivers/bluetooth/btmrvl_sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applie
Hi Markus,
> 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
> ---
> drivers/bluetooth/btmrvl_sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has
Hi Markus,
> From: Markus Elfring
> Date: Mon, 12 Mar 2018 11:30:28 +0100
>
> Add a jump target so that the setting of a specific error code is stored
> only once at the end of this function.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/bluetooth/btmrvl_sdio.c | 13 +++--
> 1 file
Hi Takashi,
> we've got a but report about the broken Atheros BT on the recent
> kernels:
> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
>
> In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and
> this could be worked around by the patch to move 0cf3:3004 blacklist
> entry
Hi Philippe,
> Signed-off-by: Philippe De Swert
No signed-off-by please.
> ---
> doc/voicecallmanager-api.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/voicecallmanager-api.txt b/doc/voicecallmanager-api.txt
> index 5c4ce11b..96492ced 100644
> --- a/doc/vo
901 - 1000 of 5887 matches
Mail list logo
