Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

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 + >>>

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

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 + >>>

Re: [PATCH 0/7] gnss: add new GNSS subsystem

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

Re: [PATCH 0/7] gnss: add new GNSS subsystem

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

Re: [PATCH] Bluetooth: btusb: add ID for LiteOn 04ca:301a

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:*

Re: [PATCH] Bluetooth: btusb: add ID for LiteOn 04ca:301a

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:*

Re: [PATCH] Bluetooth: use wait_event API instead of open-coding it

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

Re: [PATCH] Bluetooth: use wait_event API instead of open-coding it

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

Re: [PATCH] Bluetooth: use wait_event API instead of open-coding it

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

Re: Bluetooth/lock_sock: false positive "WARNING: possible recursive locking detected"

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

Re: [PATCH v7 0/4] Bluetooth: hci_qca: Add serdev support

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

Re: [PATCH v7 0/4] Bluetooth: hci_qca: Add serdev support

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

Re: [PATCH] Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loader

l...@linaro.org> > CC: Nicolas Dechesne <nicolas.deche...@linaro.org> > CC: Marcel Holtmann <mar...@holtmann.org> > CC: Johan Hedberg <johan.hedb...@gmail.com> > CC: Stable <sta...@vger.kernel.org> > Signed-off-by: Amit Pundir <amit.pun...@linaro.org&g

Re: [PATCH] Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loader

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

Re: [PATCH 0/2] gobi: support SMD devices (smartphone SoC)

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,

Re: [PATCH 0/2] gobi: support SMD devices (smartphone SoC)

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 >

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()

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

Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()

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

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

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

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

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 + >

Re: [PATCH] Bluetooth: Mark expected switch fall-throughs

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

Re: [PATCH] Bluetooth: Mark expected switch fall-throughs

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

Re: [PATCH] Bluetooth: Mark expected switch fall-throughs

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

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

Re: pull request: bluetooth 2018-03-16

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

Re: [PATCH v5 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

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

Re: [PATCH v5 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

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

Re: [PATCH v5 3/3] Bluetooth: hci_qca: Add serdev support

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

Re: [PATCH v5 3/3] Bluetooth: hci_qca: Add serdev support

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)

Re: pull request: bluetooth 2018-03-16

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

Re: [PATCH 3/4] Bluetooth: trailing statements

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

Re: [PATCH 3/4] Bluetooth: trailing statements

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 >

Re: [PATCH 1/4] Bluetooth: trailing whitespace

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 >

Re: [PATCH 1/4] Bluetooth: trailing whitespace

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: [PATCH] Bluebooth: btusb: Fix quirk for Atheros 1525/QCA6174

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

Re: [PATCH] Bluebooth: btusb: Fix quirk for Atheros 1525/QCA6174

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

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

; drivers/bluetooth/Kconfig| 4 +--- > drivers/net/wireless/rsi/Kconfig | 4 +++- > 2 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann <mar...@holtmann.org> Since I think Kalle still has to take it through his tree until the btrsi driver makes it into net-next. Regards Marcel

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

; drivers/bluetooth/Kconfig| 4 +--- > drivers/net/wireless/rsi/Kconfig | 4 +++- > 2 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann <mar...@holtmann.org> Since I think Kalle still has to take it through his tree until the btrsi driver makes it into net-next. Regards Marcel

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

; drivers/bluetooth/Kconfig| 4 +--- > drivers/net/wireless/rsi/Kconfig | 4 +++- > 2 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann <mar...@holtmann.org> Since I think Kalle still has to take it through his tree until the btrsi driver makes it into net-next. Regards Marcel

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

nfig| 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

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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 >>> >>>

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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 >>> >>>

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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 >>> >>>

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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 >>> >>>

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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) >

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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) >

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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) >

Re: [PATCH] Bluetooth: btrsi: rework dependencies

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) >

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

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

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

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

Re: [PATCH v4 3/3] Bluetooth: hci_qca: Add serdev support

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

Re: [PATCH v4 3/3] Bluetooth: hci_qca: Add serdev support

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() > -

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

Hi Bjorn, > + bt-disable-n-gpios = <_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

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

