From: Johan Hedberg <johan.hedberg@gmail.com>
To: "Ganir, Chen" <chen.ganir@ti.com>
Cc: Andre Guedes <andre.guedes@openbossa.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH v2 9/9] Bluetooth: Support LE-Only discovery procedure
Date: Wed, 30 Nov 2011 13:27:03 +0200 [thread overview]
Message-ID: <20111130112703.GA12146@x220> (raw)
In-Reply-To: <F0070FBC0FB3174D8D11444EB2D5B0264282C0@DNCE02.ent.ti.com>
Hi Chen,
On Wed, Nov 30, 2011, Ganir, Chen wrote:
> > Firstly you should realize that this is not about functionality exposed
> > to the user or applications, but functionality exposed to bluetoothd.
> > The fact that we have something in the mgmt interface doesn't mean that
> > it'll automatically be exposed in the D-Bus interface or bluetoothd
> > internal APIs.
> >
> > As for this particular case (allowing bluetoothd to restrict device
> > discovery to LE or BR/EDR) the reason is the concern that when doing
> > discovery for a specific profile which is only applicable for BR/EDR or
> > LE, you really don't want to waste the users time doing the "other"
> > discovery which will not yield any valuable results. Examples of this
> > could be discovering devices to send a file over Object Push (BR/EDR
> > only) or when running a application for a LE profile which utilizes
> > features only available though an LE radio.
> >
> > I'm not completely sure the need for this will be strong enough for
> > exposing it in the D-Bus API, but not having it in the kernel interface
> > (mgmt) from the start makes it a lot harder to fix if we do end up
> > needing it later (as opposed to the D-Bus interface which would "only"
> > mean doing a new major BlueZ version).
> >
> > Johan
>
> If this is the case, and we know that for now, we have no need for
> this, why introduce more complexity?
I really fail to see what you can consider complex about a single extra
parameter to start_discovery.
> How will the current GAP device search work?
Just like it has worked so far.
> How will interleaved scanning work?
Just like it would work without the extra parameter. It gets triggered
when user-space (bluetoothd) says it wants LE + BR/EDR discovery.
> Will it be triggered from the bluetoothd?
Yes, just like it would without the extra parameter.
> Will it be handled by the kernel ?
Yes, just like it would without the extra parameter.
Johan
next prev parent reply other threads:[~2011-11-30 11:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-25 23:53 [PATCH v2 0/9] LE-Only discovery procedure support Andre Guedes
2011-11-25 23:53 ` [PATCH v2 1/9] Bluetooth: Add dev_flags to struct hci_dev Andre Guedes
2011-11-28 16:17 ` Marcel Holtmann
2011-11-25 23:53 ` [PATCH v2 2/9] Bluetooth: LE Set Scan Parameter Command Andre Guedes
2011-11-28 16:17 ` Marcel Holtmann
2011-12-02 12:19 ` Gustavo Padovan
2011-11-25 23:53 ` [PATCH v2 3/9] Bluetooth: Add helper functions to send LE scan commands Andre Guedes
2011-11-28 16:19 ` Marcel Holtmann
2011-11-25 23:53 ` [PATCH v2 4/9] Bluetooth: Add structs to implement LE scan Andre Guedes
2011-11-25 23:53 ` [PATCH v2 5/9] Bluetooth: LE scan infra-structure Andre Guedes
2011-11-28 16:24 ` Marcel Holtmann
2011-11-30 18:11 ` Andre Guedes
2011-12-02 10:02 ` Query on Media Interface "RegisterPlayer" and Dbus signal "TrackChanged" Jaganath
2011-12-02 11:07 ` Luiz Augusto von Dentz
2011-12-05 13:03 ` sathish
2011-12-06 6:21 ` Chethan T N
2011-11-25 23:53 ` [PATCH v2 6/9] Bluetooth: Add LE scan functions to hci_core Andre Guedes
2011-11-28 16:28 ` Marcel Holtmann
2011-11-30 18:11 ` Andre Guedes
2011-11-25 23:53 ` [PATCH v2 7/9] Bluetooth: Add 'eir_len' param to mgmt_device_found() Andre Guedes
2011-11-27 6:37 ` Ganir, Chen
2011-11-28 11:08 ` Anderson Lizardo
2011-11-28 14:06 ` Andre Guedes
2011-11-25 23:53 ` [PATCH v2 8/9] Bluetooth: Report LE devices Andre Guedes
2011-11-25 23:53 ` [PATCH v2 9/9] Bluetooth: Support LE-Only discovery procedure Andre Guedes
2011-11-27 6:44 ` Ganir, Chen
2011-11-28 14:51 ` Andre Guedes
2011-11-29 9:14 ` Johan Hedberg
2011-11-30 6:43 ` Ganir, Chen
2011-11-30 11:27 ` Johan Hedberg [this message]
2011-11-30 11:38 ` Ganir, Chen
2011-11-30 11:44 ` Johan Hedberg
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=20111130112703.GA12146@x220 \
--to=johan.hedberg@gmail.com \
--cc=andre.guedes@openbossa.org \
--cc=chen.ganir@ti.com \
--cc=linux-bluetooth@vger.kernel.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.