Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Andre Guedes <andre.guedes@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH v2 09/16] Bluetooth: Prepare for full support discovery procedures
Date: Wed, 10 Aug 2011 17:24:50 -0700	[thread overview]
Message-ID: <1313022292.3373.135.camel@aeonflux> (raw)
In-Reply-To: <59EF67F7-A9E0-4C6D-963E-C4EF90F611FC@openbossa.org>

Hi Andre,

<snip>

> >> diff --git a/include/net/bluetooth/hci_core.h b/include/net/ 
> >> bluetooth/hci_core.h
> >> index 1ff59f2..0d2e703 100644
> >> --- a/include/net/bluetooth/hci_core.h
> >> +++ b/include/net/bluetooth/hci_core.h
> >> @@ -597,6 +597,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
> >> #define lmp_esco_capable(dev)      ((dev)->features[3] & LMP_ESCO)
> >> #define lmp_ssp_capable(dev)       ((dev)->features[6] &  
> >> LMP_SIMPLE_PAIR)
> >> #define lmp_no_flush_capable(dev)  ((dev)->features[6] &  
> >> LMP_NO_FLUSH)
> >> +#define lmp_bredr_capable(dev)     (!((dev)->features[4] &  
> >> LMP_NO_BREDR))
> >
> > I don't think this is a good idea. You keep forgetting if you actually
> > have LE switched on or not.
> >
> > I think we should keep it like this and just keep a global hci_dev  
> > state
> > which discovery procedure to use. Depending on if the device is just
> > really LE-Only, it is dual-stack, but LE got switched off (we will  
> > need
> > this eventually for testing) or it is just only BR/EDR.
> 
> I agree. What really matters for the discovery procedure is the
> operation mode not the device type. The term "device type" was
> misused here.
> 
> About the global hci_dev state, IMO we may not need it. By looking
> at the controller's LMP features we are able to infer what is the
> controller's operation mode.

you need to look at the extended features page 1, but yes, if you have
that available, the it might be as simple as have the global state.

It really depends on how often you have to check. Maybe it is worth to
just have a simple operation mode variable compared to always have to
access multiple bits in the features array. Depends on how often you
need to use it.

> >> #define lmp_le_capable(dev)        ((dev)->features[4] & LMP_LE)
> >>
> >> /* ----- Extended LMP capabilities ----- */
> >> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> >> index bbb0daa..dcfb466 100644
> >> --- a/net/bluetooth/mgmt.c
> >> +++ b/net/bluetooth/mgmt.c
> >> @@ -32,6 +32,15 @@
> >> #define MGMT_VERSION	0
> >> #define MGMT_REVISION	1
> >>
> >> +enum bt_device_type {
> >> +	BREDR_ONLY,
> >> +	LE_ONLY,
> >> +	BREDR_LE,
> >> +	UNKNOWN,
> >> +};
> >
> > What is this for? We essentially have a local device capabilities  
> > and an
> > operation mode. They are both different. We do not have a device type.
> 
> I'll change this. I may call this bt_operation_mode or something.

Call it bt_opermode or similar. Something shorter than some long crazy
name that takes a lot of space at least ;)

Also remove the UNKNOWN thing. That is useless. The devices is either
BREDR or LE_ONLY anyway. And worst case it is really BREDR. That has
been the default for a long time now.

And while at it just call it BREDR. And prefix this with
BT_OPERMODE_BREDR or so.

Regards

Marcel



  reply	other threads:[~2011-08-11  0:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 19:49 [PATCH v2 00/16] Full support discovery procedure Andre Guedes
2011-07-25 19:49 ` [PATCH v2 01/16] Bluetooth: Periodic Inquiry and mgmt discovering event Andre Guedes
2011-07-25 19:49 ` [PATCH v2 02/16] Bluetooth: Add failed/complete functions to discovery commands Andre Guedes
2011-07-25 19:49 ` [PATCH v2 03/16] Bluetooth: Remove pending " Andre Guedes
2011-07-25 19:49 ` [PATCH v2 04/16] Bluetooth: Check pending command in start_discovery() Andre Guedes
2011-07-25 19:49 ` [PATCH v2 05/16] Bluetooth: Check pending commands in stop_discovery() Andre Guedes
2011-07-25 19:49 ` [PATCH v2 06/16] Bluetooth: Create do_inquiry() Andre Guedes
2011-07-25 19:49 ` [PATCH v2 07/16] Bluetooth: Create cancel_inquiry() Andre Guedes
2011-07-25 19:49 ` [PATCH v2 08/16] Bluetooth: Fix stop_discovery() Andre Guedes
2011-07-25 19:49 ` [PATCH v2 09/16] Bluetooth: Prepare for full support discovery procedures Andre Guedes
2011-08-10 13:48   ` Marcel Holtmann
2011-08-10 19:51     ` Andre Guedes
2011-08-11  0:24       ` Marcel Holtmann [this message]
2011-09-09 20:43         ` Andre Guedes
2011-07-25 19:49 ` [PATCH v2 10/16] Bluetooth: Check 'dev_class' in mgmt_device_found() Andre Guedes
2011-07-25 19:50 ` [PATCH v2 11/16] Bluetooth: Add 'eir_len' param to mgmt_device_found() Andre Guedes
2011-08-10 13:50   ` Marcel Holtmann
2011-08-10 14:42     ` Anderson Lizardo
2011-08-10 15:17       ` Marcel Holtmann
2011-08-10 19:51         ` Andre Guedes
2011-08-10 20:58           ` Anderson Lizardo
2011-08-11  0:26             ` Marcel Holtmann
2011-08-11 17:12               ` Andre Guedes
2011-09-05  9:03                 ` Marcel Holtmann
2011-09-06 20:06                   ` Andre Guedes
2011-07-25 19:50 ` [PATCH v2 12/16] Bluetooth: Report LE devices Andre Guedes
2011-07-25 19:50 ` [PATCH v2 13/16] Bluetooth: Add 'le_scan_timer' to struct hci_dev Andre Guedes
2011-07-25 19:50 ` [PATCH v2 14/16] Bluetooth: Add LE Scan helper functions Andre Guedes
2011-07-25 19:50 ` [PATCH v2 15/16] Bluetooth: Support LE-Only discovery procedure Andre Guedes
2011-08-10 13:52   ` Marcel Holtmann
2011-08-11 20:08     ` Andre Guedes
2011-09-05  9:00       ` Marcel Holtmann
2011-07-25 19:50 ` [PATCH v2 16/16] Bluetooth: Support BR/EDR/LE " Andre Guedes

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=1313022292.3373.135.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=andre.guedes@openbossa.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox