gumstix/meta-gumstix-extras — pull request #1 by pabigot (2013-08-11 14:34:28+00:00)
Title: dylan: rework bluetooth systemd support

I've been refamiliarizing myself with gumstix and notice that some recent commits are related to a bluetooth UART feature I did in January for a potential client but never released. I've updated that feature in the commit in this pull request.

The primary value I see in this version is it introduces the necessary systemd dependencies to make sure bluetooth is enabled along with bluetooth-hciattach. Without that dependency---or subsequent patches that are reverted in this pull---the device isn't really created and usable (at least not as far as I can tell; hcitool dev won't show it). I've also provided a way to customize the the UART features, and a sample service that provides a login prompt over the bluetooth link.

This sequence also reverts the recent changes 9e5dd9bacc and cacc4598 to enable bluetooth services by default. The reason they got complicated is because systemd support for bluetooth is not in the bluez recipe, it's in a bbappend added by the OE Core layer. In that layer SYSTEMD_AUTO_ENABLE's default is overridden to be "disabled". Analogously, the original version of the secondary bbappend in meta-gumstix simply overrode, rather than extended, the original bbappend's SYSTEMD_SERVICE variable.

The systemd dependencies in this version should make much of that unnecessary: specifically, if you enable ttyO1 you get the stuff required to make it work. I haven't incorporated support for the final change to to enable all bluetooth services by default, because (a) I finished this before noticing that commit, (b) I'm unclear what good enabling bluetooth-ttyO1 does without something that uses it; and (c) I don't think the new bluetooth-sp should be enabled by default because it does cause kernel panics under Linux 3.5 when the rfcomm0 tty disappears. (It works fine under my 3.8 linux-yocto--based kernel.)

Note that "systemctl enable bluetooth-ttyO1.service" does not enable bluetooth.service; but subsequently starting bluetooth-ttyO1.service will cause bluetooth.service to be started even though it isn't enabled in its own right.

So consider this an opportunity for discussion, or if you like use it as a reference to apply any subset of the features that you think are valuable.