HI,
On 19-03-18 23:13, Marcel Holtmann wrote:
Hi Hans,
While fixing the bluetooth on the meegopad t08 I noticed that
it (and other devices) have a BDADDR efivar with the same guid
as used for the nvram variable which contains the wifi's
nvram settings for sdio broadcom wifi chips (if present):
hexdump -C /sys/firmware/efi/efivars/BDADDR-74b00bd9-805a-4d61-b51f-43268123d113
00000000 07 00 00 00 ac 83 f3 37 39 af |.......79.|
Booting into Windows shows the bluetooth using
an address of ac 83 f3 37 39 af, which makes
sense as the meegopad has an AMPAK AP6234 wifi
module and the ac 83 f3 prefix belongs to AMPAK.
Getting the contents from an efivar from within the kernel is
not that hard, so I was thinking that maybe we need to teach
the hci_bcm code to check for this and use the bd_addr from
there so that we have the same bd_addr as Windows, OTOH not
having the same bd_addr is an advantage because this allows
devices which can be paired to multiple bt hosts to be paired
with both Windows and Linux at the same time using a different
key.
So what do you think about adding support for the BDADDR efivar
and using it to set bd_addr?
1) Good idea?
2) Good idea, but make it optional (compile and/or runtime) ?
3) Bad idea ?
I am all for using the BD_ADDR from EFI variables. That way this become how it was intended. If we want to be flexible, we can add a module parameter to disable it and have it stick with the default one.
Ok.
If we can do it directly from within the kernel automatically, then lets do it. Some similar code was added to hci_ll.c for DT entries from the boot loader. Alternative, this can be always done from userspace via Set Public Address mgmt command.
Accessing the efivar from the kernel is easy (the internal API for this
is a bit clunky but usable), so we can do this within the kernel automatically.
I've put writing a patch for this on my TODO.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
