* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Arnd Bergmann @ 2010-10-28 12:22 UTC (permalink / raw)
To: Par-Gunnar Hjalmdahl
Cc: Alan Cox, linus.walleij, linux-bluetooth, linux-kernel,
Lukasz.Rymanowski
In-Reply-To: <AANLkTik-S50ZX6mFG+vWhBv0x_WmipP=t+4VqmAgssRC@mail.gmail.com>
On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:
> >
> > So - NAK this for the moment, it needs to be split cleanly into ldisc
> > (thing which speaks the protocol and eg sees "speed change required" and
> > acts on it) and device (thing which knows about the hardware).
>
> OK. We will try to figure out a new design.
> I'm not too happy about putting the ldisc part in Bluetooth though
> since it is only partly Bluetooth, it is also GPS and FM. Better could
> maybe be under char/?
After getting a better idea of what the base mfd driver does, my impression
is now that you should not register a second N_HCI line discipline at all,
but instead extend the existing line discipline with this number.
I'm not sure what happens if you need two modules that try to register
the same ldisc number, but I imagine it is not good.
Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?
Arnd
^ permalink raw reply
* Re: [PATCH] bluetooth: fix not setting security level when creating a rfcomm session
From: Gustavo F. Padovan @ 2010-10-28 13:07 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, ville.tervo
In-Reply-To: <1282215970-32758-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
* Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2010-08-19 14:06:10 +0300]:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This cause 'No Bonding' to be used if userspace has not yet been paired
> with remote device since the l2cap socket used to create the rfcomm
> session does not have any security level set.
>
> Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
> ---
> net/bluetooth/rfcomm/core.c | 13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
Patch has been applied to the bluetooth-2.6 tree. Thanks.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Bluetooth: Automate remote name requests
From: Johan Hedberg @ 2010-10-28 13:56 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikKGDtybssKjoNUACAwzg1HA7VC4rWrnNFvJ-2u@mail.gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> This seems to be done only for some connections which IMO is not the
> correct, so for instance it wouldn't request name for SDP connections
> nor for incoming connections, is there a reason for that?
>
> Perhaps requesting the name regardless the security level on
> hci_remote_features_evt and then latter, when we got the name
> response, we continue with security level check and authentication
> request if necessary. Wouldn't that work better?
Yeah, you're right. Basicly what the patch does is replace the
occurences of AUTH_REQ with NAME_REQ and then do the AUTH_REQ in the
name_req_complete callback. However that is not the same as userspace is
doing which is an unconditional name request for every single connect
complete event. FWIW, there seems to be a potential bug with the
existing authentication request too: the code doesn't trigger it if the
extended features request fails (hci_cs_read_remote_ext_features
function).
I'll try to come up with a new revision of the name request patch
shortly.
Johan
^ permalink raw reply
* [PATCH v2] Bluetooth: Automate remote name requests
From: johan.hedberg @ 2010-10-28 16:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
From: Johan Hedberg <johan.hedberg@nokia.com>
In Bluetooth there are no automatic updates of remote device names when
they get changed on the remote side. Instead, it is a good idea to do a
manual name request when a new connection gets created (for whatever
reason) since at this point it is very cheap (no costly baseband
connection creation needed just for the sake of the name request).
So far userspace has been responsible for this extra name request but
tighter control is needed in order not to flood Bluetooth controllers
with two many commands during connection creation. It has been shown
that some controllers simply fail to function correctly if they get too
many (almost) simultaneous commands during connection creation. The
simplest way to acheive better control of these commands is to move
their sending completely to the kernel side.
This patch inserts name requests into the sequence of events that the
kernel performs during connection creation. It does this after the
remote features have been successfully requested and before any pending
authentication requests are performed. The code will work sub-optimally
with userspace versions that still do the name requesting themselves (it
shouldn't break anything though) so it is recommended to combine this
with a userspace software version that doesn't have automated name
requests.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
v2 makes sure that the name request gets always sent instead of just
doing it for cases when we're also going to request authentication.
net/bluetooth/hci_event.c | 151 ++++++++++++++++++++++++++++++++-------------
1 files changed, 107 insertions(+), 44 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 84093b0..6e770e8 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -677,9 +677,51 @@ static void hci_cs_set_conn_encrypt(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
+static void request_outgoing_auth(struct hci_dev *hdev, bdaddr_t *bdaddr)
+{
+ struct hci_cp_auth_requested cp;
+ struct hci_conn *conn;
+
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, bdaddr);
+ if (!conn)
+ return;
+
+ if (conn->state != BT_CONFIG || !conn->out)
+ return;
+
+ if (conn->sec_level == BT_SECURITY_SDP)
+ return;
+
+ /* Only request authentication for SSP connections or non-SSP
+ * devices with sec_level HIGH */
+ if (!(hdev->ssp_mode > 0 && conn->ssp_mode > 0) &&
+ conn->sec_level != BT_SECURITY_HIGH)
+ return;
+
+ cp.handle = __cpu_to_le16(conn->handle);
+ hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
+}
+
static void hci_cs_remote_name_req(struct hci_dev *hdev, __u8 status)
{
+ struct hci_cp_remote_name_req *cp;
+
BT_DBG("%s status 0x%x", hdev->name, status);
+
+ /* If successful wait for the name req complete event before
+ * checking for the need to do authentication */
+ if (!status)
+ return;
+
+ cp = hci_sent_cmd_data(hdev, HCI_OP_REMOTE_NAME_REQ);
+ if (!cp)
+ return;
+
+ hci_dev_lock(hdev);
+
+ request_outgoing_auth(hdev, &cp->bdaddr);
+
+ hci_dev_unlock(hdev);
}
static void hci_cs_read_remote_features(struct hci_dev *hdev, __u8 status)
@@ -1090,9 +1132,17 @@ static inline void hci_auth_complete_evt(struct hci_dev *hdev, struct sk_buff *s
static inline void hci_remote_name_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
+ struct hci_ev_remote_name *ev = (void *) skb->data;
+
BT_DBG("%s", hdev->name);
hci_conn_check_pending(hdev);
+
+ hci_dev_lock(hdev);
+
+ request_outgoing_auth(hdev, &ev->bdaddr);
+
+ hci_dev_unlock(hdev);
}
static inline void hci_encrypt_change_evt(struct hci_dev *hdev, struct sk_buff *skb)
@@ -1162,33 +1212,39 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(ev->handle));
- if (conn) {
- if (!ev->status)
- memcpy(conn->features, ev->features, 8);
+ if (!conn)
+ goto unlock;
- if (conn->state == BT_CONFIG) {
- if (!ev->status && lmp_ssp_capable(hdev) &&
- lmp_ssp_capable(conn)) {
- struct hci_cp_read_remote_ext_features cp;
- cp.handle = ev->handle;
- cp.page = 0x01;
- hci_send_cmd(hdev,
- HCI_OP_READ_REMOTE_EXT_FEATURES,
- sizeof(cp), &cp);
- } else if (!ev->status && conn->out &&
- conn->sec_level == BT_SECURITY_HIGH) {
- struct hci_cp_auth_requested cp;
- cp.handle = ev->handle;
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
+ if (!ev->status)
+ memcpy(conn->features, ev->features, 8);
+
+ if (conn->state != BT_CONFIG)
+ goto unlock;
+
+ if (!ev->status && lmp_ssp_capable(hdev) && lmp_ssp_capable(conn)) {
+ struct hci_cp_read_remote_ext_features cp;
+ cp.handle = ev->handle;
+ cp.page = 0x01;
+ hci_send_cmd(hdev, HCI_OP_READ_REMOTE_EXT_FEATURES,
sizeof(cp), &cp);
- } else {
- conn->state = BT_CONNECTED;
- hci_proto_connect_cfm(conn, ev->status);
- hci_conn_put(conn);
- }
- }
+ goto unlock;
+ }
+
+ if (!ev->status) {
+ struct hci_cp_remote_name_req cp;
+ memset(&cp, 0, sizeof(cp));
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pscan_rep_mode = 0x02;
+ hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ, sizeof(cp), &cp);
+ }
+
+ if (!conn->out || conn->sec_level != BT_SECURITY_HIGH) {
+ conn->state = BT_CONNECTED;
+ hci_proto_connect_cfm(conn, ev->status);
+ hci_conn_put(conn);
}
+unlock:
hci_dev_unlock(hdev);
}
@@ -1646,32 +1702,39 @@ static inline void hci_remote_ext_features_evt(struct hci_dev *hdev, struct sk_b
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(ev->handle));
- if (conn) {
- if (!ev->status && ev->page == 0x01) {
- struct inquiry_entry *ie;
+ if (!conn)
+ goto unlock;
- if ((ie = hci_inquiry_cache_lookup(hdev, &conn->dst)))
- ie->data.ssp_mode = (ev->features[0] & 0x01);
+ if (!ev->status && ev->page == 0x01) {
+ struct inquiry_entry *ie;
- conn->ssp_mode = (ev->features[0] & 0x01);
- }
+ if ((ie = hci_inquiry_cache_lookup(hdev, &conn->dst)))
+ ie->data.ssp_mode = (ev->features[0] & 0x01);
- if (conn->state == BT_CONFIG) {
- if (!ev->status && hdev->ssp_mode > 0 &&
- conn->ssp_mode > 0 && conn->out &&
- conn->sec_level != BT_SECURITY_SDP) {
- struct hci_cp_auth_requested cp;
- cp.handle = ev->handle;
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
- sizeof(cp), &cp);
- } else {
- conn->state = BT_CONNECTED;
- hci_proto_connect_cfm(conn, ev->status);
- hci_conn_put(conn);
- }
- }
+ conn->ssp_mode = (ev->features[0] & 0x01);
}
+ if (conn->state != BT_CONFIG)
+ goto unlock;
+
+ if (!ev->status) {
+ struct hci_cp_remote_name_req cp;
+ memset(&cp, 0, sizeof(cp));
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pscan_rep_mode = 0x02;
+ hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ, sizeof(cp), &cp);
+ }
+
+ /* If legacy pairing, or an incoming connection, or SDP security
+ * consider ourself connected */
+ if (!(hdev->ssp_mode > 0 && conn->ssp_mode > 0) || !conn->out ||
+ conn->sec_level == BT_SECURITY_SDP) {
+ conn->state = BT_CONNECTED;
+ hci_proto_connect_cfm(conn, ev->status);
+ hci_conn_put(conn);
+ }
+
+unlock:
hci_dev_unlock(hdev);
}
--
1.7.1
^ permalink raw reply related
* Re: Unable to get on D-Bus: bluez 4.77
From: Puneet Pant @ 2010-10-28 17:18 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20101028120950.GB17930@vigoh>
Hi Gustavo,
On Thu, Oct 28, 2010 at 5:39 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Puneet,
>
> * Puneet Pant <pant.puneet464@gmail.com> [2010-10-28 17:02:48 +0530]:
>
>> Hello,
>>
>> I have compiled Bluez 4.77. But I'm getting the following error when
>> trying to start Bluetooth Daemon:
>>
>> root@puneet-VirtualBox:/home/puneet/packages/bluez-4.77/src#
>> dbus-daemon --system
>> root@puneet-VirtualBox:/home/puneet/packages/bluez-4.77/src# ./bluetoothd -nd
>> bluetoothd[11819]: Bluetooth deamon 4.77
>> bluetoothd[11819]: src/main.c:parse_config() parsing main.conf
>> bluetoothd[11819]: src/main.c:parse_config() discovto=0
>> bluetoothd[11819]: src/main.c:parse_config() pairto=0
>> bluetoothd[11819]: src/main.c:parse_config() pageto=8192
>> bluetoothd[11819]: src/main.c:parse_config() name=%h-%d
>> bluetoothd[11819]: src/main.c:parse_config() class=0x000100
>> bluetoothd[11819]: src/main.c:parse_config() discov_interval=0
>> bluetoothd[11819]: src/main.c:parse_config() Key file does not have
>> key 'DeviceID'
>> bluetoothd[11819]: Unable to get on D-Bus
>
> One of the reasons could be that you already have the bluetoothd daemon
> running.
>
I did "ps -e | grep bluetooth" and found no bluetoothd running.
Could this be related to D-Bus library version incompatibility with ubuntu.
As I see, Ubuntu 10.10 comes with Dbus 1.4.0 installed, but when I run
./configure for bluez, it does not detect the installed D-Bus. I had
to manually download and install D-Bus 1.2.24 for bluez configure to
detect and compile?
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
>
Thanks,
Puneet
^ permalink raw reply
* Re: [PATCH v3] Fix obexd crash for empty listing invalid cache
From: Johan Hedberg @ 2010-10-28 17:51 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1288255408-3967-2-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Thu, Oct 28, 2010, Dmitriy Paliy wrote:
> This fixes obexd crash in 3-way calling scenario when filtered listing
> response is empty. Valid cache and empty pbap buffer mean that cache was
> already attempted to be created within a single session, but no data was
> available. Hence, it is not notified and no such file error returned.
>
> Such avoids clearing and creating a new cache operations for each incoming
> call, which is one of possible solution to fix this bug. It can be
> extensive for large phone books. New cache is not created within current
> obex session or unless path is changed.
> ---
> plugins/pbap.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Remove old hcid.conf
From: Johan Hedberg @ 2010-10-28 18:08 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1288257675-17086-1-git-send-email-padovan@profusion.mobi>
Hi Gustavo,
On Thu, Oct 28, 2010, Gustavo F. Padovan wrote:
> ---
> src/hcid.conf | 57 -------------
> src/hcid.conf.5.in | 227 ----------------------------------------------------
> 2 files changed, 0 insertions(+), 284 deletions(-)
> delete mode 100644 src/hcid.conf
> delete mode 100644 src/hcid.conf.5.in
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: RFCOMM connection from android device to desktop pc
From: Leandro de Oliveira @ 2010-10-28 18:11 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTinBqjTmLiXwd5LkzZRXOkuYkfS=48m6gWQ9AQO7@mail.gmail.com>
So, any ideas? Don't you find it strange that bluez can't communicate
with itself?
2010/10/22 Leandro de Oliveira <lehphyro@gmail.com>:
> Hi,
>
> I'm trying to open an RFCOMM connection from my android device to my
> desktop pc running Ubuntu 10.04, send some data, close the connection
> and then do it again. My desktop program is written in Java and relies
> on BlueCove[1] to handle bluetooth details which calls Bluez 4.x in
> this case.
>
> The problem is that I get a successful connection and data transfer in
> the first communication attempt but nothing in subsequent attempts.
>
> There is this thread[2] in the android-platform mailing list with much
> more detail, but I think you could just take a look at this hcidump
> that has been requested there to let me know if this is a problem in
> bluez on the android or desktop side:
> http://dl.dropbox.com/u/1401233/pc-hcidump.txt
>
> Please, let me know if you need more info.
>
> The same program works perfectly when the android application connects
> to it running on Windows 7 using the Microsoft Bluetooth Stack.
>
> [1] http://www.bluecove.org/
> [2] http://groups.google.com/group/android-platform/browse_thread/thread/485db57409304d3e?hl=en
>
> Thank you very much
>
^ permalink raw reply
* Re: [PATCH 1/5] Fix issue when setting limited discoverable mode
From: Johan Hedberg @ 2010-10-28 18:24 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288252859-10337-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> if (discoverable && adapter->pairable && adapter->discov_timeout > 0 &&
> - adapter->discov_timeout <= 60)
> + adapter->discov_timeout <= 60) {
> + adapter->mode = MODE_LIMITED;
> adapter_set_limited_discoverable(adapter, TRUE);
Wouldn't it make more sense to do the fix to adapter->mode inside the
adapter_set_limited_discoverable function?
Johan
^ permalink raw reply
* Re: [PATCH 2/5] Fix not waiting mode change when setting powered property
From: Johan Hedberg @ 2010-10-28 18:28 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288252859-10337-2-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This may cause errors if the user application immediately set another
> mode.
> ---
> src/adapter.c | 84 +++++++++++++++++++++++++++++---------------------------
> 1 files changed, 43 insertions(+), 41 deletions(-)
This patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: RFCOMM connection from android device to desktop pc
From: jaikumar Ganesh @ 2010-10-28 18:47 UTC (permalink / raw)
To: Leandro de Oliveira; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimU3vT0MiqiTk0E8mFhVJJWXB5xJ50RosiYHCBy@mail.gmail.com>
Hi Leandro:
Debugging this is on my list. I will get back to you.
Thanks
On Thu, Oct 28, 2010 at 11:11 AM, Leandro de Oliveira
<lehphyro@gmail.com> wrote:
> So, any ideas? Don't you find it strange that bluez can't communicate
> with itself?
>
> 2010/10/22 Leandro de Oliveira <lehphyro@gmail.com>:
>> Hi,
>>
>> I'm trying to open an RFCOMM connection from my android device to my
>> desktop pc running Ubuntu 10.04, send some data, close the connection
>> and then do it again. My desktop program is written in Java and relies
>> on BlueCove[1] to handle bluetooth details which calls Bluez 4.x in
>> this case.
>>
>> The problem is that I get a successful connection and data transfer in
>> the first communication attempt but nothing in subsequent attempts.
>>
>> There is this thread[2] in the android-platform mailing list with much
>> more detail, but I think you could just take a look at this hcidump
>> that has been requested there to let me know if this is a problem in
>> bluez on the android or desktop side:
>> http://dl.dropbox.com/u/1401233/pc-hcidump.txt
>>
>> Please, let me know if you need more info.
>>
>> The same program works perfectly when the android application connects
>> to it running on Windows 7 using the Microsoft Bluetooth Stack.
>>
>> [1] http://www.bluecove.org/
>> [2] http://groups.google.com/group/android-platform/browse_thread/thread/485db57409304d3e?hl=en
>>
>> Thank you very much
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 3/5] Fix setting Discoverable when adapter is down
From: Johan Hedberg @ 2010-10-28 19:00 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288252859-10337-3-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This cause an error because adapter_up will load the mode from storage
> ignoring pending mode which cause modes to mismatch.
>
> To fix this behavior now when attempting to change mode we first store
> the new mode and wait DEVUP to complete set the mode stored.
> ---
> src/adapter.c | 19 +++++++++++--------
> 1 files changed, 11 insertions(+), 8 deletions(-)
Patches 3/5, 4/5 and 5/5 have also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* AVRCP 1.4 Patch
From: John Crosbie @ 2010-10-29 5:23 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth
João Paulo,
I have been working with your AVRCP 1.4 patches that are posted on
GSOC. I found a problem in one of your patch files that I thought I
would relate:
in [PATCH 03/10] AVRCP: Handle GetCapabilities PDU
at line 48
+ metadata = (struct metadata_header *) avrcp + AVRCP_HEADER_LENGTH + 3;
the pointer arithmetic is broken and should be something like:
+ metadata = (struct metadata_header *)((uint8_t*)avrcp +
AVRCP_HEADER_LENGTH + 3);
Now the device (CT) Requests CAP_COMPANY_ID and CAP_EVENTS_SUPPORTED
as expected but doesn't do anything more so I will continue digging.
I am working with a Sony Ericsson MW600 device. It claims to have
AVRCP 1.4 support but I have not confirmed that it works as yet.
If I am working with old code please let me know.
Regards,
John Crosbie
Excelfore
^ permalink raw reply
* Re: Unable to get on D-Bus: bluez 4.77
From: Puneet Pant @ 2010-10-29 7:30 UTC (permalink / raw)
Cc: linux-bluetooth
In-Reply-To: <AANLkTi=H+zqzZb6f303VJRXA_zmibiG=Zec0unxy5b-=@mail.gmail.com>
Hello,
On Thu, Oct 28, 2010 at 10:48 PM, Puneet Pant <pant.puneet464@gmail.com> wrote:
> Hi Gustavo,
>
> On Thu, Oct 28, 2010 at 5:39 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
>> Hi Puneet,
>>
>> * Puneet Pant <pant.puneet464@gmail.com> [2010-10-28 17:02:48 +0530]:
>>
>>> Hello,
>>>
>>> I have compiled Bluez 4.77. But I'm getting the following error when
>>> trying to start Bluetooth Daemon:
>>>
>>> root@puneet-VirtualBox:/home/puneet/packages/bluez-4.77/src#
>>> dbus-daemon --system
>>> root@puneet-VirtualBox:/home/puneet/packages/bluez-4.77/src# ./bluetoothd -nd
>>> bluetoothd[11819]: Bluetooth deamon 4.77
>>> bluetoothd[11819]: src/main.c:parse_config() parsing main.conf
>>> bluetoothd[11819]: src/main.c:parse_config() discovto=0
>>> bluetoothd[11819]: src/main.c:parse_config() pairto=0
>>> bluetoothd[11819]: src/main.c:parse_config() pageto=8192
>>> bluetoothd[11819]: src/main.c:parse_config() name=%h-%d
>>> bluetoothd[11819]: src/main.c:parse_config() class=0x000100
>>> bluetoothd[11819]: src/main.c:parse_config() discov_interval=0
>>> bluetoothd[11819]: src/main.c:parse_config() Key file does not have
>>> key 'DeviceID'
>>> bluetoothd[11819]: Unable to get on D-Bus
>>
>> One of the reasons could be that you already have the bluetoothd daemon
>> running.
>>
>
> I did "ps -e | grep bluetooth" and found no bluetoothd running.
> Could this be related to D-Bus library version incompatibility with ubuntu.
> As I see, Ubuntu 10.10 comes with Dbus 1.4.0 installed, but when I run
> ./configure for bluez, it does not detect the installed D-Bus. I had
> to manually download and install D-Bus 1.2.24 for bluez configure to
> detect and compile?
>
>> --
I am able to resolve the issue by installing appropriate D-Bus library
headers through Synaptic Manager on Ubuntu 10.10 and rebuilding Bluez
code.
Installing Dbus separately seems to have caused the problem.
After building the code, bluetooth daemon is working fine.
>> Gustavo F. Padovan
>> ProFUSION embedded systems - http://profusion.mobi
>>
>
> Thanks,
> Puneet
>
Thanks,
Puneet
^ permalink raw reply
* btusb Headset Microphone not working
From: Michael Kopp @ 2010-10-29 8:41 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I upgraded my notebook recently and as of now the headset microphone
is not working anymore. When trying arecord no data is being recorded.
I already tried several versions of bluez up and to including 4.75
with kernels 2.6.32, 2.6.34 2.6.35, no joy.
I get the following error in dmesg
btusb_submit_isoc_urb: hci0 urb f359fe00 submission failed (28)
btusb_submit_isoc_urb: hci0 urb f5f37200 submission failed (28)
/var/log/messages reveals a little more
ct 29 08:40:54 mkopp bluetoothd[5751]: link_key_request
(sba=1C:65:9D:02:DE:E0, dba=00:16:94:09:DB:88)
Oct 29 08:40:54 mkopp bluetoothd[5751]: link_key_request
(sba=1C:65:9D:02:DE:E0, dba=00:16:94:09:DB:88)
Oct 29 08:40:57 mkopp kernel: input: 00:16:94:09:DB:88 as
/devices/virtual/input/input16
Oct 29 08:42:21 mkopp kernel: btusb_submit_isoc_urb: hci0 urb f359fe00
submission failed (28)
Oct 29 08:43:28 mkopp bluetoothd[5751]: No matching connection found
for handle 6
Oct 29 08:45:28 mkopp kernel: btusb_submit_isoc_urb: hci0 urb f5f37200
submission failed (28)
Oct 29 08:45:50 mkopp bluetoothd[5751]: No matching connection found
for handle 6
Oct 29 08:49:19 mkopp kernel: input: 00:16:94:09:DB:88 as
/devices/virtual/input/input17
Oct 29 08:49:20 mkopp bluetoothd[5751]: Disconnected from
00:16:94:09:DB:88, /org/bluez/5751/hci0/dev_00_16_94_09_DB_88
Audio output works for both AD2P and SCO, input works on neither
although the headset supports it and works on my cell phone.
my .asoundrc is as simple as it gets
pcm.bluetooth {
type bluetooth
device "00:16:94:09:DB:88"
profile "voice"
}
I've tried google and all sorts of forums but although I've seen this
error several times I was not able to find a solution. I would be
grateful if somebody could point me towards a solution.
Best regards
Michael Kopp
^ permalink raw reply
* [PATCH] Fix handling nco affiliation fields
From: Lukasz Pawlik @ 2010-10-29 9:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
Previously when contact record was divided into separate replies,
phonebook-tracker would use first reply and merge only phone numbers,
addresses and emails from next. Now it's merging all fields dependent on the
nco:hasAffiliation as well.
---
plugins/phonebook-tracker.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 96290a4..f37ed5a 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -982,6 +982,14 @@ static void add_phone_number(struct phonebook_contact *contact,
contact->numbers = g_slist_append(contact->numbers, number);
}
+static void add_affiliation(char **field, const char *value)
+{
+ if(strlen(*field) != 0 || value == NULL || strlen(value) == 0)
+ return;
+
+ *field = g_strdup(value);
+}
+
static struct phonebook_email *find_email(GSList *emails, const char *address,
int type)
{
@@ -1196,6 +1204,13 @@ add_numbers:
g_free(home_addr);
g_free(work_addr);
+ /* Adding fields connected by nco:hasAffiliation - they may be in
+ * separate replies */
+ add_affiliation(&contact->title, reply[33]);
+ add_affiliation(&contact->company, reply[22]);
+ add_affiliation(&contact->department, reply[23]);
+ add_affiliation(&contact->role, reply[24]);
+
DBG("contact %p", contact);
/* Adding contacts data to wrapper struct - this data will be used to
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
From: Ville Tervo @ 2010-10-29 10:44 UTC (permalink / raw)
To: ext Anderson Briglia
Cc: linux-bluetooth@vger.kernel.org, Vinicius Costa Gomes
In-Reply-To: <1287791820-22693-3-git-send-email-anderson.briglia@openbossa.org>
Hi Anderson,
On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> As L2CAP packets coming over LE don't have any more encapsulation,
> other than L2CAP, we are able to process them as soon as they arrive.
Why is this change needed? Was something broken without this patch?
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/l2cap.c | 17 +++++++++++++++--
> 1 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 2bf083e..1ac44f4 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
> static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
> {
> struct l2cap_conn *conn = hcon->l2cap_data;
> + struct l2cap_hdr *hdr;
> + int len;
>
> if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
> goto drop;
>
> BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
>
> + if (hcon->type == LE_LINK) {
> + hdr = (struct l2cap_hdr *) skb->data;
> + len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
> +
> + if (len == skb->len) {
> + /* Complete frame received */
> + l2cap_recv_frame(conn, skb);
> + return 0;
> + }
> +
> + goto drop;
> + }
> +
> if (flags & ACL_START) {
> - struct l2cap_hdr *hdr;
> struct sock *sk;
> u16 cid;
> - int len;
>
> if (conn->rx_len) {
> BT_ERR("Unexpected start frame (len %d)", skb->len);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ville
^ permalink raw reply
* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Par-Gunnar Hjalmdahl @ 2010-10-29 11:53 UTC (permalink / raw)
To: Alan Cox; +Cc: linus.walleij, linux-bluetooth, linux-kernel
In-Reply-To: <20101022135130.617f0ce8@lxorguk.ukuu.org.uk>
2010/10/22 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> +
>> +/**
>> + * create_work_item() - Create work item and add it to the work queue.
>> + * @wq: work queue struct where the work will be added.
>> + * @work_func: Work function.
>> + * @data: Private data for the work.
>> + *
>> + * Returns:
>> + * 0 if there is no error.
>> + * -EBUSY if not possible to queue work.
>> + * -ENOMEM if allocation fails.
>> + */
>> +static int create_work_item(struct workqueue_struct *wq, work_func_t work_func,
>> + void *data)
>> +{
>> + struct uart_work_struct *new_work;
>> + int err;
>> +
>> + new_work = kmalloc(sizeof(*new_work), GFP_ATOMIC);
>
> So instead of a tiny object embedded in your device you've got a whole
> error path to worry about, a printk disguised in a macro and a text
> string longer than the struct size ? Surely this should be part of the
> device
>
I've tried now to use 3 separate work_structs in the device (one for
each work function used), but this doesn't work out.
The reason is that the work is generated so often that a work is not
finished before next work of same type comes. This is especially true
for transmit and receive. Then I get 0 back when queuing the work and
there is no real way to solve it from what I can see than to allocate
new work structures every time.
/P-G
^ permalink raw reply
* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Par-Gunnar Hjalmdahl @ 2010-10-29 11:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Cox, linus.walleij, linux-bluetooth, linux-kernel,
Lukasz.Rymanowski
In-Reply-To: <201010281422.46687.arnd@arndb.de>
2010/10/28 Arnd Bergmann <arnd@arndb.de>:
> On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:
>
>> >
>> > So - NAK this for the moment, it needs to be split cleanly into ldisc
>> > (thing which speaks the protocol and eg sees "speed change required" and
>> > acts on it) and device (thing which knows about the hardware).
>>
>> OK. We will try to figure out a new design.
>> I'm not too happy about putting the ldisc part in Bluetooth though
>> since it is only partly Bluetooth, it is also GPS and FM. Better could
>> maybe be under char/?
>
> After getting a better idea of what the base mfd driver does, my impression
> is now that you should not register a second N_HCI line discipline at all,
> but instead extend the existing line discipline with this number.
>
> I'm not sure what happens if you need two modules that try to register
> the same ldisc number, but I imagine it is not good.
>
> Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?
>
> Arnd
>
We also need the ldisc code to handle events from FM and GPS and since
that is chip specific we cannot add that to the generic hci_ldisc
code.
I agree that we might run into problems if two drivers try to register
the same line discipline. It might then be better to introduce a new
line discipline then even though that could cause other problems. I do
not know if it is possible to add a condition in Kconfig otherwise so
the CG2900 ldisc cannot be active while the "normal" ldisc driver is
selected.
/P-G
^ permalink raw reply
* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Par-Gunnar Hjalmdahl @ 2010-10-29 12:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Cox, linus.walleij, linux-bluetooth, linux-kernel,
Lukasz.Rymanowski
In-Reply-To: <AANLkTinh3D8V8UaN8FyCouwUQ98A4RRWEHXU7Tr9XMbs@mail.gmail.com>
2010/10/29 Par-Gunnar Hjalmdahl <pghatwork@gmail.com>:
> 2010/10/28 Arnd Bergmann <arnd@arndb.de>:
>> On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:
>>
>>> >
>>> > So - NAK this for the moment, it needs to be split cleanly into ldisc
>>> > (thing which speaks the protocol and eg sees "speed change required" and
>>> > acts on it) and device (thing which knows about the hardware).
>>>
>>> OK. We will try to figure out a new design.
>>> I'm not too happy about putting the ldisc part in Bluetooth though
>>> since it is only partly Bluetooth, it is also GPS and FM. Better could
>>> maybe be under char/?
>>
>> After getting a better idea of what the base mfd driver does, my impression
>> is now that you should not register a second N_HCI line discipline at all,
>> but instead extend the existing line discipline with this number.
>>
>> I'm not sure what happens if you need two modules that try to register
>> the same ldisc number, but I imagine it is not good.
>>
>> Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?
>>
>> Arnd
>>
>
> We also need the ldisc code to handle events from FM and GPS and since
> that is chip specific we cannot add that to the generic hci_ldisc
> code.
> I agree that we might run into problems if two drivers try to register
> the same line discipline. It might then be better to introduce a new
> line discipline then even though that could cause other problems. I do
> not know if it is possible to add a condition in Kconfig otherwise so
> the CG2900 ldisc cannot be active while the "normal" ldisc driver is
> selected.
>
> /P-G
>
Hi again,
I might have been a bit too quick there.
The actual channel matching and packet creation is done in hci_h4.c
while ldisc registration is done in hci_ldisc.c.
So it might to be enough to create a new hci_h4-cg2900.c (or similar
name) that can separate the right channels. We must however do changes
to hci_ldisc as well since it seems to always register to the
Bluetooth stack here, which we definitely don't want since that is
handled by btcg2900.c.
Also note that this ldisc issue is only valid when using UART as
transport. We will also support SPI and then we will probably run into
completely new, interesting problems. :-)
/P-G
^ permalink raw reply
* Re: Kernel panic in rfcomm_run - unbalanced refcount on rfcomm_session
From: Simantini Bhattacharya @ 2010-10-29 12:34 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Nick Pelly, Ville Tervo, Dave Young, Bluettooth Linux,
Marcel Holtmann
In-Reply-To: <508e92ca1003190133m1e2769ev36430d3c3b28504@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6961 bytes --]
Hi All ,
I have seen a similar issue when testing my device with Motorola 17 mono
headset . The use-case tried was as follows :
1)Pair connect device to Motorola H17
2)Power up Bluetooth on my device
3)Power back Bluetooth on the device .
On repeating this sequence for around 10-15 times I see the following kernel
panic . Trace shown as below .
Can you let me know your comments on this ?
<6>[ 1100.245300] Bluetooth:
<6>[ 1100.247985] Bluetooth:
<6>[ 1100.251068] Bluetooth: sock ca817360, sk cbe32e00
<6>[ 1100.263336] Bluetooth: sock ca817360, sk cbe32e00
<6>[ 1100.268524] Bluetooth: sock cbe32e00 state 4
<6>[ 1100.273468] Bluetooth: sk cbe32e00 state 4 socket ca817360
<6>[ 1100.279296] Bluetooth: parent cbe32e00
<6>[ 1100.283325] Bluetooth: sock d3832080 state 7
<6>[ 1100.287872] Bluetooth: hu db514b00 count 52 rx_state 0 rx_count 0
<6>[ 1100.294372] Bluetooth: Event packet
<6>[ 1100.298126] Bluetooth: Event header: evt 0x13 plen 5
<6>[ 1100.303375] Bluetooth: len 5 room 1078
<6>[ 1100.307403] Bluetooth: Complete data
<6>[ 1100.311218] Bluetooth: Event packet
<6>[ 1100.314941] Bluetooth: Event header: evt 0x13 plen 5
<6>[ 1100.320281] Bluetooth: hci0
<6>[ 1100.323272] Bluetooth: hdev cbe32980 len 7
<6>[ 1100.327606] Bluetooth: hci0 num_hndl 1
<6>[ 1100.331665] Bluetooth: hci0 acl 3 sco 4
<6>[ 1100.335723] Bluetooth: hci0
<6>[ 1100.338714] Bluetooth: conn (null) quote 0
<6>[ 1100.343139] Bluetooth: hci0
<6>[ 1100.346099] Bluetooth: conn (null) quote 0
<6>[ 1100.350463] Bluetooth: hci0
<6>[ 1100.353515] Bluetooth: conn (null) quote 0
<6>[ 1100.357849] Bluetooth: len 5 room 1078
<6>[ 1100.361846] Bluetooth: Complete data
<6>[ 1100.365722] Bluetooth: ACL packet
<6>[ 1100.369262] Bluetooth: ACL header: dlen 14
<6>[ 1100.373596] Bluetooth: hci0
<6>[ 1100.376586] Bluetooth: hdev cbe32980 len 7
<6>[ 1100.381011] Bluetooth: hci0 num_hndl 1
<6>[ 1100.384979] Bluetooth: hci0 acl 4 sco 4
<6>[ 1100.389038] Bluetooth: hci0
<6>[ 1100.392089] Bluetooth: conn (null) quote 0
<6>[ 1100.396453] Bluetooth: hci0
<6>[ 1100.399414] Bluetooth: conn (null) quote 0
<6>[ 1100.403839] Bluetooth: hci0
<6>[ 1100.406799] Bluetooth: conn (null) quote 0
<6>[ 1100.411163] Bluetooth: len 14 room 1076
<6>[ 1100.415283] Bluetooth: Complete data
<6>[ 1100.419097] Bluetooth: ACL packet
<6>[ 1100.422637] Bluetooth: ACL header: dlen 24
<6>[ 1100.427032] Bluetooth: hci0
<6>[ 1100.430023] Bluetooth: hdev cbe32980 len 18
<6>[ 1100.434448] Bluetooth: hci0 ACL data packet
<6>[ 1100.438934] Bluetooth: hci0 len 14 handle 0x1 flags 0x2
<6>[ 1100.444458] Bluetooth: conn d3a0f5c0 mode 0
<6>[ 1100.448913] Bluetooth: conn db5473c0 len 14 flags 0x2
<6>[ 1100.454284] Bluetooth: len 10, cid 0x0001
<6>[ 1100.458557] Bluetooth: conn db5473c0
<6>[ 1100.462341] Bluetooth: code 0x05 len 6 id 0x02
<6>[ 1100.467132] Bluetooth: scid 0x0040 flags 0x00 result 0x00
<6>[ 1100.472808] Bluetooth: sk d3832080, parent (null)
<6>[ 1100.477874] Bluetooth: sock d3832080 state 1
<6>[ 1100.482421] Bluetooth: len 24 room 1076
<6>[ 1100.487579] Bluetooth: sock ca817b08
<6>[ 1100.491485] Bluetooth: cmd 400448ca arg 0
<6>[ 1100.498565] Bluetooth: sk d3832080 state 1 socket (null)
<6>[ 1100.504699] Bluetooth: 0
<6>[ 1100.507415] Bluetooth: hci0 cbe32980
<6>[ 1100.511230] Bluetooth: hci0 err 0x13
<6>[ 1100.515014] Bluetooth: cache cbe32bc0
<6>[ 1100.518981] Bluetooth: hdev hci0
<6>[ 1100.522430] Bluetooth: hcon d3a0f5c0 reason 22
<6>[ 1100.527130] Bluetooth: hcon d3a0f5c0 conn db5473c0, err 103
<6>[ 1100.533081] Bluetooth: sock d3832080 state 1
<6>[ 1100.537597] Bluetooth: sk d3832080, conn db5473c0, err 103
<6>[ 1100.543487] Bluetooth: sk d3832080 state 9
<6>[ 1100.547821] Bluetooth: sk d3832080
<6>[ 1100.551452] Bluetooth: hcon d3a0f5c0 reason 22
<6>[ 1100.556213] Bluetooth: hci0 conn d3a0f5c0 handle 1
<6>[ 1100.561279] Bluetooth: conn d3a0f5c0
<1>[ 1100.566925] Unable to handle kernel paging request at virtual address
6b6b6b6b
<1>[ 1100.574584] pgd = c0004000
<1>[ 1100.577453] [6b6b6b6b] *pgd=00000000
<0>[ 1100.581420] Internal error: Oops: 5 [#1] PREEMPT
<0>[ 1100.586303] last sysfs file:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
<4>[ 1100.594573] Modules linked in: em_u32 sch_htb cls_u32 act_police
sch_ingress act_mirred ifb sec
<4>[ 1100.604522] CPU: 0 Tainted: G W (2.6.32.9-g09b2432-dirty
#1)
<4>[ 1100.611602] PC is at release_sock+0x60/0xf0
<4>[ 1100.616088] LR is at release_sock+0x18/0xf0
<4>[ 1101.576324] [<c0309930>] (release_sock+0x60/0xf0) from [<c03e9f40>]
(__l2cap_sock_close+0x8c/0x31c)
<4>[ 1101.585876] [<c03e9f40>] (__l2cap_sock_close+0x8c/0x31c) from
[<c03ed9b4>] (l2cap_sock_shutdown+0x5c/0xa0)
<4>[ 1101.596069] [<c03ed9b4>] (l2cap_sock_shutdown+0x5c/0xa0) from
[<c03eda2c>] (l2cap_sock_release+0x34/0x90)
<4>[ 1101.606170] [<c03eda2c>] (l2cap_sock_release+0x34/0x90) from
[<c0307ccc>] (sock_release+0x20/0xb0)
<4>[ 1101.615570] [<c0307ccc>] (sock_release+0x20/0xb0) from [<c0307d7c>]
(sock_close+0x20/0x2c)
<4>[ 1101.624267] [<c0307d7c>] (sock_close+0x20/0x2c) from [<c00c978c>]
(__fput+0x11c/0x218)
<4>[ 1101.632659] [<c00c978c>] (__fput+0x11c/0x218) from [<c00c65a8>]
(filp_close+0x6c/0x78)
<4>[ 1101.641052] [<c00c65a8>] (filp_close+0x6c/0x78) from [<c0068f38>]
(put_files_struct+0x88/0xf0)
<4>[ 1101.650085] [<c0068f38>] (put_files_struct+0x88/0xf0) from
[<c006a7bc>] (do_exit+0x1b0/0x698)
<4>[ 1101.659088] [<c006a7bc>] (do_exit+0x1b0/0x698) from [<c006ad54>]
(do_group_exit+0xb0/0xdc)
<4>[ 1101.667846] [<c006ad54>] (do_group_exit+0xb0/0xdc) from [<c006ad90>]
(sys_exit_group+0x10/0x18)
<4>[ 1101.677032] [<c006ad90>] (sys_exit_group+0x10/0x18) from [<c0034f40>]
(ret_fast_syscall+0x0/0x2c)
On Fri, Mar 19, 2010 at 2:03 PM, Andrei Emeltchenko <
andrei.emeltchenko.news@gmail.com> wrote:
> Hi,
>
> On Tue, Mar 9, 2010 at 9:31 AM, Nick Pelly <npelly@google.com> wrote:
> > On Mon, Mar 8, 2010 at 11:19 PM, Ville Tervo <ville.tervo@nokia.com>
> wrote:
> >> Tervo Ville (Nokia-D/Helsinki) wrote:
> >>>
> >>> l2cap socket status might change while rfcomm is processing frames. And
> >>> that makes rfcomm_process_rx to do double rfcomm_session_put() for
> incoming
> >>> session reference. We cannot use sk_state.
> >>>
> >>> Could you try with this patch if it helps to your problems also? My OPP
> >>> problems went away with this patch.
> >>>
> >>> I moved rfcomm_session_put() for incoming session to
> rfcomm_session_close
> >>> in order to get more clear _hold()/_put() pairs.
> >>>
> >>>
> >>
> >> Any comments about the patch in previous mail?
> >
> > Your patch looks sane to me, although I know enough of the Bluez
> > rfcomm state machine to know that I don't know it that well :)
>
> We have tested this patch and it looks to be working. Shall we apply it?
>
> Regards,
> Andrei
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: Type: text/html, Size: 8861 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix handling nco affiliation fields
From: Anderson Lizardo @ 2010-10-29 12:46 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1288344619-18133-1-git-send-email-lucas.pawlik@gmail.com>
On Fri, Oct 29, 2010 at 5:30 AM, Lukasz Pawlik <lucas.pawlik@gmail.com> wrote:
> Previously when contact record was divided into separate replies,
> phonebook-tracker would use first reply and merge only phone numbers,
> addresses and emails from next. Now it's merging all fields dependent on the
> nco:hasAffiliation as well.
> ---
> plugins/phonebook-tracker.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index 96290a4..f37ed5a 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -982,6 +982,14 @@ static void add_phone_number(struct phonebook_contact *contact,
> contact->numbers = g_slist_append(contact->numbers, number);
> }
>
> +static void add_affiliation(char **field, const char *value)
> +{
> + if(strlen(*field) != 0 || value == NULL || strlen(value) == 0)
> + return;
Is *field always non-NULL ? If yes, then the next g_strdup() will leak
one byte (the "\0"). If not, strlen() will segfault on a NULL pointer.
> +
> + *field = g_strdup(value);
> +}
> +
> static struct phonebook_email *find_email(GSList *emails, const char *address,
> int type)
> {
> @@ -1196,6 +1204,13 @@ add_numbers:
> g_free(home_addr);
> g_free(work_addr);
>
> + /* Adding fields connected by nco:hasAffiliation - they may be in
> + * separate replies */
> + add_affiliation(&contact->title, reply[33]);
> + add_affiliation(&contact->company, reply[22]);
> + add_affiliation(&contact->department, reply[23]);
> + add_affiliation(&contact->role, reply[24]);
> +
> DBG("contact %p", contact);
>
> /* Adding contacts data to wrapper struct - this data will be used to
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH] Fix issue when setting limited discoverable mode
From: Luiz Augusto von Dentz @ 2010-10-29 12:58 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
When setting limited discoverable mode it will always switch to
discoverable on adapter_mode_changed which doesn't match the pending mode
requested.
To fix this MODE_LIMITED was removed since it didn't represent a real
scan mode but a discoverable mode so that limited discoverable and
general discoverable are now both represented by MODE_DISCOVERABLE.
Also limited bits are now set at same point the timeout start and removed
when mode change to something different then discoverable or when
discoverable timeout is removed permanently (set to 0).
---
src/adapter.c | 76 +++++++++++++++++++++++++-------------------------------
src/hcid.h | 1 -
2 files changed, 34 insertions(+), 43 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 1b03ef1..32c74d1 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -410,7 +410,6 @@ static const char *mode2str(uint8_t mode)
case MODE_CONNECTABLE:
return "connectable";
case MODE_DISCOVERABLE:
- case MODE_LIMITED:
return "discoverable";
default:
return "unknown";
@@ -425,8 +424,6 @@ static uint8_t get_mode(const bdaddr_t *bdaddr, const char *mode)
return MODE_CONNECTABLE;
else if (strcasecmp("discoverable", mode) == 0)
return MODE_DISCOVERABLE;
- else if (strcasecmp("limited", mode) == 0)
- return MODE_LIMITED;
else if (strcasecmp("on", mode) == 0) {
char onmode[14], srcaddr[18];
@@ -439,12 +436,33 @@ static uint8_t get_mode(const bdaddr_t *bdaddr, const char *mode)
return MODE_UNKNOWN;
}
+static void adapter_set_limited_discoverable(struct btd_adapter *adapter,
+ gboolean limited)
+{
+ DBG("%s", limited ? "TRUE" : "FALSE");
+
+ /* Check if limited bit needs to be set/reset */
+ if (limited)
+ adapter->wanted_cod |= LIMITED_BIT;
+ else
+ adapter->wanted_cod &= ~LIMITED_BIT;
+
+ /* If we dont need the toggling, save an unnecessary CoD write */
+ if (adapter->pending_cod ||
+ adapter->wanted_cod == adapter->current_cod)
+ return;
+
+ if (adapter_ops->set_limited_discoverable(adapter->dev_id,
+ adapter->wanted_cod, limited) == 0)
+ adapter->pending_cod = adapter->wanted_cod;
+}
+
static void adapter_remove_discov_timeout(struct btd_adapter *adapter)
{
if (!adapter)
return;
- if(adapter->discov_timeout_id == 0)
+ if (adapter->discov_timeout_id == 0)
return;
g_source_remove(adapter->discov_timeout_id);
@@ -470,33 +488,23 @@ static void adapter_set_discov_timeout(struct btd_adapter *adapter,
adapter->discov_timeout_id = 0;
}
- if (interval == 0)
+ if (interval == 0) {
+ adapter_set_limited_discoverable(adapter, FALSE);
return;
+ }
+
+ /* Set limited discoverable if pairable and interval between 0 to 60
+ sec */
+ if (adapter->pairable && interval <= 60)
+ adapter_set_limited_discoverable(adapter, TRUE);
+ else
+ adapter_set_limited_discoverable(adapter, FALSE);
adapter->discov_timeout_id = g_timeout_add_seconds(interval,
discov_timeout_handler,
adapter);
}
-static void adapter_set_limited_discoverable(struct btd_adapter *adapter,
- gboolean limited)
-{
- /* Check if limited bit needs to be set/reset */
- if (limited)
- adapter->wanted_cod |= LIMITED_BIT;
- else
- adapter->wanted_cod &= ~LIMITED_BIT;
-
- /* If we dont need the toggling, save an unnecessary CoD write */
- if (adapter->pending_cod ||
- adapter->wanted_cod == adapter->current_cod)
- return;
-
- if (adapter_ops->set_limited_discoverable(adapter->dev_id,
- adapter->wanted_cod, limited) == 0)
- adapter->pending_cod = adapter->wanted_cod;
-}
-
static struct session_req *session_ref(struct session_req *req)
{
req->refcount++;
@@ -551,9 +559,6 @@ static int adapter_set_mode(struct btd_adapter *adapter, uint8_t mode)
if (adapter->discov_timeout)
adapter_set_discov_timeout(adapter, adapter->discov_timeout);
- if (mode != MODE_LIMITED && adapter->mode == MODE_LIMITED)
- adapter_set_limited_discoverable(adapter, FALSE);
-
return 0;
}
@@ -629,11 +634,6 @@ static DBusMessage *set_discoverable(DBusConnection *conn, DBusMessage *msg,
mode = discoverable ? MODE_DISCOVERABLE : MODE_CONNECTABLE;
- if (mode == MODE_DISCOVERABLE && adapter->pairable &&
- adapter->discov_timeout > 0 &&
- adapter->discov_timeout <= 60)
- mode = MODE_LIMITED;
-
if (mode == adapter->mode)
return dbus_message_new_method_return(msg);
@@ -673,7 +673,6 @@ static DBusMessage *set_pairable(DBusConnection *conn, DBusMessage *msg,
gboolean pairable, void *data)
{
struct btd_adapter *adapter = data;
- uint8_t mode;
int err;
if (adapter->scan_mode == SCAN_DISABLED)
@@ -685,11 +684,7 @@ static DBusMessage *set_pairable(DBusConnection *conn, DBusMessage *msg,
if (!(adapter->scan_mode & SCAN_INQUIRY))
goto store;
- mode = (pairable && adapter->discov_timeout > 0 &&
- adapter->discov_timeout <= 60) ?
- MODE_LIMITED : MODE_DISCOVERABLE;
-
- err = set_mode(adapter, mode, NULL);
+ err = set_mode(adapter, MODE_DISCOVERABLE, NULL);
if (err < 0 && msg)
return failed_strerror(msg, -err);
@@ -3255,10 +3250,7 @@ void adapter_mode_changed(struct btd_adapter *adapter, uint8_t scan_mode)
ADAPTER_INTERFACE, "Pairable",
DBUS_TYPE_BOOLEAN, &pairable);
- if (discoverable && adapter->pairable && adapter->discov_timeout > 0 &&
- adapter->discov_timeout <= 60)
- adapter_set_limited_discoverable(adapter, TRUE);
- else if (!discoverable)
+ if (!discoverable)
adapter_set_limited_discoverable(adapter, FALSE);
emit_property_changed(connection, path,
diff --git a/src/hcid.h b/src/hcid.h
index 040411b..c73fe80 100644
--- a/src/hcid.h
+++ b/src/hcid.h
@@ -39,7 +39,6 @@
#define MODE_OFF 0x00
#define MODE_CONNECTABLE 0x01
#define MODE_DISCOVERABLE 0x02
-#define MODE_LIMITED 0x03
#define MODE_UNKNOWN 0xff
struct main_opts {
--
1.7.1
^ permalink raw reply related
* Re: [RFC] AVRCP 1.4 : Design proposal for future on Target Role
From: Luiz Augusto von Dentz @ 2010-10-29 13:16 UTC (permalink / raw)
To: shivendra.agrawal@stericsson.com; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikzecKtx3ib-03n3f8_2u4KF0Y+PSmEJgccEg-i@mail.gmail.com>
Hi,
On Wed, Oct 27, 2010 at 11:23 AM, shivendra.agrawal@stericsson.com
<ag.shivendra@gmail.com> wrote:
> Hi All,
>
> ST-Ericsson plans to implement the commands to support target role of
> AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
> With our initial discussion, I would be aligning with BlueZ
> contributors and would propose for the ideas that has not been
> touched/developed so far, in order to have a design/implementation
> that can be accepted.
>
> As a very first, and very rough, design proposal for the BlueZ parts:
> - A new SDP record for AVRCP 1.4 would be added to inform CT of the
> version and features supported by target.
> - A new callback to accept browsing channel establishment.
> - Enhancing similar to bt_io_listen for browsing PSM.
> - A new browsing command handler
> - Incremental addition to AVRCP 1.4 commands.
>
> Any feedback is very much appreciated!
>
> Ref: Previous discussion subject: "AVRCP 1.4 : Future on Target Role"
I guess for all people that are interested in AVRCP 1.4 we can start
adding items to TODO list, to make it easier to share development
between us. Since this may be too much to handle in a single global
TODO maybe we can have a separated file like audio/TODO.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
From: Vinicius Gomes @ 2010-10-29 13:41 UTC (permalink / raw)
To: Ville Tervo; +Cc: ext Anderson Briglia, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101029104435.GQ15050@null>
Hi Ville,
On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Anderson,
>
> On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
>> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>>
>> As L2CAP packets coming over LE don't have any more encapsulation,
>> other than L2CAP, we are able to process them as soon as they arrive.
>
> Why is this change needed? Was something broken without this patch?
>
This change is needed because without it the receiving side would
always think that it was receiving continuation frames.
As the flags parameter is zero, it would fall into the "} else {"
condition, and because no frame was received before, conn->rx_len
would be zero and the frame would be discarded. Without this patch I
was seeing those "Unexpected continuation frame ..." messages on the
receiving side.
>
>
>>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>> ---
>> net/bluetooth/l2cap.c | 17 +++++++++++++++--
>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index 2bf083e..1ac44f4 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
>> static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
>> {
>> struct l2cap_conn *conn = hcon->l2cap_data;
>> + struct l2cap_hdr *hdr;
>> + int len;
>>
>> if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
>> goto drop;
>>
>> BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
>>
>> + if (hcon->type == LE_LINK) {
>> + hdr = (struct l2cap_hdr *) skb->data;
>> + len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
>> +
>> + if (len == skb->len) {
>> + /* Complete frame received */
>> + l2cap_recv_frame(conn, skb);
>> + return 0;
>> + }
>> +
>> + goto drop;
>> + }
>> +
>> if (flags & ACL_START) {
>> - struct l2cap_hdr *hdr;
>> struct sock *sk;
>> u16 cid;
>> - int len;
>>
>> if (conn->rx_len) {
>> BT_ERR("Unexpected start frame (len %d)", skb->len);
>> --
>> 1.7.0.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Ville
>
Cheers,
--
Vinicius
^ 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