* [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth @ 2019-03-05 13:09 Stephan Gerhold 2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Stephan Gerhold @ 2019-03-05 13:09 UTC (permalink / raw) To: Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth, Stephan Gerhold Add the device ID for the BT/FM/GPS combo chip BCM2076 (rev B1) used in the AMPAK AP6476 WiFi/BT/FM/GPS module. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- drivers/bluetooth/btbcm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c index d5d6e6e5da3b..ea1a20a49f91 100644 --- a/drivers/bluetooth/btbcm.c +++ b/drivers/bluetooth/btbcm.c @@ -333,6 +333,7 @@ struct bcm_subver_table { static const struct bcm_subver_table bcm_uart_subver_table[] = { { 0x4103, "BCM4330B1" }, /* 002.001.003 */ { 0x410e, "BCM43341B0" }, /* 002.001.014 */ + { 0x4204, "BCM2076B1" }, /* 002.002.004 */ { 0x4406, "BCM4324B3" }, /* 002.004.006 */ { 0x6109, "BCM4335C0" }, /* 003.001.009 */ { 0x610c, "BCM4354" }, /* 003.001.012 */ -- 2.21.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-03-05 13:09 [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold @ 2019-03-05 13:09 ` Stephan Gerhold 2019-03-05 18:26 ` Ferry Toth 2019-04-30 15:04 ` Stephan Gerhold 2019-04-08 16:55 ` [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold 2019-04-23 17:11 ` Marcel Holtmann 2 siblings, 2 replies; 12+ messages in thread From: Stephan Gerhold @ 2019-03-05 13:09 UTC (permalink / raw) To: Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth, Stephan Gerhold BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. This address is used by at least 5 devices with the AMPAK AP6476 module and is also suspicious because it starts with the chip name 2076 (followed by a different revision A0 for some reason). Add it to the list of default addresses and leave it up to the user to configure a valid one. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- drivers/bluetooth/btbcm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c index ea1a20a49f91..35394076267b 100644 --- a/drivers/bluetooth/btbcm.c +++ b/drivers/bluetooth/btbcm.c @@ -34,6 +34,7 @@ #define BDADDR_BCM20702A0 (&(bdaddr_t) {{0x00, 0xa0, 0x02, 0x70, 0x20, 0x00}}) #define BDADDR_BCM20702A1 (&(bdaddr_t) {{0x00, 0x00, 0xa0, 0x02, 0x70, 0x20}}) +#define BDADDR_BCM2076B1 (&(bdaddr_t) {{0x79, 0x56, 0x00, 0xa0, 0x76, 0x20}}) #define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xac, 0x1f, 0x12, 0xa0, 0x43, 0x43}}) #define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, 0x43}}) #define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, 0x43}}) @@ -69,6 +70,9 @@ int btbcm_check_bdaddr(struct hci_dev *hdev) * The address 20:70:02:A0:00:00 indicates a BCM20702A1 controller * with no configured address. * + * The address 20:76:A0:00:56:79 indicates a BCM2076B1 controller + * with no configured address. + * * The address 43:24:B3:00:00:00 indicates a BCM4324B3 controller * with waiting for configuration state. * @@ -80,6 +84,7 @@ int btbcm_check_bdaddr(struct hci_dev *hdev) */ if (!bacmp(&bda->bdaddr, BDADDR_BCM20702A0) || !bacmp(&bda->bdaddr, BDADDR_BCM20702A1) || + !bacmp(&bda->bdaddr, BDADDR_BCM2076B1) || !bacmp(&bda->bdaddr, BDADDR_BCM4324B3) || !bacmp(&bda->bdaddr, BDADDR_BCM4330B1) || !bacmp(&bda->bdaddr, BDADDR_BCM43430A0)) { -- 2.21.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold @ 2019-03-05 18:26 ` Ferry Toth 2019-03-19 14:03 ` Stephan Gerhold 2019-04-30 15:04 ` Stephan Gerhold 1 sibling, 1 reply; 12+ messages in thread From: Ferry Toth @ 2019-03-05 18:26 UTC (permalink / raw) To: Stephan Gerhold, Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth Op 05-03-19 om 14:09 schreef Stephan Gerhold: > BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. > This address is used by at least 5 devices with the AMPAK AP6476 > module and is also suspicious because it starts with the chip name > 2076 (followed by a different revision A0 for some reason). With BCM43340 (Edison) it's the same principle. With the fake address I found everything (in user space) seems to work except PAN/NAP (bnep) and no decent error message anywhere making this quite hard to debug. > Add it to the list of default addresses and leave it up to the > user to configure a valid one. Which way is the user supposed to configure the valid one? The only way I found is bd_addr (tool from bluez that is not normally built/installed). Using this tool requires hci0 to be up and bluetoothd to be restarted if that was already running, which is quite inconvenient. I also saw there was a patch to put the address in dt. But nowhere did I find a kernel parameter to pass the address. Did I miss something? > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > drivers/bluetooth/btbcm.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c > index ea1a20a49f91..35394076267b 100644 > --- a/drivers/bluetooth/btbcm.c > +++ b/drivers/bluetooth/btbcm.c > @@ -34,6 +34,7 @@ > #define BDADDR_BCM20702A0 (&(bdaddr_t) {{0x00, 0xa0, 0x02, 0x70, 0x20, > 0x00}}) > #define BDADDR_BCM20702A1 (&(bdaddr_t) {{0x00, 0x00, 0xa0, 0x02, 0x70, > 0x20}}) > +#define BDADDR_BCM2076B1 (&(bdaddr_t) {{0x79, 0x56, 0x00, 0xa0, 0x76, > 0x20}}) > #define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xac, 0x1f, 0x12, 0xa0, 0x43, > 0x43}}) > #define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, > 0x43}}) > #define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, > 0x43}}) > @@ -69,6 +70,9 @@ int btbcm_check_bdaddr(struct hci_dev *hdev) > * The address 20:70:02:A0:00:00 indicates a BCM20702A1 controller > * with no configured address. > * > + * The address 20:76:A0:00:56:79 indicates a BCM2076B1 controller > + * with no configured address. > + * > * The address 43:24:B3:00:00:00 indicates a BCM4324B3 controller > * with waiting for configuration state. > * > @@ -80,6 +84,7 @@ int btbcm_check_bdaddr(struct hci_dev *hdev) > */ > if (!bacmp(&bda->bdaddr, BDADDR_BCM20702A0) || > !bacmp(&bda->bdaddr, BDADDR_BCM20702A1) || > + !bacmp(&bda->bdaddr, BDADDR_BCM2076B1) || > !bacmp(&bda->bdaddr, BDADDR_BCM4324B3) || > !bacmp(&bda->bdaddr, BDADDR_BCM4330B1) || > !bacmp(&bda->bdaddr, BDADDR_BCM43430A0)) { ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-03-05 18:26 ` Ferry Toth @ 2019-03-19 14:03 ` Stephan Gerhold 2019-03-20 21:11 ` Ferry Toth 0 siblings, 1 reply; 12+ messages in thread From: Stephan Gerhold @ 2019-03-19 14:03 UTC (permalink / raw) To: Ferry Toth; +Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth Hi, Sorry for the late response. I've been quite busy lately... On Tue, Mar 05, 2019 at 07:26:14PM +0100, Ferry Toth wrote: > > Op 05-03-19 om 14:09 schreef Stephan Gerhold: > > BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. > > This address is used by at least 5 devices with the AMPAK AP6476 > > module and is also suspicious because it starts with the chip name > > 2076 (followed by a different revision A0 for some reason). > With BCM43340 (Edison) it's the same principle. With the fake address I > found everything (in user space) seems to work except PAN/NAP (bnep) and no > decent error message anywhere making this quite hard to debug. Not familiar with PAN/NAP, but the main reason to avoid default addresses is that they will cause issues as soon as you have two of those devices next to each other. > > Add it to the list of default addresses and leave it up to the > > user to configure a valid one. > > Which way is the user supposed to configure the valid one? > It took me a while to figure this out - there is not much documentation for this. The following is only based on my own investigations: As far as the kernel is concerned, HCI_QUIRK_INVALID_BDADDR is exposed through the btmgmt API [1]. With the quirk, the BT controller will appear as "unconfigured" controller to userspace, and will have the public address as missing option. As soon as the address is configured with the "Set Public Address Command", the unconfigured controller is removed and replaced with a regular controller. Only then it will be usable through bluetoothd. The btmgmt API has to be controlled from user space. As far as I know, the only tool in bluez to set the public address is the "btmgmt" tool: btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx ... will run the "Set Public Address Command" described above. However, it was mentioned several times that "btmgmt" is not a "stable" tool. In other words, it is not installed by default and is only intended for debugging. It may change any time. There was a related discussion on IRC recently: (I was not involved) 10:50 <Mis012[m]> sjanc: do I need to convince my distro to package btmgmt, or will you revert that commit? 10:51 <sjanc> Mis012[m]: I'd ask holtmann about this :) but btmgmt was more like testing tool than real end user tool (ie, no manpages, rather ad-hoc design and command set etc 10:53 <sjanc> Mis012[m]: but if you really need this feature, I'd consider starting discussion on mailing list on how this could be handled by bluetoothd 10:53 <sjanc> as mentioned, this could be in plugin, either common plugin or maybe platform specific, which would set public address via mgmt api 10:54 <sjanc> open point is how bluetootd would extract public address, which is always platform specific 10:55 <holtmann> Mis012[m]: btmgmt is not a stable tool. 10:55 <Mis012[m]> holtmann: but it's the only one which can do this 10:56 <holtmann> Then add support to bluetoothd for it or do it via an external tool / daemon. I wrote a long post to the mailing list about that. I have such an external daemon for Android (since it does not use bluez) at [2]. It would be easy to refactor it to something more portable. [1]: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt [2]: https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/bluetooth/bdaddr.c > The only way I found is bd_addr (tool from bluez that is not normally > built/installed). > > Using this tool requires hci0 to be up and bluetoothd to be restarted if > that was already running, which is quite inconvenient. > bdaddr does not use the btmgmt API. It sends vendor-specific commands to the HCI interface. This might be the reason why you need to restart bluetoothd. With HCI_QUIRK_INVALID_BDADDR set, the BT controller should not show up at all in bluetoothctl until its public address is configured. It does not matter if bluetoothd is started too early. > I also saw there was a patch to put the address in dt. > > But nowhere did I find a kernel parameter to pass the address. Did I miss > something? > I'm not familiar with setting the address from DT/kernel parameters. Sorry :( ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-03-19 14:03 ` Stephan Gerhold @ 2019-03-20 21:11 ` Ferry Toth 2019-03-21 9:23 ` Stephan Gerhold 0 siblings, 1 reply; 12+ messages in thread From: Ferry Toth @ 2019-03-20 21:11 UTC (permalink / raw) To: Stephan Gerhold; +Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth Op 19-03-19 om 15:03 schreef Stephan Gerhold: > Hi, > > Sorry for the late response. I've been quite busy lately... Thanks for responding anyway! > > On Tue, Mar 05, 2019 at 07:26:14PM +0100, Ferry Toth wrote: >> Op 05-03-19 om 14:09 schreef Stephan Gerhold: >>> BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. >>> This address is used by at least 5 devices with the AMPAK AP6476 >>> module and is also suspicious because it starts with the chip name >>> 2076 (followed by a different revision A0 for some reason). >> With BCM43340 (Edison) it's the same principle. With the fake address I >> found everything (in user space) seems to work except PAN/NAP (bnep) and no >> decent error message anywhere making this quite hard to debug. > Not familiar with PAN/NAP, but the main reason to avoid default > addresses is that they will cause issues as soon as you have two of > those devices next to each other. That might be the main issue with other services, but if you have only a single device you won't see this. With PAN/NAP I found bnep network device is created and immediately removed, which confuses connman and give no other message than 'I/O error'. Even with only one device. >>> Add it to the list of default addresses and leave it up to the >>> user to configure a valid one. >> Which way is the user supposed to configure the valid one? >> > It took me a while to figure this out - there is not much > documentation for this. The following is only based on my own > investigations: > > As far as the kernel is concerned, HCI_QUIRK_INVALID_BDADDR is exposed > through the btmgmt API [1]. With the quirk, the BT controller will > appear as "unconfigured" controller to userspace, and will have the > public address as missing option. As soon as the address is configured > with the "Set Public Address Command", the unconfigured controller is > removed and replaced with a regular controller. > Only then it will be usable through bluetoothd. Yes, Andy Shevchenko already discovered we are missing to put the device on the blacklist. I was all ready worried I would get a unconfigured controller. Now I see, that is a good thing. Thanks, this is really useful. > The btmgmt API has to be controlled from user space. > As far as I know, the only tool in bluez to set the public address > is the "btmgmt" tool: > > btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx > > ... will run the "Set Public Address Command" described above. Especially in combination with this. I will be documenting this for Edison, so hopefully other can benefit. > However, it was mentioned several times that "btmgmt" is not > a "stable" tool. In other words, it is not installed by default > and is only intended for debugging. It may change any time. > > There was a related discussion on IRC recently: (I was not involved) > > 10:50 <Mis012[m]> sjanc: do I need to convince my distro to package > btmgmt, or will you revert that commit? > 10:51 <sjanc> Mis012[m]: I'd ask holtmann about this :) but btmgmt > was more like testing tool than real end user tool > (ie, no manpages, rather ad-hoc design and command set etc > 10:53 <sjanc> Mis012[m]: but if you really need this feature, > I'd consider starting discussion on mailing list > on how this could be handled by bluetoothd > 10:53 <sjanc> as mentioned, this could be in plugin, > either common plugin or maybe platform specific, > which would set public address via mgmt api > 10:54 <sjanc> open point is how bluetootd would extract public address, > which is always platform specific > 10:55 <holtmann> Mis012[m]: btmgmt is not a stable tool. > 10:55 <Mis012[m]> holtmann: but it's the only one which can do this > 10:56 <holtmann> Then add support to bluetoothd for it or do it via an > external tool / daemon. I wrote a long post to the mailing list > about that. > > I have such an external daemon for Android (since it does not use bluez) > at [2]. It would be easy to refactor it to something more portable. Do I understand correct: support needs to go into bluetoothd first and then into bluetoothctl? > > [1]: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt > [2]: https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/bluetooth/bdaddr.c > >> The only way I found is bd_addr (tool from bluez that is not normally >> built/installed). >> >> Using this tool requires hci0 to be up and bluetoothd to be restarted if >> that was already running, which is quite inconvenient. >> > bdaddr does not use the btmgmt API. It sends vendor-specific commands to > the HCI interface. This might be the reason why you need to restart > bluetoothd. I see. > > With HCI_QUIRK_INVALID_BDADDR set, the BT controller should not show up > at all in bluetoothctl until its public address is configured. > It does not matter if bluetoothd is started too early. > >> I also saw there was a patch to put the address in dt. >> >> But nowhere did I find a kernel parameter to pass the address. Did I miss >> something? >> > I'm not familiar with setting the address from DT/kernel parameters. > Sorry :( To me sounds like reading from a configuration file on disk would make more sense. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-03-20 21:11 ` Ferry Toth @ 2019-03-21 9:23 ` Stephan Gerhold 0 siblings, 0 replies; 12+ messages in thread From: Stephan Gerhold @ 2019-03-21 9:23 UTC (permalink / raw) To: Ferry Toth; +Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth On Wed, Mar 20, 2019 at 10:11:45PM +0100, Ferry Toth wrote: > > Op 19-03-19 om 15:03 schreef Stephan Gerhold: > > Hi, > > > > Sorry for the late response. I've been quite busy lately... > Thanks for responding anyway! > > > > On Tue, Mar 05, 2019 at 07:26:14PM +0100, Ferry Toth wrote: > > > Op 05-03-19 om 14:09 schreef Stephan Gerhold: > > > > BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. > > > > This address is used by at least 5 devices with the AMPAK AP6476 > > > > module and is also suspicious because it starts with the chip name > > > > 2076 (followed by a different revision A0 for some reason). > > > With BCM43340 (Edison) it's the same principle. With the fake address I > > > found everything (in user space) seems to work except PAN/NAP (bnep) and no > > > decent error message anywhere making this quite hard to debug. > > Not familiar with PAN/NAP, but the main reason to avoid default > > addresses is that they will cause issues as soon as you have two of > > those devices next to each other. > > That might be the main issue with other services, but if you have only a > single device you won't see this. > Well, the other obvious thing is that it goes against the BT specification if you use an address that is not unique. :) But you are right, I've also been using the default address for more than a year, simply because I wasn't aware that the BT controller does not have a proper BT device address. I did not run into any problems. > With PAN/NAP I found bnep network device is created and immediately removed, > which confuses connman and give no other message than 'I/O error'. Even with > only one device. > > > > > Add it to the list of default addresses and leave it up to the > > > > user to configure a valid one. > > > Which way is the user supposed to configure the valid one? > > > > > It took me a while to figure this out - there is not much > > documentation for this. The following is only based on my own > > investigations: > > > > As far as the kernel is concerned, HCI_QUIRK_INVALID_BDADDR is exposed > > through the btmgmt API [1]. With the quirk, the BT controller will > > appear as "unconfigured" controller to userspace, and will have the > > public address as missing option. As soon as the address is configured > > with the "Set Public Address Command", the unconfigured controller is > > removed and replaced with a regular controller. > > Only then it will be usable through bluetoothd. > Yes, Andy Shevchenko already discovered we are missing to put the device on > the blacklist. I was all ready worried I would get a unconfigured > controller. Now I see, that is a good thing. Thanks, this is really useful. > > The btmgmt API has to be controlled from user space. > > As far as I know, the only tool in bluez to set the public address > > is the "btmgmt" tool: > > > > btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx > > > > ... will run the "Set Public Address Command" described above. > Especially in combination with this. I will be documenting this for Edison, > so hopefully other can benefit. > > However, it was mentioned several times that "btmgmt" is not > > a "stable" tool. In other words, it is not installed by default > > and is only intended for debugging. It may change any time. > > > > There was a related discussion on IRC recently: (I was not involved) > > > > 10:50 <Mis012[m]> sjanc: do I need to convince my distro to package > > btmgmt, or will you revert that commit? > > 10:51 <sjanc> Mis012[m]: I'd ask holtmann about this :) but btmgmt > > was more like testing tool than real end user tool > > (ie, no manpages, rather ad-hoc design and command set etc > > 10:53 <sjanc> Mis012[m]: but if you really need this feature, > > I'd consider starting discussion on mailing list > > on how this could be handled by bluetoothd > > 10:53 <sjanc> as mentioned, this could be in plugin, > > either common plugin or maybe platform specific, > > which would set public address via mgmt api > > 10:54 <sjanc> open point is how bluetootd would extract public address, > > which is always platform specific > > 10:55 <holtmann> Mis012[m]: btmgmt is not a stable tool. > > 10:55 <Mis012[m]> holtmann: but it's the only one which can do this > > 10:56 <holtmann> Then add support to bluetoothd for it or do it via an > > external tool / daemon. I wrote a long post to the mailing list > > about that. > > > > I have such an external daemon for Android (since it does not use bluez) > > at [2]. It would be easy to refactor it to something more portable. > Do I understand correct: support needs to go into bluetoothd first and then > into bluetoothctl? I'm not very familiar with the bluez code base to be honest. As far as I know, bluetoothctl only controls bluetoothd, so this sounds correct. The way such a feature would be exposed (command line tool, configuration option, ...) would need to be discussed further on the mailing list first. > > > > [1]: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt > > [2]: https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/bluetooth/bdaddr.c > > > > > The only way I found is bd_addr (tool from bluez that is not normally > > > built/installed). > > > > > > Using this tool requires hci0 to be up and bluetoothd to be restarted if > > > that was already running, which is quite inconvenient. > > > > > bdaddr does not use the btmgmt API. It sends vendor-specific commands to > > the HCI interface. This might be the reason why you need to restart > > bluetoothd. > I see. > > > > With HCI_QUIRK_INVALID_BDADDR set, the BT controller should not show up > > at all in bluetoothctl until its public address is configured. > > It does not matter if bluetoothd is started too early. > > > > > I also saw there was a patch to put the address in dt. > > > > > > But nowhere did I find a kernel parameter to pass the address. Did I miss > > > something? > > > > > I'm not familiar with setting the address from DT/kernel parameters. > > Sorry :( > To me sounds like reading from a configuration file on disk would make more > sense. On my device, the real WiFi/BT address resides on an extra partition with a device-specific file system layout, so a configuration file would not really help me personally. A simple option that would make BT work out of the box for all devices with this quirk would be to generate a random MAC address once, and then keep using it across reboots. But I'm not sure if such a feature would be accepted for bluez. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold 2019-03-05 18:26 ` Ferry Toth @ 2019-04-30 15:04 ` Stephan Gerhold 2019-04-30 15:06 ` Marcel Holtmann 1 sibling, 1 reply; 12+ messages in thread From: Stephan Gerhold @ 2019-04-30 15:04 UTC (permalink / raw) To: Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth Hi Marcel, Hi Johan, On Tue, Mar 05, 2019 at 02:09:01PM +0100, Stephan Gerhold wrote: > BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. > This address is used by at least 5 devices with the AMPAK AP6476 > module and is also suspicious because it starts with the chip name > 2076 (followed by a different revision A0 for some reason). > > Add it to the list of default addresses and leave it up to the > user to configure a valid one. > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > drivers/bluetooth/btbcm.c | 5 +++++ > 1 file changed, 5 insertions(+) > As far as I can tell, you have applied the first patch of this series, but forgot about this one. :) It does not apply as-is anymore since you applied the patch from Ferry Toth first, but it still applies cleanly with with "git am --3way". Is that fine for you or should I re-send it on top of latest bluetooth-next? Thanks, Stephan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 2019-04-30 15:04 ` Stephan Gerhold @ 2019-04-30 15:06 ` Marcel Holtmann 2019-05-01 7:18 ` [PATCH RESEND] " Stephan Gerhold 0 siblings, 1 reply; 12+ messages in thread From: Marcel Holtmann @ 2019-04-30 15:06 UTC (permalink / raw) To: Stephan Gerhold; +Cc: Johan Hedberg, linux-bluetooth Hi Stephan, >> BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. >> This address is used by at least 5 devices with the AMPAK AP6476 >> module and is also suspicious because it starts with the chip name >> 2076 (followed by a different revision A0 for some reason). >> >> Add it to the list of default addresses and leave it up to the >> user to configure a valid one. >> >> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> >> --- >> drivers/bluetooth/btbcm.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> > > As far as I can tell, you have applied the first patch of this series, > but forgot about this one. :) > > It does not apply as-is anymore since you applied the patch from > Ferry Toth first, but it still applies cleanly with with > "git am --3way". > > Is that fine for you or should I re-send it on top of latest > bluetooth-next? just re-send it against bluetooth-next. Regards Marcel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH RESEND] Bluetooth: btbcm: Add default address for BCM2076B1 2019-04-30 15:06 ` Marcel Holtmann @ 2019-05-01 7:18 ` Stephan Gerhold 2019-05-05 17:29 ` Marcel Holtmann 0 siblings, 1 reply; 12+ messages in thread From: Stephan Gerhold @ 2019-05-01 7:18 UTC (permalink / raw) To: Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth, Stephan Gerhold BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. This address is used by at least 5 devices with the AMPAK AP6476 module and is also suspicious because it starts with the chip name 2076 (followed by a different revision A0 for some reason). Add it to the list of default addresses and leave it up to the user to configure a valid one. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- (rebased on latest bluetooth-next) drivers/bluetooth/btbcm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c index 71e74ec08310..8e17963ab65a 100644 --- a/drivers/bluetooth/btbcm.c +++ b/drivers/bluetooth/btbcm.c @@ -34,6 +34,7 @@ #define BDADDR_BCM20702A0 (&(bdaddr_t) {{0x00, 0xa0, 0x02, 0x70, 0x20, 0x00}}) #define BDADDR_BCM20702A1 (&(bdaddr_t) {{0x00, 0x00, 0xa0, 0x02, 0x70, 0x20}}) +#define BDADDR_BCM2076B1 (&(bdaddr_t) {{0x79, 0x56, 0x00, 0xa0, 0x76, 0x20}}) #define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xac, 0x1f, 0x12, 0xa0, 0x43, 0x43}}) #define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, 0x43}}) #define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, 0x43}}) @@ -70,6 +71,9 @@ int btbcm_check_bdaddr(struct hci_dev *hdev) * The address 20:70:02:A0:00:00 indicates a BCM20702A1 controller * with no configured address. * + * The address 20:76:A0:00:56:79 indicates a BCM2076B1 controller + * with no configured address. + * * The address 43:24:B3:00:00:00 indicates a BCM4324B3 controller * with waiting for configuration state. * @@ -81,6 +85,7 @@ int btbcm_check_bdaddr(struct hci_dev *hdev) */ if (!bacmp(&bda->bdaddr, BDADDR_BCM20702A0) || !bacmp(&bda->bdaddr, BDADDR_BCM20702A1) || + !bacmp(&bda->bdaddr, BDADDR_BCM2076B1) || !bacmp(&bda->bdaddr, BDADDR_BCM4324B3) || !bacmp(&bda->bdaddr, BDADDR_BCM4330B1) || !bacmp(&bda->bdaddr, BDADDR_BCM43430A0) || -- 2.21.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH RESEND] Bluetooth: btbcm: Add default address for BCM2076B1 2019-05-01 7:18 ` [PATCH RESEND] " Stephan Gerhold @ 2019-05-05 17:29 ` Marcel Holtmann 0 siblings, 0 replies; 12+ messages in thread From: Marcel Holtmann @ 2019-05-05 17:29 UTC (permalink / raw) To: Stephan Gerhold; +Cc: Johan Hedberg, linux-bluetooth Hi Stephan, > BCM2076B1 appears to use 20:76:A0:00:56:79 as default address. > This address is used by at least 5 devices with the AMPAK AP6476 > module and is also suspicious because it starts with the chip name > 2076 (followed by a different revision A0 for some reason). > > Add it to the list of default addresses and leave it up to the > user to configure a valid one. > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > (rebased on latest bluetooth-next) > > drivers/bluetooth/btbcm.c | 5 +++++ > 1 file changed, 5 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth 2019-03-05 13:09 [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold 2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold @ 2019-04-08 16:55 ` Stephan Gerhold 2019-04-23 17:11 ` Marcel Holtmann 2 siblings, 0 replies; 12+ messages in thread From: Stephan Gerhold @ 2019-04-08 16:55 UTC (permalink / raw) To: Marcel Holtmann, Johan Hedberg; +Cc: linux-bluetooth Hi Marcel, Hi Johan, On Tue, Mar 05, 2019 at 02:09:00PM +0100, Stephan Gerhold wrote: > Add the device ID for the BT/FM/GPS combo chip BCM2076 (rev B1) > used in the AMPAK AP6476 WiFi/BT/FM/GPS module. > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > drivers/bluetooth/btbcm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c > index d5d6e6e5da3b..ea1a20a49f91 100644 > --- a/drivers/bluetooth/btbcm.c > +++ b/drivers/bluetooth/btbcm.c > @@ -333,6 +333,7 @@ struct bcm_subver_table { > static const struct bcm_subver_table bcm_uart_subver_table[] = { > { 0x4103, "BCM4330B1" }, /* 002.001.003 */ > { 0x410e, "BCM43341B0" }, /* 002.001.014 */ > + { 0x4204, "BCM2076B1" }, /* 002.002.004 */ > { 0x4406, "BCM4324B3" }, /* 002.004.006 */ > { 0x6109, "BCM4335C0" }, /* 003.001.009 */ > { 0x610c, "BCM4354" }, /* 003.001.012 */ > -- > 2.21.0 > Is there anything I can change in these two patches to get them applied? Or should I re-send them? Thanks, Stephan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth 2019-03-05 13:09 [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold 2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold 2019-04-08 16:55 ` [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold @ 2019-04-23 17:11 ` Marcel Holtmann 2 siblings, 0 replies; 12+ messages in thread From: Marcel Holtmann @ 2019-04-23 17:11 UTC (permalink / raw) To: Stephan Gerhold; +Cc: Johan Hedberg, linux-bluetooth Hi Stephan, > Add the device ID for the BT/FM/GPS combo chip BCM2076 (rev B1) > used in the AMPAK AP6476 WiFi/BT/FM/GPS module. > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > drivers/bluetooth/btbcm.c | 1 + > 1 file changed, 1 insertion(+) patch has been applied to bluetooth-next tree. Regards Marcel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-05-05 17:29 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-05 13:09 [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold 2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold 2019-03-05 18:26 ` Ferry Toth 2019-03-19 14:03 ` Stephan Gerhold 2019-03-20 21:11 ` Ferry Toth 2019-03-21 9:23 ` Stephan Gerhold 2019-04-30 15:04 ` Stephan Gerhold 2019-04-30 15:06 ` Marcel Holtmann 2019-05-01 7:18 ` [PATCH RESEND] " Stephan Gerhold 2019-05-05 17:29 ` Marcel Holtmann 2019-04-08 16:55 ` [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold 2019-04-23 17:11 ` Marcel Holtmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.