All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jérôme de Bretagne" <jerome.debretagne@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>, linux-bluetooth@vger.kernel.org
Subject: Re: btattach: auto triggering at boot time by Linux distributions
Date: Fri, 09 Sep 2016 00:03:26 +0200	[thread overview]
Message-ID: <1473372206.3263.39.camel@gmail.com> (raw)
In-Reply-To: <57368BCF-67A1-416C-A4DF-19289E7E06A8@holtmann.org>

Hi Marcel, hi everyone,

> > > Until then, you need an userspace part that triggers btattach with the
> > > right hardware id on the right /dev/ttySx device node as soon as it
> > > becomes available.
> > 
> > Maybe my mistake is that I've interpreted your sentence: "as soon as
> > *it* becomes available" to assume that "it" was referring to the
> > /dev/ttyS1 device node. I'll try to see if I can create another udev
> > rule that would trigger based on the actual BT chipset becoming
> > available, and not based on /dev/ttyS1 , but I'm still looking for how
> > to do it with dev.
> 
> maybe the RFKILL switch part gets discovered later than the TTY. I don't
> have a platform to verify, but just at few printk into the probe routine
> and see if its finds the according GPIOs for power control.

I've continued my investigation first by trying to create another udev rule
detecting the actual BCM4324(1) rev B5 Bluetooth chipset this time.

And I'm happy to share that it works finally!! as I have Bluetooth working
at boot.

This is not over though as I've just discovered this via "man udev" :-(

  Starting daemons or other long-running processes is not appropriate
  for udev; the forked processes, detached or not, will be
  unconditionally *killed* after the event handling has finished.

and indeed btattach gets killed later on. For that part, I will continue my
investigations off the list as I've found blogs / articles explaining
several solutions and how to do it using systemd for instance.

Once I'm done, would you be interested to see such a rule integrated into
the BlueZ project directly? Or do you consider this "last mile" integration
work to be more the responsibility of the various Linux distributions?

Thanks again for all your help and your great work on the Bluetooth stack. 

Regards,
Jérôme


P.S. For a ThinkPad 8 tablet, a hardcoded version of the basic working rule
looks like this, in case that can be useful for someone else:

   $ cat /etc/udev/rules.d/98-bluetooth-attach-broadcom.rule
   KERNEL=="BCM2E55:00", RUN+="/usr/bin/btattach --bredr /dev/ttyS1 -P bcm"

  reply	other threads:[~2016-09-08 22:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-04 17:10 btattach: auto triggering at boot time by Linux distributions Jérôme de Bretagne
2016-09-04 19:30 ` Marcel Holtmann
2016-09-05 21:40   ` Jérôme de Bretagne
2016-09-05 22:31     ` Marcel Holtmann
2016-09-06 21:35       ` Jérôme de Bretagne
2016-09-06 21:41       ` Jérôme de Bretagne
2016-09-07 21:25   ` Jérôme de Bretagne
2016-09-07 22:59     ` Marcel Holtmann
2016-09-08 22:03       ` Jérôme de Bretagne [this message]
2016-09-12  7:29         ` Marcel Holtmann
2016-09-12 20:42           ` Jérôme de Bretagne
2016-09-12 22:12             ` Jérôme de Bretagne
2016-09-14 21:03               ` Timing-related issue when loading the BT firmware on Broadcom Wi+Fi & BT combo chips (was: btattach: auto triggering at boot time by Linux distributions) Jérôme de Bretagne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1473372206.3263.39.camel@gmail.com \
    --to=jerome.debretagne@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.