* [RFC] Bluetooth: Provide access to reassembled Rx packets
From: Suraj Sumangala @ 2010-07-26 6:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
Provide the HCI transport driver access to reassembled Rx packets before
sending to Host.
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 350b3e6..769530b 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -156,6 +156,7 @@ struct hci_dev {
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
int (*send)(struct sk_buff *skb);
+ int (*recv)(struct hci_dev *hdev, struct sk_buff *skb);
void (*destruct)(struct hci_dev *hdev);
void (*notify)(struct hci_dev *hdev, unsigned int evt);
int (*ioctl)(struct hci_dev *hdev, unsigned int cmd, unsigned long arg);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 995c9f9..8d74f9d 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1132,6 +1132,10 @@ static int hci_reassembly(struct hci_dev *hdev, int type, void *data,
/* Complete frame */
bt_cb(skb)->pkt_type = type;
+
+ if (hdev->recv)
+ hdev->recv(hdev, skb);
+
hci_recv_frame(skb);
hdev->reassembly[index] = NULL;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2] watch: Free service data in service_reply
From: Zhenhua Zhang @ 2010-07-26 1:11 UTC (permalink / raw)
To: linux-bluetooth
Avoid the memory leak of server_data.
---
gdbus/watch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gdbus/watch.c b/gdbus/watch.c
index 1d479fa..29f23e2 100644
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -533,7 +533,7 @@ static void check_service(DBusConnection *connection, const char *name,
goto done;
}
- dbus_pending_call_set_notify(call, service_reply, data, NULL);
+ dbus_pending_call_set_notify(call, service_reply, data, g_free);
dbus_pending_call_unref(call);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v4 0/5] Enhanced support for extended inquiry response
From: ingas @ 2010-07-25 22:48 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, rshaffer, marcel
In-Reply-To: <20100723084300.GA14443@jh-x301>
Hi Johan,
> Hi,
>
> On Fri, Jul 23, 2010, Johan Hedberg wrote:
>> On Fri, Jul 23, 2010, Johan Hedberg wrote:
>> > Could you explain to me why this is needed. With the current git
>> > (without your patches) the local EIR data seems to be correctly
>> updated
>> > whenever the SDP database changes. Are there some scenarios when this
>> > doesn't happen? I did a quick test with sdptool add/del while
>> bluetoothd
>> > was running and I could see the appropriate "Write Extended Inquiry
>> > Response" commands with hcidump.
>>
>> It seems currently this only happens when a local record change causes
>> the service class bits of the class of device to be updated too. If the
>> record change doesn't affect the class of device then it seems the EIR
>> data isn't modified accordingly. Is this correct? If so, could you
>> please add that information to your commit message so that it's clear
>> why the patch is needed.
>
> Even with your patch it seems this still doesn't work. If I I don't have
> any OBEX servers running and I do "sdptool add OPUSH" I get the
> apropriate EIR update with the OPP UUID (0x1105) added to the list, but
> if I do a consecutive "sdptool add FTP" 0x1106 doesn't get added even
> though it should. Then when I do sdptool del for the OPP record the UUID
> doesn't get removed from the EIR data. So it seems some things still
> need fixing.
>
> Also, could you somehow try to avoid the multiple "Write Extended
> Inquiry Response" commands while bluetoothd is probing drivers for an
> adapter that entered the UP state? With the class of device this is done
> through adapter->cache_enable, so maybe some more generic system could
> be used for all HCI trafic related to probing drivers.
>
> Johan
>
Thank you for your comments.
It seems my comment for this patch submisiion was not specific enough (my
apologies). The extended support for EIR update was meant for the cases
when d-bus methods "AddRecord", "RemoveRecord" and "Update Record" were
called. I did verify the problems that you indicated in EIR update when
using sdptool. However, this is a pre-existing condition not related to
the extensions that I submitted. sdptool uses different mechanism for EIR
update that was not affected by my changes. That needs to be fixed in a
separate patch set, IMO.
Testing of EIR being updated when calling the above mentioned d-bus
methods can be done using d-feet interface to call the methods with
subsequent call to hcitool to execute "Read EIR" command ($hcitool -i
hci<n> cmd 0x03 0x0051).
I do need to change the comments on the patches to expalin better what has
been added. Will that be sufficient?
Regards,
Inga
^ permalink raw reply
* Re: [PATCH] watch: Free service data in service_reply
From: Johan Hedberg @ 2010-07-25 19:52 UTC (permalink / raw)
To: Zhenhua Zhang; +Cc: linux-bluetooth
In-Reply-To: <1279964787-3989-1-git-send-email-zhenhua.zhang@intel.com>
Hi,
On Sat, Jul 24, 2010, Zhenhua Zhang wrote:
> Avoid the memory leak of server_data.
> ---
> gdbus/watch.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/gdbus/watch.c b/gdbus/watch.c
> index 1d479fa..ccdbb64 100644
> --- a/gdbus/watch.c
> +++ b/gdbus/watch.c
> @@ -468,8 +468,10 @@ static void service_reply(DBusPendingCall *call, void *user_data)
> dbus_bool_t has_owner;
>
> reply = dbus_pending_call_steal_reply(call);
> - if (reply == NULL)
> + if (reply == NULL) {
> + g_free(data);
> return;
> + }
>
> dbus_error_init(&error);
>
> @@ -490,6 +492,7 @@ static void service_reply(DBusPendingCall *call, void *user_data)
>
> done:
> dbus_message_unref(reply);
> + g_free(data);
> }
>
> static void check_service(DBusConnection *connection, const char *name,
Thanks for the patch, but wouldnt't the following be simpler:
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -533,7 +533,7 @@ static void check_service(DBusConnection *connection, const char *name,
goto done;
}
- dbus_pending_call_set_notify(call, service_reply, data, NULL);
+ dbus_pending_call_set_notify(call, service_reply, data, g_free);
dbus_pending_call_unref(call);
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use hci_recv_stream_fragment() in UART driver
From: Marcel Holtmann @ 2010-07-25 18:43 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <20100724044856.GB9787@vigoh>
Hi Gustavo,
> > Use the new hci_recv_stream_fragment() to reassembly incoming UART
> > streams.
> >
> > Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> > ---
> > drivers/bluetooth/hci_h4.c | 103 +-------------------------------------------
> > 1 files changed, 2 insertions(+), 101 deletions(-)
> >
>
> Please, can someone test this code? I don't have such UART hardware to
> make sure that this patch is working.
I think that Johan or Claudio can test this easily with their LE dongles
since they only talk H4 anyway.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Defer SCO setup if mode change is pending
From: Marcel Holtmann @ 2010-07-25 18:41 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4C49B7B5.9040802@codeaurora.org>
Hi Ron,
> >> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >> index 6c57fc7..9aee8c5 100644
> >> --- a/net/bluetooth/hci_event.c
> >> +++ b/net/bluetooth/hci_event.c
> >> @@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
> >>
> >> BT_DBG("%s status 0x%x", hdev->name, status);
> >>
> >> - if (!status)
> >> - return;
> >> -
> >> cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
> >> if (!cp)
> >> return;
> >> @@ -785,8 +782,15 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
> >> hci_dev_lock(hdev);
> >>
> >> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
> >> - if (conn)
> >> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> >> + if (conn) {
> >> + if (status) {
> >> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> >> +
> >> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
> >> + &conn->pend))
> >> + hci_sco_setup(conn, status);
> >> + }
> >> + }
> >>
> >> hci_dev_unlock(hdev);
> >> }
> >
> > this change now makes it worse, please revert to initial
> >
> > if (!status)
> > return;
> >
> > check at the top and the just do
> >
> > if (conn) {
> > clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> >
> > if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
> > hci_sco_setup(conn, status);
> > }
> >
> > The only reason why I moved the status check down, because I was not
> > thinking straight and overlooked that in case of success we don't wanna
> > do a single thing here.
>
> Makes sense. Done.
>
> >
> >> @@ -798,9 +802,6 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
> >>
> >> BT_DBG("%s status 0x%x", hdev->name, status);
> >>
> >> - if (!status)
> >> - return;
> >> -
> >> cp = hci_sent_cmd_data(hdev, HCI_OP_EXIT_SNIFF_MODE);
> >> if (!cp)
> >> return;
> >> @@ -808,8 +809,15 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
> >> hci_dev_lock(hdev);
> >>
> >> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
> >> - if (conn)
> >> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> >> + if (conn) {
> >> + if (status) {
> >> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> >> +
> >> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
> >> + &conn->pend))
> >> + hci_sco_setup(conn, status);
> >> + }
> >> + }
> >>
> >> hci_dev_unlock(hdev);
> >> }
> >
> > Same applies here btw.
>
> Same. Done.
>
> >
> >> @@ -915,20 +923,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
> >> } else
> >> conn->state = BT_CLOSED;
> >>
> >> - if (conn->type == ACL_LINK) {
> >> - struct hci_conn *sco = conn->link;
> >> - if (sco) {
> >> - if (!ev->status) {
> >> - if (lmp_esco_capable(hdev))
> >> - hci_setup_sync(sco, conn->handle);
> >> - else
> >> - hci_add_sco(sco, conn->handle);
> >> - } else {
> >> - hci_proto_connect_cfm(sco, ev->status);
> >> - hci_conn_del(sco);
> >> - }
> >> - }
> >> - }
> >> + if (conn->type == ACL_LINK)
> >> + hci_sco_setup(conn, ev->status);
> >>
> >> if (ev->status) {
> >> hci_proto_connect_cfm(conn, ev->status);
> >> @@ -1478,6 +1474,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
> >> conn->power_save = 1;
> >> else
> >> conn->power_save = 0;
> >> + } else if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
> >> + &conn->pend)) {
> >> + hci_sco_setup(conn, ev->status);
> >> }
> >> }
> >
> > Please don't do else if here. Just add a separate check like I had in my
> > initial patch. We don't wanna depend on two flags pending flags set
> > here. If the SCO setup is pending, then we execute it. No matter how we
> > reached that point. It is important that even if we receive a mode
> > change without us triggering it, that we clear any potential SCO pending
> > flag.
>
> Hmmm. I know I found a bug here, but I can't remember how it manifested
> itself. Today, I can't reproduce it, so either I was seeing things or
> I'm losing it.
>
> I'll revert it back, and if I run across the issue again, we can fix it
> later.
please send v3 of this patch then.
Regards
Marcel
^ permalink raw reply
* Re: Virtual cable unplug not supported in BlueZ?
From: Liang Bao @ 2010-07-25 14:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikgDEY67+bvfd78gD1EV2AigDti-3MQ3FeSgYsE@mail.gmail.com>
2010/7/23 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi,
>
> On Fri, Jul 23, 2010 at 5:03 AM, Liang Bao <tim.bao@gmail.com> wrote:
>> Adapter.RemoveDevice() also removes the pair information according to
>> the document doc/adapter-api.txt. However, unplug a virtual cable in
>> HID spec doesn't mean unpair. Anyway, let me check the source once
>> again. Thanks.
>
> The question is, why do you want to use virtual cable unplug manually?
> There doesn't seems to be any useful use case for that, there is no
> "Virtual Cable Plug" either so if we do export virtual cable unplug
> feature how we plug it again?
Yes, I agree with that virtual plug looks like something hard to
understand to an end-user. User will be happy as long as he can
connect and disconnect. However, virtual plug is defined by the HID
spec as a mandatory requirement for HID host role.By my understanding,
this is just to gracefully to remove the 1:1 relationship between the
HID device and host. Because unplug doesn't mean unpair, the
reconnection procedure still work and then they "plug" again. Maybe we
can do a unplug using hidd in command line..?
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
^ permalink raw reply
* [PATCH] Driver-core: Always create class directories for classses that support namespaces.
From: Eric W. Biederman @ 2010-07-25 5:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, Kay Sievers, Andrew Morton, Greg KH,
Rafael J. Wysocki, Maciej W. Rozycki, netdev,
<linux-kernel@vger.kernel.org> Marcel Holtmann,
linux-bluetooth, Greg KH
In-Reply-To: <20100722185449.GB528@suse.de>
This fixes the regression in 2.6.35-rcX where bluetooth network devices would
fail to be deleted from sysfs, causing their destruction and recreation to
fail. In addition this fixes the mac80211_hwsim driver where it would leave
around sysfs files when the driver was removed. This problem is discussed at
https://bugzilla.kernel.org/show_bug.cgi?id=16257
The reason for the regression is that the network namespace support added to
sysfs expects and requires that network devices be put in directories that can
contain only network devices. Today get_device_parent almost provides that
guarantee for all class devices, except for a specific exception when the
parent of a class devices is a class device. It would be nice to simply
remove that arguably incorrect special case, but apparently the input devices
depend on it being there. So I have only removed it for class devices with
network namespace support. Which today are the network devices.
It has been suggested that a better fix would be to change the parent device
from a class device to a bus device, which in the case of the bluetooth driver
would change /sys/class/bluetooth to /sys/bus/bluetoth, I can not see how we
would avoid significant userspace breakage if we were to make that change.
Adding an extra directory in the path to the device will also be userspace
visible but it is much less likely to break things. Everything is still
accessible from /sys/class (for example), and it fixes two bugs. Adding an
extra directory fixes a 3 year old regression introduced with the new sysfs
layout that makes if impossible to rename bnep0 network devices to names that
conflict with hci device attributes like hci_revsion. Adding an additional
directory remove the new failure modes introduced by the network namespace
code.
If it weren't for the regession in the renaming of network devices I would
figure out how to just make the sysfs code deal with this configuration of
devices.
In summary this patch fixes regressions by changing:
"/sys/class/bluetooth/hci0/bnep0" to "/sys/class/bluetooth/hci0/net/bnep0".
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
p.s. Linus my apologies for sending this directly but I have gotten an
incredible amount of flak trying to fix this problem, and I would like
not to leave an accidental regression whose cause is well known in
2.6.35 if I can help it.
drivers/base/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 9630fbd..9b9d3bd 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -673,7 +673,7 @@ static struct kobject *get_device_parent(struct device *dev,
*/
if (parent == NULL)
parent_kobj = virtual_device_parent(dev);
- else if (parent->class)
+ else if (parent->class && !dev->class->ns_type)
return &parent->kobj;
else
parent_kobj = &parent->kobj;
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Use hci_recv_stream_fragment() in UART driver
From: Suraj @ 2010-07-24 16:30 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-bluetooth@vger.kernel.org, marcel@holtmann.org,
Gustavo F. Padovan
In-Reply-To: <20100724044856.GB9787@vigoh>
Hi Gustavo,
On 7/24/2010 10:18 AM, Gustavo F. Padovan wrote:
> * Gustavo F. Padovan<gustavo@padovan.org> [2010-07-24 01:46:57 -0300]:
>
>> From: Gustavo F. Padovan<padovan@profusion.mobi>
>>
>> Use the new hci_recv_stream_fragment() to reassembly incoming UART
>> streams.
>>
>> Signed-off-by: Gustavo F. Padovan<padovan@profusion.mobi>
>> ---
>> drivers/bluetooth/hci_h4.c | 103 +-------------------------------------------
>> 1 files changed, 2 insertions(+), 101 deletions(-)
>>
>
> Please, can someone test this code? I don't have such UART hardware to
> make sure that this patch is working.
>
I have tested the reassembly code on HCI_ATH3K driver. But, It would be
great if someone can verify it on a different serial Bluetooth controller.
Regards
Suraj
^ permalink raw reply
* Re: [PATCH] Bluetooth: Update L2CAP version after enable ERTM by default
From: Marcel Holtmann @ 2010-07-24 13:47 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1279949837-19944-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> Enable ERTM by default is a big change in the code, so changing the
> version here.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/l2cap.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
actually no. We only increase the version number once per merge cycle
and I already have patch that does that.
Regards
Marcel
^ permalink raw reply
* [PATCH] watch: Free service data in service_reply
From: Zhenhua Zhang @ 2010-07-24 9:46 UTC (permalink / raw)
To: linux-bluetooth
Avoid the memory leak of server_data.
---
gdbus/watch.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gdbus/watch.c b/gdbus/watch.c
index 1d479fa..ccdbb64 100644
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -468,8 +468,10 @@ static void service_reply(DBusPendingCall *call, void *user_data)
dbus_bool_t has_owner;
reply = dbus_pending_call_steal_reply(call);
- if (reply == NULL)
+ if (reply == NULL) {
+ g_free(data);
return;
+ }
dbus_error_init(&error);
@@ -490,6 +492,7 @@ static void service_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ g_free(data);
}
static void check_service(DBusConnection *connection, const char *name,
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Bluetooth: Update L2CAP version after enable ERTM by default
From: Gustavo F. Padovan @ 2010-07-24 5:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
Enable ERTM by default is a big change in the code, so changing the
version here.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9ba1e8e..273aba9 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -55,7 +55,7 @@
#include <net/bluetooth/hci_core.h>
#include <net/bluetooth/l2cap.h>
-#define VERSION "2.15"
+#define VERSION "2.16"
static int disable_ertm = 0;
--
1.7.1.1
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Add __init and __exit marks to RFCOMM
From: Gustavo F. Padovan @ 2010-07-24 5:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
In-Reply-To: <1279947885-19304-1-git-send-email-gustavo@padovan.org>
From: Gustavo F. Padovan <padovan@profusion.mobi>
Those annotation save memory and space on the binary. __init code is
discarded just after execute and __exit code is discarded if the module is
built into the kernel image or unload of modules is not allowed.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/rfcomm/sock.c | 2 +-
net/bluetooth/rfcomm/tty.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 43fbf6b..44a6232 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -1152,7 +1152,7 @@ error:
return err;
}
-void rfcomm_cleanup_sockets(void)
+void __exit rfcomm_cleanup_sockets(void)
{
debugfs_remove(rfcomm_sock_debugfs);
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 309b6c2..026205c 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -1153,7 +1153,7 @@ static const struct tty_operations rfcomm_ops = {
.tiocmset = rfcomm_tty_tiocmset,
};
-int rfcomm_init_ttys(void)
+int __init rfcomm_init_ttys(void)
{
rfcomm_tty_driver = alloc_tty_driver(RFCOMM_TTY_PORTS);
if (!rfcomm_tty_driver)
@@ -1183,7 +1183,7 @@ int rfcomm_init_ttys(void)
return 0;
}
-void rfcomm_cleanup_ttys(void)
+void __exit rfcomm_cleanup_ttys(void)
{
tty_unregister_driver(rfcomm_tty_driver);
put_tty_driver(rfcomm_tty_driver);
--
1.7.1.1
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: Add __init and __exit marks to UART drivers
From: Gustavo F. Padovan @ 2010-07-24 5:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
Those marks are useful to save space in the binary and in the memory.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
drivers/bluetooth/hci_ath.c | 4 ++--
drivers/bluetooth/hci_bcsp.c | 4 ++--
drivers/bluetooth/hci_h4.c | 4 ++--
drivers/bluetooth/hci_ll.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index 5ab258b..b941dd5 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -217,7 +217,7 @@ static struct hci_uart_proto athp = {
.flush = ath_flush,
};
-int ath_init(void)
+int __init ath_init(void)
{
int err = hci_uart_register_proto(&athp);
@@ -229,7 +229,7 @@ int ath_init(void)
return err;
}
-int ath_deinit(void)
+int __exit ath_deinit(void)
{
return hci_uart_unregister_proto(&athp);
}
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index 42d69d4..9c5b2dc 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -739,7 +739,7 @@ static struct hci_uart_proto bcsp = {
.flush = bcsp_flush
};
-int bcsp_init(void)
+int __init bcsp_init(void)
{
int err = hci_uart_register_proto(&bcsp);
@@ -751,7 +751,7 @@ int bcsp_init(void)
return err;
}
-int bcsp_deinit(void)
+int __exit bcsp_deinit(void)
{
return hci_uart_unregister_proto(&bcsp);
}
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index b2cf50e..7b8ad93 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -173,7 +173,7 @@ static struct hci_uart_proto h4p = {
.flush = h4_flush,
};
-int h4_init(void)
+int __init h4_init(void)
{
int err = hci_uart_register_proto(&h4p);
@@ -185,7 +185,7 @@ int h4_init(void)
return err;
}
-int h4_deinit(void)
+int __exit h4_deinit(void)
{
return hci_uart_unregister_proto(&h4p);
}
diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 5744aba..38595e7 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -517,7 +517,7 @@ static struct hci_uart_proto llp = {
.flush = ll_flush,
};
-int ll_init(void)
+int __init ll_init(void)
{
int err = hci_uart_register_proto(&llp);
@@ -529,7 +529,7 @@ int ll_init(void)
return err;
}
-int ll_deinit(void)
+int __exit ll_deinit(void)
{
return hci_uart_unregister_proto(&llp);
}
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Use hci_recv_stream_fragment() in UART driver
From: Gustavo F. Padovan @ 2010-07-24 4:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
In-Reply-To: <1279946817-18060-1-git-send-email-gustavo@padovan.org>
* Gustavo F. Padovan <gustavo@padovan.org> [2010-07-24 01:46:57 -0300]:
> From: Gustavo F. Padovan <padovan@profusion.mobi>
>
> Use the new hci_recv_stream_fragment() to reassembly incoming UART
> streams.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> drivers/bluetooth/hci_h4.c | 103 +-------------------------------------------
> 1 files changed, 2 insertions(+), 101 deletions(-)
>
Please, can someone test this code? I don't have such UART hardware to
make sure that this patch is working.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH] Bluetooth: Use hci_recv_stream_fragment() in UART driver
From: Gustavo F. Padovan @ 2010-07-24 4:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
Use the new hci_recv_stream_fragment() to reassembly incoming UART
streams.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
drivers/bluetooth/hci_h4.c | 103 +-------------------------------------------
1 files changed, 2 insertions(+), 101 deletions(-)
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index 3f038f5..b2cf50e 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -151,107 +151,8 @@ static inline int h4_check_data_len(struct h4_struct *h4, int len)
/* Recv data */
static int h4_recv(struct hci_uart *hu, void *data, int count)
{
- struct h4_struct *h4 = hu->priv;
- register char *ptr;
- struct hci_event_hdr *eh;
- struct hci_acl_hdr *ah;
- struct hci_sco_hdr *sh;
- register int len, type, dlen;
-
- BT_DBG("hu %p count %d rx_state %ld rx_count %ld",
- hu, count, h4->rx_state, h4->rx_count);
-
- ptr = data;
- while (count) {
- if (h4->rx_count) {
- len = min_t(unsigned int, h4->rx_count, count);
- memcpy(skb_put(h4->rx_skb, len), ptr, len);
- h4->rx_count -= len; count -= len; ptr += len;
-
- if (h4->rx_count)
- continue;
-
- switch (h4->rx_state) {
- case H4_W4_DATA:
- BT_DBG("Complete data");
-
- hci_recv_frame(h4->rx_skb);
-
- h4->rx_state = H4_W4_PACKET_TYPE;
- h4->rx_skb = NULL;
- continue;
-
- case H4_W4_EVENT_HDR:
- eh = hci_event_hdr(h4->rx_skb);
-
- BT_DBG("Event header: evt 0x%2.2x plen %d", eh->evt, eh->plen);
-
- h4_check_data_len(h4, eh->plen);
- continue;
-
- case H4_W4_ACL_HDR:
- ah = hci_acl_hdr(h4->rx_skb);
- dlen = __le16_to_cpu(ah->dlen);
-
- BT_DBG("ACL header: dlen %d", dlen);
-
- h4_check_data_len(h4, dlen);
- continue;
-
- case H4_W4_SCO_HDR:
- sh = hci_sco_hdr(h4->rx_skb);
-
- BT_DBG("SCO header: dlen %d", sh->dlen);
-
- h4_check_data_len(h4, sh->dlen);
- continue;
- }
- }
-
- /* H4_W4_PACKET_TYPE */
- switch (*ptr) {
- case HCI_EVENT_PKT:
- BT_DBG("Event packet");
- h4->rx_state = H4_W4_EVENT_HDR;
- h4->rx_count = HCI_EVENT_HDR_SIZE;
- type = HCI_EVENT_PKT;
- break;
-
- case HCI_ACLDATA_PKT:
- BT_DBG("ACL packet");
- h4->rx_state = H4_W4_ACL_HDR;
- h4->rx_count = HCI_ACL_HDR_SIZE;
- type = HCI_ACLDATA_PKT;
- break;
-
- case HCI_SCODATA_PKT:
- BT_DBG("SCO packet");
- h4->rx_state = H4_W4_SCO_HDR;
- h4->rx_count = HCI_SCO_HDR_SIZE;
- type = HCI_SCODATA_PKT;
- break;
-
- default:
- BT_ERR("Unknown HCI packet type %2.2x", (__u8)*ptr);
- hu->hdev->stat.err_rx++;
- ptr++; count--;
- continue;
- };
-
- ptr++; count--;
-
- /* Allocate packet */
- h4->rx_skb = bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
- if (!h4->rx_skb) {
- BT_ERR("Can't allocate mem for new packet");
- h4->rx_state = H4_W4_PACKET_TYPE;
- h4->rx_count = 0;
- return -ENOMEM;
- }
-
- h4->rx_skb->dev = (void *) hu->hdev;
- bt_cb(h4->rx_skb)->pkt_type = type;
- }
+ if (hci_recv_stream_fragment(hu->hdev, data, count) < 0)
+ BT_ERR("Frame Reassembly Failed");
return count;
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH] Bluetooth: Test 'count' value before enter the loop
From: Gustavo F. Padovan @ 2010-07-24 4:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
Testing first we avoid enter the loop when count = 0.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/hci_core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 995c9f9..8303f1c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1149,7 +1149,7 @@ int hci_recv_fragment(struct hci_dev *hdev, int type, void *data, int count)
if (type < HCI_ACLDATA_PKT || type > HCI_EVENT_PKT)
return -EILSEQ;
- do {
+ while (count) {
rem = hci_reassembly(hdev, type, data, count,
type - 1, GFP_ATOMIC);
if (rem < 0)
@@ -1157,7 +1157,7 @@ int hci_recv_fragment(struct hci_dev *hdev, int type, void *data, int count)
data += (count - rem);
count = rem;
- } while (count);
+ };
return rem;
}
@@ -1170,7 +1170,7 @@ int hci_recv_stream_fragment(struct hci_dev *hdev, void *data, int count)
int type;
int rem = 0;
- do {
+ while (count) {
struct sk_buff *skb = hdev->reassembly[STREAM_REASSEMBLY];
if (!skb) {
@@ -1192,7 +1192,7 @@ int hci_recv_stream_fragment(struct hci_dev *hdev, void *data, int count)
data += (count - rem);
count = rem;
- } while (count);
+ };
return rem;
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH] Bluetooth: Fix permission of hci_ath.c
From: Gustavo F. Padovan @ 2010-07-24 4:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, suraj, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
.c file shall not have the 'x' permission.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100755 => 100644 drivers/bluetooth/hci_ath.c
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
old mode 100755
new mode 100644
--
1.7.1.1
^ permalink raw reply
* Re: [PATCH][RFC] Fix SDP resolving segfault
From: Luiz Augusto von Dentz @ 2010-07-23 20:37 UTC (permalink / raw)
To: Manuel Naranjo; +Cc: Johan Hedberg, BlueZ
In-Reply-To: <4C470E2D.7000607@aircable.net>
Hi,
On Wed, Jul 21, 2010 at 6:11 PM, Manuel Naranjo <manuel@aircable.net> wrote:
> I think this is the one that really fix the problem. I see connect_watch
> getting called and then getting into the crash. I have a nice log with the
> tracing feature I sent the other day, here's the end of it (the hole thing
> is almost 40 megs if someone wants just ask for it).
I just figure out that our connect_watch in glib_helper.c is not quite
right, it should be something similar as we have btio.c, specially
this one is particular important:
/* If the user aborted this connect attempt */
if ((cond & G_IO_NVAL) || check_nval(io))
return FALSE;
It is probably because of not having this check that the cb is still
called after bt_cancel_discovery. Of course this doesn't invalidate
your fix to bt_cancel_discovery itself, but I guess this should also
be included to safe that the callback is not called after cancelling
the discovery.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: How to past connect complete event status (page timeout) to apps
From: Luiz Augusto von Dentz @ 2010-07-23 20:15 UTC (permalink / raw)
To: Ed Tsang; +Cc: Bluettooth Linux
In-Reply-To: <444018.59197.qm@web52606.mail.re2.yahoo.com>
Hi,
On Fri, Jul 23, 2010 at 8:48 PM, Ed Tsang <netdesign_98@yahoo.com> wrote:
> Hi, I tried to implement my apps to do different things depend on the failed
> connection attempt.
> On Hci dump I could saw the connect complete status is different depend on the
> actual failure (e.g. 0x10 accept timeout, 0x06, PIN missing, 0x04 page
> timeout). But the apps (base on obex-client) is not able to see those status
> code.
> The obex-client attempt a sdp_connect and then g_io_add_watch. On the
> callback, we could see the G_IO_ERROR but I could not figure out a way to get
> more detail on the failed condition. I tried look into the Bluez and could not
> figure what to change to pass those connect event status up..
> Anyone could offer some advise/hint...
Well first you will not get the same error on the socket, they will be
translated to errno but the errors will be very similar e.g: page
timeout is mapped to EHOSTDOWN.
But it seems we have a bug in obex-client, basically we need to check
SO_ERROR with getsockopt before proceeding with sdp_set_notify. If you
are fixing this please have a look at btio.c, it should be ok and it
seems ofono does it in a similar fashion:
/* If the user aborted this connect attempt */
if ((cond & G_IO_NVAL) || check_nval(io))
return FALSE;
if (cond & G_IO_OUT) {
int err = 0, sock = g_io_channel_unix_get_fd(io);
socklen_t len = sizeof(err);
if (getsockopt(sock, SOL_SOCKET, SO_ERROR, &err, &len) < 0)
err = errno;
if (err)
g_set_error(&gerr, BT_IO_ERROR,
BT_IO_ERROR_CONNECT_FAILED, "%s (%d)",
strerror(err), err);
} else if (cond & (G_IO_HUP | G_IO_ERR))
g_set_error(&gerr, BT_IO_ERROR, BT_IO_ERROR_CONNECT_FAILED,
"HUP or ERR on socket");
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 6/6] pcmcia: remove cs_types.h
From: David Miller @ 2010-07-23 18:48 UTC (permalink / raw)
To: linux
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial
In-Reply-To: <1279874305-21191-6-git-send-email-linux@dominikbrodowski.net>
From: Dominik Brodowski <linux@dominikbrodowski.net>
Date: Fri, 23 Jul 2010 10:38:25 +0200
> Remove cs_types.h which is no longer needed: Most definitions aren't
> used at all, a few can be made away with, and two remaining definitions
> (typedefs, unfortunatley) may be moved to more specific places.
>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Any update on software caused connection abort issue??
From: Gustavo F. Padovan @ 2010-07-23 18:20 UTC (permalink / raw)
To: Lukas Hetzenecker; +Cc: john michelle, linux-bluetooth
In-Reply-To: <201007230144.02983.LuHe@gmx.at>
Hi Lukas,
* Lukas Hetzenecker <LuHe@gmx.at> [2010-07-23 01:44:02 +0200]:
> I also noticed these kernel messages during the disconnect in my
> /var/log/messages log
>
> Jul 22 23:52:35 erde kernel: btusb_intr_complete: hci0 urb ffff88010d409540
> failed to resubmit (1)
> Jul 22 23:52:35 erde kernel: btusb_bulk_complete: hci0 urb ffff88010d409900
> failed to resubmit (1)
> Jul 22 23:52:35 erde kernel: btusb_bulk_complete: hci0 urb ffff88010d409b40
> failed to resubmit (1)
>
> [these messages are repeated for several times, even before the disconnect]
>
> Jul 22 23:52:36 erde kernel: usb 5-1: reset full speed USB device using
> uhci_hcd and address 2
> Jul 22 23:52:36 erde kernel: btusb 5-1:1.0: no reset_resume for driver btusb?
> Jul 22 23:52:36 erde bluetoothd[1580]: HCI dev 0 down
> Jul 22 23:52:36 erde bluetoothd[1580]: Adapter /org/bluez/1574/hci0 has been
> disabled
> Jul 22 23:52:36 erde bluetoothd[1580]: Stopping security manager 0
> Jul 22 23:52:36 erde kernel: btusb 5-1:1.1: no reset_resume for driver btusb?
> Jul 22 23:52:37 erde bluetoothd[1580]: HCI dev 0 unregistered
> Jul 22 23:52:37 erde bluetoothd[1580]: Unregister path: /org/bluez/1574/hci0
> Jul 22 23:52:37 erde NetworkManager[1520]: <info> BT device 00:1B:AF:84:FF:E2
> removed
> Jul 22 23:52:37 erde bluetoothd[1580]: HCI dev 0 registered
> Jul 22 23:52:37 erde bluetoothd[1580]: HCI dev 0 up
> Jul 22 23:52:37 erde bluetoothd[1580]: Starting security manager 0
> Jul 22 23:52:37 erde bluetoothd[1580]: Parsing /etc/bluetooth/serial.conf
> failed: No such file or directory
> Jul 22 23:52:37 erde bluetoothd[1580]: probe failed with driver input-headset
> for device /org/bluez/1574/hci0/dev_00_1B_AF_84_FF_E2
> Jul 22 23:52:37 erde bluetoothd[1580]: Adapter /org/bluez/1574/hci0 has been
> enabled
>
>
> It is also strange that this error affects only my PC with an USB bluetooth
> stick, not my notebook with an integrated Intel PRO Wireless
> 4965AGN bluetooth module.
Is there any difference on the systems in both machines? And can you try
reproduce this with another Bluetooth dongle, just to make sure that the
problem is not the hardware.
>
> Do you need any more informations for debugging?
>
>
> On Thursday 22 July 2010 16:17:57 john michelle wrote:
> > Hi Lukas,
> >
> > > It would be great to see this problem fixed soon, because it's nearly
> > > impossible to use bluetooth on my PC.
> >
> > I think it's useless to get any reply from this mailing list, i have
> > been reporting this
> > Problem for a long time and no one simply cares.
> >
> > John
> >
> > On Wed, Jul 21, 2010 at 5:53 PM, Lukas <LuHe@gmx.at> wrote:
> > > Hello,
> > >
> > > On Wednesday 21 July 2010 17:35:15 john michelle wrote:
> > >> Any update on software caused connection abort issue
> > >
> > > I also noticed this error when I used the software suite Series60-Remote
> > > to connect to my mobile phone.
> > >
> > > Shortly after the connection establishment is completed I get the error
> > > message "software caused connection abort" and the device gets
> > > disconnected.
> > >
> > > I also see the HCI reset, as described below, when I try to investigate
> > > this error using hcidump.
> > >
> > > The software uses the RFCOMM protocol for the connection.
> > > I use an USB bluetooth adapter from Belkin, lsusb reports the following
> > > device id:
> > > ID 050d:0131 Belkin Components Bluetooth Device with trace filter
> > >
> > > This bug happens with the following kernel:
> > > root@erde ~ # rpm -q kernel bluez
> > > kernel-2.6.33.6-147.fc13.x86_64
> > > bluez-4.64-1.fc13.x86_64
> > >
> > > You can also look at this thread in my mailing list for further
> > > informations:
> > > https://sourceforge.net/mailarchive/forum.php?thread_name=201007192136.2
> > > 7723.LuHe%40gmx.at&forum_name=series60- remote-devel
> > >
> > > It would be great to see this problem fixed soon, because it's nearly
> > > impossible to use bluetooth on my PC.
> > >
> > > Thanks,
> > > Lukas
> > >
> > >> >>On Wed, Jun 23, 2010 at 12:48 AM, john michelle
> > >> >><jhnmichelle@gmail.com>
> > >
> > > wrote:
> > >> >> Dear Bluetooth community,
> > >> >>
> > >> >> You are committing version after version and have time to add new
> > >> >> Features and the core stack have a major bug (software Caused
> > >> >> connection abort) that i
> > >> >> Have reported on the 7th of may the problem seems to be either in the
> > >> >> usb part of the
> > >> >> Kernel or the bluez stack, i am no kernel engineer so i came directly
> > >> >> to you for reporting
> > >> >> This problem and my requests to look into this problem are just
> > >> >> ignored. this is a blocker
> > >> >> Issue that would prevent and discourage any one from developing
> > >> >> application that rely on
> > >> >> Bluez sco capabilities, since during transmission the above mentioned
> > >> >> error just occurs.
> > >> >> I hope that my voice is heared and i would get a reply from the bluez
> > >> >> community.
> > >> >>
> > >> >> John
> > >> >>
> > >> >> On Wed, Jun 16, 2010 at 3:11 PM, john michelle
> > >> >> <jhnmichelle@gmail.com>
> > >
> > > wrote:
> > >> >>> On Sun, May 30, 2010 at 1:12 PM, john michelle
> > >> >>> <jhnmichelle@gmail.com>
> > >
> > > wrote:
> > >> >>>> Hi Gustavo,
> > >> >>>>
> > >> >>>>>> Please post the output of hcidump when the connection abort
> > >> >>>>>> happens.
> > >> >>>>
> > >> >>>> Below is the output of hcidump the moments the software caused
> > >> >>>> connection abort
> > >> >>>>
> > >> >>>> Dongle 1:
> > >> >>>>> HCI Event: Number of Completed Packets (0x13) plen 5
> > >> >>>>
> > >> >>>> . * . . .
> > >> >>>> < HCI Command: Reset (0x03|0x0003) plen 0
> > >> >>>> device: disconnected
> > >> >>>>
> > >> >>>> Dongle 2:
> > >> >>>>> HCI Event: Number of Completed Packets (0x13) plen 5
> > >> >>>>
> > >> >>>> . * . . .
> > >> >>>> < HCI Command: Reset (0x03|0x0003) plen 0
> > >> >>>> device: disconnected
> > >> >>>>
> > >> >>>>
> > >> >>>> I think something triggers hci reset which causes this problem, but
> > >> >>>> what exactly Triggers it i don't know.
> > >> >>>>
> > >> >>>>
> > >> >>>> John
> > >> >>>
> > >> >>> Hi all,
> > >> >>>
> > >> >>> Is anyone going to give this problem a try, it has been like a month
> > >> >>> now This is a real problem in the bluez stack and someone have to
> > >> >>> look in this Issue.
> > >> >>>
> > >> >>> John
> > >> >>>
> > >> >>>> On Mon, May 17, 2010 at 5:21 PM, john michelle
> > >> >>>> <jhnmichelle@gmail.com>
> > >
> > > wrote:
> > >> >>>>>> Hi Jonh,
> > >> >>>>>>
> > >> >>>>>> First of all, don't do top posting in this mailing list. ;)
> > >> >>>>>
> > >> >>>>> Thanks for the advise , will keep that in mind for future posts.
> > >> >>>>>
> > >> >>>>>> In which bluez/kernel version the problem started? Any hardware
> > >> >>>>>> update during this time? The problem happens when you are already
> > >> >>>>>> tranfering SCO data?
> > >> >>>>>
> > >> >>>>> I tried bluez versions 3.XX and kernel 2.6.26(I think) the
> > >> >>>>> problem occurs and the kernel panics with no core dumps.then i
> > >> >>>>> tried with bluez 4.53-4.62 with
> > >> >>>>> Kernel 2.6.31 and 2.6.32. the connection abort problem occurs but
> > >> >>>>> the kernel doesn't
> > >> >>>>> Panic. regarding the hardware update you mean the dongle or the
> > >> >>>>> box.Anyway i changed both and tried different box's, this even
> > >> >>>>> happens on a box with 2 giga ram
> > >> >>>>> And core2 processor . as for the dongles i am using trust
> > >> >>>>>
> > >> >>>>> http://www.twenga.co.uk/prices-Bluetooth-2-USB-Adapter-10m-BT-2250
> > >> >>>>> p-T RUST-Wireless-network-card-adapter-176178-0
> > >> >>>>>
> > >> >>>>> and also using no name dongles all the same problem.
> > >> >>>>>
> > >> >>>>>> Please post the output of hcidump when the connection abort
> > >> >>>>>> happens.
> > >> >>>>>
> > >> >>>>> well that is going to be a hard one since i have more than one
> > >> >>>>> dongle in place And very hard to predict which one will crash.i
> > >> >>>>> will work on this and update You as soon as i have the hcidump
> > >> >>>>> log.
> > >> >>>>>
> > >> >>>>>> I tried reproduce this issue in L2CAP but it is a bit hard, lets
> > >> >>>>>> say it happen once in a thousand, so it's not easy to track it. I
> > >> >>>>>> have to try reproduce that using the SCO, but I'm not used to
> > >> >>>>>> that layer yet. ;)
> > >> >>>>>
> > >> >>>>> I hoped that it happens 1 in 1000 in SCO , but it actually happens
> > >> >>>>> 1 in 15
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> John
> > >> >>>>>
> > >> >>>>>> Regards,
> > >> >>>>>>
> > >> >>>>>>> John
> > >> >>>>>>>
> > >> >>>>>>> On Fri, May 7, 2010 at 3:53 PM, Gustavo F. Padovan
> > >
> > > <gustavo@padovan.org> wrote:
> > >> >>>>>>> > * john michelle <jhnmichelle@gmail.com> [2010-05-07 15:49:05
> > >
> > > -0400]:
> > >> >>>>>>> >> Hi Bluetooth hackers,
> > >> >>>>>>> >>
> > >> >>>>>>> >> i am having this consistent problem with bluez , from time to
> > >> >>>>>>> >> time i get the error Software caused connection abort (103 )
> > >> >>>>>>> >> And the bluetooth stick seems to disconnect and reconnects.
> > >> >>>>>>> >> this happens during an sco connection and it occurs even
> > >> >>>>>>> >> More when i am having the voice stream comming through the
> > >> >>>>>>> >> internet rather than the lan.i don't know what exact
> > >> >>>>>>> >> Details you need to solve this problem please tell me and i
> > >> >>>>>>> >> will give you an immediate reply . i have linux kernel
> > >> >>>>>>> >> 2.6.33 and bluez 4.62
> > >> >>>>>>> >
> > >> >>>>>>> > I get the same problem sometimes when testing ERTM with
> > >> >>>>>>> > l2test. So the problem is on l2cap too. I didn't have time to
> > >> >>>>>>> > debug this yet. Now that someone else have confirmed it too,
> > >> >>>>>>> > I'll to take a look at the problem.
> > >> >>>>>>
> > >> >>>>>> --
> > >> >>>>>> Gustavo F. Padovan
> > >> >>>>>> http://padovan.org
> > >>
> > >> --
> > >> 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
> >
> > --
> > 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
> --
> 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
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [patch -next] bluetooth/hci_ath: kfree() => kfree_skb()
From: Gustavo F. Padovan @ 2010-07-23 18:10 UTC (permalink / raw)
To: Dan Carpenter
Cc: Marcel Holtmann, Suraj Sumangala, linux-bluetooth,
kernel-janitors
In-Reply-To: <20100723101104.GD26313@bicker>
Hi Dan,
* Dan Carpenter <error27@gmail.com> [2010-07-23 12:11:04 +0200]:
> sk_buffs have to be freed with kfree_skb() instead of kfree().
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
> index 5ab258b..74a8f61 100755
> --- a/drivers/bluetooth/hci_ath.c
> +++ b/drivers/bluetooth/hci_ath.c
> @@ -163,7 +163,7 @@ static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> struct ath_struct *ath = hu->priv;
>
> if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) {
> - kfree(skb);
> + kfree_skb(skb);
> return 0;
> }
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 18/60] Implement function to send md_abort_mdl_req
From: Gustavo F. Padovan @ 2010-07-23 18:07 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <4C495FE9.7010802@libresoft.es>
Hi Santiago,
* Santiago Carot-Nemesio <scarot@libresoft.es> [2010-07-23 11:24:57 +0200]:
> Hi,
> On 07/23/10 02:07, Gustavo F. Padovan wrote:
> > Hi Santiago,
> >
> > * Santiago Carot-Nemesio<sancane@gmail.com> [2010-07-22 10:52:13 +0200]:
> >
> >
> >> ---
> >> mcap/mcap.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 files changed, 48 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/mcap/mcap.c b/mcap/mcap.c
> >> index 5419d54..6f6e08a 100644
> >> --- a/mcap/mcap.c
> >> +++ b/mcap/mcap.c
> >> @@ -519,6 +519,38 @@ void mcap_req_mdl_deletion(struct mcap_mdl *mdl, GError **err,
> >> g_free(con);
> >> }
> >>
> >> +void mcap_mdl_abort(struct mcap_mdl *mdl, GError **err,
> >> + mcap_mdl_del_cb abort_cb, gpointer user_data)
> >> +{
> >> + struct mcap_mdl_op_cb *con;
> >> + struct mcap_mcl *mcl = mdl->mcl;
> >> + uint8_t *cmd;
> >> +
> >> + if (mdl->state != MDL_WAITING) {
> >> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_FAILED,
> >> + "Mdl in invalid state");
> >> + return;
> >> + }
> >> +
> >> + con = g_new0(struct mcap_mdl_op_cb, 1);
> >> + cmd = create_req(MCAP_MD_ABORT_MDL_REQ, mdl->mdlid);
> >> + mcap_send_std_opcode(mcl, cmd, sizeof(mcap_md_req), err);
> >> + if (*err) {
> >> + g_free(con);
> >> + g_free(cmd);
> >> + return;
> >> + }
> >> +
> >> + con->mdl = mdl;
> >> + con->cb.del = abort_cb;
> >> + con->user_data = user_data;
> >> +
> >> + mcl->priv_data = con;
> >> +
> >> + mcl->tid = g_timeout_add_seconds(RESPONSE_TIMER, wait_response_timer,
> >> + mcl);
> >> +}
> >> +
> >> static void update_mcl_state(struct mcap_mcl *mcl)
> >> {
> >> GSList *l;
> >> @@ -554,6 +586,22 @@ static struct mcap_mcl *find_mcl(GSList *list, const bdaddr_t *addr)
> >> return NULL;
> >> }
> >>
> >> +int mcap_mdl_get_fd(struct mcap_mdl *mdl)
> >> +{
> >> + if ((!mdl) || (mdl->state != MDL_CONNECTED))
> >> + return -1;
> >>
> > A proper Unix error is better than -1 here.
> >
> Patch 58 fix that.
So merge 58 into this one.. ;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Gustavo F. Padovan @ 2010-07-23 18:05 UTC (permalink / raw)
To: Santiago Carot-Nemesio
Cc: Elvis Pfützenreuter, José Antonio Santos Cadenas,
Luiz Augusto von Dentz, Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <4C49CEB5.60600@libresoft.es>
Hi Santiago,
* Santiago Carot-Nemesio <scarot@libresoft.es> [2010-07-23 19:17:41 +0200]:
> Hi,
> On 07/23/10 13:30, Elvis Pfützenreuter wrote:
> > On 23/07/2010, at 07:44, José Antonio Santos Cadenas wrote:
> >
> >
> >> Hi,
> >>
> >> El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió:
> >>
> >>> Hi,
> >>>
> >>> On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg<johan.hedberg@gmail.com>
> >>>
> >> wrote:
> >>
> >>>> The SDP code in libbluetooth is probably the absolute worst place to
> >>>> look for good examples. In this case the second variable in the function
> >>>> is completely unnecessary. Just assign the malloc return directly to the
> >>>> mcap_md_req pointer and get rid of the uint8_t* variable.
> >>>>
> >>>> Btw, I'd like to understand why we should use different acceptance
> >>>> criteria for your patches compared to everything else that gets
> >>>> submitted to BlueZ. The convention (which I'm sure you've noticed if you
> >>>> follow the list) is that when issues are found in submitted patches the
> >>>> submitter is requested to fix the issue in the patch and resubmit a new
> >>>> version of the patch. You're essentially requesting for buggy patches to
> >>>> be accepted as such and only fix the issues through new patches on top
> >>>> of the buggy ones.
> >>>>
> >>> I completely agree with this, one of the reason for this convention is
> >>> that we don't want this changes split apart because they probably
> >>> cannot be reverted individually. Another point is the history will be
> >>> completely disorganized if we start to accept those fixes separately,
> >>> it worth mention that this can eventually happen with patches already
> >>> upstream, but then it is normally a regression fix and as such we
> >>> normally mention the original commit which has caused it. I would
> >>> understand if we were in the old days of cvs, but with git it is
> >>> pretty simple to rearrange the changes, just use git rebase -i + git
> >>> reset or whatever other form to get this fixed in place.
> >>>
> >> We agree with you two. This is the complete development history that we have
> >> now. We sent it like this because we understood that keeping the history will
> >> be better. We don't care sending a different history with all the bug
> >> corrections amended.
> >>
> >> About the use of git rebase, it is not the first time that we do this and
> >> because of this we know that rebase some commits will make some of the
> >> following commits not compile. It will be a long and hard work to fix this, so
> >> it will be better and easier to create a new "virtual" history that splits the
> >> whole implementation in smaller patches.
> >>
> > In this line, it is better to put MCAP files inside health/ as Marcel asked.
> Don't worry. I will set MCAP into health directory. I don't try to
> explain anymore that MCAP is not only a health focused specification. It
> is like I want to make program that only requires TCP to work and you
> are forcing to me to import HTTP libraries, change HTTP by HDP and TCP
> by MCAP and you will get the analogy.
> I just hope that nobody get surprised if in the coming years are new
> non-health related profiles that require use MCAP and you need import
> Health to implement it.
If that happens we can move to new 'mcap' directory. For now only HDP
uses it, so makes sense keep iut inside health/
--
Gustavo F. Padovan
http://padovan.org
^ 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