There is no guarantee that a fix delay is actually enough, because with the BT_EN gpio, we only control activation of bluetooth on the chip. But we don't know the status of the whole chip. Also hciattach has anyway a timeout of 5 seconds, so 0.1 seconds does probably not make a big difference in this regard. So in order to make it the safest possible, we can only rely a failure handling and retrying. The number 5 for retries has been defined since repeated restart of the service with only 3 retries leads to failure pretty quickly. At 4 there is no failure anymore. So with 5 we are sure the risk of failure is really low. BugzID: 70195 |
||
|---|---|---|
| bbappends/ublox-module | ||
| classes | ||
| conf | ||
| freescale/recipes-imx | ||
| recipes-bsp | ||
| recipes-connectivity | ||
| recipes-core | ||
| recipes-firmware/firmware-ti-wl18xx | ||
| recipes-kernel | ||
| recipes-navigation/gpsd | ||
| wic | ||
| README | ||
README
This layer depends on: URI: git://git.yoctoproject.org/poky branch: warrior revision: HEAD URI: git://git.openembedded.org/meta-openembedded branch: warrior revision: HEAD layers: meta-python, meta-oe, meta-networking