Hi Bjorn, > + bt-disable-n-gpios = <_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

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

Hi Bjoern, >>> + bt-disable-n-gpios = <_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 the

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

Hi Bjoern, >>> + bt-disable-n-gpios = <_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 the

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

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

Re: [PATCH v4 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

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 > >

Re: [2/3] mwifiex: support sysfs initiated device coredump

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: [2/3] mwifiex: support sysfs initiated device coredump

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: [2/3] mwifiex: support sysfs initiated device coredump

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: Atheros 1525/QCA6174 BT issue

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: Atheros 1525/QCA6174 BT issue

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

Re: [PATCH 1/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_register_dev()

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

Re: [PATCH 1/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_register_dev()

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

Re: [PATCH 3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host() after error detection

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. >

Re: [PATCH 3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host() after error detection

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. >

Re: [PATCH 2/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_register_dev()

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

Re: [PATCH 4/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_card_to_host()

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

Re: [PATCH 2/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_register_dev()

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

Re: [PATCH 4/5] Bluetooth: btmrvl: Delete an unnecessary variable initialisation in btmrvl_sdio_card_to_host()

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

Re: [PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()

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 > ---

Re: [PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()

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

Re: Atheros 1525/QCA6174 BT issue

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 >

Re: Atheros 1525/QCA6174 BT issue

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 >

Re: [PATCH 1/1] doc: Fix documentation for HFP memory dialling

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

Re: [PATCH 1/2] cfg80211: Add support to enable or disable btcoex

Hi Arend, This patch introduces NL80211_CMD_SET_BTCOEX command and NL80211_ATTR_BTCOEX_OP attribute to enable or disable btcoex. >>> >>> What kind of btcoex are we talking about here? Is it signalling >>> between wlan and bt to get access to the shared RF. >> >> Yes, at least that's

Re: [PATCH] Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table

Hi Kai-Heng, > The issue can be reproduced before commit fd865802c66b ("Bluetooth: > btusb: fix QCA Rome suspend/resume") gets introduced, so the reset > resume quirk is still needed for this system. > > T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > D: Ver= 2.01

Re: [PATCH] Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table

Hi Kai-Heng, > The issue can be reproduced before commit fd865802c66b ("Bluetooth: > btusb: fix QCA Rome suspend/resume") gets introduced, so the reset > resume quirk is still needed for this system. > > T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > D: Ver= 2.01

Re: [PATCH] Bluetooth: btqcomsmd: Fix channel open check

Hi Bjorn, > rpmsg_create_ept() returns NULL on error and as such > qcom_wcnss_open_channel() does the same. Clarify this in the > kernel-doc and correct the error checks in btqcomsmd. > > Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI > driver") > Cc:

Re: [PATCH] Bluetooth: btqcomsmd: Fix channel open check

Hi Bjorn, > rpmsg_create_ept() returns NULL on error and as such > qcom_wcnss_open_channel() does the same. Clarify this in the > kernel-doc and correct the error checks in btqcomsmd. > > Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI > driver") > Cc:

Re: [PATCH 3/3] btmrvl: support sysfs initiated firmware coredump

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 in btmrvl_sdio adding the .coredump() > driver callback. This makes dump through debugfs obsolete so removing > it. >

Re: [PATCH 3/3] btmrvl: support sysfs initiated firmware coredump

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 in btmrvl_sdio adding the .coredump() > driver callback. This makes dump through debugfs obsolete so removing > it. >

Re: [PATCH 3/3] btmrvl: support sysfs initiated firmware coredump

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 in btmrvl_sdio adding the .coredump() > driver callback. This makes dump through debugfs obsolete so removing > it. >

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Carlo, >> Great, thanks for all the info! I'll definitely keep you CC'ed on my >> progress. I'm still very new to kernel development so I expect it'll >> take me quite a while, but I do have a fair bit of time to devote to >> this. > > Welcome to this crazy world ;) > Keep me on CC also, I

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Martin, Is this for devices with a RTL8723BS chip? If so then they still will not work after this since there also no longer is a /dev/ttyS4 created for the UART for the bluetooth, instead you probably want:

<    4   5   6   7   8   9   10   11   12   13   >