* [PATCH v2 0/2] Bluetooth: hci_bcm: Autobaud mode support @ 2022-05-20 15:07 Hakan Jansson 2022-05-20 15:07 ` [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode Hakan Jansson 2022-05-20 15:07 ` [PATCH v2 2/2] Bluetooth: hci_bcm: Add support for FW loading in " Hakan Jansson 0 siblings, 2 replies; 6+ messages in thread From: Hakan Jansson @ 2022-05-20 15:07 UTC (permalink / raw) Cc: Hakan Jansson, David S. Miller, Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Linus Walleij, netdev, devicetree, linux-kernel, Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate when first powered on. Only a limited subset of HCI commands are supported in autobaud mode. These patches add a DT property, "brcm,uses-autobaud-mode", to control autobaud mode selection. Changes v1 -> v2: - Modify description in binding document Hakan Jansson (2): dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode Bluetooth: hci_bcm: Add support for FW loading in autobaud mode .../bindings/net/broadcom-bluetooth.yaml | 9 ++++++ drivers/bluetooth/btbcm.c | 31 ++++++++++++++----- drivers/bluetooth/btbcm.h | 8 ++--- drivers/bluetooth/hci_bcm.c | 15 +++++++-- 4 files changed, 48 insertions(+), 15 deletions(-) base-commit: 48b57999e38745b707abe233019786cc097df3c9 -- 2.25.1 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode 2022-05-20 15:07 [PATCH v2 0/2] Bluetooth: hci_bcm: Autobaud mode support Hakan Jansson @ 2022-05-20 15:07 ` Hakan Jansson 2022-05-22 8:14 ` Krzysztof Kozlowski 2022-05-20 15:07 ` [PATCH v2 2/2] Bluetooth: hci_bcm: Add support for FW loading in " Hakan Jansson 1 sibling, 1 reply; 6+ messages in thread From: Hakan Jansson @ 2022-05-20 15:07 UTC (permalink / raw) Cc: Hakan Jansson, David S. Miller, Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Linus Walleij, netdev, devicetree, linux-kernel, Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate when first powered on. This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud mode selection. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> --- V1 -> V2: Modify property description .../devicetree/bindings/net/broadcom-bluetooth.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml index 5aac094fd217..a29f059c21cc 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -92,6 +92,15 @@ properties: pcm-sync-mode: slave, master pcm-clock-mode: slave, master + brcm,uses-autobaud-mode: + type: boolean + description: > + Setting this property will make the host (driver) assert the controller + chip's BT_UART_CTS_N prior to asserting BT_REG_ON. This will make the + controller start up in autobaud mode. The controller will then detect the + baud rate of the first incoming (HCI Reset) command from the host and + subsequently use that baud rate. + interrupts: items: - description: Handle to the line HOST_WAKE used to wake -- 2.25.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode 2022-05-20 15:07 ` [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode Hakan Jansson @ 2022-05-22 8:14 ` Krzysztof Kozlowski 2022-05-23 9:21 ` Hakan Jansson 0 siblings, 1 reply; 6+ messages in thread From: Krzysztof Kozlowski @ 2022-05-22 8:14 UTC (permalink / raw) To: Hakan Jansson Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Linus Walleij, netdev, devicetree, linux-kernel, Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth On 20/05/2022 17:07, Hakan Jansson wrote: > Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Which devices support this? You probably need allOf:if:then. > Autobaud mode can also be required on some boards where the controller > device is using a non-standard baud rate when first powered on. > > This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud > mode selection. Don't use "This patch": https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 > > Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> > --- > V1 -> V2: Modify property description > > .../devicetree/bindings/net/broadcom-bluetooth.yaml | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml > index 5aac094fd217..a29f059c21cc 100644 > --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml > +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml > @@ -92,6 +92,15 @@ properties: > pcm-sync-mode: slave, master > pcm-clock-mode: slave, master > > + brcm,uses-autobaud-mode: Based on description, I understand the host triggers using autobaud. However here you word it as "uses", so it is independent of host, it looks like property of a device. The commit msg describes it even different - "require autobaud". This leads to second issue - it looks like there is some hardware property (requiring to use autobaud) which should be described by bindings. But instead you describe desired operational feature. > + type: boolean > + description: > No need for '>'. > + Setting this property will make the host (driver) assert the controller > + chip's BT_UART_CTS_N prior to asserting BT_REG_ON. This will make the > + controller start up in autobaud mode. The controller will then detect the > + baud rate of the first incoming (HCI Reset) command from the host and > + subsequently use that baud rate. > + > interrupts: > items: > - description: Handle to the line HOST_WAKE used to wake Best regards, Krzysztof ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode 2022-05-22 8:14 ` Krzysztof Kozlowski @ 2022-05-23 9:21 ` Hakan Jansson 2022-05-30 7:44 ` Krzysztof Kozlowski 0 siblings, 1 reply; 6+ messages in thread From: Hakan Jansson @ 2022-05-23 9:21 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Linus Walleij, netdev, devicetree, linux-kernel, Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth Hi Krzysztof, Thanks for responding. On 5/22/2022 10:14 AM, Krzysztof Kozlowski wrote: >> Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. > Which devices support this? You probably need allOf:if:then. Most devices _support_ autobaud mode but I don't have a definitive list. The CYW5557x is the first device family to _require_ autobaud mode for FW loading as far as I know. >> Autobaud mode can also be required on some boards where the controller >> device is using a non-standard baud rate when first powered on. >> >> This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud >> mode selection. > Don't use "This patch": > https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 Sorry, will change in next rev. >> Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> >> --- >> V1 -> V2: Modify property description >> >> .../devicetree/bindings/net/broadcom-bluetooth.yaml | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml >> index 5aac094fd217..a29f059c21cc 100644 >> --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml >> +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml >> @@ -92,6 +92,15 @@ properties: >> pcm-sync-mode: slave, master >> pcm-clock-mode: slave, master >> >> + brcm,uses-autobaud-mode: > Based on description, I understand the host triggers using autobaud. Correct, the host triggers using autobaud. > However here you word it as "uses", so it is independent of host, it > looks like property of a device. I've been thinking of it as a a property of a specific board HW, inherited either from a property of the device being used or from a property of the HW design (e.g. a PCB using an alternate crystal frequency yielding a non-standard baud rate). > The commit msg describes it even > different - "require autobaud". Yes, the commit message describes two separate reasons why autobaud mode would be required: 1. Requirement coming from Device: "Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading." 2. Requirement coming from HW design: "Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate when first powered on." > This leads to second issue - it looks like there is some hardware > property (requiring to use autobaud) which should be described by > bindings. But instead you describe desired operational feature. Sorry about that. I've really been struggling with what should go into the description. Any suggestions or hints would be much appreciated. How about, changing the property name to "brcm,requires-autobaud-mode" and the description to: "Set this property if autobaud mode is required. Autobaud mode is required if the device's baud rate in normal mode is not supported by the host or if the device requires autobaud mode startup before loading FW." Would that be an appropriate name and description? >> + type: boolean >> + description: > > No need for '>'. Ok, will remove in next rev. >> + Setting this property will make the host (driver) assert the controller >> + chip's BT_UART_CTS_N prior to asserting BT_REG_ON. This will make the >> + controller start up in autobaud mode. The controller will then detect the >> + baud rate of the first incoming (HCI Reset) command from the host and >> + subsequently use that baud rate. >> + >> interrupts: >> items: >> - description: Handle to the line HOST_WAKE used to wake > Thanks, Håkan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode 2022-05-23 9:21 ` Hakan Jansson @ 2022-05-30 7:44 ` Krzysztof Kozlowski 0 siblings, 0 replies; 6+ messages in thread From: Krzysztof Kozlowski @ 2022-05-30 7:44 UTC (permalink / raw) To: Hakan Jansson Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Linus Walleij, netdev, devicetree, linux-kernel, Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth On 23/05/2022 11:21, Hakan Jansson wrote: > Hi Krzysztof, > > Thanks for responding. > > On 5/22/2022 10:14 AM, Krzysztof Kozlowski wrote: >>> Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. >> Which devices support this? You probably need allOf:if:then. > > Most devices _support_ autobaud mode but I don't have a definitive list. > The CYW5557x is the first device family to _require_ autobaud mode for > FW loading as far as I know. > >>> Autobaud mode can also be required on some boards where the controller >>> device is using a non-standard baud rate when first powered on. >>> >>> This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud >>> mode selection. >> Don't use "This patch": >> https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 > > Sorry, will change in next rev. > >>> Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> >>> --- >>> V1 -> V2: Modify property description >>> >>> .../devicetree/bindings/net/broadcom-bluetooth.yaml | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml >>> index 5aac094fd217..a29f059c21cc 100644 >>> --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml >>> +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml >>> @@ -92,6 +92,15 @@ properties: >>> pcm-sync-mode: slave, master >>> pcm-clock-mode: slave, master >>> >>> + brcm,uses-autobaud-mode: >> Based on description, I understand the host triggers using autobaud. > > Correct, the host triggers using autobaud. > >> However here you word it as "uses", so it is independent of host, it >> looks like property of a device. > > I've been thinking of it as a a property of a specific board HW, > inherited either from a property of the device being used or from a > property of the HW design (e.g. a PCB using an alternate crystal > frequency yielding a non-standard baud rate). > >> The commit msg describes it even >> different - "require autobaud". > > Yes, the commit message describes two separate reasons why autobaud mode > would be required: > > 1. Requirement coming from Device: "Some devices (e.g. CYW5557x) require > autobaud mode to enable FW loading." > > 2. Requirement coming from HW design: "Autobaud mode can also be > required on some boards where the controller device is using a > non-standard baud rate when first powered on." > >> This leads to second issue - it looks like there is some hardware >> property (requiring to use autobaud) which should be described by >> bindings. But instead you describe desired operational feature. > > Sorry about that. I've really been struggling with what should go into > the description. Any suggestions or hints would be much appreciated. > > How about, changing the property name to "brcm,requires-autobaud-mode" > and the description to: > "Set this property if autobaud mode is required. Autobaud mode is > required if the device's baud rate in normal mode is not supported by > the host or if the device requires autobaud mode startup before loading FW." > > Would that be an appropriate name and description? Yes, sounds good. I also have trouble to name it nicely. Sorry for late reply. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2 2/2] Bluetooth: hci_bcm: Add support for FW loading in autobaud mode 2022-05-20 15:07 [PATCH v2 0/2] Bluetooth: hci_bcm: Autobaud mode support Hakan Jansson 2022-05-20 15:07 ` [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode Hakan Jansson @ 2022-05-20 15:07 ` Hakan Jansson 1 sibling, 0 replies; 6+ messages in thread From: Hakan Jansson @ 2022-05-20 15:07 UTC (permalink / raw) Cc: Hakan Jansson, David S. Miller, Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Linus Walleij, netdev, devicetree, linux-kernel, Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate when first powered on. Only a limited subset of HCI commands are supported in autobaud mode. This patch looks for a DT property, "brcm,uses-autobaud-mode", to enable autobaud mode selection. If the property is present, the device is started in autobaud mode by keeping RTS asserted while powering on the device. The patch also prevents the use of unsupported commands for devices started in autobaud mode. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> --- V1 -> V2: No changes, submitted as part of updated patch series drivers/bluetooth/btbcm.c | 31 +++++++++++++++++++++++-------- drivers/bluetooth/btbcm.h | 8 ++++---- drivers/bluetooth/hci_bcm.c | 15 ++++++++++++--- 3 files changed, 39 insertions(+), 15 deletions(-) diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c index 92a2b7e81757..0c0958030c0a 100644 --- a/drivers/bluetooth/btbcm.c +++ b/drivers/bluetooth/btbcm.c @@ -403,6 +403,13 @@ static int btbcm_read_info(struct hci_dev *hdev) bt_dev_info(hdev, "BCM: chip id %u", skb->data[1]); kfree_skb(skb); + return 0; +} + +static int btbcm_print_controller_features(struct hci_dev *hdev) +{ + struct sk_buff *skb; + /* Read Controller Features */ skb = btbcm_read_controller_features(hdev); if (IS_ERR(skb)) @@ -513,7 +520,7 @@ static const char *btbcm_get_board_name(struct device *dev) #endif } -int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done) +int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode) { u16 subver, rev, pid, vid; struct sk_buff *skb; @@ -550,9 +557,16 @@ int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done) if (err) return err; } - err = btbcm_print_local_name(hdev); - if (err) - return err; + + if (!use_autobaud_mode) { + err = btbcm_print_controller_features(hdev); + if (err) + return err; + + err = btbcm_print_local_name(hdev); + if (err) + return err; + } bcm_subver_table = (hdev->bus == HCI_USB) ? bcm_usb_subver_table : bcm_uart_subver_table; @@ -635,13 +649,13 @@ int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done) } EXPORT_SYMBOL_GPL(btbcm_initialize); -int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done) +int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode) { int err; /* Re-initialize if necessary */ if (*fw_load_done) { - err = btbcm_initialize(hdev, fw_load_done); + err = btbcm_initialize(hdev, fw_load_done, use_autobaud_mode); if (err) return err; } @@ -657,15 +671,16 @@ EXPORT_SYMBOL_GPL(btbcm_finalize); int btbcm_setup_patchram(struct hci_dev *hdev) { bool fw_load_done = false; + bool use_autobaud_mode = false; int err; /* Initialize */ - err = btbcm_initialize(hdev, &fw_load_done); + err = btbcm_initialize(hdev, &fw_load_done, use_autobaud_mode); if (err) return err; /* Re-initialize after loading Patch */ - return btbcm_finalize(hdev, &fw_load_done); + return btbcm_finalize(hdev, &fw_load_done, use_autobaud_mode); } EXPORT_SYMBOL_GPL(btbcm_setup_patchram); diff --git a/drivers/bluetooth/btbcm.h b/drivers/bluetooth/btbcm.h index 8bf01565fdfc..b4cb24231a20 100644 --- a/drivers/bluetooth/btbcm.h +++ b/drivers/bluetooth/btbcm.h @@ -62,8 +62,8 @@ int btbcm_write_pcm_int_params(struct hci_dev *hdev, int btbcm_setup_patchram(struct hci_dev *hdev); int btbcm_setup_apple(struct hci_dev *hdev); -int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done); -int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done); +int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode); +int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode); #else @@ -104,12 +104,12 @@ static inline int btbcm_setup_apple(struct hci_dev *hdev) return 0; } -static inline int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done) +static inline int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode) { return 0; } -static inline int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done) +static inline int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode) { return 0; } diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c index 785f445dd60d..0230cfcc8e3e 100644 --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -99,6 +99,7 @@ struct bcm_device_data { * @no_early_set_baudrate: don't set_baudrate before setup() * @drive_rts_on_open: drive RTS signal on ->open() when platform requires it * @pcm_int_params: keep the initial PCM configuration + * @use_autobaud_mode: start Bluetooth device in autobaud mode */ struct bcm_device { /* Must be the first member, hci_serdev.c expects this. */ @@ -136,6 +137,7 @@ struct bcm_device { #endif bool no_early_set_baudrate; bool drive_rts_on_open; + bool use_autobaud_mode; u8 pcm_int_params[5]; }; @@ -472,7 +474,9 @@ static int bcm_open(struct hci_uart *hu) out: if (bcm->dev) { - if (bcm->dev->drive_rts_on_open) + if (bcm->dev->use_autobaud_mode) + hci_uart_set_flow_control(hu, false); /* Assert BT_UART_CTS_N */ + else if (bcm->dev->drive_rts_on_open) hci_uart_set_flow_control(hu, true); hu->init_speed = bcm->dev->init_speed; @@ -564,6 +568,7 @@ static int bcm_setup(struct hci_uart *hu) { struct bcm_data *bcm = hu->priv; bool fw_load_done = false; + bool use_autobaud_mode = (bcm->dev ? bcm->dev->use_autobaud_mode : 0); unsigned int speed; int err; @@ -572,7 +577,7 @@ static int bcm_setup(struct hci_uart *hu) hu->hdev->set_diag = bcm_set_diag; hu->hdev->set_bdaddr = btbcm_set_bdaddr; - err = btbcm_initialize(hu->hdev, &fw_load_done); + err = btbcm_initialize(hu->hdev, &fw_load_done, use_autobaud_mode); if (err) return err; @@ -616,7 +621,7 @@ static int bcm_setup(struct hci_uart *hu) btbcm_write_pcm_int_params(hu->hdev, ¶ms); } - err = btbcm_finalize(hu->hdev, &fw_load_done); + err = btbcm_finalize(hu->hdev, &fw_load_done, use_autobaud_mode); if (err) return err; @@ -1197,6 +1202,10 @@ static int bcm_acpi_probe(struct bcm_device *dev) static int bcm_of_probe(struct bcm_device *bdev) { + bdev->use_autobaud_mode = device_property_read_bool(bdev->dev, "brcm,uses-autobaud-mode"); + if (bdev->use_autobaud_mode) + bdev->no_early_set_baudrate = true; + device_property_read_u32(bdev->dev, "max-speed", &bdev->oper_speed); device_property_read_u8_array(bdev->dev, "brcm,bt-pcm-int-params", bdev->pcm_int_params, 5); -- 2.25.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-05-30 7:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-20 15:07 [PATCH v2 0/2] Bluetooth: hci_bcm: Autobaud mode support Hakan Jansson 2022-05-20 15:07 ` [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode Hakan Jansson 2022-05-22 8:14 ` Krzysztof Kozlowski 2022-05-23 9:21 ` Hakan Jansson 2022-05-30 7:44 ` Krzysztof Kozlowski 2022-05-20 15:07 ` [PATCH v2 2/2] Bluetooth: hci_bcm: Add support for FW loading in " Hakan Jansson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).