* Re: [PATCH] Updated TODO list for LE HCI Scan, Advertise and Connect commands.
From: Claudio Takahasi @ 2010-12-23 20:41 UTC (permalink / raw)
To: Sumit Kumar BAJPAI; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4765B7BC10CB4C488A56C73E15D6FBA31DA368123F@EXDCVYMBSTM005.EQ1STM.local>
Hi Sumit,
On Thu, Dec 23, 2010 at 7:07 AM, Sumit Kumar BAJPAI
<sumitkumar.bajpai@stericsson.com> wrote:
> Updated TODO list for HCI commands for LE that ST-Ericsson plans to
> implement and contribute back.
>
> ---
> TODO | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 93 insertions(+), 0 deletions(-)
>
> diff --git a/TODO b/TODO
> index 49a9e76..e62c6e5 100644
> --- a/TODO
> +++ b/TODO
> @@ -66,6 +66,99 @@ Low Energy
> Priority: Low
> Complexity: C2
>
> +- Implement Set Advertise data via Host interface. This Set Advertise Data is
> + used by advertising device to advertise with some data field. This is via
> + undirected and connectable events. Data field is maximum of 30 octets, and is
> + primarily used for small data advertisement. Scanning device can see in scan
> + results the advertised data as set by the advertising device.
> + See Volume 2, Part E, section 7.8.7 for more information.
> +
> + Priority: Low
> + Complexity: C1
> +
> +- Implement Set Advertise parameters via Host interface. This Set Advertise
> + parameters is used by advertising device to set advertising parameters. The
> + Host shall not issue this command when advertising is enabled in the
> + Controller; if it is the Command Disallowed error code shall be used.
> + See Volume 2, Part E, section 7.8.5 for more information.
> +
> + Priority: Low
> + Complexity: C1
> +
> +- Implement Set Scan Response Data via host interface. This data is set by the
> + advertiser in case it wants to send data only to those devices that are
> + currently actively scanning. This is via undirected and connectable events.
> + Data can be set before or after advertising and can be maximum of 30 octets.
> + See Volume 2, Part E, section 7.8.8 for more information.
> +
> + Priority: Low
> + Complexity: C1
We don't need to expose a method to allow the applications to change
the advertising parameters. The idea is to manage them automatically
based on the registered gatt servers.
Broadcaster Role is out of scope at the moment. Peripheral, we are
planning to start the implementation soon, but first we need to define
the GATT server API.
IMHO we need to align the advertising parameter settings with the
Adapter "Discoverable" property and the registered GATT servers.
Set Scan Response Data: I don't an answer at the moment.
> +
> +- Implement Read Advertise Channel Tx Power via Host interface. This Read
> + Advertise Channel Tx power is used by advertising host to read the transmit
> + power level used for LE advertising channel packets.
> + See Volume 2, Part E, section 7.8.6 for more information.
> +
> + Priority: Low
> + Complexity: C1
Could you please give an usage example?
If I understood correctly we will need a function
hci_le_read_xxx_tx_power() to fill the TX Power Level in the
advertising data, right?
> +
> +- Implement Add Device to White List in LE controller via host interface.
> + This command is used to add a single device to white list stored in the
> + controller. Once the device is in white list it should follow scan and
> + connect rules as stated in advertising filter policy.
> + See Volume 2, Part E, section 7.8.16 for more information.
> +
> + Priority: Low
> + Complexity: C1
> +
> +- Implement Remove Device from White List in LE controller via host interface.
> + This command is used to remove a single device from white list stored in the
> + controller. This command has certain restrictions on its usage. Command
> + complete event is generated on completion.
> + See Volume 2, Part E, section 7.8.17 for more information.
> +
> + Priority: Low
> + Complexity: C1
> +
> +- Implement Clear White List in LE controller via host interface. This command
> + is used to clear the white list stored in the controller. This command has
> + certain restrictions on its usage. This command has no command parameters
> + to be pushed on controller. Command complete event is generated on completion.
> + See Volume 2, Part E, section 7.8.15 for more information.
> +
> + Priority: Low
> + Complexity: C1
> +
> +- Implement Read White List Size in LE controller via host interface. This
> + command is used to read the maximum size of the white list supported by the
> + controller.
> + See Volume 2, Part E, section 7.8.14 for more information.
> +
> + Priority: Low
> + Complexity: C1
Maybe we will need this feature to implement the Register Application
API. Automatic connections are planned, but it can be useful to
reduce/filter the amount of advertising reports.
> +
> +- Implement Read LE buffer Size via host interface. This data is used to read
> + the maximum size of data portion of HCI LE ACL Data Packets sent from the
> + Host to the Controller. The Host will segment the data transmitted to the
> + Controller according to these values, so that the HCI Data Packets will
> + contain data with up to this size. The LE_Read_Buffer_Size command also
> + returns the total number of HCI LE ACL Data Packets that can be stored in
> + the data buffers of the Controller. The LE_Read_Buffer_Size command must be
> + issued by the Host before it sends any data to an LE Controller.
> + See Volume 2, Part E, section 7.8.2 for more information.
> +
> + Priority: Low
> + Complexity: C1
> +
> +- Implement LE Connection Update command via Host interface. The
> + LE_Connection_Update command is used to change the Link Layer connection
> + parameters of a connection. This command shall only be used when the local
> + device's role is Master.
> + See Volume 2, Part E, section 7.8.18 for more information.
> +
> + Priority: Medium
> + Complexity: C1
Is it necessary to notify the userpace or it is a kernel task only?
Please remove it if it is a kernel task.
For the other tasks I suggest to keep them in the TODO file to track
the missing features, no matter if we will use them directly(eg:
hcitool, hciconfig) or in the API/services implementation.
If possible please add the expected deliverable for each task, it will
make easier to other developers to contribute.
Regards.
Claudio
^ permalink raw reply
* Re: [PATCH] Fix spurious DeviceDisappeared signals after name resolution
From: Johan Hedberg @ 2010-12-23 19:09 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1293125965-11782-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Lizardo,
On Thu, Dec 23, 2010, Anderson Lizardo wrote:
> update_oor_devices() was being called twice, first after a inquiry, then
> after name resolution. This caused the just found devices to be always
> reported as "disappeared" after name resolution.
> ---
> src/adapter.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Thanks. Pushed upstream.
Johan
^ permalink raw reply
* [PATCH] Fix spurious DeviceDisappeared signals after name resolution
From: Anderson Lizardo @ 2010-12-23 17:39 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
update_oor_devices() was being called twice, first after a inquiry, then
after name resolution. This caused the just found devices to be always
reported as "disappeared" after name resolution.
---
src/adapter.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 69d3da0..096d684 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2641,13 +2641,14 @@ void adapter_set_state(struct btd_adapter *adapter, int state)
}
if (discov_active == FALSE) {
- update_oor_devices(adapter);
if (type & DISC_RESOLVNAME) {
if (adapter_resolve_names(adapter) == 0) {
adapter->state |= STATE_RESOLVNAME;
return;
}
}
+
+ update_oor_devices(adapter);
} else if (adapter->disc_sessions && main_opts.discov_interval)
adapter->scheduler_id = g_timeout_add_seconds(
main_opts.discov_interval,
--
1.7.0.4
^ permalink raw reply related
* Re: [RFCv2] Bluetooth: Use non-flushable by default L2CAP data packets
From: Andrei Emeltchenko @ 2010-12-23 15:04 UTC (permalink / raw)
To: Gustavo F. Padovan, Nick Pelly; +Cc: linux-bluetooth
In-Reply-To: <20101223020615.GA26284@vigoh>
Hi Gustavo,
On Thu, Dec 23, 2010 at 4:06 AM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-16 16:54:26 +0200]:
>
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> Modification of Nick Pelly <npelly@google.com> patch.
>>
>> With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
>> makes ACL data packets non-flushable by default on compatible chipsets, and
>> adds the BT_FLUSHABLE socket option to explicitly request flushable ACL
>> data packets for a given L2CAP socket. This is useful for A2DP data which can
>> be safely discarded if it can not be delivered within a short time (while
>> other ACL data should not be discarded).
>>
>> Note that making ACL data flushable has no effect unless the automatic flush
>> timeout for that ACL link is changed from its default of 0 (infinite).
>>
>> Default packet types (for compatible chipsets):
>> Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
>> Bluetooth HCI H4
>> Bluetooth HCI ACL Packet
>> .... 0000 0000 0010 = Connection Handle: 0x0002
>> ..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
>> 00.. .... .... .... = BC Flag: Point-To-Point (0)
>> Data Total Length: 8
>> Bluetooth L2CAP Packet
>>
>> After setting BT_FLUSHABLE
>> (sock.setsockopt(274 /*SOL_BLUETOOTH*/, 8 /* BT_FLUSHABLE */, 1 /* flush */))
>> Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
>> Bluetooth HCI H4
>> Bluetooth HCI ACL Packet
>> .... 0000 0000 0010 = Connection Handle: 0x0002
>> ..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
>> 00.. .... .... .... = BC Flag: Point-To-Point (0)
>> Data Total Length: 8
>> Bluetooth L2CAP Packet
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> include/net/bluetooth/bluetooth.h | 5 ++++
>> include/net/bluetooth/hci.h | 2 +
>> include/net/bluetooth/hci_core.h | 1 +
>> include/net/bluetooth/l2cap.h | 2 +
>> net/bluetooth/hci_core.c | 6 +++-
>> net/bluetooth/l2cap.c | 48 ++++++++++++++++++++++++++++++++++--
>> 6 files changed, 59 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
>> index 0c5e725..ed7d775 100644
>> --- a/include/net/bluetooth/bluetooth.h
>> +++ b/include/net/bluetooth/bluetooth.h
>> @@ -64,6 +64,11 @@ struct bt_security {
>>
>> #define BT_DEFER_SETUP 7
>>
>> +#define BT_FLUSHABLE 8
>> +
>> +#define BT_FLUSHABLE_OFF 0
>> +#define BT_FLUSHABLE_ON 1
>> +
>> #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
>> #define BT_ERR(fmt, arg...) printk(KERN_ERR "%s: " fmt "\n" , __func__ , ## arg)
>> #define BT_DBG(fmt, arg...) pr_debug("%s: " fmt "\n" , __func__ , ## arg)
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index 29a7a8c..333d5cb 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -150,6 +150,7 @@ enum {
>> #define EDR_ESCO_MASK (ESCO_2EV3 | ESCO_3EV3 | ESCO_2EV5 | ESCO_3EV5)
>>
>> /* ACL flags */
>> +#define ACL_START_NO_FLUSH 0x00
>> #define ACL_CONT 0x01
>> #define ACL_START 0x02
>> #define ACL_ACTIVE_BCAST 0x04
>> @@ -193,6 +194,7 @@ enum {
>> #define LMP_EDR_ESCO_3M 0x40
>> #define LMP_EDR_3S_ESCO 0x80
>>
>> +#define LMP_NO_FLUSH 0x01
>
> Isn't this 0x40? As stated on Core v4.0 (Volume 2, part C, 3.3 Feature Mask
> Definition)
Yes you are right, I will fix this and other comments.
Regards,
Andrei
>
>> #define LMP_SIMPLE_PAIR 0x08
>>
>> /* Connection modes */
>> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
>> index 1992fac..9778bc8 100644
>> --- a/include/net/bluetooth/hci_core.h
>> +++ b/include/net/bluetooth/hci_core.h
>> @@ -456,6 +456,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
>> #define lmp_sniffsubr_capable(dev) ((dev)->features[5] & LMP_SNIFF_SUBR)
>> #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)
>>
>> /* ----- HCI protocols ----- */
>> struct hci_proto {
>> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
>> index 7ad25ca..af35711 100644
>> --- a/include/net/bluetooth/l2cap.h
>> +++ b/include/net/bluetooth/l2cap.h
>> @@ -75,6 +75,7 @@ struct l2cap_conninfo {
>> #define L2CAP_LM_TRUSTED 0x0008
>> #define L2CAP_LM_RELIABLE 0x0010
>> #define L2CAP_LM_SECURE 0x0020
>> +#define L2CAP_LM_FLUSHABLE 0x0040
>
> Not using this flag in the code.
>
>>
>> /* L2CAP command codes */
>> #define L2CAP_COMMAND_REJ 0x01
>> @@ -327,6 +328,7 @@ struct l2cap_pinfo {
>> __u8 sec_level;
>> __u8 role_switch;
>> __u8 force_reliable;
>> + __u8 flushable;
>>
>> __u8 conf_req[64];
>> __u8 conf_len;
>> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
>> index 51c61f7..c0d776b 100644
>> --- a/net/bluetooth/hci_core.c
>> +++ b/net/bluetooth/hci_core.c
>> @@ -1380,7 +1380,7 @@ void hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags)
>>
>> skb->dev = (void *) hdev;
>> bt_cb(skb)->pkt_type = HCI_ACLDATA_PKT;
>> - hci_add_acl_hdr(skb, conn->handle, flags | ACL_START);
>> + hci_add_acl_hdr(skb, conn->handle, flags);
>>
>> list = skb_shinfo(skb)->frag_list;
>> if (!list) {
>> @@ -1398,12 +1398,14 @@ void hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags)
>> spin_lock_bh(&conn->data_q.lock);
>>
>> __skb_queue_tail(&conn->data_q, skb);
>
> add an empty line here.
>
>> + flags &= ~ACL_START;
>> + flags |= ACL_CONT;
>> do {
>> skb = list; list = list->next;
>>
>> skb->dev = (void *) hdev;
>> bt_cb(skb)->pkt_type = HCI_ACLDATA_PKT;
>> - hci_add_acl_hdr(skb, conn->handle, flags | ACL_CONT);
>> + hci_add_acl_hdr(skb, conn->handle, flags);
>>
>> BT_DBG("%s frag %p len %d", hdev->name, skb, skb->len);
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index c791fcd..efa60eb 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -362,13 +362,19 @@ static inline u8 l2cap_get_ident(struct l2cap_conn *conn)
>> static inline void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, void *data)
>> {
>> struct sk_buff *skb = l2cap_build_cmd(conn, code, ident, len, data);
>> + u8 flags;
>>
>> BT_DBG("code 0x%2.2x", code);
>>
>> if (!skb)
>> return;
>>
>> - hci_send_acl(conn->hcon, skb, 0);
>> + if (lmp_no_flush_capable(conn->hcon->hdev))
>> + flags = ACL_START_NO_FLUSH;
>> + else
>> + flags = ACL_START;
>> +
>> + hci_send_acl(conn->hcon, skb, flags);
>> }
>>
>> static inline void l2cap_send_sframe(struct l2cap_pinfo *pi, u16 control)
>> @@ -900,6 +906,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
>> pi->sec_level = l2cap_pi(parent)->sec_level;
>> pi->role_switch = l2cap_pi(parent)->role_switch;
>> pi->force_reliable = l2cap_pi(parent)->force_reliable;
>> + pi->flushable = l2cap_pi(parent)->flushable;
>> } else {
>> pi->imtu = L2CAP_DEFAULT_MTU;
>> pi->omtu = 0;
>> @@ -915,6 +922,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
>> pi->sec_level = BT_SECURITY_LOW;
>> pi->role_switch = 0;
>> pi->force_reliable = 0;
>> + pi->flushable = BT_FLUSHABLE_OFF;
>
> You need to check for the no_flush feature here, right?
>
>> }
>>
>> /* Default config options */
>> @@ -1450,10 +1458,17 @@ static void l2cap_drop_acked_frames(struct sock *sk)
>> static inline void l2cap_do_send(struct sock *sk, struct sk_buff *skb)
>> {
>> struct l2cap_pinfo *pi = l2cap_pi(sk);
>> + struct hci_conn *hcon = pi->conn->hcon;
>> + u16 flags;
>>
>> BT_DBG("sk %p, skb %p len %d", sk, skb, skb->len);
>>
>> - hci_send_acl(pi->conn->hcon, skb, 0);
>> + if (lmp_no_flush_capable(hcon->hdev) && !l2cap_pi(sk)->flushable)
>> + flags = ACL_START_NO_FLUSH;
>> + else
>> + flags = ACL_START;
>> +
>> + hci_send_acl(hcon, skb, flags);
>
> There is another call to hci_send_acl() in l2cap. It is in
> l2cap_send_sframe(), but I'm still wondering if we shall flush those packets
> or not in the case flushable was set. Now I'm thinking that don't.
>
> Then you need to add the same check in l2cap_send_cmd to l2cap_send_sframe().
>
>> }
>>
>> static void l2cap_streaming_send(struct sock *sk)
>> @@ -2045,6 +2060,7 @@ static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __us
>> static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, char __user *optval, unsigned int optlen)
>> {
>> struct sock *sk = sock->sk;
>> + struct hci_conn *hcon = l2cap_pi(sk)->conn->hcon;
>> struct bt_security sec;
>> int len, err = 0;
>> u32 opt;
>> @@ -2098,6 +2114,26 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
>> bt_sk(sk)->defer_setup = opt;
>> break;
>>
>> + case BT_FLUSHABLE:
>> + if (get_user(opt, (u32 __user *) optval)) {
>> + err = -EFAULT;
>> + break;
>> + }
>> +
>> + if (opt > BT_FLUSHABLE_ON) {
>> + err = -EINVAL;
>> + break;
>> + }
>> +
>> + if (opt == BT_FLUSHABLE_OFF &&
>> + !lmp_no_flush_capable(hcon->hdev)) {
>
> I'm not really happy with !lmp_no_flush... 2 negatives in the same place, but
> that is the feature name. So we can't do too much here. Btw, the "No" in the
> feature name is making my brain hurt. ;)
>
> regards,
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
>
^ permalink raw reply
* Re: [PATCH] PBAP tracker-query update for addr fields
From: Johan Hedberg @ 2010-12-23 12:10 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1293103208-17664-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Thu, Dec 23, 2010, Radoslaw Jablonski wrote:
> This is needed to display many addresses of the same type
> (WORK/HOME/OTHER) in different rows in pbap pull response.
> Currently in that case all addresses of the same type
> were displayed in the same row.
> ---
> plugins/phonebook-tracker.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] PBAP tracker-query update for addr fields
From: Radoslaw Jablonski @ 2010-12-23 11:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
This is needed to display many addresses of the same type
(WORK/HOME/OTHER) in different rows in pbap pull response.
Currently in that case all addresses of the same type
were displayed in the same row.
---
plugins/phonebook-tracker.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 59221cb..b7acead 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -109,7 +109,7 @@
"tracker:coalesce(nco:locality(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:region(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:postalcode(?aff_addr), \"\"), \";\"," \
-"tracker:coalesce(nco:country(?aff_addr), \"\") ),\";\")" \
+"tracker:coalesce(nco:country(?aff_addr), \"\") ),\"\30\")" \
"WHERE {" \
"?_role nco:hasPostalAddress ?aff_addr" \
"}) " \
@@ -191,7 +191,7 @@
"tracker:coalesce(nco:locality(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:region(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:postalcode(?aff_addr), \"\"), \";\"," \
- "tracker:coalesce(nco:country(?aff_addr), \"\") ),\";\")" \
+ "tracker:coalesce(nco:country(?aff_addr), \"\") ),\"\30\")" \
"WHERE {" \
"?_role nco:hasPostalAddress ?aff_addr" \
"}) " \
@@ -337,7 +337,7 @@
"tracker:coalesce(nco:locality(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:region(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:postalcode(?aff_addr), \"\"), \";\"," \
- "tracker:coalesce(nco:country(?aff_addr), \"\") ),\";\")" \
+ "tracker:coalesce(nco:country(?aff_addr), \"\") ),\"\30\")" \
"WHERE {" \
"?_role nco:hasPostalAddress ?aff_addr" \
"}) " \
@@ -482,7 +482,7 @@
"tracker:coalesce(nco:locality(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:region(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:postalcode(?aff_addr), \"\"), \";\"," \
- "tracker:coalesce(nco:country(?aff_addr), \"\") ),\";\")" \
+ "tracker:coalesce(nco:country(?aff_addr), \"\") ),\"\30\")" \
"WHERE {" \
"?_role nco:hasPostalAddress ?aff_addr" \
"}) " \
@@ -621,7 +621,7 @@
"tracker:coalesce(nco:locality(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:region(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:postalcode(?aff_addr), \"\"), \";\"," \
- "tracker:coalesce(nco:country(?aff_addr), \"\") ),\";\")" \
+ "tracker:coalesce(nco:country(?aff_addr), \"\") ),\"\30\")" \
"WHERE {" \
"?_role nco:hasPostalAddress ?aff_addr" \
"}) " \
@@ -813,7 +813,7 @@
"tracker:coalesce(nco:locality(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:region(?aff_addr), \"\"), \";\"," \
"tracker:coalesce(nco:postalcode(?aff_addr), \"\"), \";\"," \
-"tracker:coalesce(nco:country(?aff_addr), \"\") ),\";\")" \
+"tracker:coalesce(nco:country(?aff_addr), \"\") ),\"\30\")" \
"WHERE {" \
"?_role nco:hasPostalAddress ?aff_addr" \
"}) " \
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 00/11] mfd and bluetooth: Add CG2900 support
From: Pavan Savoy @ 2010-12-23 10:48 UTC (permalink / raw)
To: Par-Gunnar HJALMDAHL
Cc: Vitaly Wool, Linus Walleij, Alan Cox, Arnd Bergmann, Samuel Ortiz,
Marcel Holtmann, linux-kernel@vger.kernel.org,
linux-bluetooth@vger.kernel.org, Lukasz Rymanowski,
Par-Gunnar Hjalmdahl
In-Reply-To: <AFCDDB4A3EA003429EEF1E7B211FDBBA3348A3A516@EXDCVYMBSTM005.EQ1STM.local>
P-G, Vitaly,
>
> I would say our design would map like this:
> common-hci-module: cg2900_core
> serial, spi, i2c,... : cg2900_uart together with hci_ldisc (for other tra=
nsports it would be different files)
> bt, ti-radio, st-e-radio,...: cg2900_chip together with btcg2900 and othe=
r users per channel (cg2900_char_devices for users in User space)
> So it is not a 1-to-1 mapping for the upper parts. I would draw it like t=
his:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bt =C2=A0 st-e-radio =C2=A0st-e-gps
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------+----------+
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ti-xx =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0st-e cg2900...
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--=
-------+----------+
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 common-hci-module
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------=
--+-----------+
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 serial =C2=A0 =C2=
=A0spi =C2=A0 =C2=A0 i2c =C2=A0 =C2=A0...
regarding the architecture above suggested...
Is having the common-hci-module, only way ?
Why is this dependency on bluetooth at all?
for example: today I don't compile my kernel with BT support, but
still want to use
the chip for FM & GPS, It should be possible correct ?
Even in TI case, although the firmware download is HCI-VS way, we
don't use hci_core
to interpret the responses...
instead of common-hci-module, why not create a algo-driver layer 'ala
i2c ? where individual drivers can register their receive handlers for
data interpretation ?
>
> The reason for this difference I've gone through before. Basically there =
are so many special behaviors and needed handling that is individual for ea=
ch chip (like startup and shutdown and in the case of CG2900 flow control o=
ver FM and BT channels for audio commands). If you then look at the users I=
guess it would be possible to have one BT user, but it would have to be mo=
dified to handle vendor specific commands (as btcg2900 does with BT_ENABLE =
command). As Arnd has drawn for FM and GPS the users would be completely in=
dividual since they don't have a standardized =C2=A0interface.
>
> /P-G
>
^ permalink raw reply
* [PATCH] Updated TODO list for LE HCI Scan, Advertise and Connect commands.
From: Sumit Kumar BAJPAI @ 2010-12-23 10:07 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Updated TODO list for HCI commands for LE that ST-Ericsson plans to
implement and contribute back.
---
TODO | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 49a9e76..e62c6e5 100644
--- a/TODO
+++ b/TODO
@@ -66,6 +66,99 @@ Low Energy
Priority: Low
Complexity: C2
+- Implement Set Advertise data via Host interface. This Set Advertise Data is
+ used by advertising device to advertise with some data field. This is via
+ undirected and connectable events. Data field is maximum of 30 octets, and is
+ primarily used for small data advertisement. Scanning device can see in scan
+ results the advertised data as set by the advertising device.
+ See Volume 2, Part E, section 7.8.7 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Set Advertise parameters via Host interface. This Set Advertise
+ parameters is used by advertising device to set advertising parameters. The
+ Host shall not issue this command when advertising is enabled in the
+ Controller; if it is the Command Disallowed error code shall be used.
+ See Volume 2, Part E, section 7.8.5 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Set Scan Response Data via host interface. This data is set by the
+ advertiser in case it wants to send data only to those devices that are
+ currently actively scanning. This is via undirected and connectable events.
+ Data can be set before or after advertising and can be maximum of 30 octets.
+ See Volume 2, Part E, section 7.8.8 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Read Advertise Channel Tx Power via Host interface. This Read
+ Advertise Channel Tx power is used by advertising host to read the transmit
+ power level used for LE advertising channel packets.
+ See Volume 2, Part E, section 7.8.6 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Add Device to White List in LE controller via host interface.
+ This command is used to add a single device to white list stored in the
+ controller. Once the device is in white list it should follow scan and
+ connect rules as stated in advertising filter policy.
+ See Volume 2, Part E, section 7.8.16 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Remove Device from White List in LE controller via host interface.
+ This command is used to remove a single device from white list stored in the
+ controller. This command has certain restrictions on its usage. Command
+ complete event is generated on completion.
+ See Volume 2, Part E, section 7.8.17 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Clear White List in LE controller via host interface. This command
+ is used to clear the white list stored in the controller. This command has
+ certain restrictions on its usage. This command has no command parameters
+ to be pushed on controller. Command complete event is generated on completion.
+ See Volume 2, Part E, section 7.8.15 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Read White List Size in LE controller via host interface. This
+ command is used to read the maximum size of the white list supported by the
+ controller.
+ See Volume 2, Part E, section 7.8.14 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement Read LE buffer Size via host interface. This data is used to read
+ the maximum size of data portion of HCI LE ACL Data Packets sent from the
+ Host to the Controller. The Host will segment the data transmitted to the
+ Controller according to these values, so that the HCI Data Packets will
+ contain data with up to this size. The LE_Read_Buffer_Size command also
+ returns the total number of HCI LE ACL Data Packets that can be stored in
+ the data buffers of the Controller. The LE_Read_Buffer_Size command must be
+ issued by the Host before it sends any data to an LE Controller.
+ See Volume 2, Part E, section 7.8.2 for more information.
+
+ Priority: Low
+ Complexity: C1
+
+- Implement LE Connection Update command via Host interface. The
+ LE_Connection_Update command is used to change the Link Layer connection
+ parameters of a connection. This command shall only be used when the local
+ device's role is Master.
+ See Volume 2, Part E, section 7.8.18 for more information.
+
+ Priority: Medium
+ Complexity: C1
+
ATT/GATT
========
--
1.6.5
^ permalink raw reply related
* Re: [PATCH 18/18] Add a "services" command to test-device
From: Johan Hedberg @ 2010-12-23 8:33 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1292966800-6264-19-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Tue, Dec 21, 2010, Vinicius Costa Gomes wrote:
> This command adds a way to retrieve the Services property that each
> device has.
> ---
> test/test-device | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
I've finished pushing all the patches in this set to the upstream tree.
Please double check that I didn't miss anything.
Johan
^ permalink raw reply
* Re: [PATCH] Add a way to retrieve ATT primary services
From: Johan Hedberg @ 2010-12-23 8:27 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1293063673-25058-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Wed, Dec 22, 2010, Vinicius Costa Gomes wrote:
> As the primary services were discovered by the core bluetoothd, we need
> a way to export that information.
>
> The service discovery uses the same primary list as the device, there's no
> need to free that list when the discovery finishes. That list will be removed
> when the device is free'd.
> ---
> src/adapter.c | 6 +++---
> src/device.c | 15 +++++++++++++++
> src/device.h | 3 +++
> src/glib-helper.c | 1 -
> 4 files changed, 21 insertions(+), 4 deletions(-)
This one has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Add support for creating devices from stored primary services
From: Johan Hedberg @ 2010-12-23 8:24 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1293063397-24958-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Wed, Dec 22, 2010, Vinicius Costa Gomes wrote:
> From what we can retrieve from storage we are able to create the devices
> and probe the device drivers.
> ---
> src/adapter.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 77 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] drivers:staging: ti-st: delete old bt_drv driver
From: pavan_savoy @ 2010-12-23 7:23 UTC (permalink / raw)
To: gregkh, linux-kernel; +Cc: padovan, marcel, linux-bluetooth, Pavan Savoy
In-Reply-To: <1293089037-23130-2-git-send-email-pavan_savoy@ti.com>
From: Pavan Savoy <pavan_savoy@ti.com>
point the new v7 driver to build if ST_BT is selected
in Makefile and delete the old bt_drv driver.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
drivers/staging/ti-st/Makefile | 2 +-
drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
drivers/staging/ti-st/bt_drv.h | 61 -----
3 files changed, 1 insertions(+), 571 deletions(-)
delete mode 100644 drivers/staging/ti-st/bt_drv.c
delete mode 100644 drivers/staging/ti-st/bt_drv.h
diff --git a/drivers/staging/ti-st/Makefile b/drivers/staging/ti-st/Makefile
index 5f11b82..9125462 100644
--- a/drivers/staging/ti-st/Makefile
+++ b/drivers/staging/ti-st/Makefile
@@ -2,4 +2,4 @@
# Makefile for TI's shared transport line discipline
# and its protocol drivers (BT, FM, GPS)
#
-obj-$(CONFIG_ST_BT) += bt_drv.o
+obj-$(CONFIG_ST_BT) += btwilink.o
diff --git a/drivers/staging/ti-st/bt_drv.c b/drivers/staging/ti-st/bt_drv.c
deleted file mode 100644
index 75065bf..0000000
--- a/drivers/staging/ti-st/bt_drv.c
+++ /dev/null
@@ -1,509 +0,0 @@
-/*
- * Texas Instrument's Bluetooth Driver For Shared Transport.
- *
- * Bluetooth Driver acts as interface between HCI CORE and
- * TI Shared Transport Layer.
- *
- * Copyright (C) 2009 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- */
-
-#include <net/bluetooth/bluetooth.h>
-#include <net/bluetooth/hci_core.h>
-
-#include <linux/ti_wilink_st.h>
-#include "bt_drv.h"
-
-/* Define this macro to get debug msg */
-#undef DEBUG
-
-#ifdef DEBUG
-#define BT_DRV_DBG(fmt, arg...) printk(KERN_INFO "(btdrv):"fmt"\n" , ## arg)
-#define BTDRV_API_START() printk(KERN_INFO "(btdrv): %s Start\n", \
- __func__)
-#define BTDRV_API_EXIT(errno) printk(KERN_INFO "(btdrv): %s Exit(%d)\n", \
- __func__, errno)
-#else
-#define BT_DRV_DBG(fmt, arg...)
-#define BTDRV_API_START()
-#define BTDRV_API_EXIT(errno)
-#endif
-
-#define BT_DRV_ERR(fmt, arg...) printk(KERN_ERR "(btdrv):"fmt"\n" , ## arg)
-
-static int reset;
-static struct hci_st *hst;
-
-/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
-static inline void hci_st_tx_complete(struct hci_st *hst, int pkt_type)
-{
- struct hci_dev *hdev;
-
- BTDRV_API_START();
-
- hdev = hst->hdev;
-
- /* Update HCI stat counters */
- switch (pkt_type) {
- case HCI_COMMAND_PKT:
- hdev->stat.cmd_tx++;
- break;
-
- case HCI_ACLDATA_PKT:
- hdev->stat.acl_tx++;
- break;
-
- case HCI_SCODATA_PKT:
- hdev->stat.cmd_tx++;
- break;
- }
-
- BTDRV_API_EXIT(0);
-}
-
-/* ------- Interfaces to Shared Transport ------ */
-
-/* Called by ST layer to indicate protocol registration completion
- * status.hci_st_open() function will wait for signal from this
- * API when st_register() function returns ST_PENDING.
- */
-static void hci_st_registration_completion_cb(void *priv_data, char data)
-{
- struct hci_st *lhst = (struct hci_st *)priv_data;
- BTDRV_API_START();
-
- /* hci_st_open() function needs value of 'data' to know
- * the registration status(success/fail),So have a back
- * up of it.
- */
- lhst->streg_cbdata = data;
-
- /* Got a feedback from ST for BT driver registration
- * request.Wackup hci_st_open() function to continue
- * it's open operation.
- */
- complete(&lhst->wait_for_btdrv_reg_completion);
-
- BTDRV_API_EXIT(0);
-}
-
-/* Called by Shared Transport layer when receive data is
- * available */
-static long hci_st_receive(void *priv_data, struct sk_buff *skb)
-{
- int err;
- int len;
- struct hci_st *lhst = (struct hci_st *)priv_data;
-
- BTDRV_API_START();
-
- err = 0;
- len = 0;
-
- if (skb == NULL) {
- BT_DRV_ERR("Invalid SKB received from ST");
- BTDRV_API_EXIT(-EFAULT);
- return -EFAULT;
- }
- if (!lhst) {
- kfree_skb(skb);
- BT_DRV_ERR("Invalid hci_st memory,freeing SKB");
- BTDRV_API_EXIT(-EFAULT);
- return -EFAULT;
- }
- if (!test_bit(BT_DRV_RUNNING, &lhst->flags)) {
- kfree_skb(skb);
- BT_DRV_ERR("Device is not running,freeing SKB");
- BTDRV_API_EXIT(-EINVAL);
- return -EINVAL;
- }
-
- len = skb->len;
- skb->dev = (struct net_device *)lhst->hdev;
-
- /* Forward skb to HCI CORE layer */
- err = hci_recv_frame(skb);
- if (err) {
- kfree_skb(skb);
- BT_DRV_ERR("Unable to push skb to HCI CORE(%d),freeing SKB",
- err);
- BTDRV_API_EXIT(err);
- return err;
- }
- lhst->hdev->stat.byte_rx += len;
-
- BTDRV_API_EXIT(0);
- return 0;
-}
-
-/* ------- Interfaces to HCI layer ------ */
-
-/* Called from HCI core to initialize the device */
-static int hci_st_open(struct hci_dev *hdev)
-{
- static struct st_proto_s hci_st_proto;
- unsigned long timeleft;
- int err;
-
- BTDRV_API_START();
-
- err = 0;
-
- BT_DRV_DBG("%s %p", hdev->name, hdev);
-
- /* Already registered with ST ? */
- if (test_bit(BT_ST_REGISTERED, &hst->flags)) {
- BT_DRV_ERR("Registered with ST already,open called again?");
- BTDRV_API_EXIT(0);
- return 0;
- }
-
- /* Populate BT driver info required by ST */
- memset(&hci_st_proto, 0, sizeof(hci_st_proto));
-
- /* BT driver ID */
- hci_st_proto.type = ST_BT;
-
- /* Receive function which called from ST */
- hci_st_proto.recv = hci_st_receive;
-
- /* Packet match function may used in future */
- hci_st_proto.match_packet = NULL;
-
- /* Callback to be called when registration is pending */
- hci_st_proto.reg_complete_cb = hci_st_registration_completion_cb;
-
- /* This is write function pointer of ST. BT driver will make use of this
- * for sending any packets to chip. ST will assign and give to us, so
- * make it as NULL */
- hci_st_proto.write = NULL;
-
- /* send in the hst to be received at registration complete callback
- * and during st's receive
- */
- hci_st_proto.priv_data = hst;
-
- /* Register with ST layer */
- err = st_register(&hci_st_proto);
- if (err == -EINPROGRESS) {
- /* Prepare wait-for-completion handler data structures.
- * Needed to syncronize this and st_registration_completion_cb()
- * functions.
- */
- init_completion(&hst->wait_for_btdrv_reg_completion);
-
- /* Reset ST registration callback status flag , this value
- * will be updated in hci_st_registration_completion_cb()
- * function whenever it called from ST driver.
- */
- hst->streg_cbdata = -EINPROGRESS;
-
- /* ST is busy with other protocol registration(may be busy with
- * firmware download).So,Wait till the registration callback
- * (passed as a argument to st_register() function) getting
- * called from ST.
- */
- BT_DRV_DBG(" %s waiting for reg completion signal from ST",
- __func__);
-
- timeleft =
- wait_for_completion_timeout
- (&hst->wait_for_btdrv_reg_completion,
- msecs_to_jiffies(BT_REGISTER_TIMEOUT));
- if (!timeleft) {
- BT_DRV_ERR("Timeout(%ld sec),didn't get reg"
- "completion signal from ST",
- BT_REGISTER_TIMEOUT / 1000);
- BTDRV_API_EXIT(-ETIMEDOUT);
- return -ETIMEDOUT;
- }
-
- /* Is ST registration callback called with ERROR value? */
- if (hst->streg_cbdata != 0) {
- BT_DRV_ERR("ST reg completion CB called with invalid"
- "status %d", hst->streg_cbdata);
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
- err = 0;
- } else if (err == -1) {
- BT_DRV_ERR("st_register failed %d", err);
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
-
- /* Do we have proper ST write function? */
- if (hci_st_proto.write != NULL) {
- /* We need this pointer for sending any Bluetooth pkts */
- hst->st_write = hci_st_proto.write;
- } else {
- BT_DRV_ERR("failed to get ST write func pointer");
-
- /* Undo registration with ST */
- err = st_unregister(ST_BT);
- if (err < 0)
- BT_DRV_ERR("st_unregister failed %d", err);
-
- hst->st_write = NULL;
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
-
- /* Registration with ST layer is completed successfully,
- * now chip is ready to accept commands from HCI CORE.
- * Mark HCI Device flag as RUNNING
- */
- set_bit(HCI_RUNNING, &hdev->flags);
-
- /* Registration with ST successful */
- set_bit(BT_ST_REGISTERED, &hst->flags);
-
- BTDRV_API_EXIT(err);
- return err;
-}
-
-/* Close device */
-static int hci_st_close(struct hci_dev *hdev)
-{
- int err;
-
- BTDRV_API_START();
-
- err = 0;
-
- /* Unregister from ST layer */
- if (test_and_clear_bit(BT_ST_REGISTERED, &hst->flags)) {
- err = st_unregister(ST_BT);
- if (err != 0) {
- BT_DRV_ERR("st_unregister failed %d", err);
- BTDRV_API_EXIT(-EBUSY);
- return -EBUSY;
- }
- }
-
- hst->st_write = NULL;
-
- /* ST layer would have moved chip to inactive state.
- * So,clear HCI device RUNNING flag.
- */
- if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags)) {
- BTDRV_API_EXIT(0);
- return 0;
- }
-
- BTDRV_API_EXIT(err);
- return err;
-}
-
-/* Called from HCI CORE , Sends frames to Shared Transport */
-static int hci_st_send_frame(struct sk_buff *skb)
-{
- struct hci_dev *hdev;
- struct hci_st *hst;
- long len;
-
- BTDRV_API_START();
-
- if (skb == NULL) {
- BT_DRV_ERR("Invalid skb received from HCI CORE");
- BTDRV_API_EXIT(-ENOMEM);
- return -ENOMEM;
- }
- hdev = (struct hci_dev *)skb->dev;
- if (!hdev) {
- BT_DRV_ERR("SKB received for invalid HCI Device (hdev=NULL)");
- BTDRV_API_EXIT(-ENODEV);
- return -ENODEV;
- }
- if (!test_bit(HCI_RUNNING, &hdev->flags)) {
- BT_DRV_ERR("Device is not running");
- BTDRV_API_EXIT(-EBUSY);
- return -EBUSY;
- }
-
- hst = (struct hci_st *)hdev->driver_data;
-
- /* Prepend skb with frame type */
- memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
-
- BT_DRV_DBG(" %s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
- skb->len);
-
- /* Insert skb to shared transport layer's transmit queue.
- * Freeing skb memory is taken care in shared transport layer,
- * so don't free skb memory here.
- */
- if (!hst->st_write) {
- kfree_skb(skb);
- BT_DRV_ERR(" Can't write to ST, st_write null?");
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
- len = hst->st_write(skb);
- if (len < 0) {
- /* Something went wrong in st write , free skb memory */
- kfree_skb(skb);
- BT_DRV_ERR(" ST write failed (%ld)", len);
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
-
- /* ST accepted our skb. So, Go ahead and do rest */
- hdev->stat.byte_tx += len;
- hci_st_tx_complete(hst, bt_cb(skb)->pkt_type);
-
- BTDRV_API_EXIT(0);
- return 0;
-}
-
-static void hci_st_destruct(struct hci_dev *hdev)
-{
- BTDRV_API_START();
-
- if (!hdev) {
- BT_DRV_ERR("Destruct called with invalid HCI Device"
- "(hdev=NULL)");
- BTDRV_API_EXIT(0);
- return;
- }
-
- BT_DRV_DBG("%s", hdev->name);
-
- /* free hci_st memory */
- if (hdev->driver_data != NULL)
- kfree(hdev->driver_data);
-
- BTDRV_API_EXIT(0);
- return;
-}
-
-/* Creates new HCI device */
-static int hci_st_register_dev(struct hci_st *hst)
-{
- struct hci_dev *hdev;
-
- BTDRV_API_START();
-
- /* Initialize and register HCI device */
- hdev = hci_alloc_dev();
- if (!hdev) {
- BT_DRV_ERR("Can't allocate HCI device");
- BTDRV_API_EXIT(-ENOMEM);
- return -ENOMEM;
- }
- BT_DRV_DBG(" HCI device allocated. hdev= %p", hdev);
-
- hst->hdev = hdev;
- hdev->bus = HCI_UART;
- hdev->driver_data = hst;
- hdev->open = hci_st_open;
- hdev->close = hci_st_close;
- hdev->flush = NULL;
- hdev->send = hci_st_send_frame;
- hdev->destruct = hci_st_destruct;
- hdev->owner = THIS_MODULE;
-
- if (reset)
- set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
-
- if (hci_register_dev(hdev) < 0) {
- BT_DRV_ERR("Can't register HCI device");
- hci_free_dev(hdev);
- BTDRV_API_EXIT(-ENODEV);
- return -ENODEV;
- }
-
- BT_DRV_DBG(" HCI device registered. hdev= %p", hdev);
- BTDRV_API_EXIT(0);
- return 0;
-}
-
-/* ------- Module Init interface ------ */
-
-static int __init bt_drv_init(void)
-{
- int err;
-
- BTDRV_API_START();
-
- err = 0;
-
- BT_DRV_DBG(" Bluetooth Driver Version %s", VERSION);
-
- /* Allocate local resource memory */
- hst = kzalloc(sizeof(struct hci_st), GFP_KERNEL);
- if (!hst) {
- BT_DRV_ERR("Can't allocate control structure");
- BTDRV_API_EXIT(-ENFILE);
- return -ENFILE;
- }
-
- /* Expose "hciX" device to user space */
- err = hci_st_register_dev(hst);
- if (err) {
- /* Release local resource memory */
- kfree(hst);
-
- BT_DRV_ERR("Unable to expose hci0 device(%d)", err);
- BTDRV_API_EXIT(err);
- return err;
- }
- set_bit(BT_DRV_RUNNING, &hst->flags);
-
- BTDRV_API_EXIT(err);
- return err;
-}
-
-/* ------- Module Exit interface ------ */
-
-static void __exit bt_drv_exit(void)
-{
- BTDRV_API_START();
-
- /* Deallocate local resource's memory */
- if (hst) {
- struct hci_dev *hdev = hst->hdev;
-
- if (hdev == NULL) {
- BT_DRV_ERR("Invalid hdev memory");
- kfree(hst);
- } else {
- hci_st_close(hdev);
- if (test_and_clear_bit(BT_DRV_RUNNING, &hst->flags)) {
- /* Remove HCI device (hciX) created
- * in module init.
- */
- hci_unregister_dev(hdev);
-
- /* Free HCI device memory */
- hci_free_dev(hdev);
- }
- }
- }
- BTDRV_API_EXIT(0);
-}
-
-module_init(bt_drv_init);
-module_exit(bt_drv_exit);
-
-/* ------ Module Info ------ */
-
-module_param(reset, bool, 0644);
-MODULE_PARM_DESC(reset, "Send HCI reset command on initialization");
-MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
-MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
-MODULE_VERSION(VERSION);
-MODULE_LICENSE("GPL");
diff --git a/drivers/staging/ti-st/bt_drv.h b/drivers/staging/ti-st/bt_drv.h
deleted file mode 100644
index a0beebe..0000000
--- a/drivers/staging/ti-st/bt_drv.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Texas Instrument's Bluetooth Driver For Shared Transport.
- *
- * Bluetooth Driver acts as interface between HCI CORE and
- * TI Shared Transport Layer.
- *
- * Copyright (C) 2009 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- */
-
-#ifndef _BT_DRV_H
-#define _BT_DRV_H
-
-/* Bluetooth Driver Version */
-#define VERSION "1.0"
-
-/* Defines number of seconds to wait for reg completion
- * callback getting called from ST (in case,registration
- * with ST returns PENDING status)
- */
-#define BT_REGISTER_TIMEOUT msecs_to_jiffies(6000) /* 6 sec */
-
-/* BT driver's local status */
-#define BT_DRV_RUNNING 0
-#define BT_ST_REGISTERED 1
-
-/* BT driver operation structure */
-struct hci_st {
-
- /* hci device pointer which binds to bt driver */
- struct hci_dev *hdev;
-
- /* used locally,to maintain various BT driver status */
- unsigned long flags;
-
- /* to hold ST registration callback status */
- char streg_cbdata;
-
- /* write function pointer of ST driver */
- long (*st_write) (struct sk_buff *);
-
- /* Wait on comepletion handler needed to synchronize
- * hci_st_open() and hci_st_registration_completion_cb()
- * functions.*/
- struct completion wait_for_btdrv_reg_completion;
-};
-
-#endif
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] drivers:staging: ti-st: add the v7 btwilink driver
From: pavan_savoy @ 2010-12-23 7:23 UTC (permalink / raw)
To: gregkh, linux-kernel; +Cc: padovan, marcel, linux-bluetooth, Pavan Savoy
In-Reply-To: <1293089037-23130-1-git-send-email-pavan_savoy@ti.com>
From: Pavan Savoy <pavan_savoy@ti.com>
Add the btwilink driver which has undergone 7 revisions
of review. Based on bluetooth maintainer comments, since
there might be some re-work needed on underlying ST driver,
park the driver here.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
drivers/staging/ti-st/btwilink.c | 363 ++++++++++++++++++++++++++++++++++++++
1 files changed, 363 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/btwilink.c
diff --git a/drivers/staging/ti-st/btwilink.c b/drivers/staging/ti-st/btwilink.c
new file mode 100644
index 0000000..71e69f8
--- /dev/null
+++ b/drivers/staging/ti-st/btwilink.c
@@ -0,0 +1,363 @@
+/*
+ * Texas Instrument's Bluetooth Driver For Shared Transport.
+ *
+ * Bluetooth Driver acts as interface between HCI core and
+ * TI Shared Transport Layer.
+ *
+ * Copyright (C) 2009-2010 Texas Instruments
+ * Author: Raja Mani <raja_mani@ti.com>
+ * Pavan Savoy <pavan_savoy@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include <linux/ti_wilink_st.h>
+
+/* Bluetooth Driver Version */
+#define VERSION "1.0"
+
+/* Number of seconds to wait for registration completion
+ * when ST returns PENDING status.
+ */
+#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
+
+/**
+ * struct ti_st - driver operation structure
+ * @hdev: hci device pointer which binds to bt driver
+ * @reg_status: ST registration callback status
+ * @st_write: write function provided by the ST driver
+ * to be used by the driver during send_frame.
+ * @wait_reg_completion - completion sync between ti_st_open
+ * and ti_st_registration_completion_cb.
+ */
+struct ti_st {
+ struct hci_dev *hdev;
+ char reg_status;
+ long (*st_write) (struct sk_buff *);
+ struct completion wait_reg_completion;
+};
+
+/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
+static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
+{
+ struct hci_dev *hdev = hst->hdev;
+
+ /* Update HCI stat counters */
+ switch (pkt_type) {
+ case HCI_COMMAND_PKT:
+ hdev->stat.cmd_tx++;
+ break;
+
+ case HCI_ACLDATA_PKT:
+ hdev->stat.acl_tx++;
+ break;
+
+ case HCI_SCODATA_PKT:
+ hdev->stat.sco_tx++;
+ break;
+ }
+}
+
+/* ------- Interfaces to Shared Transport ------ */
+
+/* Called by ST layer to indicate protocol registration completion
+ * status.ti_st_open() function will wait for signal from this
+ * API when st_register() function returns ST_PENDING.
+ */
+static void st_registration_completion_cb(void *priv_data, char data)
+{
+ struct ti_st *lhst = priv_data;
+
+ /* Save registration status for use in ti_st_open() */
+ lhst->reg_status = data;
+ /* complete the wait in ti_st_open() */
+ complete(&lhst->wait_reg_completion);
+}
+
+/* Called by Shared Transport layer when receive data is
+ * available */
+static long st_receive(void *priv_data, struct sk_buff *skb)
+{
+ struct ti_st *lhst = priv_data;
+ int err;
+
+ if (!skb)
+ return -EFAULT;
+
+ if (!lhst) {
+ kfree_skb(skb);
+ return -EFAULT;
+ }
+
+ skb->dev = (void *) lhst->hdev;
+
+ /* Forward skb to HCI core layer */
+ err = hci_recv_frame(skb);
+ if (err < 0) {
+ BT_ERR("Unable to push skb to HCI core(%d)", err);
+ return err;
+ }
+
+ lhst->hdev->stat.byte_rx += skb->len;
+
+ return 0;
+}
+
+/* ------- Interfaces to HCI layer ------ */
+/* protocol structure registered with shared transport */
+static struct st_proto_s ti_st_proto = {
+ .type = ST_BT,
+ .recv = st_receive,
+ .reg_complete_cb = st_registration_completion_cb,
+};
+
+/* Called from HCI core to initialize the device */
+static int ti_st_open(struct hci_dev *hdev)
+{
+ unsigned long timeleft;
+ struct ti_st *hst;
+ int err;
+
+ BT_DBG("%s %p", hdev->name, hdev);
+ if (test_and_set_bit(HCI_RUNNING, &hdev->flags)) {
+ BT_ERR("btwilink already opened");
+ return -EBUSY;
+ }
+
+ /* provide contexts for callbacks from ST */
+ hst = hdev->driver_data;
+ ti_st_proto.priv_data = hst;
+
+ err = st_register(&ti_st_proto);
+ if (err == -EINPROGRESS) {
+ /* ST is busy with either protocol registration or firmware
+ * download.
+ */
+ /* Prepare wait-for-completion handler data structures.
+ */
+ init_completion(&hst->wait_reg_completion);
+
+ /* Reset ST registration callback status flag , this value
+ * will be updated in ti_st_registration_completion_cb()
+ * function whenever it called from ST driver.
+ */
+ hst->reg_status = -EINPROGRESS;
+
+ BT_DBG("waiting for registration completion signal from ST");
+ timeleft = wait_for_completion_timeout
+ (&hst->wait_reg_completion,
+ msecs_to_jiffies(BT_REGISTER_TIMEOUT));
+ if (!timeleft) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("Timeout(%d sec),didn't get reg "
+ "completion signal from ST",
+ BT_REGISTER_TIMEOUT / 1000);
+ return -ETIMEDOUT;
+ }
+
+ /* Is ST registration callback called with ERROR status? */
+ if (hst->reg_status != 0) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("ST registration completed with invalid "
+ "status %d", hst->reg_status);
+ return -EAGAIN;
+ }
+ err = 0;
+ } else if (err != 0) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("st_register failed %d", err);
+ return err;
+ }
+
+ /* ti_st_proto.write is filled up by the underlying shared
+ * transport driver upon registration
+ */
+ hst->st_write = ti_st_proto.write;
+ if (!hst->st_write) {
+ BT_ERR("undefined ST write function");
+ clear_bit(HCI_RUNNING, &hdev->flags);
+
+ /* Undo registration with ST */
+ err = st_unregister(ST_BT);
+ if (err)
+ BT_ERR("st_unregister() failed with error %d", err);
+
+ hst->st_write = NULL;
+ return err;
+ }
+
+ return err;
+}
+
+/* Close device */
+static int ti_st_close(struct hci_dev *hdev)
+{
+ int err;
+ struct ti_st *hst = hdev->driver_data;
+
+ if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
+ return 0;
+
+ /* continue to unregister from transport */
+ err = st_unregister(ST_BT);
+ if (err)
+ BT_ERR("st_unregister() failed with error %d", err);
+
+ hst->st_write = NULL;
+
+ return err;
+}
+
+static int ti_st_send_frame(struct sk_buff *skb)
+{
+ struct hci_dev *hdev;
+ struct ti_st *hst;
+ long len;
+
+ hdev = (struct hci_dev *)skb->dev;
+
+ if (!test_bit(HCI_RUNNING, &hdev->flags))
+ return -EBUSY;
+
+ hst = hdev->driver_data;
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
+
+ BT_DBG("%s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
+ skb->len);
+
+ /* Insert skb to shared transport layer's transmit queue.
+ * Freeing skb memory is taken care in shared transport layer,
+ * so don't free skb memory here.
+ */
+ len = hst->st_write(skb);
+ if (len < 0) {
+ kfree_skb(skb);
+ BT_ERR("ST write failed (%ld)", len);
+ /* Try Again, would only fail if UART has gone bad */
+ return -EAGAIN;
+ }
+
+ /* ST accepted our skb. So, Go ahead and do rest */
+ hdev->stat.byte_tx += len;
+ ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
+
+ return 0;
+}
+
+static void ti_st_destruct(struct hci_dev *hdev)
+{
+ BT_DBG("%s", hdev->name);
+ kfree(hdev->driver_data);
+}
+
+static int bt_ti_probe(struct platform_device *pdev)
+{
+ static struct ti_st *hst;
+ struct hci_dev *hdev;
+ int err;
+
+ hst = kzalloc(sizeof(struct ti_st), GFP_KERNEL);
+ if (!hst)
+ return -ENOMEM;
+
+ /* Expose "hciX" device to user space */
+ hdev = hci_alloc_dev();
+ if (!hdev) {
+ kfree(hst);
+ return -ENOMEM;
+ }
+
+ BT_DBG("hdev %p", hdev);
+
+ hst->hdev = hdev;
+ hdev->bus = HCI_UART;
+ hdev->driver_data = hst;
+ hdev->open = ti_st_open;
+ hdev->close = ti_st_close;
+ hdev->flush = NULL;
+ hdev->send = ti_st_send_frame;
+ hdev->destruct = ti_st_destruct;
+ hdev->owner = THIS_MODULE;
+
+ err = hci_register_dev(hdev);
+ if (err < 0) {
+ BT_ERR("Can't register HCI device error %d", err);
+ kfree(hst);
+ hci_free_dev(hdev);
+ return err;
+ }
+
+ BT_DBG("HCI device registered (hdev %p)", hdev);
+
+ dev_set_drvdata(&pdev->dev, hst);
+ return err;
+}
+
+static int bt_ti_remove(struct platform_device *pdev)
+{
+ struct hci_dev *hdev;
+ struct ti_st *hst = dev_get_drvdata(&pdev->dev);
+
+ if (!hst)
+ return -EFAULT;
+
+ hdev = hst->hdev;
+ ti_st_close(hdev);
+ hci_unregister_dev(hdev);
+
+ hci_free_dev(hdev);
+ kfree(hst);
+
+ dev_set_drvdata(&pdev->dev, NULL);
+ return 0;
+}
+
+static struct platform_driver btwilink_driver = {
+ .probe = bt_ti_probe,
+ .remove = bt_ti_remove,
+ .driver = {
+ .name = "btwilink",
+ .owner = THIS_MODULE,
+ },
+};
+
+/* ------- Module Init/Exit interfaces ------ */
+static int __init btwilink_init(void)
+{
+ BT_INFO("Bluetooth Driver for TI WiLink - Version %s", VERSION);
+
+ return platform_driver_register(&btwilink_driver);
+}
+
+static void __exit btwilink_exit(void)
+{
+ platform_driver_unregister(&btwilink_driver);
+}
+
+module_init(btwilink_init);
+module_exit(btwilink_exit);
+
+/* ------ Module Info ------ */
+
+MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
+MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/2] drivers:staging:ti-st: keep updated
From: pavan_savoy @ 2010-12-23 7:23 UTC (permalink / raw)
To: gregkh, linux-kernel; +Cc: padovan, marcel, linux-bluetooth, Pavan Savoy
From: Pavan Savoy <pavan_savoy@ti.com>
Greg,
Happy Holidays.
Re-ordering the patches as you suggested.
1. Adds the new btwilink driver
2. deletes the old driver and points it to new one.
This is all to keep the drivers/staging/ti-st/ directory updated,
and since the btwilink driver has undergone huge modifications,
there was an update required.
So parking the most recent version of driver here, while
underlying TI-ST driver modifications are carried out.
Pavan Savoy (2):
drivers:staging: ti-st: add the v7 btwilink driver
drivers:staging: ti-st: delete old bt_drv driver
drivers/staging/ti-st/Makefile | 2 +-
drivers/staging/ti-st/bt_drv.c | 509 --------------------------------------
drivers/staging/ti-st/bt_drv.h | 61 -----
drivers/staging/ti-st/btwilink.c | 363 +++++++++++++++++++++++++++
4 files changed, 364 insertions(+), 571 deletions(-)
delete mode 100644 drivers/staging/ti-st/bt_drv.c
delete mode 100644 drivers/staging/ti-st/bt_drv.h
create mode 100644 drivers/staging/ti-st/btwilink.c
^ permalink raw reply
* pull request: bluetooth-next-2.6 2010-12-23
From: Gustavo F. Padovan @ 2010-12-23 3:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth
Hi John,
Here are my last set of patches to 2.6.38. Biggest feature is the new
Bluetooth Management Interface, which intends to replace all HCI raw access
from bluetoothd. That interface is still disabled by default. However you can
enable it via a module parameter.
The other two patches from me is simple fixes in the stack. Tracey's patch is
already in net-next and I only pushed it to solve a merge conflict.
This time I'm using a link to my git tree inside master.kernel.org,
git.kernel.org is really slow today.
Please pull or let me know any problems. Thanks.
The following changes since commit 5c4bc1ce917d93ce8f7dd498fbec6881b3d7743a:
rtlwifi: Fix large packet issue (2010-12-22 15:45:52 -0500)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git master
Gustavo F. Padovan (2):
Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state
Bluetooth: Improve handling of HCI control channel in bind
Johan Hedberg (9):
Bluetooth: Add Bluetooth Management interface definitions
Bluetooth: Add initial Bluetooth Management interface callbacks
Bluetooth: Make hci_send_to_sock usable for management control sockets
Bluetooth: Add error handling for managment command handlers
Bluetooth: Add read_version management command
Bluetooth: Add read_index_list management command
Bluetooth: Add read_info management command
Bluetooth: Add management events for controller addition & removal
Bluetooth: Fix __hci_request synchronization for hci_open_dev
Tracey Dent (1):
Net: bluetooth: Makefile: Remove deprecated kbuild goal definitions
include/net/bluetooth/bluetooth.h | 1 +
include/net/bluetooth/hci.h | 4 +
include/net/bluetooth/hci_core.h | 9 +-
include/net/bluetooth/mgmt.h | 87 +++++++++++
net/bluetooth/Makefile | 2 +-
net/bluetooth/hci_core.c | 17 ++-
net/bluetooth/hci_event.c | 33 +++--
net/bluetooth/hci_sock.c | 52 ++++++-
net/bluetooth/l2cap.c | 8 +-
net/bluetooth/mgmt.c | 308 +++++++++++++++++++++++++++++++++++++
10 files changed, 498 insertions(+), 23 deletions(-)
create mode 100644 include/net/bluetooth/mgmt.h
create mode 100644 net/bluetooth/mgmt.c
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFCv2] Bluetooth: Use non-flushable by default L2CAP data packets
From: Gustavo F. Padovan @ 2010-12-23 2:06 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1292511266-826-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-16 16:54:26 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Modification of Nick Pelly <npelly@google.com> patch.
>
> With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
> makes ACL data packets non-flushable by default on compatible chipsets, and
> adds the BT_FLUSHABLE socket option to explicitly request flushable ACL
> data packets for a given L2CAP socket. This is useful for A2DP data which can
> be safely discarded if it can not be delivered within a short time (while
> other ACL data should not be discarded).
>
> Note that making ACL data flushable has no effect unless the automatic flush
> timeout for that ACL link is changed from its default of 0 (infinite).
>
> Default packet types (for compatible chipsets):
> Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
> Bluetooth HCI H4
> Bluetooth HCI ACL Packet
> .... 0000 0000 0010 = Connection Handle: 0x0002
> ..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
> 00.. .... .... .... = BC Flag: Point-To-Point (0)
> Data Total Length: 8
> Bluetooth L2CAP Packet
>
> After setting BT_FLUSHABLE
> (sock.setsockopt(274 /*SOL_BLUETOOTH*/, 8 /* BT_FLUSHABLE */, 1 /* flush */))
> Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
> Bluetooth HCI H4
> Bluetooth HCI ACL Packet
> .... 0000 0000 0010 = Connection Handle: 0x0002
> ..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
> 00.. .... .... .... = BC Flag: Point-To-Point (0)
> Data Total Length: 8
> Bluetooth L2CAP Packet
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/bluetooth.h | 5 ++++
> include/net/bluetooth/hci.h | 2 +
> include/net/bluetooth/hci_core.h | 1 +
> include/net/bluetooth/l2cap.h | 2 +
> net/bluetooth/hci_core.c | 6 +++-
> net/bluetooth/l2cap.c | 48 ++++++++++++++++++++++++++++++++++--
> 6 files changed, 59 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index 0c5e725..ed7d775 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -64,6 +64,11 @@ struct bt_security {
>
> #define BT_DEFER_SETUP 7
>
> +#define BT_FLUSHABLE 8
> +
> +#define BT_FLUSHABLE_OFF 0
> +#define BT_FLUSHABLE_ON 1
> +
> #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
> #define BT_ERR(fmt, arg...) printk(KERN_ERR "%s: " fmt "\n" , __func__ , ## arg)
> #define BT_DBG(fmt, arg...) pr_debug("%s: " fmt "\n" , __func__ , ## arg)
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 29a7a8c..333d5cb 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -150,6 +150,7 @@ enum {
> #define EDR_ESCO_MASK (ESCO_2EV3 | ESCO_3EV3 | ESCO_2EV5 | ESCO_3EV5)
>
> /* ACL flags */
> +#define ACL_START_NO_FLUSH 0x00
> #define ACL_CONT 0x01
> #define ACL_START 0x02
> #define ACL_ACTIVE_BCAST 0x04
> @@ -193,6 +194,7 @@ enum {
> #define LMP_EDR_ESCO_3M 0x40
> #define LMP_EDR_3S_ESCO 0x80
>
> +#define LMP_NO_FLUSH 0x01
Isn't this 0x40? As stated on Core v4.0 (Volume 2, part C, 3.3 Feature Mask
Definition)
> #define LMP_SIMPLE_PAIR 0x08
>
> /* Connection modes */
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 1992fac..9778bc8 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -456,6 +456,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
> #define lmp_sniffsubr_capable(dev) ((dev)->features[5] & LMP_SNIFF_SUBR)
> #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)
>
> /* ----- HCI protocols ----- */
> struct hci_proto {
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 7ad25ca..af35711 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -75,6 +75,7 @@ struct l2cap_conninfo {
> #define L2CAP_LM_TRUSTED 0x0008
> #define L2CAP_LM_RELIABLE 0x0010
> #define L2CAP_LM_SECURE 0x0020
> +#define L2CAP_LM_FLUSHABLE 0x0040
Not using this flag in the code.
>
> /* L2CAP command codes */
> #define L2CAP_COMMAND_REJ 0x01
> @@ -327,6 +328,7 @@ struct l2cap_pinfo {
> __u8 sec_level;
> __u8 role_switch;
> __u8 force_reliable;
> + __u8 flushable;
>
> __u8 conf_req[64];
> __u8 conf_len;
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 51c61f7..c0d776b 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1380,7 +1380,7 @@ void hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags)
>
> skb->dev = (void *) hdev;
> bt_cb(skb)->pkt_type = HCI_ACLDATA_PKT;
> - hci_add_acl_hdr(skb, conn->handle, flags | ACL_START);
> + hci_add_acl_hdr(skb, conn->handle, flags);
>
> list = skb_shinfo(skb)->frag_list;
> if (!list) {
> @@ -1398,12 +1398,14 @@ void hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags)
> spin_lock_bh(&conn->data_q.lock);
>
> __skb_queue_tail(&conn->data_q, skb);
add an empty line here.
> + flags &= ~ACL_START;
> + flags |= ACL_CONT;
> do {
> skb = list; list = list->next;
>
> skb->dev = (void *) hdev;
> bt_cb(skb)->pkt_type = HCI_ACLDATA_PKT;
> - hci_add_acl_hdr(skb, conn->handle, flags | ACL_CONT);
> + hci_add_acl_hdr(skb, conn->handle, flags);
>
> BT_DBG("%s frag %p len %d", hdev->name, skb, skb->len);
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index c791fcd..efa60eb 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -362,13 +362,19 @@ static inline u8 l2cap_get_ident(struct l2cap_conn *conn)
> static inline void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, void *data)
> {
> struct sk_buff *skb = l2cap_build_cmd(conn, code, ident, len, data);
> + u8 flags;
>
> BT_DBG("code 0x%2.2x", code);
>
> if (!skb)
> return;
>
> - hci_send_acl(conn->hcon, skb, 0);
> + if (lmp_no_flush_capable(conn->hcon->hdev))
> + flags = ACL_START_NO_FLUSH;
> + else
> + flags = ACL_START;
> +
> + hci_send_acl(conn->hcon, skb, flags);
> }
>
> static inline void l2cap_send_sframe(struct l2cap_pinfo *pi, u16 control)
> @@ -900,6 +906,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
> pi->sec_level = l2cap_pi(parent)->sec_level;
> pi->role_switch = l2cap_pi(parent)->role_switch;
> pi->force_reliable = l2cap_pi(parent)->force_reliable;
> + pi->flushable = l2cap_pi(parent)->flushable;
> } else {
> pi->imtu = L2CAP_DEFAULT_MTU;
> pi->omtu = 0;
> @@ -915,6 +922,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
> pi->sec_level = BT_SECURITY_LOW;
> pi->role_switch = 0;
> pi->force_reliable = 0;
> + pi->flushable = BT_FLUSHABLE_OFF;
You need to check for the no_flush feature here, right?
> }
>
> /* Default config options */
> @@ -1450,10 +1458,17 @@ static void l2cap_drop_acked_frames(struct sock *sk)
> static inline void l2cap_do_send(struct sock *sk, struct sk_buff *skb)
> {
> struct l2cap_pinfo *pi = l2cap_pi(sk);
> + struct hci_conn *hcon = pi->conn->hcon;
> + u16 flags;
>
> BT_DBG("sk %p, skb %p len %d", sk, skb, skb->len);
>
> - hci_send_acl(pi->conn->hcon, skb, 0);
> + if (lmp_no_flush_capable(hcon->hdev) && !l2cap_pi(sk)->flushable)
> + flags = ACL_START_NO_FLUSH;
> + else
> + flags = ACL_START;
> +
> + hci_send_acl(hcon, skb, flags);
There is another call to hci_send_acl() in l2cap. It is in
l2cap_send_sframe(), but I'm still wondering if we shall flush those packets
or not in the case flushable was set. Now I'm thinking that don't.
Then you need to add the same check in l2cap_send_cmd to l2cap_send_sframe().
> }
>
> static void l2cap_streaming_send(struct sock *sk)
> @@ -2045,6 +2060,7 @@ static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __us
> static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, char __user *optval, unsigned int optlen)
> {
> struct sock *sk = sock->sk;
> + struct hci_conn *hcon = l2cap_pi(sk)->conn->hcon;
> struct bt_security sec;
> int len, err = 0;
> u32 opt;
> @@ -2098,6 +2114,26 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
> bt_sk(sk)->defer_setup = opt;
> break;
>
> + case BT_FLUSHABLE:
> + if (get_user(opt, (u32 __user *) optval)) {
> + err = -EFAULT;
> + break;
> + }
> +
> + if (opt > BT_FLUSHABLE_ON) {
> + err = -EINVAL;
> + break;
> + }
> +
> + if (opt == BT_FLUSHABLE_OFF &&
> + !lmp_no_flush_capable(hcon->hdev)) {
I'm not really happy with !lmp_no_flush... 2 negatives in the same place, but
that is the feature name. So we can't do too much here. Btw, the "No" in the
feature name is making my brain hurt. ;)
regards,
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* [PATCH] Add a way to retrieve ATT primary services
From: Vinicius Costa Gomes @ 2010-12-23 0:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <20101222225258.GE10702@jh-x301>
As the primary services were discovered by the core bluetoothd, we need
a way to export that information.
The service discovery uses the same primary list as the device, there's no
need to free that list when the discovery finishes. That list will be removed
when the device is free'd.
---
src/adapter.c | 6 +++---
src/device.c | 15 +++++++++++++++
src/device.h | 3 +++
src/glib-helper.c | 1 -
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 77a04f0..ff1f0a4 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1994,14 +1994,14 @@ static void create_stored_device_from_primary(char *key, char *value,
for (l = services, uuids = NULL; l; l = l->next) {
struct att_primary *prim = l->data;
uuids = g_slist_append(uuids, prim->uuid);
+
+ device_add_primary(device, prim);
}
device_probe_drivers(device, uuids);
- g_slist_free(uuids);
-
- g_slist_foreach(services, (GFunc) g_free, NULL);
g_slist_free(services);
+ g_slist_free(uuids);
}
static void load_devices(struct btd_adapter *adapter)
diff --git a/src/device.c b/src/device.c
index d67f804..ae399f3 100644
--- a/src/device.c
+++ b/src/device.c
@@ -115,6 +115,7 @@ struct btd_device {
struct btd_adapter *adapter;
GSList *uuids;
GSList *services; /* Primary services path */
+ GSList *primaries; /* List of primary services */
GSList *drivers; /* List of driver_data */
GSList *watches; /* List of disconnect_data */
gboolean temporary;
@@ -209,6 +210,9 @@ static void device_free(gpointer user_data)
g_slist_foreach(device->uuids, (GFunc) g_free, NULL);
g_slist_free(device->uuids);
+ g_slist_foreach(device->primaries, (GFunc) g_free, NULL);
+ g_slist_free(device->primaries);
+
if (device->tmp_records)
sdp_list_free(device->tmp_records,
(sdp_free_func_t) sdp_record_free);
@@ -1571,6 +1575,7 @@ static void primary_cb(GSList *services, int err, gpointer user_data)
for (l = services; l; l = l->next) {
struct att_primary *prim = l->data;
uuids = g_slist_append(uuids, prim->uuid);
+ device_add_primary(device, prim);
}
device_probe_drivers(device, uuids);
@@ -2383,6 +2388,16 @@ void device_add_service(struct btd_device *device, const char *path)
device->services = g_slist_append(device->services, g_strdup(path));
}
+void device_add_primary(struct btd_device *device, struct att_primary *prim)
+{
+ device->primaries = g_slist_append(device->primaries, prim);
+}
+
+GSList *btd_device_get_primaries(struct btd_device *device)
+{
+ return device->primaries;
+}
+
void btd_device_add_uuid(struct btd_device *device, const char *uuid)
{
GSList *uuid_list;
diff --git a/src/device.h b/src/device.h
index 7820636..0bd6fff 100644
--- a/src/device.h
+++ b/src/device.h
@@ -25,6 +25,7 @@
#define DEVICE_INTERFACE "org.bluez.Device"
struct btd_device;
+struct att_primary;
typedef enum {
AUTH_TYPE_PINCODE,
@@ -53,7 +54,9 @@ int device_browse(struct btd_device *device, DBusConnection *conn,
void device_probe_drivers(struct btd_device *device, GSList *profiles);
const sdp_record_t *btd_device_get_record(struct btd_device *device,
const char *uuid);
+GSList *btd_device_get_primaries(struct btd_device *device);
void device_add_service(struct btd_device *device, const char *path);
+void device_add_primary(struct btd_device *device, struct att_primary *prim);
void btd_device_add_uuid(struct btd_device *device, const char *uuid);
struct btd_adapter *device_get_adapter(struct btd_device *device);
void device_get_address(struct btd_device *device, bdaddr_t *bdaddr);
diff --git a/src/glib-helper.c b/src/glib-helper.c
index 60248cf..648dd62 100644
--- a/src/glib-helper.c
+++ b/src/glib-helper.c
@@ -75,7 +75,6 @@ static void gattrib_context_free(struct gattrib_context *ctxt)
if (ctxt->destroy)
ctxt->destroy(ctxt->user_data);
- g_slist_foreach(ctxt->primaries, (GFunc) g_free, NULL);
g_slist_free(ctxt->primaries);
g_attrib_unref(ctxt->attrib);
if (ctxt->io) {
--
1.7.3.4
^ permalink raw reply related
* [PATCH] Add support for creating devices from stored primary services
From: Vinicius Costa Gomes @ 2010-12-23 0:16 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <20101222225054.GD10702@jh-x301>
>From what we can retrieve from storage we are able to create the devices
and probe the device drivers.
---
src/adapter.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 9c57bea..77a04f0 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -55,6 +55,7 @@
#include "glib-helper.h"
#include "agent.h"
#include "storage.h"
+#include "att.h"
/* Flags Descriptions */
#define EIR_LIM_DISC 0x01 /* LE Limited Discoverable Mode */
@@ -1931,6 +1932,78 @@ static void create_stored_device_from_types(char *key, char *value,
}
}
+static GSList *string_to_primary_list(char *str)
+{
+ GSList *l = NULL;
+ char **services;
+ int i;
+
+ if (str == NULL)
+ return NULL;
+
+ services = g_strsplit(str, " ", 0);
+ if (services == NULL)
+ return NULL;
+
+ for (i = 0; services[i]; i++) {
+ struct att_primary *prim;
+ int ret;
+
+ prim = g_new0(struct att_primary, 1);
+
+ ret = sscanf(services[i], "%04hX#%04hX#%s", &prim->start,
+ &prim->end, prim->uuid);
+
+ if (ret < 3) {
+ g_free(prim);
+ continue;
+ }
+
+ l = g_slist_append(l, prim);
+ }
+
+ g_strfreev(services);
+
+ return l;
+}
+
+static void create_stored_device_from_primary(char *key, char *value,
+ void *user_data)
+{
+ struct btd_adapter *adapter = user_data;
+ struct btd_device *device;
+ GSList *services, *uuids, *l;
+
+ l = g_slist_find_custom(adapter->devices,
+ key, (GCompareFunc) device_address_cmp);
+ if (l)
+ device = l->data;
+ else {
+ device = device_create(connection, adapter, key, DEVICE_TYPE_BREDR);
+ if (!device)
+ return;
+
+ device_set_temporary(device, FALSE);
+ adapter->devices = g_slist_append(adapter->devices, device);
+ }
+
+ services = string_to_primary_list(value);
+ if (services == NULL)
+ return;
+
+ for (l = services, uuids = NULL; l; l = l->next) {
+ struct att_primary *prim = l->data;
+ uuids = g_slist_append(uuids, prim->uuid);
+ }
+
+ device_probe_drivers(device, uuids);
+
+ g_slist_free(uuids);
+
+ g_slist_foreach(services, (GFunc) g_free, NULL);
+ g_slist_free(services);
+}
+
static void load_devices(struct btd_adapter *adapter)
{
char filename[PATH_MAX + 1];
@@ -1944,6 +2017,10 @@ static void load_devices(struct btd_adapter *adapter)
textfile_foreach(filename, create_stored_device_from_profiles,
adapter);
+ create_name(filename, PATH_MAX, STORAGEDIR, srcaddr, "primary");
+ textfile_foreach(filename, create_stored_device_from_primary,
+ adapter);
+
create_name(filename, PATH_MAX, STORAGEDIR, srcaddr, "linkkeys");
textfile_foreach(filename, create_stored_device_from_linkkeys, &keys);
--
1.7.3.4
^ permalink raw reply related
* Re: [RFC 1/2] Add g_attrib_send_seq()
From: Brian Gix @ 2010-12-22 23:13 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: rshaffer, padovan, linux-bluetooth
In-Reply-To: <AANLkTinnsNX_9ENWvBcnN7j8_kmBhbSoL6cCWJ8-Lzgh@mail.gmail.com>
Thanks Claudio,
On Wed, 2010-12-22 at 19:29 -0300, Claudio Takahasi wrote:
> Hi Brian,
>
> On Fri, Dec 17, 2010 at 7:48 PM, Brian Gix <bgix@codeaurora.org> wrote:
> > Add g_attrib_send_seq() as an extension to g_attrib_send().
> > g_attrib_send_seq() functionally queues an entire
> > "GATT Procedure" as defined in the BT Core v4.0.
> > The intention is that the full procedure is run
> > to completion before the next GATT Procedure is
> > started. Subsequent ATT requests to a continuing
> > procedure are added to the head of the Attrib queue.
> >
> > Fix g_attrib_send() to be the degenerative case of g_attrib_send_seq()
> > This function now chains to g_attrib_send_seq() with arguments
> > indicating that it is *not* a compound (multi-step) GATT
> > procedure, but rather that the entire procedure is performed
> > with a single ATT opcode request/response.
> >
> > Fix received_data() to recognize that incoming response is (or isn't)
> > part of a compound Procedure, so that it waits for additional
> > requests before servicing the Attrib queue.
> > ---
> > attrib/gattrib.c | 44 ++++++++++++++++++++++++++++++++++++--------
> > attrib/gattrib.h | 4 ++++
> > 2 files changed, 40 insertions(+), 8 deletions(-)
> >
> > diff --git a/attrib/gattrib.c b/attrib/gattrib.c
> > index eace01b..8ef5d92 100644
> > --- a/attrib/gattrib.c
> > +++ b/attrib/gattrib.c
> > @@ -58,6 +58,7 @@ struct command {
> > guint16 len;
> > guint8 expected;
> > gboolean sent;
> > + gboolean compound;
> > GAttribResultFunc func;
> > gpointer user_data;
> > GDestroyNotify notify;
> > @@ -285,6 +286,7 @@ static gboolean received_data(GIOChannel *io, GIOCondition cond, gpointer data)
> > uint8_t buf[512], status;
> > gsize len;
> > GIOStatus iostat;
> > + gboolean compound = FALSE;
> Intialization is not necessary.
There is a path to it's usage (a "goto done") just after
g_io_channel_read_chars call.
>
> >
> > if (cond & (G_IO_HUP | G_IO_ERR | G_IO_NVAL)) {
> > attrib->read_watch = 0;
> > @@ -319,6 +321,8 @@ static gboolean received_data(GIOChannel *io, GIOCondition cond, gpointer data)
> > return attrib->events != NULL;
> > }
> >
> > + compound = cmd->compound;
> > +
> > if (buf[0] == ATT_OP_ERROR) {
> > status = buf[4];
> > goto done;
> > @@ -332,7 +336,8 @@ static gboolean received_data(GIOChannel *io, GIOCondition cond, gpointer data)
> > status = 0;
> >
> > done:
> > - if (attrib->queue && g_queue_is_empty(attrib->queue) == FALSE)
> > + if (!compound && attrib->queue &&
> > + g_queue_is_empty(attrib->queue) == FALSE)
> > wake_up_sender(attrib);
> >
> > if (cmd) {
> > @@ -340,6 +345,11 @@ done:
> > cmd->func(status, buf, len, cmd->user_data);
> >
> > command_destroy(cmd);
> > +
> > + if (compound && attrib->queue &&
> > + g_queue_is_empty(attrib->queue) == FALSE)
> > + wake_up_sender(attrib);
> > +
> Any chance to change the logic to avoid duplicated verification?
> No mater the value of "compound" wake_up_sender() is always called. Is
> the order important?
This is probably the ugliest part of my additions.
Here is the problem:
I wanted to delay the call to wake_up_sender() until *after* the
invocation of the cmd->func() callback, because if the the subsequent
ATT command is to be sent next, it needs to be added to the head of the
queue before the sender is woken up. wake_up_sender calls
g_io_add_watch_full(), and I am unsure how the process threading works
here, so I don't know if received_data() is going to be preempted (and
send the current queue head) by that call.
I do see that the call to wake_up_sender is called by the g_attrib_send*
function, but only if the addition was to a previously empty queue (so
that the count is now 1). It appeared to me that care was taken by the
original coder to make sure wake_up_sender() was called exactly once for
each ATT command that was queued, and since only a single ATT command
can be outstanding at a time, I believe this is the correct
functionality.
Also, there is the problem that just because a GATT procedure *may* be
compound, there is no guarantee that it *will* need to queue an
additional ATT command. In the read characteristic case, for instance,
if the result is less than 22 bytes, it will not end up being truly
compound at all. However, we do not know that until we have processed
the first result.
I could get around the "two code blocks that do almost the same thing"
problem by the following changes:
1. In g_attrib_send_seq(), pull "if length == 1 then wake_up_sender"
block out one level, so that it is invoked for both the
push_head and push_tail cases.
2. In received_data(), Check the queue member count prior to invoking
cmd->func, and then calling wake_up_sender afterwards if the
prior count was non-zero. We can't check the current count
at that point, because wake_up_sender may have already been
called in g_attrib_send_seq.
3. Then, we can totally eliminate the "compound" local var, and
structure member, making the whole thing cleaner.
Should I try that?
>
> > }
> >
> > return TRUE;
> > @@ -367,12 +377,16 @@ GAttrib *g_attrib_new(GIOChannel *io)
> > return g_attrib_ref(attrib);
> > }
> >
> > -guint g_attrib_send(GAttrib *attrib, guint8 opcode, const guint8 *pdu,
> > - guint16 len, GAttribResultFunc func,
> > - gpointer user_data, GDestroyNotify notify)
> > +guint g_attrib_send_seq(GAttrib *attrib, gboolean compound, guint id,
> > + guint8 opcode, const guint8 *pdu, guint16 len,
> > + GAttribResultFunc func, gpointer user_data,
> > + GDestroyNotify notify)
> > {
> > struct command *c;
> >
> > + if (attrib == NULL || attrib->queue == NULL)
> > + return 0;
> > +
> Is it necessary to check if queue is NULL?
I don't know. What happens if g_queue_push_head or g_queue_push_tail is
passed a NULL pointer for the queue? I noticed that it is checked by
g_attrib_cancel, and was unsure as to why it would be different.
>
> > c = g_try_new0(struct command, 1);
> > if (c == NULL)
> > return 0;
> > @@ -385,16 +399,30 @@ guint g_attrib_send(GAttrib *attrib, guint8 opcode, const guint8 *pdu,
> > c->func = func;
> > c->user_data = user_data;
> > c->notify = notify;
> > - c->id = ++attrib->next_cmd_id;
> > + c->compound = compound;
> >
> > - g_queue_push_tail(attrib->queue, c);
> > + if (id) {
> > + c->id = id;
> > + g_queue_push_head(attrib->queue, c);
> > + } else {
> > + c->id = ++attrib->next_cmd_id;
> > + g_queue_push_tail(attrib->queue, c);
> >
> > - if (g_queue_get_length(attrib->queue) == 1)
> > - wake_up_sender(attrib);
> > + if (g_queue_get_length(attrib->queue) == 1)
> > + wake_up_sender(attrib);
> > + }
> >
> > return c->id;
> > }
> >
> > +guint g_attrib_send(GAttrib *attrib, guint8 opcode, const guint8 *pdu,
> > + guint16 len, GAttribResultFunc func,
> > + gpointer user_data, GDestroyNotify notify)
> > +{
> > + return g_attrib_send_seq(attrib, FALSE, 0, opcode,
> > + pdu, len, func, user_data, notify);
> Coding style issue here.
What is the issue? I saw in g_attrib_new() that a return of a call to
g_attrib_ref was tail-chain-returned.
>
> Claudio
Thanks,
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: SBC loudness bug?
From: Siarhei Siamashka @ 2010-12-22 23:07 UTC (permalink / raw)
To: Christian Hoene
Cc: 'Luiz Augusto von Dentz', linux-bluetooth,
'Hagen Hentschel (Ellisys)'
In-Reply-To: <000601cba1e2$86077e70$92167b50$@de>
[-- Attachment #1: Type: Text/Plain, Size: 2735 bytes --]
On Wednesday 22 December 2010 16:14:16 Christian Hoene wrote:
> Hello,
>
> Mr. Hagen Hentschel was telling me that the BlueZ SBC implementation still
> has an bug.
Yes, unfortunately bluez sbc *decoder* is still as bad as it used to be. There
easily may be more than one bug in it.
I feel somewhat responsible for not bringing sbc decoder into a better shape
earlier. But at that time, only properly working and fast sbc *encoder* was
needed for A2DP bluetooth stereo headsets support in Nokia N900. Moreover, I
had run out of allocated time to this task (due to actually having to fix some
bluez sbc encoder bugs in addition to doing just performance optimizations) and
had to wrap up this activity even before all the planned ARM NEON optimizations
had been implemented.
Fortunately I had some spare time on the last summer vacation to spend on bluez
sbc codec. It was a tough choice deciding between either fixing the decoder or
adding missing ARM NEON optimizations to the encoder. But in the end I decided
to get at least one thing done right (the encoder), especially considering that
it happens to be referred from several places as an example of ARM NEON
optimizations. And I just did not feel right about having clearly incomplete
stuff there :) So the encoder got more optimizations [1][2], and the decoder
remained the way it was (it is still in my low priority TODO list).
> As compared to Bluetooth's reference implementation the signal
> is twotimes too silent. We told me, that in the last step of calculating
> the PCM samples a 1 bit right shift was done too much.
>
> A correct implementation for C# can be found at
> http://sourceforge.net/projects/sbcsharp/
>
> Sorry, due to time limits I cannot provide you with a patch...
Even without looking at the changes (after all, it's not so easy without a
patch), I guess it's more like a band aid. The whole decoder needs to be
seriously reworked. At least dropping the current synthesis filter
completely and reimplementing it straight according to A2DP spec is
necessary. We can't verify whether the current filter is correct, and also
its low precision is likely masking the other bugs and deviations from the
spec. I had some notes about it earlier in [3].
I have no idea when this all might be done unless somebody steps up for this
task (Hagen?). Or unless I myself somehow get an opportunity to work on fixing
sbc decoder full time for at least a week (next summer vacation?).
1. http://marc.info/?l=linux-bluetooth&m=127781938327437&w=2
2. http://marc.info/?l=linux-bluetooth&m=127807359119577&w=2
3. http://marc.info/?l=linux-bluetooth&m=126106163120842&w=2
--
Best regards,
Siarhei Siamashka
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 08/18] Add a way to retrieve ATT primary services
From: Johan Hedberg @ 2010-12-22 22:52 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1292966800-6264-9-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Tue, Dec 21, 2010, Vinicius Costa Gomes wrote:
> As the primary services were discovered by the core bluetoothd, we need
> a way to export that information.
>
> The service discovery uses the same primary list as the device, there's no
> need to free that list when the discovery finishes. That list will be removed
> when the device is free'd.
> ---
> src/adapter.c | 6 +++---
> src/device.c | 15 +++++++++++++++
> src/device.h | 3 +++
> src/glib-helper.c | 1 -
> 4 files changed, 21 insertions(+), 4 deletions(-)
I tried to continue applying the patches starting with this one, but it
doesn't apply cleanly anymore probably due to me skipping patch 7 with
its compilation errors. So I'll once again stop processing the patch set
here.
Johan
^ permalink raw reply
* Re: [PATCH 07/18] Add support for creating devices from stored primary services
From: Johan Hedberg @ 2010-12-22 22:50 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1292966800-6264-8-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Tue, Dec 21, 2010, Vinicius Costa Gomes wrote:
> From what we can retrieve from storage we are able to create the devices
> and probe the device drivers.
> ---
> src/adapter.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 77 insertions(+), 0 deletions(-)
Patches 5 and 6 have been pushed upstream, but this one doesn't compile:
src/adapter.c: In function 'string_to_primary_list':
src/adapter.c:1958: error: implicit declaration of function 'att_primary_free'
src/adapter.c: In function 'create_stored_device_from_primary':
src/adapter.c:2003: error: 'att_primary_free' undeclared (first use in this function)
src/adapter.c:2003: error: (Each undeclared identifier is reported only once
src/adapter.c:2003: error: for each function it appears in.)
make[1]: *** [src/adapter.o] Error 1
Please fix and resubmit.
Johan
^ permalink raw reply
* Re: [PATCH v3] sbc: detect when bitpool has changed
From: Johan Hedberg @ 2010-12-22 22:44 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1293010548-25151-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Wed, Dec 22, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> A2DP spec allow bitpool changes midstream which is why sbc configuration
> has a range of values for bitpool that the encoder can use and decoder
> must support.
>
> Bitpool changes do not affect the state of encoder/decoder so they don't
> need to be reinitialize when this happens, so the impact is fairly small,
> what it does change is the frame length so encoders may change the
> bitpool to use the link more efficiently.
> ---
> sbc/sbc.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
The patch has been pushed upstream. Thanks. Could you also make sure
that it gets applied to PulseAudio's copy of libsbc?
Johan
^ permalink raw reply
* Re: [PATCH] Change LE scan interval and window to recommended values
From: Johan Hedberg @ 2010-12-22 22:42 UTC (permalink / raw)
To: Bruna Moreira; +Cc: linux-bluetooth
In-Reply-To: <1293045108-14011-1-git-send-email-bruna.moreira@openbossa.org>
Hi Bruna,
On Wed, Dec 22, 2010, Bruna Moreira wrote:
> Replace default scan interval and scan window values with recommended
> ones for general discovery procedure, according to the Core
> specification.
> ---
> plugins/hciops.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2 3/18] Move primary service storage to device.c
From: Johan Hedberg @ 2010-12-22 22:41 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1293055273-21076-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Wed, Dec 22, 2010, Sheldon Demario wrote:
> Discover All Primary Services has beed moved to device.c in order
> to follow a similar approach of BR/EDR service records.
> ---
> attrib/att.h | 6 ++++++
> attrib/client.c | 41 -----------------------------------------
> attrib/gattrib.c | 1 +
> src/device.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> src/glib-helper.c | 24 ++++++++++++++++--------
> 5 files changed, 66 insertions(+), 50 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox