Hi Carlo, > >>> --- > >>> tools/btattach.c | 10 +++++++++- > >>> 1 file changed, 9 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/tools/btattach.c b/tools/btattach.c > >>> index 5adbc8d..f1f115d 100644 > >>> --- a/tools/btattach.c > >>> +++ b/tools/btattach.c > >>> @@ -194,6 +194,7 @@ static void usage(void) > >>> "\t-P, --protocol <proto> Specify protocol type\n" > >>> "\t-S, --speed <baudrate> Specify which baudrate to use\n" > >>> "\t-N, --noflowctl Disable flow control\n" > >>> + "\t-D, --detach Open device and then fork\n" > >>> "\t-h, --help Show help options\n”); > >> > >> And is this really a good idea. I think that I had removed all the fork calls from the standard tools. Mainly since we fail to maintain the signals and more important child signals correctly. So we quickly end up with zombies or orphaned processes. My thinking instead was to leave this to systemd to handle. > > > > Interesting. Any pointer how to achieve that? > > The problem is that I have btattach called by a systemd unit file to > > download the firmware to the bluetooth transceiver. I also have > > another systemd unit that must be called strictly after btattach has > > done uploading the firmware. Since btattach is hanging on the port > > AFAIU there is no way I can tell exactly when it is done uploading the > > firmware. That's why I was adding this detach option, to mark the unit > > as 'Type=forking' and enforcing the ordering with > > 'Before=next.service`. > > Anything I am missing? > > why do you need to know when the firmware uploading has completed? What hardware is this? > > The hardware is a custom ARM board based on an Amlogic SOC. > More specifically I need btattach systemd unit to run before systemd-rfkill. This is because the rfkill driver is actually driving the GPIO enable of the transceiver, so if systemd-rfkill runs before btattach has completed telling to disable the radio (because we rebooted with the BT off) this just interrupts the firmware downloading leaving the transceiver in a non-working state. this whole design mess with RFKILL switches for GPIO reset lines is a problem. We start fixing this for Intel and Broadcom based Bluetooth chips. So I would prefer if we can get this fixed inside the kernel. Also serdev bus is coming that will make btattach obsolete for hardwired Bluetooth UART chips. And frankly, I would prefer to add RFKILL handling to btattach then trying to introduce a fork() which only existence to is to do some syncing with systemd-rfkill. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
