Hi Nazar,

Adding such a feature to the Bluetooth stack sounds like a good idea, but I suspect we need to discuss a bit whether it should be a host extension using a __weak function, an extension to the HCI driver API or something else. Could you open a new enhancement request on github, providing initially the same information as in your email, and we’ll then continue the discussion there: https://github.com/zephyrproject-rtos/zephyr/issues/new/choose

Thanks!

Johan

Hello Devel team,

My name is Nazar. I am working for Infineon in the SW integration team. Currently, I am working on the integration of our CYW43xxx connectivity device into Zephyr (PSoC 6 family).

At the moment, I am working on the integration of the BT part. Wi-Fi will be the next step and I am going to use the HCI H4 driver. HCI H4 driver provides to the user _weak bt_hci_transport_setup to reset the Bluetooth IC. I will use it to power the CYW43xxx device.

The CYW43xxx device requires downloading the controller firmware (via vendor HCI commands) after a power-on. Unfortunately, I cannot do this from bt_hci_transport_setup because the bt hci interface does not start on time when bt_hci_transport_setup is called.

I see the solution as update of the Zephyr common_init() function in hci_core.c, where the add hook to execute the vendor-specific init sequence is:

int __weak  bt_hci_vendor_init_sequence(void)

{

    return 0;

}

static int common_init(void)

{

    struct net_buf *rsp;

    int err;

    /* Execute vendor-specific commands to initialize the controller */

    err = bt_hci_vendor_init_sequence();

    if (err) {

        return err;

    }

...

}

My integration part will implement bt_hci_transport_setup and  bt_hci_vendor_init_sequence functions.

Could you possibly share your considerations on the solution? There may exist another approach to the execution of vendor-specific commands for initializing the controller, before hci_core starts its own initialization.

Thanks and Regards,
Nazar