From: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>
To: Mat Martineau <mathewm@codeaurora.org>
Cc: linux-bluetooth@vger.kernel.org, pkrystad@codeaurora.org
Subject: Re: [PATCH] Bluetooth: Assure BREDR HCI device first in the list
Date: Wed, 16 Nov 2011 10:46:43 +0200 [thread overview]
Message-ID: <20111116084642.GE30662@aemeltch-MOBL1> (raw)
In-Reply-To: <alpine.DEB.2.02.1111150822270.7320@mathewm-linux>
Hi Mat,
On Tue, Nov 15, 2011 at 08:45:47AM -0800, Mat Martineau wrote:
> >Using different list_add to make sure that BR/EDR HCI device is the
> >first device in the hci_dev_list. This is needed for e.g. A2MP Discover
> >Command which requires that "entry for Controller ID 0x00 (Primary
> >BR/EDR controller) shall always be sent and shall be the first entry
> >in the Controller List.
> >Also output from hciconfig looks nicer :-)
> >
> >Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >---
> >net/bluetooth/hci_core.c | 6 +++++-
> >1 files changed, 5 insertions(+), 1 deletions(-)
> >
> >diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> >index 02a6f15..bf24218 100644
> >--- a/net/bluetooth/hci_core.c
> >+++ b/net/bluetooth/hci_core.c
> >@@ -1501,7 +1501,11 @@ int hci_register_dev(struct hci_dev *hdev)
> >
> > sprintf(hdev->name, "hci%d", id);
> > hdev->id = id;
> >- list_add(&hdev->list, head);
> >+
> >+ if (hdev->dev_type == HCI_BREDR)
> >+ list_add(&hdev->list, head);
> >+ else
> >+ list_add_tail(&hdev->list, head);
> >
> > atomic_set(&hdev->refcnt, 1);
> > spin_lock_init(&hdev->lock);
> >--
> >1.7.4.1
>
> I'm don't think it works to depend on the ordering in hdev->list for
> A2MP discover, since there might be multiple BR/EDR controllers.
What about following change:
- list_add(&hdev->list, head);
+ list_add_tail(&hdev->list, head);
This way hci devices queued to the list as opposed to stacked now.
Usual use case is that we have the 1st device BR/EDR and second AMP.
> Controller 0x00 is the BR/EDR controller that received the A2MP
> discover request. The rest of the list should be only AMP
> controllers, any other BR/EDR controllers should not be listed. In
> practice, this means that the 0x00 entry in the list is hard-coded
> and hdev->list is only used to look for AMP controllers.
It is actually how it is done in my RFC, I wanted to make it nicer :-(
Best regards
Andrei Emeltchenko
next prev parent reply other threads:[~2011-11-16 8:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-15 12:58 [PATCH] Bluetooth: Assure BREDR HCI device first in the list Emeltchenko Andrei
2011-11-15 16:45 ` Mat Martineau
2011-11-16 8:46 ` Emeltchenko Andrei [this message]
2011-11-16 18:21 ` Mat Martineau
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=20111116084642.GE30662@aemeltch-MOBL1 \
--to=andrei.emeltchenko.news@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=mathewm@codeaurora.org \
--cc=pkrystad@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox