Return-Path: MIME-Version: 1.0 References: <20170201171431.9633-1-carlo@caione.org> <02A0165B-9058-4663-9809-E7DA030E0878@holtmann.org> In-Reply-To: <02A0165B-9058-4663-9809-E7DA030E0878@holtmann.org> From: Carlo Caione Date: Thu, 02 Feb 2017 09:40:25 +0000 Message-ID: Subject: Re: [PATCH] tools/btattach: Add detach option To: Marcel Holtmann Cc: Bluez mailing list , Carlo Caione , Linux Upstreaming Team Content-Type: multipart/alternative; boundary=f403045f91080db9bb054788f5f1 List-ID: --f403045f91080db9bb054788f5f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2 Feb 2017 at 04:25, Marcel Holtmann wrote: > 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 Specify protocol type\n" > >>> "\t-S, --speed 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=E2=80=9D); > >> > >> And is this really a good idea. I think that I had removed all the for= k > calls from the standard tools. Mainly since we fail to maintain the signa= ls > 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=3Dforking' and enforcing the ordering with > > 'Before=3Dnext.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. > -- Carlo Caione | +39.340.80.30.096 | Endless --f403045f91080db9bb054788f5f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, 2 Feb 2017 at 04:25, Marce= l Holtmann <marcel@holtmann.org> wrote:
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)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\t-P, --= protocol <proto> Specify protocol type\n"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\t-S, --= speed <baudrate> Specify which baudrate to use\n"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\t-N, --= noflowctl=C2=A0 =C2=A0 =C2=A0 =C2=A0 Disable flow control\n"
>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"\t-D, -= -detach=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Open device and then fork\n= "
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\t-h, --= help=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Show help options\n=E2= =80=9D);
>>
>> 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 s= ignals and more important child signals correctly. So we quickly end up wit= h zombies or orphaned processes. My thinking instead was to leave this to s= ystemd 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=3Dforking' and enforcing the ordering with
> 'Before=3Dnext.service`.
> Anything I am missing?

why do you need to know when the firmware uploading has completed? What har= dware is this?

--f403045f91080db9bb054788f5f1--