* Re: [PATCH v4 1/2] HID: Add Support for Setting and Getting Feature Reports from hidraw
From: Jiri Kosina @ 2010-10-01 13:30 UTC (permalink / raw)
To: Antonio Ospite
Cc: Alan Ott, Stefan Achatz, Alexey Dobriyan, Tejun Heo, Alan Stern,
Greg Kroah-Hartman, Marcel Holtmann, Stephane Chatty,
Michael Poole, David S. Miller, Bastien Nocera, Eric Dumazet,
linux-input, linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <20100928153011.32750e5d.ospite@studenti.unina.it>
On Tue, 28 Sep 2010, Antonio Ospite wrote:
> Hi Alan, I am doing some stress testing on hidraw, if I have a loop with
> HIDIOCGFEATURE on a given report and I disconnect the device while the
> loop is running I get this:
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> IP: [<ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid]
>
> Full log attached along with the test program, the device is a Sony PS3
> Controller (sixaxis).
>
> If my objdump analysis is right, hidraw_ioctl+0xfc should be around line
> 361 in hidraw.c (with your patch applied):
>
> struct hid_device *hid = dev->hid;
>
> It looks like 'dev' (which is hidraw_table[minor]) can be NULL
> sometimes, can't it?
> This is not introduced by your changes tho.
>
> Just as a side note, the bug does not show up if the userspace program
> handles return values properly and exits as soon as it gets an error
> from the HID layer, see the XXX comment in test_hidraw_feature.c.
>
> This fixes it, if it looks ok I will resend the patch rebased on
> mainline code:
>
> diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
> index 7df1310..3c040c6 100644
> --- a/drivers/hid/hidraw.c
> +++ b/drivers/hid/hidraw.c
> @@ -322,6 +322,10 @@ static long hidraw_ioctl(struct file *file, unsigned int cmd,
>
> mutex_lock(&minors_lock);
> dev = hidraw_table[minor];
> + if (!dev) {
> + ret = -ENODEV;
> + goto out;
> + }
>
> switch (cmd) {
> case HIDIOCGRDESCSIZE:
> @@ -412,6 +416,7 @@ static long hidraw_ioctl(struct file *file, unsigned int cmd,
>
> ret = -ENOTTY;
> }
> +out:
> mutex_unlock(&minors_lock);
> return ret;
> }
Yes, this patch makes sense even for current mainline code. Could you
please resend it to me with Signed-off-by: and changelog text, so that I
could apply it?
Thanks!
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: HDP development status and collaboration
From: Jose Antonio Santos Cadenas @ 2010-10-01 14:29 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: linux-bluetooth, Jarvenpaa Jarmo (Nokia/Oulu), Aldenor Martins,
Johan Hedberg, Santiago Carot-Nemesio
In-Reply-To: <1879C724-F5EC-48FE-AD5D-46C8B290DEC6@signove.com>
Hi Elvis,
Find inline comments about the state of the development
2010/9/29 Elvis Pfützenreuter <epx@signove.com>:
> Attached is a spreadsheet with a simple breakdown of HDP development tasks. Managers like spreadsheets, most of us don't, so the most relevant part -- the pending tasks -- are listed below for convenience:
>
> device.Echo PENDING
Partially done win the CreateChanel petition (almost complete)
> device.CreateChannel IN PROGRESS (OpenHealth)
Done, needs a little bit more testing
> device.DestroyChannel PENDING
In progress
> device.ChannelConnected PENDING
This is already done
> device.ChannelDeleted PENDING
This one is also done.
> device properties PENDING
> Channel object PENDING
The object channel is also created, but not the methods.
> channel.Acquire PENDING
> channel.Release PENDING
> channel properties PENDING
> HDP verification against PTS PENDING (depends on the rest)
>
> I'd say that we are getting near completion. Would be nearer if we could distribute those tasks; currently, only OpenHealth friends are working on HDP code, in their repository.
>
> I know it's sometimes difficult to collaborate while working on the very same source files, but we should try; the breakdown by API calls seem to be the way to divide work among available developers.
>
>
>
As you say, the collaboration over the same code is difficult, event
for Satiago and me working in the same office, because all the code is
very related. I think that the development is going quite fast and we
plan to finisht it soon, note that the last week we were a little bit
delayed because we were creating most of the core functions that will
be reused for the other petitions, so the development of the other
functionality will be faster than expected.
Regards.
Jose.
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Update conf_state with L2CAP_CONF_REQ_SENT before send config_req out in l2cap_config_req().
From: haijun liu @ 2010-10-01 14:31 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Haijun.Liu, linux-bluetooth, ville.tervo, dan.tian, suraj
In-Reply-To: <20100930140042.GB4615@vigoh>
Hi Gustavo,
On Thu, Sep 30, 2010 at 10:00 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Haijun,
>
> * Haijun.Liu <haijun.liu@atheros.com> [2010-09-30 16:52:40 +0800]:
>
>>
>> Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
>> ---
>> net/bluetooth/l2cap_core.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>> index 279f98a..9e788c2 100644
>> --- a/net/bluetooth/l2cap_core.c
>> +++ b/net/bluetooth/l2cap_core.c
>
> Patch has been applied to my bluetooth-next-2.6 tree with modifications
> to the commit message and subject. Next time pay attention to not
> overstep the 72 characters in the commit subject and do not add a "." in
> the end of your subject. Thanks.
>
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
> --
> 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
>
Thank you.
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Replace hard code of configuration flag with self-comment macro.
From: haijun liu @ 2010-10-01 14:40 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Haijun.Liu, linux-bluetooth, ville.tervo, dan.tian, suraj
In-Reply-To: <20100930135618.GA4615@vigoh>
Hi Gustavo,
On Thu, Sep 30, 2010 at 9:56 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Haijun,
>
> * Haijun.Liu <haijun.liu@atheros.com> [2010-09-30 16:52:39 +0800]:
>
>>
>> Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
>> ---
>> net/bluetooth/l2cap_core.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> Your patch doesn't build:
>
> net/bluetooth/l2cap_core.c: In function 'l2cap_config_req':
> net/bluetooth/l2cap_core.c:2988: error: 'L2CAP_CONF_FLAG_CONT'
> undeclared (first use in this function)
> net/bluetooth/l2cap_core.c:2988: error: (Each undeclared identifier is
> reported only once
> net/bluetooth/l2cap_core.c:2988: error: for each function it appears
> in.)
> net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp':
> net/bluetooth/l2cap_core.c:3096: error: 'L2CAP_CONF_FLAG_CONT'
> undeclared (first use in this function)
>
>
> You also have to fix your commit subject, it would be good if you can do
> it with 50 characters, but never overstep the 72 characters. If need to
> add more info the commit message is there for you ;)
>
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
> --
> 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
>
Sorry for this mistake, I'll mail out right one soon.
--
Haijun Liu
^ permalink raw reply
* [PATCH] Bluetooth: Replace hard code of configuration continuous flag
From: haijun liu @ 2010-10-01 14:43 UTC (permalink / raw)
To: Gustavo F. Padovan, linux-bluetooth@vger.kernel.org
Cc: dan.tian, suraj, Ville Tervo
In-Reply-To: <1285943147-2546-1-git-send-email-haijun.liu@atheros.com>
Replace hard code of configuration continuous flag with
self-commented macro L2CAP_CONF_FLAG_CONT in functions
l2cap_config_req() and l2cap_config_rsp().
Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
---
include/net/bluetooth/l2cap.h | 2 ++
net/bluetooth/l2cap_core.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index df599dc..2b114ca 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -193,6 +193,8 @@ struct l2cap_conf_rsp {
#define L2CAP_CONF_REJECT 0x0002
#define L2CAP_CONF_UNKNOWN 0x0003
+#define L2CAP_CONF_FLAG_CONT 0x0001
+
struct l2cap_conf_opt {
__u8 type;
__u8 len;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 07b55c1..9e788c2 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2985,11 +2985,11 @@ static inline int l2cap_config_req(struct
l2cap_conn *conn, struct l2cap_cmd_hdr
memcpy(l2cap_pi(sk)->conf_req + l2cap_pi(sk)->conf_len, req->data, len);
l2cap_pi(sk)->conf_len += len;
- if (flags & 0x0001) {
+ if (flags & L2CAP_CONF_FLAG_CONT) {
/* Incomplete config. Send empty response. */
l2cap_send_cmd(conn, cmd->ident, L2CAP_CONF_RSP,
l2cap_build_conf_rsp(sk, rsp,
- L2CAP_CONF_SUCCESS, 0x0001), rsp);
+ L2CAP_CONF_SUCCESS,
L2CAP_CONF_FLAG_CONT), rsp);
goto unlock;
}
@@ -3093,7 +3093,7 @@ static inline int l2cap_config_rsp(struct
l2cap_conn *conn, struct l2cap_cmd_hdr
goto done;
}
- if (flags & 0x01)
+ if (flags & L2CAP_CONF_FLAG_CONT)
goto done;
l2cap_pi(sk)->conf_state |= L2CAP_CONF_INPUT_DONE;
--
1.6.3.3
^ permalink raw reply related
* Re: HDP development status and collaboration
From: Elvis Pfützenreuter @ 2010-10-01 16:38 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas
Cc: linux-bluetooth, Aldenor Martins, Santiago Carot-Nemesio
In-Reply-To: <AANLkTi=xdBH5prtbfkviPdzfLrBkt5ixGFrM36G-jJ-D@mail.gmail.com>
On 01/10/2010, at 11:29, Jose Antonio Santos Cadenas wrote:
> Hi Elvis,
>
> Find inline comments about the state of the development
>
> 2010/9/29 Elvis Pfützenreuter <epx@signove.com>:
>> Attached is a spreadsheet with a simple breakdown of HDP development tasks. Managers like spreadsheets, most of us don't, so the most relevant part -- the pending tasks -- are listed below for convenience:
>>
>> device.Echo PENDING
>
> Partially done win the CreateChanel petition (almost complete)
>
>> device.CreateChannel IN PROGRESS (OpenHealth)
>
> Done, needs a little bit more testing
>
>> device.DestroyChannel PENDING
>
> In progress
>
>> device.ChannelConnected PENDING
>
> This is already done
>
>> device.ChannelDeleted PENDING
>
> This one is also done.
>
>> device properties PENDING
>> Channel object PENDING
>
> The object channel is also created, but not the methods.
>
>> channel.Acquire PENDING
>> channel.Release PENDING
>> channel properties PENDING
>> HDP verification against PTS PENDING (depends on the rest)
>>
>> I'd say that we are getting near completion. Would be nearer if we could distribute those tasks; currently, only OpenHealth friends are working on HDP code, in their repository.
>>
>> I know it's sometimes difficult to collaborate while working on the very same source files, but we should try; the breakdown by API calls seem to be the way to divide work among available developers.
>>
Lots of progress, congratulations. I had seen some of those in the repository, before the e-mail.
>>
>>
> As you say, the collaboration over the same code is difficult, event
> for Satiago and me working in the same office, because all the code is
> very related. I think that the development is going quite fast and we
> plan to finisht it soon, note that the last week we were a little bit
> delayed because we were creating most of the core functions that will
> be reused for the other petitions, so the development of the other
> functionality will be faster than expected.
Please let us know if you need help in anything.
We will begin to test and PTS the code as it progresses, so at least that one is parallelized.
That Python-based implementation of HDP (HDPy), that mimics the (future) D-Bus BlueZ API, already passes PTS tests, save by 8 of them (which I am investigating). So we have something to compare against, if needed.
>
> Regards.
>
> Jose.
^ permalink raw reply
* Re: [PATCH] Added firmware load patch to crap directory. This patch loads firmware from btusb when device is plugged in.
From: Luis R. Rodriguez @ 2010-10-01 20:47 UTC (permalink / raw)
To: Bala Shanmugam; +Cc: linux-wireless, marcel, linux-bluetooth, linux-kernel
In-Reply-To: <1285931572-3592-1-git-send-email-sbalashanmugam@atheros.com>
On Fri, Oct 1, 2010 at 4:12 AM, Bala Shanmugam
<sbalashanmugam@atheros.com> wrote:
> Disabled staging directory compilation for bt target.
Huh? This commit log message also is unrelated to the patch below,
please separate and submit two separate patches.
> Signed-off-by: Bala Shanmugam <sbalashanmugam@atheros.com>
> ---
> =C2=A0Makefile =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=
=A09 +-
> =C2=A0crap/0003-btusb-Add-fw-load-support.patch | =C2=A0424 +++++++++++++=
++++++++++++++++
> =C2=A02 files changed, 428 insertions(+), 5 deletions(-)
> =C2=A0create mode 100644 crap/0003-btusb-Add-fw-load-support.patch
>
> diff --git a/Makefile b/Makefile
> index e2c594a..4505080 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -31,17 +31,16 @@ obj-$(CONFIG_COMPAT_NET_USB_MODULES) +=3D drivers/net=
/usb/
>
> =C2=A0obj-$(CONFIG_COMPAT_NETWORK_MODULES) +=3D drivers/net/
> =C2=A0obj-$(CONFIG_COMPAT_VAR_MODULES) +=3D =C2=A0drivers/ssb/ drivers/mi=
sc/eeprom/
> -endif
> -
> -obj-$(CONFIG_COMPAT_BLUETOOTH) +=3D net/bluetooth/
> -obj-$(CONFIG_COMPAT_BLUETOOTH_MODULES) +=3D drivers/bluetooth/
> -
>
> =C2=A0ifeq ($(CONFIG_STAGING_EXCLUDE_BUILD),)
> =C2=A0obj-$(CONFIG_COMPAT_STAGING) +=3D drivers/staging/ath6kl/
> =C2=A0obj-$(CONFIG_COMPAT_STAGING) +=3D drivers/staging/brcm80211/
> =C2=A0endif
>
> +endif
> +
> +obj-$(CONFIG_COMPAT_BLUETOOTH) +=3D net/bluetooth/
> +obj-$(CONFIG_COMPAT_BLUETOOTH_MODULES) +=3D drivers/bluetooth/
>
> =C2=A0else
>
> diff --git a/crap/0003-btusb-Add-fw-load-support.patch b/crap/0003-btusb-=
Add-fw-load-support.patch
> new file mode 100644
> index 0000000..2fc1abe
> --- /dev/null
> +++ b/crap/0003-btusb-Add-fw-load-support.patch
Actually I'd like to apply this patch to linux-next-pending/ not to
crap/ as you *did* post the patch upstream right? It just is not
getting applied yet for the reasons you stated.
> @@ -0,0 +1,424 @@
> +Reason for not yet publishing:
This not accurate, you did publish the patch, this goes into
linux-next-pending and you instead need a "Reason for not being merged
yet" or for adding it to the linux-next-pending/ directory.
> Marcel feels that Atheros sflash based BT device
> +doesn't follow bluetooth H:2 specification and HCI commands should be su=
pported
> +in firmware if it is detected as bluetooth device. Using HCI command, fi=
rmware
> +should be loaded.
> +
> +In sfash based device we don't have enough memory to support HCI command=
s in firmware.
> +So load firmware from btusb when the device comes up.
> +
You should still ask the maintainer for an alternative, otherwise the
device unusable. Did you submit the patch first in [PATCH] form? If
not please submit the patch, all I saw as an RFC and no followup at
all.
^ permalink raw reply
* Re: [PATCH] ath3k: add support for new firmware
From: Luis R. Rodriguez @ 2010-10-01 20:56 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Vikram, linux-bluetooth, lrodriguez
In-Reply-To: <1275586452.2182.30.camel@localhost.localdomain>
On Thu, Jun 03, 2010 at 10:34:12AM -0700, Marcel Holtmann wrote:
> Hi Vikram,
>
> > updated new firmware has few critical bug fixes and shared antenna
> > support.
> >
> > Signed-off-by: Vikram Kandukuri <vkandukuri@atheros.com>
> > ---
> > drivers/bluetooth/ath3k.c | 9 ++++++---
> > 1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
> > index 128cae4..7bda549 100644
> > --- a/drivers/bluetooth/ath3k.c
> > +++ b/drivers/bluetooth/ath3k.c
> > @@ -122,9 +122,12 @@ static int ath3k_probe(struct usb_interface *intf,
> >
> > data->udev = udev;
> >
> > - if (request_firmware(&firmware, "ath3k-1.fw", &udev->dev) < 0) {
> > - kfree(data);
> > - return -EIO;
> > + if (request_firmware(&firmware, "ath3k-2.fw", &udev->dev) < 0) {
> > + BT_DBG("requesting old firmware");
> > + if (request_firmware(&firmware, "ath3k-1.fw", &udev->dev) < 0) {
> > + kfree(data);
> > + return -EIO;
> > + }
> > }
> >
> > size = max_t(uint, firmware->size, 4096);
>
> can we just have a list of supported firmware in a table instead of just
> hardcoding this. I think something similar to what iwlwifi for WiFi has
> beend doing would be nice.
Vikram, you never followed up so this patch is not yet upstream....
Mind you, ath3k-2.fw is on the linux-firmware.git tree though.
Luis
^ permalink raw reply
* Re: a2dp, myth, pulse
From: Brad Midgley @ 2010-10-02 0:45 UTC (permalink / raw)
To: Sander van Grieken; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=bx1Bv1GD9SuMGbYcE-NNK5e0x5N3Oz-FkH-Zm@mail.gmail.com>
Guys
> unfortunately there isn't a clear way to merge a udp/hdhomerun remote
> coming in on lircd with avrcp events from inputlircd. I'll take it up
> with the lirc folks and summarize here later.
lirc should be used to inject input events and probably nothing else.
There are three different lirc daemon flavors, each one missing key
features. If you need to merge multiple sources, you have to do a
confusing dance with tcp sockets, master servers, etc. Unfortunately,
the event driver interface is one thing in lirc that apparently
doesn't work at all.
I made it work instead with gizmod talking to the mythtv telnet
control connection, see script.
Gizmod does have a problem with its compile prefix, see
https://bugs.launchpad.net/ubuntu/+source/gizmod/+bug/645058
So, the complete hack under ubuntu 10.04...
* add uinput to /etc/modules
* tell myth to use the pulse device
* add to /etc/pulse/default.pa: load-module module-alsa-sink device=plug:dmix
* click the headset button to connect it
* use pavucontrol to move the myth stream over to the headset
* install the script below in ~/.gizmod/modules.d/001-AVRCP-MythTV.py
* sudo ln -s /etc /usr/etc
* sudo gizmod
--
Brad Midgley
from GizmoDaemon import *
from GizmoScriptEnableChecker import *
import sys
import telnetlib
ENABLED = True
VERSION_NEEDED = 3.2
class AVRCPMythTV(GizmoScriptEnableChecker):
def msend(self, msg):
telnet = telnetlib.Telnet("localhost", 6546)
telnet.read_until("# ")
telnet.write(msg + "\n")
telnet.close
def onEvent(self, Event, Gizmo = None):
if Event.Remote:
return False
if Event.Class != GizmoEventClass.Standard:
return False
if Event.Type != GizmoEventType.EV_KEY:
return False
if Event.Value != 1:
return False
name = str(Event.Code)
if name == "KEY_NEXTSONG":
self.msend("key right")
return True
elif name == "KEY_PLAYCD" or name == "KEY_PAUSECD":
self.msend("key p")
return True
elif name == "KEY_STOPCD":
self.msend("key escape")
return True
elif name == "KEY_PREVIOUSSONG":
self.msend("key left")
return True
return False
def __init__(self):
GizmoScriptEnableChecker.__init__(self, ENABLED, VERSION_NEEDED)
^ permalink raw reply
* Re: >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Pacho Ramos @ 2010-10-02 13:58 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100920184943.GA22968@jh-x301>
[-- Attachment #1.1: Type: text/plain, Size: 1245 bytes --]
El lun, 20-09-2010 a las 21:49 +0300, Johan Hedberg escribió:
> Hi,
>
> On Mon, Sep 20, 2010, Pacho Ramos wrote:
> > Reporter found that the problem with his dongle was introduced in commit
> > aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> > level MEDIUM", he asked here, on upstream mailing list, but didn't get
> > any reply clarifying this:
> > http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
>
> The important piece of info missing here is an HCI trace of the failure
> (i.e. output of hcidump). There was a similar issue reported on IRC a
> few days back and the hcidump there revealed a LMP response timeout
> after BlueZ issues a HCI_Set_Connection_Encryption command. This would
> seem to indicate a bug either in the local adapter or the remote device
> (headset). Only an airtrace would really reveal what's going on.
> However, I suspect it might be possible to work around this by looking
> into possibilities of changing the ordering and timing of when the
> kernel sends the encryption request.
>
> Johan
>
Sorry for the delay but downstream reporter wasn't able to provide the
information sooner.
Attached is hcidump output, I hope it helps :-)
Thanks a lot
[-- Attachment #1.2: hcidump.out --]
[-- Type: text/plain, Size: 6956 bytes --]
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Link Key Request (0x17) plen 6
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
> HCI Event: Command Complete (0x0e) plen 10
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< ACL data: handle 12 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Max Slots Change (0x1b) plen 3
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0049 scid 0x0040 result 1 status 2
Connection pending - Authorization pending
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0049 scid 0x0040 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0049 flags 0x00 clen 0
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
< ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0049 flags 0x00 result 0 clen 4
MTU 48
< ACL data: handle 12 flags 0x02 dlen 24
L2CAP(d): cid 0x0049 len 20 [psm 1]
SDP SSA Req: tid 0x0 len 0xf
pat uuid-16 0x111e (Handsfree)
max 65535
aid(s) 0x0000 - 0xffff
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 12 flags 0x02 dlen 52
L2CAP(d): cid 0x0040 len 48 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x2b
count 38
cont 02 00 39
< ACL data: handle 12 flags 0x02 dlen 26
L2CAP(d): cid 0x0049 len 22 [psm 1]
SDP SSA Req: tid 0x1 len 0x11
pat uuid-16 0x111e (Handsfree)
max 65535
aid(s) 0x0000 - 0xffff
cont 02 00 39
> ACL data: handle 12 flags 0x02 dlen 52
L2CAP(d): cid 0x0040 len 48 [psm 1]
SDP SSA Rsp: tid 0x1 len 0x2b
count 38
cont 02 00 13
< ACL data: handle 12 flags 0x02 dlen 26
L2CAP(d): cid 0x0049 len 22 [psm 1]
SDP SSA Req: tid 0x2 len 0x11
pat uuid-16 0x111e (Handsfree)
max 65535
aid(s) 0x0000 - 0xffff
cont 02 00 13
> ACL data: handle 12 flags 0x02 dlen 31
L2CAP(d): cid 0x0040 len 27 [psm 1]
SDP SSA Rsp: tid 0x2 len 0x16
count 19
record #0
aid 0x0000 (SrvRecHndl)
uint 0x10002
aid 0x0001 (SrvClassIDList)
< uuid-16 0x111e (Handsfree) uuid-16 0x1203 (Audio) >
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x1 > >
aid 0x0006 (LangBaseAttrIDList)
< uint 0x656e uint 0x6a uint 0x100 >
aid 0x0009 (BTProfileDescList)
< < uuid-16 0x111e (Handsfree) uint 0x101 > >
aid 0x0100 (SrvName)
str "Hands-Free unit"
aid 0x0311 (SuppFeatures)
uint 0x18
cont 00
< ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x004a scid 0x0041 result 1 status 2
Connection pending - Authorization pending
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x004a scid 0x0041 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x004a flags 0x00 clen 4
MTU 1013
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 1013
< ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x004a flags 0x00 result 0 clen 4
MTU 1013
< ACL data: handle 12 flags 0x02 dlen 8
L2CAP(d): cid 0x004a len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> ACL data: handle 12 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Auth Complete (0x06) plen 3
< HCI Command: Set Connection Encryption (0x01|0x0013) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Number of Completed Packets (0x13) plen 5
< ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0049 scid 0x0040
< ACL data: handle 12 flags 0x02 dlen 8
L2CAP(d): cid 0x004a len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 2 pf 1 ilen 0 fcs 0xb8
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Disconn Complete (0x05) plen 4
< HCI Command: Create Connection (0x01|0x0005) plen 13
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Link Key Request (0x17) plen 6
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
> HCI Event: Command Complete (0x0e) plen 10
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Max Slots Change (0x1b) plen 3
> HCI Event: Command Status (0x0f) plen 4
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
> HCI Event: Remote Name Req Complete (0x07) plen 255
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Auth Complete (0x06) plen 3
< HCI Command: Set Connection Encryption (0x01|0x0013) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Disconn Complete (0x05) plen 4
< HCI Command: Reset (0x03|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 4
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: a2dp, myth, pulse
From: Brad Midgley @ 2010-10-02 14:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTikuh82wX5ZhwihKC+WBwdJD78SSDq13Ks=qZCc6@mail.gmail.com>
sorry guys, you can crash mythtv if you don't drain the socket...
#***
#*********************************************************************
#*************************************************************************
#***
#*** GizmoDaemon Config Script
#*** AVRCP controls for MythTV
#***
#*****************************************
#*****************************************
#***
from GizmoDaemon import *
from GizmoScriptEnableChecker import *
import sys
import telnetlib
import time
ENABLED = True
VERSION_NEEDED = 3.2
class AVRCPMythTV(GizmoScriptEnableChecker):
"""
CatchAll Event Mapping for Testing
"""
def msend(self, msg):
telnet = telnetlib.Telnet("localhost", 6546)
telnet.read_until("# ")
time.sleep(0.1)
telnet.write(msg + "\n")
time.sleep(0.1)
telnet.read_eager()
telnet.write("quit\n")
time.sleep(0.1)
telnet.read_all()
telnet.close
def onEvent(self, Event, Gizmo = None):
"""
See GizmodDispatcher.onEvent documention for an explanation of this function
"""
if Event.Remote:
return False
if Event.Class != GizmoEventClass.Standard:
return False
if Event.Type != GizmoEventType.EV_KEY:
return False
if Event.Value != 1:
return False
name = str(Event.Code)
if name == "KEY_NEXTSONG":
self.msend("key right")
return True
elif name == "KEY_PLAYCD" or name == "KEY_PAUSECD":
self.msend("key p")
return True
elif name == "KEY_STOPCD":
self.msend("key escape")
return True
elif name == "KEY_PREVIOUSSONG":
self.msend("key left")
return True
return False
def __init__(self):
"""
Default Constructor
"""
GizmoScriptEnableChecker.__init__(self, ENABLED, VERSION_NEEDED)
AVRCPMythTV()
^ permalink raw reply
* [PATCH] Added firmware load patch to crap directory.
From: Bala Shanmugam @ 2010-10-03 15:00 UTC (permalink / raw)
To: linux-wireless; +Cc: marcel, linux-bluetooth, linux-kernel, Bala Shanmugam
This patch in crap directory enables btusb to load firmware
to device RAM when it is plugged in.
Signed-off-by: Bala Shanmugam <sbalashanmugam@atheros.com>
---
crap/0003-btusb-Add-fw-load-support.patch | 424 +++++++++++++++++++++++++++++
1 files changed, 424 insertions(+), 0 deletions(-)
create mode 100644 crap/0003-btusb-Add-fw-load-support.patch
diff --git a/crap/0003-btusb-Add-fw-load-support.patch b/crap/0003-btusb-Add-fw-load-support.patch
new file mode 100644
index 0000000..6642d6b
--- /dev/null
+++ b/crap/0003-btusb-Add-fw-load-support.patch
@@ -0,0 +1,424 @@
+Reason for not yet publishing: Marcel feels that Atheros sflash based BT device
+doesn't follow bluetooth H:2 specification and HCI commands should be supported
+in firmware if it is detected as bluetooth device. Using HCI command, firmware
+should be loaded.
+
+In sflash based device there is not enough memory to support HCI commands in firmware.
+So load firmware from btusb when the device comes up.
+
+From 4ac276c14578b380d0c6a27658eeaa364efe6432 Mon Sep 17 00:00:00 2001
+From: Bala Shanmugam <sbalashanmugam@atheros.com>
+Date: Fri, 1 Oct 2010 15:18:02 +0530
+Subject: [PATCH] Added support to load firmware to target RAM from btusb transport driver.
+ Each BT device vendor can add their product ID, firmware file, load and unload function
+ to btusb_fwcbs array. When the device is inserted btusb will call appropriate
+ firmware load function. This support will significantly reduce cost of
+ BT chip because of RAM based firmware.
+ Signed-off-by: Bala Shanmugam <sbalashanmugam@atheros.com>
+
+---
+ drivers/bluetooth/Makefile | 1 +
+ drivers/bluetooth/btusb.c | 67 +++++++++++++++
+ drivers/bluetooth/fwload.c | 199 ++++++++++++++++++++++++++++++++++++++++++++
+ drivers/bluetooth/fwload.h | 39 +++++++++
+ 4 files changed, 306 insertions(+), 0 deletions(-)
+ create mode 100644 drivers/bluetooth/fwload.c
+ create mode 100644 drivers/bluetooth/fwload.h
+
+diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
+index 71bdf13..5a55cbb 100644
+--- a/drivers/bluetooth/Makefile
++++ b/drivers/bluetooth/Makefile
+@@ -13,6 +13,7 @@ obj-$(CONFIG_BT_HCIBLUECARD) += bluecard_cs.o
+ obj-$(CONFIG_BT_HCIBTUART) += btuart_cs.o
+
+ obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
++obj-$(CONFIG_BT_HCIBTUSB) += fwload.o
+ obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
+
+ obj-$(CONFIG_BT_ATH3K) += ath3k.o
+diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
+index d22ce3c..13e0fb8 100644
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -34,6 +34,7 @@
+
+ #include <net/bluetooth/bluetooth.h>
+ #include <net/bluetooth/hci_core.h>
++#include "fwload.h"
+
+ #define VERSION "0.6"
+
+@@ -55,6 +56,26 @@ static struct usb_driver btusb_driver;
+ #define BTUSB_BROKEN_ISOC 0x20
+ #define BTUSB_WRONG_SCO_MTU 0x40
+
++static struct usb_device_id ath_table[] = {
++ /* Atheros AR3011 */
++ { USB_DEVICE(0x0CF3, 0x3002) },
++ { USB_DEVICE(0x13D3, 0x3304) },
++ { } /* Terminating entry */
++};
++
++/* Add firmware file, load and unload function
++ * to download the firmware to target RAM
++ */
++static struct fw_cb_config btusb_fwcbs[] = {
++ {
++ .fwfile = "ath3k-1.fw",
++ .usb_id_table = ath_table,
++ .fwload = ath_fw_load,
++ .fwunload = ath_fw_unload
++ },
++ {}
++};
++
+ static struct usb_device_id btusb_table[] = {
+ /* Generic Bluetooth USB device */
+ { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+@@ -863,6 +884,7 @@ static int btusb_probe(struct usb_interface *intf,
+ struct btusb_data *data;
+ struct hci_dev *hdev;
+ int i, err;
++ const struct usb_device_id *match;
+
+ BT_DBG("intf %p id %p", intf, id);
+
+@@ -922,6 +944,19 @@ static int btusb_probe(struct usb_interface *intf,
+ data->udev = interface_to_usbdev(intf);
+ data->intf = intf;
+
++ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
++ match = usb_match_id(intf, btusb_fwcbs[i].usb_id_table);
++ if (match) {
++ if (btusb_fwcbs[i].fwload) {
++ btusb_fwcbs[i].data =
++ btusb_fwcbs[i].fwload(intf,
++ btusb_fwcbs[i].fwfile,
++ &btusb_fwcbs[i].bsuspend);
++ }
++ break;
++ }
++ }
++
+ spin_lock_init(&data->lock);
+
+ INIT_WORK(&data->work, btusb_work);
+@@ -1030,12 +1065,26 @@ static void btusb_disconnect(struct usb_interface *intf)
+ {
+ struct btusb_data *data = usb_get_intfdata(intf);
+ struct hci_dev *hdev;
++ const struct usb_device_id *match;
++ int i;
+
+ BT_DBG("intf %p", intf);
+
+ if (!data)
+ return;
+
++ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
++ match = usb_match_id(intf, btusb_fwcbs[i].usb_id_table);
++ if (match) {
++ if (btusb_fwcbs[i].fwunload) {
++ btusb_fwcbs[i].fwunload(btusb_fwcbs[i].data,
++ btusb_fwcbs[i].bsuspend);
++ btusb_fwcbs[i].data = NULL;
++ }
++ break;
++ }
++ }
++
+ hdev = data->hdev;
+
+ __hci_dev_hold(hdev);
+@@ -1061,12 +1110,22 @@ static void btusb_disconnect(struct usb_interface *intf)
+ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
+ {
+ struct btusb_data *data = usb_get_intfdata(intf);
++ const struct usb_device_id *match;
++ int i;
+
+ BT_DBG("intf %p", intf);
+
+ if (data->suspend_count++)
+ return 0;
+
++ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
++ match = usb_match_id(intf, btusb_fwcbs[i].usb_id_table);
++ if (match) {
++ btusb_fwcbs[i].bsuspend = 1;
++ break;
++ }
++ }
++
+ spin_lock_irq(&data->txlock);
+ if (!((message.event & PM_EVENT_AUTO) && data->tx_in_flight)) {
+ set_bit(BTUSB_SUSPENDING, &data->flags);
+@@ -1179,6 +1238,14 @@ static int __init btusb_init(void)
+
+ static void __exit btusb_exit(void)
+ {
++ int i;
++ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
++ if (btusb_fwcbs[i].fwunload && btusb_fwcbs[i].data) {
++ btusb_fwcbs[i].fwunload(btusb_fwcbs[i].data,
++ btusb_fwcbs[i].bsuspend);
++ btusb_fwcbs[i].data = NULL;
++ }
++ }
+ usb_deregister(&btusb_driver);
+ }
+
+diff --git a/drivers/bluetooth/fwload.c b/drivers/bluetooth/fwload.c
+new file mode 100644
+index 0000000..a9a586a
+--- /dev/null
++++ b/drivers/bluetooth/fwload.c
+@@ -0,0 +1,199 @@
++/*
++ *
++ * Generic Bluetooth USB DFU driver to download firmware to target RAM
++ *
++ * Copyright (c) 2009-2010 Atheros Communications Inc.
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program; if not, write to the Free Software
++ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
++ *
++ */
++
++#include <linux/module.h>
++#include <linux/kernel.h>
++#include <linux/init.h>
++#include <linux/slab.h>
++#include <linux/types.h>
++#include <linux/device.h>
++#include <linux/firmware.h>
++#include <linux/usb.h>
++#include <net/bluetooth/bluetooth.h>
++
++#define USB_REQ_DFU_DNLOAD 1
++#define USB_REQ_GET_STATE 5
++#define USB_FIRMWARE_RAM_MODE 11
++#define USB_FIRMWARE_FLASH_MODE 12
++#define BULK_SIZE 4096
++#define VERSION "1.0"
++
++struct firmware_data {
++ struct usb_device *udev;
++ u8 *fw_data;
++ u32 fw_size;
++ u32 fw_sent;
++};
++
++static int load_firmware(struct firmware_data *data,
++ unsigned char *firmware,
++ int count)
++{
++ u8 *send_buf;
++ int err, pipe, len, size, sent = 0;
++ char ucFirmware = 0;
++
++ BT_DBG("ath3k %p udev %p", data, data->udev);
++
++ if ((usb_control_msg(data->udev, usb_rcvctrlpipe(data->udev, 0),
++ USB_REQ_GET_STATE,
++ USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
++ &ucFirmware, 1, USB_CTRL_SET_TIMEOUT)) < 0) {
++ BT_ERR("Can't change to loading configuration err");
++ return -EBUSY;
++ }
++
++ if (ucFirmware == USB_FIRMWARE_RAM_MODE) {
++ /* RAM based firmware is available in the target.
++ * No need to load the firmware to RAM */
++ BT_DBG("RAM based firmware is available");
++ return 0;
++ }
++
++ pipe = usb_sndctrlpipe(data->udev, 0);
++ if ((usb_control_msg(data->udev, pipe,
++ USB_REQ_DFU_DNLOAD,
++ USB_TYPE_VENDOR, 0, 0,
++ firmware, 20, USB_CTRL_SET_TIMEOUT)) < 0) {
++ BT_ERR("Can't change to loading configuration err");
++ return -EBUSY;
++ }
++ sent += 20;
++ count -= 20;
++
++ send_buf = kmalloc(BULK_SIZE, GFP_ATOMIC);
++ if (!send_buf) {
++ BT_ERR("Can't allocate memory chunk for firmware");
++ return -ENOMEM;
++ }
++
++ while (count) {
++ size = min_t(uint, count, BULK_SIZE);
++ pipe = usb_sndbulkpipe(data->udev, 0x02);
++ memcpy(send_buf, firmware + sent, size);
++
++ err = usb_bulk_msg(data->udev, pipe, send_buf, size,
++ &len, 3000);
++
++ if (err || (len != size)) {
++ BT_ERR("Error in firmware loading err = %d,"
++ "len = %d, size = %d", err, len, size);
++ goto error;
++ }
++
++ sent += size;
++ count -= size;
++ }
++
++ kfree(send_buf);
++ return 0;
++
++error:
++ kfree(send_buf);
++ return err;
++}
++
++void *ath_fw_load(struct usb_interface *intf,
++ const char *fwfile, bool *suspend)
++{
++ const struct firmware *firmware;
++ struct usb_device *udev = interface_to_usbdev(intf);
++ static struct firmware_data *data;
++ int size;
++
++ BT_DBG("\nintf %p suspend %d\n", intf, *suspend);
++
++ if (*suspend) {
++ load_firmware(data, data->fw_data, data->fw_size);
++ *suspend = 0;
++ return data;
++ }
++
++ if (intf->cur_altsetting->desc.bInterfaceNumber != 0)
++ return NULL;
++
++ data = kzalloc(sizeof(*data), GFP_KERNEL);
++ if (!data)
++ return NULL;
++ data->udev = udev;
++
++ if (request_firmware(&firmware, fwfile, &udev->dev) < 0) {
++ kfree(data);
++ return NULL;
++ }
++
++ size = max_t(uint, firmware->size, 4096);
++ data->fw_data = kmalloc(size, GFP_KERNEL);
++ if (!data->fw_data) {
++ release_firmware(firmware);
++ kfree(data);
++ return NULL;
++ }
++
++ memcpy(data->fw_data, firmware->data, firmware->size);
++ data->fw_size = firmware->size;
++ data->fw_sent = 0;
++ release_firmware(firmware);
++
++ if (load_firmware(data, data->fw_data, data->fw_size)) {
++ kfree(data->fw_data);
++ kfree(data);
++ return NULL;
++ }
++ return data;
++}
++EXPORT_SYMBOL(ath_fw_load);
++
++void ath_fw_unload(void *pdata, bool bsuspend)
++{
++ struct firmware_data *data = (struct firmware_data *)pdata;
++
++ if (data == NULL)
++ return;
++
++ /* do not free the data on suspend as we will
++ * use it on resume */
++ if (!bsuspend) {
++ kfree(data->fw_data);
++ kfree(data);
++ }
++}
++EXPORT_SYMBOL(ath_fw_unload);
++
++static int __init fwload_init(void)
++{
++ BT_INFO("Firmware load driver init. Version:%s", VERSION);
++ return 0;
++}
++
++static void __exit fwload_deinit(void)
++{
++ BT_INFO("Firmware load driver deinit");
++}
++
++module_init(fwload_init);
++module_exit(fwload_deinit);
++
++MODULE_AUTHOR("Atheros Communications");
++MODULE_DESCRIPTION("Firmware load driver");
++MODULE_VERSION(VERSION);
++MODULE_LICENSE("GPL");
+diff --git a/drivers/bluetooth/fwload.h b/drivers/bluetooth/fwload.h
+new file mode 100644
+index 0000000..5c1136a
+--- /dev/null
++++ b/drivers/bluetooth/fwload.h
+@@ -0,0 +1,39 @@
++/*
++ *
++ * Generic Bluetooth USB DFU driver to download firmware to target RAM
++ *
++ * Copyright (c) 2009-2010 Atheros Communications Inc.
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program; if not, write to the Free Software
++ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
++ *
++ */
++#ifndef _FWLOAD_H_
++#define _FWLOAD_H_
++
++/* callbacks to load firmware to BT device RAM
++ * when it is inserted */
++struct fw_cb_config {
++ const char *fwfile;
++ void * (*fwload)(struct usb_interface *intf, const char *fwfile,
++ bool *bsuspend);
++ void (*fwunload)(void *, bool);
++ const struct usb_device_id *usb_id_table;
++ void *data;
++ bool bsuspend;
++};
++void *ath_fw_load(struct usb_interface *intf, const char *, bool *);
++void ath_fw_unload(void *pdata, bool bsuspend);
++
++#endif /* _FWLOAD_H_ */
+--
+1.6.3.3
+
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Added firmware load patch to crap directory.
From: Julian Calaby @ 2010-10-03 22:13 UTC (permalink / raw)
To: Bala Shanmugam; +Cc: linux-wireless, marcel, linux-bluetooth, linux-kernel
In-Reply-To: <1286118002-2354-1-git-send-email-sbalashanmugam@atheros.com>
On Mon, Oct 4, 2010 at 02:00, Bala Shanmugam <sbalashanmugam@atheros.com> wrote:
> +Reason for not yet publishing: Marcel feels that Atheros sflash based BT device
> +doesn't follow bluetooth H:2 specification and HCI commands should be supported
> +in firmware if it is detected as bluetooth device. Using HCI command, firmware
> +should be loaded.
> +
> +In sflash based device there is not enough memory to support HCI commands in firmware.
> +So load firmware from btusb when the device comes up.
Stupid question: What's to stop you from producing a driver that
connects to this device when unflashed, loads the firmware, then hands
it over to the proper HCI bluetooth driver? (other than it being an
ugly hack)
You could post such a driver to Linux-usb and "solve" the problem in a
way that (should) make everyone happy.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* can not connect to Headset after pairing, please suggest
From: Yedire, Sandeep @ 2010-10-04 4:32 UTC (permalink / raw)
To: linux-bluetooth
Hello All,
I have been trying to connect to Bluetooth headset from the target.
I am able to see the connection status from pairing mode to paired
mode when I do ./agent 0000 <bdaddr>. Here Red-Blue blink will respond
to the agent(executable) and change to blue-blue blink.
Later Thru a2play or avtest, l2test (part of btsco, bluez) I get
connection refused-146. I tried hcidump running in back ground and
found connection refused -Security Block. Also the headset enters into
a mode where it does not take any pass-key.
I do find that pairing was successful but why do I get this error
message. Am I missing any step in between? Is there any place where
some pairing information is stored some where so that this remains in
connected state and do not ask for pass -key again.
Can some one take time to suggest me how pairing is to be done with
headset detailing in each step so that I don't miss any ?
Regards,
Sandeep.Yedire
----------------------------------------------------------
T.Jefferson, 'Victory and defeat are each of the same price"
^ permalink raw reply
* [PATCH] Bluetooth: Add support to specify patch download location
From: Suraj Sumangala @ 2010-10-04 7:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
This patch add support for specifying patch download address for
AR300x patch download logic.
---
tools/hciattach_ath3k.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/tools/hciattach_ath3k.c b/tools/hciattach_ath3k.c
index 5589254..e27cc4b 100644
--- a/tools/hciattach_ath3k.c
+++ b/tools/hciattach_ath3k.c
@@ -461,20 +461,68 @@ struct patch_entry {
uint8_t data[MAX_PATCH_CMD];
};
+#define SET_PATCH_RAM_ID 0x0D
+#define SET_PATCH_RAM_CMD_SIZE 11
+#define ADDRESS_LEN 4
+static int set_patch_ram(int dev, char *patch_loc, int len)
+{
+ int err;
+ uint8_t cmd[20];
+ int i, j;
+ char loc_byte[3];
+ uint8_t *event;
+ uint8_t *loc_ptr = (uint8_t *)&cmd[7];
+
+ if (!patch_loc)
+ return -1;
+
+ loc_byte[2] = '\0';
+
+ load_hci_ps_hdr(cmd, SET_PATCH_RAM_ID, ADDRESS_LEN, 0);
+
+ for (i = 0, j = 3; i < 4; i++, j--) {
+ loc_byte[0] = patch_loc[0];
+ loc_byte[1] = patch_loc[1];
+ loc_ptr[j] = strtol(loc_byte, NULL, 16);
+ patch_loc += 2;
+ }
+
+ err = send_hci_cmd_sync(dev, cmd, SET_PATCH_RAM_CMD_SIZE, &event);
+ if (err < 0)
+ return err;
+
+ err = read_ps_event(event, HCI_PS_CMD_OCF);
+
+ if (event)
+ free(event);
+
+ return err;
+}
+
+#define PATCH_LOC_KEY "DA:"
+#define PATCH_LOC_STRING_LEN 8
static int ps_patch_download(int fd, FILE *stream)
{
char byte[3];
char ptr[MAX_PATCH_CMD + 1];
int byte_cnt;
int patch_count = 0;
+ char patch_loc[PATCH_LOC_STRING_LEN + 1];
byte[2] = '\0';
while (fgets(ptr, MAX_PATCH_CMD, stream)) {
- if (strlen(ptr) <= 1 || !isxdigit(ptr[0]))
+ if (strlen(ptr) <= 1)
continue;
- else
+ else if (strstr(ptr, PATCH_LOC_KEY) == ptr) {
+ strncpy(patch_loc, &ptr[sizeof(PATCH_LOC_KEY) - 1],
+ PATCH_LOC_STRING_LEN);
+ if (set_patch_ram(fd, patch_loc, sizeof(patch_loc)) < 0)
+ return -1;
+ } else if (isxdigit(ptr[0]))
break;
+ else
+ return -1;
}
byte_cnt = strtol(ptr, NULL, 16);
--
1.7.0.4
^ permalink raw reply related
* Re: >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Luiz Augusto von Dentz @ 2010-10-04 10:00 UTC (permalink / raw)
To: pacho; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <1286027890.12944.1.camel@localhost.localdomain>
Hi,
On Sat, Oct 2, 2010 at 4:58 PM, Pacho Ramos
<pacho@condmat1.ciencias.uniovi.es> wrote:
> El lun, 20-09-2010 a las 21:49 +0300, Johan Hedberg escribió:
>> Hi,
>>
>> On Mon, Sep 20, 2010, Pacho Ramos wrote:
>> > Reporter found that the problem with his dongle was introduced in commit
>> > aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
>> > level MEDIUM", he asked here, on upstream mailing list, but didn't get
>> > any reply clarifying this:
>> > http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
>>
>> The important piece of info missing here is an HCI trace of the failure
>> (i.e. output of hcidump). There was a similar issue reported on IRC a
>> few days back and the hcidump there revealed a LMP response timeout
>> after BlueZ issues a HCI_Set_Connection_Encryption command. This would
>> seem to indicate a bug either in the local adapter or the remote device
>> (headset). Only an airtrace would really reveal what's going on.
>> However, I suspect it might be possible to work around this by looking
>> into possibilities of changing the ordering and timing of when the
>> kernel sends the encryption request.
>>
>> Johan
>>
>
> Sorry for the delay but downstream reporter wasn't able to provide the
> information sooner.
>
> Attached is hcidump output, I hope it helps :-)
I would say this was because of double authentication request, but it
seems it is not the case, actually ssp doesn't seems to be used at all
here so this must be something else, maybe you should try this:
http://thread.gmane.org/gmane.linux.bluez.kernel/7256
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Pacho Ramos @ 2010-10-04 10:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <AANLkTikFrvyeoXV0uLYcvD4GCj2s3ML2-q8f5GhXMxAK@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]
El lun, 04-10-2010 a las 13:00 +0300, Luiz Augusto von Dentz escribió:
> Hi,
>
> On Sat, Oct 2, 2010 at 4:58 PM, Pacho Ramos
> <pacho@condmat1.ciencias.uniovi.es> wrote:
> > El lun, 20-09-2010 a las 21:49 +0300, Johan Hedberg escribió:
> >> Hi,
> >>
> >> On Mon, Sep 20, 2010, Pacho Ramos wrote:
> >> > Reporter found that the problem with his dongle was introduced in commit
> >> > aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> >> > level MEDIUM", he asked here, on upstream mailing list, but didn't get
> >> > any reply clarifying this:
> >> > http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
> >>
> >> The important piece of info missing here is an HCI trace of the failure
> >> (i.e. output of hcidump). There was a similar issue reported on IRC a
> >> few days back and the hcidump there revealed a LMP response timeout
> >> after BlueZ issues a HCI_Set_Connection_Encryption command. This would
> >> seem to indicate a bug either in the local adapter or the remote device
> >> (headset). Only an airtrace would really reveal what's going on.
> >> However, I suspect it might be possible to work around this by looking
> >> into possibilities of changing the ordering and timing of when the
> >> kernel sends the encryption request.
> >>
> >> Johan
> >>
> >
> > Sorry for the delay but downstream reporter wasn't able to provide the
> > information sooner.
> >
> > Attached is hcidump output, I hope it helps :-)
>
> I would say this was because of double authentication request, but it
> seems it is not the case, actually ssp doesn't seems to be used at all
> here so this must be something else, maybe you should try this:
>
> http://thread.gmane.org/gmane.linux.bluez.kernel/7256
>
Thanks but, how should I try to apply that patch? Looks like
net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
Best regards
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Uwe Kleine-König @ 2010-10-04 12:35 UTC (permalink / raw)
To: Pacho Ramos; +Cc: Luiz Augusto von Dentz, Johan Hedberg, linux-bluetooth
In-Reply-To: <1286187946.7898.0.camel@localhost.localdomain>
Hello Pacho,
On Mon, Oct 04, 2010 at 12:25:46PM +0200, Pacho Ramos wrote:
> > I would say this was because of double authentication request, but it
> > seems it is not the case, actually ssp doesn't seems to be used at all
> > here so this must be something else, maybe you should try this:
> >
> > http://thread.gmane.org/gmane.linux.bluez.kernel/7256
> >
>
> Thanks but, how should I try to apply that patch? Looks like
> net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
I guess this is a patch to apply to your kernel, not bluez.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* How add support of LLMNR for PAN
From: Chetankumar Manjegowda @ 2010-10-04 12:45 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <20101004123552.GC11737@pengutronix.de>
Hi All,
I want to know how to enable/Integrate LLMNR for PAN profile.
Can anyone give some suggestions or link where I can refer the same ??
Rgds
Chetan
________________________________
http://www.mindtree.com/email/disclaimer.html
^ permalink raw reply
* Pull request: git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
From: Anderson Lizardo @ 2010-10-04 14:11 UTC (permalink / raw)
To: linux-bluetooth
The following changes since commit bb061d925ad661836d5279b543a07d17683d9b6e:
Marcel Holtmann (1):
Update list of company identifiers
are available in the git repository at:
git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
Anderson Lizardo (7):
Remove unnecessary check for watcher path
Rename global "handle" variable to "sdp_handle"
Add test/test-attrib for testing Attribute API
Add org.bluez.Watcher interface to default policy
Fix and refactor characteristic value update code
Add Write Characteristic Value support to attribute server
Allow errors to propagate from connection callback
Bruna Moreira (8):
Add encoders/decoders for the Write command
Implement Write command in GATT API
Move connection common code to l2cap_connect()
Write new value for characteristic value
Use g_slist_foreach() instead of a for loop
Make handle parameter mandatory in gatttool
Add new option for char value write in gatttool
Implement characteristic_write callback in gatttool
attrib/att.c | 45 ++++++++++++++++
attrib/att.h | 4 ++
attrib/client.c | 145 ++++++++++++++++++++++++---------------------------
attrib/gatt.c | 11 ++++
attrib/gatt.h | 3 +
attrib/gatttool.c | 120 ++++++++++++++++++++++++++++++++++++------
src/attrib-server.c | 32 ++++++++++--
src/bluetooth.conf | 1 +
test/test-attrib | 120 ++++++++++++++++++++++++++++++++++++++++++
9 files changed, 381 insertions(+), 100 deletions(-)
create mode 100755 test/test-attrib
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Inquiry_with_RSSI compatible dongles
From: Giedo Mak @ 2010-10-04 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTinbYqYrFrJDCEm3U0Mto8fYJyQLDa8s0KB6T3qi@mail.gmail.com>
Hello,
I'm working on a bluetooth program with some sort of distance sensing/tracking.
To make this easier I came across a feature called inquiry_with_RSSI.
Could somebody tell me what kind of dongles support this feature. I
mean, does every 2.1 BT dongle support it, or can you only find out
once you get one in your hands?
Kind regards,
Giedo
^ permalink raw reply
* Re: Pull request: git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
From: Johan Hedberg @ 2010-10-04 15:16 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimfiie4L6CBm_oTiyFRmB92dt6bugvBREY6vuzN@mail.gmail.com>
Hi,
On Mon, Oct 04, 2010, Anderson Lizardo wrote:
> The following changes since commit bb061d925ad661836d5279b543a07d17683d9b6e:
> Marcel Holtmann (1):
> Update list of company identifiers
>
> are available in the git repository at:
>
> git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
>
> Anderson Lizardo (7):
> Remove unnecessary check for watcher path
> Rename global "handle" variable to "sdp_handle"
> Add test/test-attrib for testing Attribute API
> Add org.bluez.Watcher interface to default policy
> Fix and refactor characteristic value update code
> Add Write Characteristic Value support to attribute server
> Allow errors to propagate from connection callback
>
> Bruna Moreira (8):
> Add encoders/decoders for the Write command
> Implement Write command in GATT API
> Move connection common code to l2cap_connect()
> Write new value for characteristic value
> Use g_slist_foreach() instead of a for loop
> Make handle parameter mandatory in gatttool
> Add new option for char value write in gatttool
> Implement characteristic_write callback in gatttool
>
> attrib/att.c | 45 ++++++++++++++++
> attrib/att.h | 4 ++
> attrib/client.c | 145 ++++++++++++++++++++++++---------------------------
> attrib/gatt.c | 11 ++++
> attrib/gatt.h | 3 +
> attrib/gatttool.c | 120 ++++++++++++++++++++++++++++++++++++------
> src/attrib-server.c | 32 ++++++++++--
> src/bluetooth.conf | 1 +
> test/test-attrib | 120 ++++++++++++++++++++++++++++++++++++++++++
> 9 files changed, 381 insertions(+), 100 deletions(-)
> create mode 100755 test/test-attrib
Thanks, all patches have been pushed upstream.
Johan
^ permalink raw reply
* Re: How add support of LLMNR for PAN
From: Arun Kumar @ 2010-10-04 15:35 UTC (permalink / raw)
To: Chetankumar Manjegowda; +Cc: linux-bluetooth
In-Reply-To: <52A922E83075C847A59D7DF98C66017501871E@MTW02MBX03.mindtree.com>
Shouldn't this support come from linux ip stack rather than bluez?
Best Regards,
Arun Kumar Singh
www.crazydaks.com
On Mon, Oct 4, 2010 at 6:15 PM, Chetankumar Manjegowda
<Chetankumar_Manjegowda@mindtree.com> wrote:
>
> Hi All,
>
> I want to know how to enable/Integrate LLMNR for PAN profile.
>
> Can anyone give some suggestions or link where I can refer the same ??
>
> Rgds
> Chetan
>
> ________________________________
>
> http://www.mindtree.com/email/disclaimer.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
--
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Claudio Takahasi @ 2010-10-04 17:27 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <AANLkTin5RWCfX07xRUfVvkq+C47AOJXCCRpMVa-vqrRA@mail.gmail.com>
On Thu, Sep 30, 2010 at 6:51 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> On Thu, Sep 30, 2010 at 11:28 AM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>> On Thu, Sep 30, 2010 at 4:39 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>>> Hi Claudio,
>>>
>>> On Wed, Sep 29, 2010, Claudio Takahasi wrote:
>>>> StartDiscovery() triggers all the process. The adapter type: BR/EDR
>>>> only/LE only or dual mode is hidden from the higher layers.
>>>> So, your suggestion it try to hide all discovery details inside the
>>>> hciops as much as possible?
>>>
>>> That was the idea yes, but I'm not 100% sure that it's the best
>>> approach. Another question is also how do we want to represent this with
>>> the new management interface. Should the kernel do it "all" through a
>>> single request from userspace or should userspace control the separate
>>> BR/EDR and LE discoveries. If it's the former, then having a single
>>> adapter_ops callback makes sense. If it's the later then we should
>>> probably have two separate ones. Either way I now realize that to
>>> implement this with a single callback we'd need to have the HCI event
>>> processing moved over to hciops and that's not something that will
>>> happen very quickly. So maybe it's better to have these as two separate
>>> adapter_ops callbacks for now.
>>>
>>> Johan
>>>
>>
>> Another point is: scanning needs to be disabled "actively", it is not
>> possible to inform a scanning length like inquiry, it is necessary to
>> create a timeout to disable the scanning. Joining inquiry and scanning
>> inside a single adapter_ops callback will be hard to control the
>> discovery procedure "states". So for now, I prefer two separate
>> callbacks due the scanning timeout and HCI events processing.
>>
>> However, for the new management interface, one single request seems to
>> be more appropriate but extra requests will be necessary to setup the
>> scan and inquiry parameters.
>>
>> Claudio
>>
>
> New pull request! Patches rebased and a new hciops callback function
> has been added to export the write LE host supported command.
>
> The following changes since commit 3a8386d428e385d97b95a890623362321a7e3a19:
>
> Fix left open socket warning for attribute server (2010-09-30 17:26:55 -0300)
>
> are available in the git repository at:
> git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
>
> Claudio Takahasi (23):
> Add LE start and stop scanning
> Remove RSSI field from the advertising report event
> Decoding the RSSI parameter from the advertising report event
> Send Discovering property "FALSE" when the interleave finishes
> Add length argument on hciops start discovery function
> Stop inquiry using the length parameter
> Fix remote name resolution for interleave discovery
> Add Write LE host supported function
> Set the LE host supported and disable simultaneous LE and BR/EDR flags
> Add extended feature mask constants definition
> Read the local extended features
> Stop LE scanning when discovery is suspended
> Rename hciops {start, stop}_discovery to {start, stop}_inquiry
> Don't enter on interleave mode if there isn't active sessions
> Code cleanup: improving inquiry logic
> Clear the remote device found list in the state transition
> Fix periodic inquiry signals
> Fixing DeviceDisappeared signal
> Postpone discovery if still resolving names
> Add adapter discovery type function
> Do not send another Discovering TRUE signal if still resolving names
> Forcing periodic inquiry exit
> Fix interleave scanning
>
> Vinicius Costa Gomes (1):
> Add BR/EDR LE interleaved discovery
>
> lib/hci.c | 29 +++++
> lib/hci.h | 17 +++-
> lib/hci_lib.h | 1 +
> plugins/hciops.c | 69 +++++++++++-
> src/adapter.c | 301 +++++++++++++++++++++++++++++++++++++-----------------
> src/adapter.h | 38 ++++---
> src/dbus-hci.c | 45 +++++++--
> src/dbus-hci.h | 1 +
> src/security.c | 131 ++++++++++++++----------
> 9 files changed, 449 insertions(+), 183 deletions(-)
>
The following changes since commit 19c8e310329bb6b369f11501afec9ff4223c2971:
Allow errors to propagate from connection callback (2010-10-04 17:06:49 +0200)
are available in the git repository at:
git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
Claudio Takahasi (23):
Add LE start and stop scanning
Remove RSSI field from the advertising report event
Decoding the RSSI parameter from the advertising report event
Send Discovering property "FALSE" when the interleave finishes
Add length argument on hciops start discovery function
Stop inquiry using the length parameter
Fix remote name resolution for interleave discovery
Add Write LE host supported function
Set the LE host supported and disable simultaneous LE and BR/EDR flags
Add extended feature mask constants definition
Read the local extended features
Stop LE scanning when discovery is suspended
Rename hciops {start, stop}_discovery to {start, stop}_inquiry
Don't enter on interleave mode if there isn't active sessions
Code cleanup: improving inquiry logic
Clear the remote device found list in the state transition
Fix periodic inquiry signals
Fixing DeviceDisappeared signal
Postpone discovery if still resolving names
Add adapter discovery type function
Do not send another Discovering TRUE signal if still resolving names
Forcing periodic inquiry exit
Fix interleave scanning
Vinicius Costa Gomes (1):
Add BR/EDR LE interleaved discovery
lib/hci.c | 29 +++++
lib/hci.h | 17 +++-
lib/hci_lib.h | 1 +
plugins/hciops.c | 69 +++++++++++-
src/adapter.c | 301 +++++++++++++++++++++++++++++++++++++-----------------
src/adapter.h | 38 ++++---
src/dbus-hci.c | 45 +++++++--
src/dbus-hci.h | 1 +
src/security.c | 131 ++++++++++++++----------
9 files changed, 449 insertions(+), 183 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: hci open callback for hci UART transport driver
From: Suraj Sumangala @ 2010-10-04 17:29 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth@vger.kernel.org, Jothikumar Mothilal
In-Reply-To: <4CA44AF2.7050908@Atheros.com>
Hi,
On 9/30/2010 2:01 PM, Suraj Sumangala wrote:
> *ping*
>
> On 9/21/2010 7:03 PM, Suraj Sumangala wrote:
>> This patch provides option for hci transport driver protocol implementation
>> to have a callback for hci open.
>>
>> Signed-off-by: Suraj Sumangala<suraj@atheros.com>
>> ---
>> drivers/bluetooth/hci_ldisc.c | 5 ++++-
>> drivers/bluetooth/hci_uart.h | 1 +
>> 2 files changed, 5 insertions(+), 1 deletions(-)
>>
>
> Regards
> Suraj
Is there any comments on this patch?
Regards
Suraj
^ 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