Hi David,
>>> This patch adds the compatbility flags, so the Rockchip Bluetooth can
>>> be referenced in the device tree
>>>
>>> Signed-off-by: David Summers <beagleboard@xxxxxxxxxxxxxxxxxxx>
>>> ---
>>> drivers/bluetooth/btrtl.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
>>> index 7f9ea8e4c1b2..4cc89c9fe371 100644
>>> --- a/drivers/bluetooth/btrtl.c
>>> +++ b/drivers/bluetooth/btrtl.c
>>> @@ -20,6 +20,8 @@
>>> #include <asm/unaligned.h>
>>> #include <linux/usb.h>
>>>
>>> +#include <linux/of.h>
>>> +
>>> #include <net/bluetooth/bluetooth.h>
>>> #include <net/bluetooth/hci_core.h>
>>>
>>> @@ -743,6 +745,21 @@ int btrtl_get_uart_settings(struct hci_dev *hdev,
>>> }
>>> EXPORT_SYMBOL_GPL(btrtl_get_uart_settings);
>>>
>>> +static const struct of_device_id hci_rtl_of_match[] = {
>>> + { .compatible = "realtek,rtl8723a" },
>>> + { .compatible = "realtek,rtl8723bs" },
>>> + { .compatible = "realtek,rtl8723b" },
>>> + { .compatible = "realtek,rtl8723d" },
>>> + { .compatible = "realtek,rtl8723ds" },
>>> + { .compatible = "realtek,rtl8821a" },
>>> + { .compatible = "realtek,rtl8821c" },
>>> + { .compatible = "realtek,rtl8761a" },
>>> + { .compatible = "realtek,rtl8822b" },
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, hci_rtl_of_match);
>> this makes no sense in btrtl.c driver. This needs to be in hci_h5.c and bound to h5_serdev_driver.
>>
>> Regards
>>
>> Marcel
>>
> Now I'm confused. hci_h5.c looks like the general 3 wire uart connection to bluetooth, which probably covers sdio devices like the 8723bs which uses sdio.
>
> But what of the 8723b, which looks like a typo earlier in the code for the 8723bu which is usb device. Or say the 8723be which is PCIe.
the cards might be PCIe or SDIO for WiFi, but normally the Bluetooth part is connected either via USB or UART. I have not seen a PCIe Bluetooth card and the SDIO Bluetooth ones are existed only in the early Bluetooth 1.1 days.
> So if all sdio hci blue tooth cards should be specified with the hci_h5.c driver, and that is general 3 wire uart, then how should this be specified in the device tree? Surely that should need a specification that says "hci uart", rather than a specific chip.
The hci_h5.c was actually a hack to support Realtek devices. I was against it, but it seems nobody wanted to actually work on my bt3wire.c proposal that I send around. The bt3wire.c was suppose to be a clean serdev based driver for all 3-Wire UART cards.
> The btrtl.c code looks like it loads drivers, so is it that drivers aren't needed in the hci uart devices made by realtek?
The btrtl.c is for common Realtek code shared between USB and UART. The same applies to btbcm.c, btintel.c etc. These modules will be loaded by dependencies on the drivers using them.
Regards
Marcel
