[PATCH 1/2] Bluetooth: btbcm: Add entry for BCM4356A2 UART bluetooth

[PATCH 1/2] Bluetooth: btbcm: Add entry for BCM4356A2 UART bluetooth

[Hans de Goede]

This patch adds the device ID for the bluetooth chip used in the
Broadcom BCM4356 PCI-E WiFi / UART BT chip.

Successfully tested using Firmware version 0273

The upper nibble of the rev field is 2 on this device, so this commit
also adds handling of 2 to the switch-case done on the upper nibble.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/bluetooth/btbcm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 9ab6cfbb831d..6443ff01e1bf 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -296,6 +296,7 @@ static const struct {
 	{ 0x4406, "BCM4324B3"	},	/* 002.004.006 */
 	{ 0x610c, "BCM4354"	},	/* 003.001.012 */
 	{ 0x2209, "BCM43430A1"  },	/* 001.002.009 */
+	{ 0x230f, "BCM4356A2"	},	/* 001.003.015 */
 	{ }
 };
 
@@ -333,6 +334,7 @@ int btbcm_initialize(struct hci_dev *hdev, char *fw_name, size_t len)
 	switch ((rev & 0xf000) >> 12) {
 	case 0:
 	case 1:
+	case 2:
 	case 3:
 		for (i = 0; bcm_uart_subver_table[i].name; i++) {
 			if (subver == bcm_uart_subver_table[i].subver) {
-- 
2.13.4

[PATCH 2/2] Bluetooth: hci_bcm: Add support for BCM2E7E

[Hans de Goede]

Tested on a GPD win with a BCM4356 PCI-E wifi/bt combo card.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/bluetooth/hci_bcm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 6a662d0161b4..4739acb5b201 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -878,6 +878,7 @@ static const struct acpi_device_id bcm_acpi_match[] = {
 	{ "BCM2E71", (kernel_ulong_t)&acpi_bcm_int_last_gpios },
 	{ "BCM2E7B", (kernel_ulong_t)&acpi_bcm_int_last_gpios },
 	{ "BCM2E7C", (kernel_ulong_t)&acpi_bcm_int_last_gpios },
+	{ "BCM2E7E", (kernel_ulong_t)&acpi_bcm_int_first_gpios },
 	{ "BCM2E95", (kernel_ulong_t)&acpi_bcm_int_first_gpios },
 	{ "BCM2E96", (kernel_ulong_t)&acpi_bcm_int_first_gpios },
 	{ },
-- 
2.13.4

Re: [PATCH 2/2] Bluetooth: hci_bcm: Add support for BCM2E7E

[Hans de Goede]

Hi,

On 07-09-17 22:25, Hans de Goede wrote:
> Tested on a GPD win with a BCM4356 PCI-E wifi/bt combo card.

Ok, so there is a bit of a snarfu with this patch, it seems
that the bluetooth part of the BCM4356A2 can be connected
via both USB and an UART and on the GPD pocket it is actually
connected through both at the same time.

This probably also explains the weird 0000:0000 vid:pid
combo on the GPD pocket which commit 9834e586fa works around.

After applying this patch, which causes the kernel to communicate
with the BT part over the UART, the BT part drops from the USB
bus and can only be reached via the UART.

When using it over USB (by not having this patch in the kernel)
I cannot get patchram to load, this might because the patchram
file from the Windows partition on the device is only meant to
be used with the device in UART mode.

In USB mode when trying to use the patchram file I get:

[   31.145258] Bluetooth: hci0: BCM: chip id 101
[   31.146265] Bluetooth: hci0: BCM: features 0x2f
[   31.162270] Bluetooth: hci0: BCM4354A2
[   31.163280] Bluetooth: hci0: BCM4354A2 (001.003.015) build 0000
[   31.744211] Bluetooth: hci0 sending frame failed (-19)
[   33.759017] Bluetooth: hci0 command 0x0c03 tx timeout
[   41.950999] Bluetooth: hci0: BCM: Reset failed (-110)
[   62.069325] Bluetooth: hci0: BCM: chip id 101
[   62.070313] Bluetooth: hci0: BCM: features 0x2f
[   62.086574] Bluetooth: hci0: BCM4354A2
[   62.087325] Bluetooth: hci0: BCM4354A2 (001.003.015) build 0000
[   62.675127] Bluetooth: hci0 sending frame failed (-19)
[   64.691105] Bluetooth: hci0 command 0x0c03 tx timeout
[   72.947944] Bluetooth: hci0: BCM: Reset failed (-110)
[   92.997864] Bluetooth: hci0: BCM: chip id 101
[   92.998367] Bluetooth: hci0: BCM: features 0x2f
[   93.014732] Bluetooth: hci0: BCM4354A2
[   93.015360] Bluetooth: hci0: BCM4354A2 (001.003.015) build 0000
[   93.658961] Bluetooth: hci0 sending frame failed (-19)
[   95.666973] Bluetooth: hci0 command 0x0c03 tx timeout

Without the patchram file it does work in USB mode.

In UART mode it works with the patchram file and I get
(with the 2 patches from this series):

[   17.663889] Bluetooth: hci0: BCM: chip id 101
[   17.664205] Bluetooth: hci0: BCM: features 0x2f
[   17.665250] Bluetooth: hci0: BCM4354A2
[   17.665256] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0000
[   18.344740] Bluetooth: hci0: BCM (001.003.015) build 0273

Given that windows seems to be using the device in UART
mode and the weird 0000:0000 USB-ID, which points to the USB
bits not being configured, I believe that the device should
really be used in UART mode.

This will happen automatically with this patch series,
but with the current 4.14 bluetooth stack it will work in
USB mode, and if we then merge this series post 4.14
bluetooth will stop working without users doing a btattach
command from userspace and we will have a regression on
our hands.

I believe that as a minimum we should revert commit 9834e586fa
("Bluetooth: btusb: Add workaround for Broadcom devices without product id")
to avoid users regressing once we move this setup over to
using UART mode.

Regards,

Hans







> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>   drivers/bluetooth/hci_bcm.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
> index 6a662d0161b4..4739acb5b201 100644
> --- a/drivers/bluetooth/hci_bcm.c
> +++ b/drivers/bluetooth/hci_bcm.c
> @@ -878,6 +878,7 @@ static const struct acpi_device_id bcm_acpi_match[] = {
>   	{ "BCM2E71", (kernel_ulong_t)&acpi_bcm_int_last_gpios },
>   	{ "BCM2E7B", (kernel_ulong_t)&acpi_bcm_int_last_gpios },
>   	{ "BCM2E7C", (kernel_ulong_t)&acpi_bcm_int_last_gpios },
> +	{ "BCM2E7E", (kernel_ulong_t)&acpi_bcm_int_first_gpios },
>   	{ "BCM2E95", (kernel_ulong_t)&acpi_bcm_int_first_gpios },
>   	{ "BCM2E96", (kernel_ulong_t)&acpi_bcm_int_first_gpios },
>   	{ },
> 

Re: [PATCH 2/2] Bluetooth: hci_bcm: Add support for BCM2E7E

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Hi Hans,

On Sun, Oct 01, 2017 at 11:27:45AM +0200, Hans de Goede wrote:
> This will happen automatically with this patch series,
> but with the current 4.14 bluetooth stack it will work in
> USB mode, and if we then merge this series post 4.14
> bluetooth will stop working without users doing a btattach
> command from userspace and we will have a regression on
> our hands.

Once the series from Frédéric Danis lands, you can get
serial based broadcom bluetooth without btattach:

https://www.spinics.net/lists/linux-bluetooth/msg71856.html

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] Bluetooth: hci_bcm: Add support for BCM2E7E

[Hans de Goede]

Hi,

On 01-10-17 12:35, Sebastian Reichel wrote:
> Hi Hans,
> 
> On Sun, Oct 01, 2017 at 11:27:45AM +0200, Hans de Goede wrote:
>> This will happen automatically with this patch series,
>> but with the current 4.14 bluetooth stack it will work in
>> USB mode, and if we then merge this series post 4.14
>> bluetooth will stop working without users doing a btattach
>> command from userspace and we will have a regression on
>> our hands.
> 
> Once the series from Frédéric Danis lands, you can get
> serial based broadcom bluetooth without btattach:
> 
> https://www.spinics.net/lists/linux-bluetooth/msg71856.html

Oh, cool. Thank you for pointing this out to me. I still
believe reverting the workaround for the 0000:0000
usb-id device is the right thing to do though.

I've tested Frédéric Danis' series and it needed quite
some work on one of my devices. I've just submitted
a 9 patch series to add all the features the platform
code paths of hci_bcm.c have and which were missing from
the serdev code paths.

Regards,

Hans

Re: [PATCH 2/2] Bluetooth: hci_bcm: Add support for BCM2E7E

[Marcel Holtmann]

Hi Hans,

>>> This will happen automatically with this patch series,
>>> but with the current 4.14 bluetooth stack it will work in
>>> USB mode, and if we then merge this series post 4.14
>>> bluetooth will stop working without users doing a btattach
>>> command from userspace and we will have a regression on
>>> our hands.
>> Once the series from Frédéric Danis lands, you can get
>> serial based broadcom bluetooth without btattach:
>> https://www.spinics.net/lists/linux-bluetooth/msg71856.html
> 
> Oh, cool. Thank you for pointing this out to me. I still
> believe reverting the workaround for the 0000:0000
> usb-id device is the right thing to do though.
> 
> I've tested Frédéric Danis' series and it needed quite
> some work on one of my devices. I've just submitted
> a 9 patch series to add all the features the platform
> code paths of hci_bcm.c have and which were missing from
> the serdev code paths.

can you send a revert patch with a proper commit message explaining why we are reverting it and then I take it in with your other patch series.

Regards

Marcel

Re: [PATCH 2/2] Bluetooth: hci_bcm: Add support for BCM2E7E

[Hans de Goede]

Hi,

On 04-10-17 21:07, Marcel Holtmann wrote:
> Hi Hans,
> 
>>>> This will happen automatically with this patch series,
>>>> but with the current 4.14 bluetooth stack it will work in
>>>> USB mode, and if we then merge this series post 4.14
>>>> bluetooth will stop working without users doing a btattach
>>>> command from userspace and we will have a regression on
>>>> our hands.
>>> Once the series from Frédéric Danis lands, you can get
>>> serial based broadcom bluetooth without btattach:
>>> https://www.spinics.net/lists/linux-bluetooth/msg71856.html
>>
>> Oh, cool. Thank you for pointing this out to me. I still
>> believe reverting the workaround for the 0000:0000
>> usb-id device is the right thing to do though.
>>
>> I've tested Frédéric Danis' series and it needed quite
>> some work on one of my devices. I've just submitted
>> a 9 patch series to add all the features the platform
>> code paths of hci_bcm.c have and which were missing from
>> the serdev code paths.
> 
> can you send a revert patch with a proper commit message explaining why we are reverting it and then I take it in with your other patch series.

Hmm, I thought I had already send that? But I cannot find it
in the archives, so it looks like I prepared it but never
send it...

I've send it out now, it would be nice to get the revert
into 4.14 so that we don't end up with one kernel release
where we do support the 0000:0000 usb-id.

Regards,

Hans