Some Bluetooth controllers may expose hci0 even when the firmware
initialization has not completed correctly. In that state, the init
script may report success but bluetoothd cannot use the controller.
Validate the controller through the kernel management interface before
accepting the initialization as successful. This matches the interface
used by bluetoothd and catches controllers that are visible through HCI
but not registered in MGMT yet.
Use a timeout for the MGMT query so a broken controller state cannot
block the init script instead of falling back to the retry loop.
https://onedigi.atlassian.net/browse/DEL-9512
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
After refactoring these scripts in a8c6dcb56e, some platforms are
not setting the enable line correctly.
Regarding the affected platforms, on the 6UL it works because that GPIO
comes enabled by default, but not on the other ones.
For the other platforms refactored, such as the CC91/93 or CCMP25,
it is not needed, as the variable is used directly in the gpioset command.
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
This commit generalizes the BT GPIO value used in the bluetooth-init
script for different platforms.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://onedigi.atlassian.net/browse/DEL-9668
This commit moves all the work related with the initialization process to a new
recipe to allow disgregate the init scripts from the bluez5 recipe.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Isaac Hermida
Mike Engel
Arturo Buzarra