Bluetooth: add exit path handling #67069
Conversation
added hci driver close support for h4 and h5 Signed-off-by: Karthikeyan Krishnasamy <karthikeyan@linumiz.com>
bt_hci_cmd_send_sync will return 0 on error if CONFIG_BT_ASSERT is disabled, which make bt_enable success even if there is no response from controller Signed-off-by: Karthikeyan Krishnasamy <karthikeyan@linumiz.com>
karthi012
requested review from
alwa-nordic,
jhedberg and
Vudentz
as code owners
zephyrbot
added
area: Bluetooth
area: Bluetooth Host
zephyrbot
requested review from
asbjornsabo,
hermabe,
jori-nordic,
kruithofa,
sjanc,
Thalley and
theob-pro
|
Aborting threads may be not safe. Resources like mutexes are not automatically freed. Is the intention to be able to recover normal operation without reboot? Then we may need a safer approach. Or is the intention just to delay the system reset so the app can gracefully reset? |
|
Why not call Could you also add a test? As @alwa-nordic said there are probably side-effects, e.g. resource leaks with the current patch. Note that when this assert happens, it usually means either:
In both cases, attempting to re-start the Bluetooth subsystem will probably not work anyways. The non-bluetooth parts of the app might be salvageable though if that was your intention with this patch. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
@alwa-nordic @jori-nordic Thanks for your comments. First i'm apologizing for long silence here. Let me share my thoughts on this, Consider a we have host and controller as running separately, let's take a nrf91dk for example, nrf9160 runnning host stack and nrf52840 in nrf91dk running as controller, There are possible case that the controller may not able to respond and if the controller is not responding, then reset the whole system is not wise option. IMO, if controller is not responding, application should take care of bluetooth failure, i think that is the wise option. Otherwise, we can end up in reset loop. |
|
@alwa-nordic @jori-nordic please revisit |
That's what I was suggesting in my comment above with |
|
What I'm saying is that I would prefer that we don't use |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
@parthitce why did you remove the stale label? author is not responding |
@karthi012 is part of our team and he is currently occupied with other activities. IMO he should be able to respond sooner with the rebase and updates here. Also he doesn't have the rights to remove the stale in Zephyr RTOS repo, which I help him with. |
|
Apologies here. I have been pretty occupied. I wil update this PR in upcoming week. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
@karthi012 this comment was made two months ago without any updates since then. Are you really planning to do anything about this PR anymore? |
|
Worked mostly on free time. I have changes in my local which is not working completely. Need to fix that. I'm closing this PR for now, will open PR once i'm finished. |
When no response from the controller the host will BT_ASSERT the system which will go system reset, return on error will
result the bluetooth initialization failure and handle exit path.