The script toggles the BT power GPIO regardless of the value being
undefined.
Check that the GPIO is defined before trying to toggle it.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The BT power GPIOgpio was determined basing on machine name on device tree.
This corresponds to the name of the board, and might be changed by a user
that designs his own carrier board to use the module on.
Besides, the BT power GPIO is a pin that's routed on the module (both on
the ConnectCore 6 and on the ConnectCard for i.MX28) not on the carrier
board.
This commit determines the BT power GPIO basing on the module string inside
the 'compatible' property. This must exactly match the module name and is
a required property for using Digi module's BSP.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-2109
If the bluetoothd daemon is launched before the interface is ready
RFCOMM/L2CAP listening socket connections fail (apparently because
the channel is not ready) with BlueZ 5.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-2042
btfilter (abtfilt) and bluetoothd are two independent services. Break the
relationship between them and split the support in independent init scripts
https://jira.digi.com/browse/DEL-1933
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
The script was basing on the variant coded in the HWID to determine
if the variant had bluetooth, by comparing to an array of hard-coded variants.
This required the script to be updated with every new variant that supported
Bluetooth.
The patch checks instead if the node 'bluetooth' exists at all in the device tree
to determine if the variant supports Bluetooth.
https://jira.digi.com/browse/DEL-1933
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
We want to unlink the script from abtfilt application, so moved to a different
recipe (that includes hciattach).
https://jira.digi.com/browse/DEL-1933
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>