* Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Jose Antonio Santos Cadenas @ 2010-10-11 12:25 UTC (permalink / raw)
To: linux-bluetooth
The following changes since commit 646f0c7e6b557c5413825ce7b04bee52bf0129e8:
Move remote name and version requests to hciops (2010-10-10 22:44:25 +0100)
are available in the git repository at:
git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
José Antonio Santos Cadenas (6):
Remove mdl_conn from struct hdp_channel
Remove app paramter from hdp_establish_mcl, it is not needed
Imcoming connection in control channel should be ERTM
Fix multiple emission of main channel property signal.
Return MCAP_MDL_BUSY when health channel can't be created
Implement callback for responding echo petitions
Santiago Carot-Nemesio (6):
Add a new function to create channels
Process request of of echo channels creation
Correctly notify the deletion of the reliable data channel
Add extra checks for avoid notifiying incoming echo channels
Delete all channels DBus interface when the instance is removed
Check first reliable configuration during channel creation
health/hdp.c | 249 +++++++++++++++++++++++++++++++++++----------------
health/hdp_types.h | 3 +-
health/hdp_util.c | 3 -
health/hdp_util.h | 1 -
health/mcap.c | 1 +
5 files changed, 174 insertions(+), 83 deletions(-)
^ permalink raw reply
* Re: How add support of LLMNR for PAN
From: Arun K. Singh @ 2010-10-11 11:17 UTC (permalink / raw)
To: Chetankumar Manjegowda; +Cc: linux-bluetooth
In-Reply-To: <52A922E83075C847A59D7DF98C660175018842@MTW02MBX03.mindtree.com>
Hello Chetan,
Based on my limited understanding of networking, avahi should
implement DNS-SD on Linux, which is quite close to Microsoft's version
of LLMNR. You may also want to use any other utility that may be
required for supporting Link-local addresses etc on your host distro.
But from Bluez perspective, pand should be really transparent as long
as endpoints TCP/IP stacks support LLMNR or similar variants of LL
name resolution protocols. It is pretty much a TCP/IP stack feature or
so I believe.
Good Luck!
--
Best Regards,
Arun Kumar Singh
www.crazydaks.com
On Tue, Oct 5, 2010 at 10:17 AM, Chetankumar Manjegowda
<Chetankumar_Manjegowda@mindtree.com> wrote:
>
> Hi Arun,
> Thanks for your reply.
>
> I am new to networking I am not sure about that.
>
> I want to send LLMNR query so i am planning to use avahi-0.6.27(avahi-autoipd) is this is fine or any other is available ?
>
> Rgds
> Chetan
>
>
> -----Original Message-----
> From: Arun Kumar [mailto:arunkat@gmail.com]
> Sent: Monday, October 04, 2010 9:06 PM
> To: Chetankumar Manjegowda
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: How add support of LLMNR for PAN
>
> 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: [PATCH 1/7] Bluetooth: Add low energy commands and events
From: Ville Tervo @ 2010-10-11 8:06 UTC (permalink / raw)
To: ext Gustavo F. Padovan; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101007163111.GA4893@vigoh>
Hi,
On Thu, Oct 07, 2010 at 06:31:11PM +0200, ext Gustavo F. Padovan wrote:
> Hi Marcel,
>
> * Marcel Holtmann <marcel@holtmann.org> [2010-10-07 12:08:25 +0200]:
>
> > Hi Ville,
> >
> > > Add needed HCI command and event to create LE connections.
> > >
> > > Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> >
> > Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
> There is a comment in patch 3/7 from Anderson that may affect this
> patch, so I'm going to wait Ville say if he actually want to remove that
> piece of the code or not to merge this one in the tree.
Yes I already have fixed version in my tree. I'll fix go through Marcel's other
suggestions also and send V2.
--
Ville
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Senthil Balasubramanian @ 2010-10-11 7:14 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Suraj Sumangala, Marcel Holtmann, David Woodhouse,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1286611288.6145.430.camel@aeonflux>
On Sat, Oct 09, 2010 at 01:31:28PM +0530, Marcel Holtmann wrote:
> Hi Luis,
>
> > What is the difference between ath3k-2.fw and ath3k-1.fw ?
> >
> > Won't the API change now that you are addressing the sflash
> > configuration fix? Would it not help to identify the two
> > different firmwares then?
> >
> > David, Marcel, what are your preferences for a firmware upgrade
> > where the firmware does not change API (lets just pretend it does
> > not for a moment) ? Do we keep the same filename?
>
> that is what most companies do and that is what iwlwifi has done so far.
Luis
this is what we have been doing for our ath9k_htc driver. We kept the same
fie name for firmware updates as we haven't changed any APIs/interfaces that
host driver depends on.
> Only if the API breaks a different suffix is used.
>
> With Bluetooth this should be never needed at all. The reason is that
> you need to expose Bluetooth HCI. And that has generic version, support
> commands and supported features commands.
>
> We are not even using the version information for anything useful these
> days since the firmware has to identify its features and its supported
> commands with standard HCI commands. So it is pretty simple to detect
> what Bluetooth subsystem needs to do.
>
> > In this particular case I would assume our new sflash configuration
> > fix that might be being worked on might change the re-enumerated
> > USB device IDs so it seems to me a good idea to use a new filename.
> > I should note ath3k-2.fw already made it to linux-firmware.git...
>
> No it does not. The changed PID is not a breakage. It will just keep
> working. So please fix this in linux-firmware.git right away and remove
> the new firmware file.
>
> And here is something that is wrong with your process as well. Don't
> submit firmware files upstream before the upstream maintainers accepted
> your driver or patch.
>
> I know it is nice to have the firmware available quickly, but if your
> driver gets rejected for the reason we have stated in this thread, you
> have dangling firmware somewhere.
>
> > I last tried to document a thread we had over this here:
> >
> > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> >
> > Does this sound sane? If so then the sflash configuration fix
> > would seem to me like it would require a new filename. Now, while
> > we're at it, how about bug fixes?
>
> If your firmware files are identical and the exposed API is identical
> (in this case Bluetooth HCI), then you do NO need a new filename.
>
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Reduction memory leaks in phonebook module
From: Johan Hedberg @ 2010-10-09 15:26 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinLGQj+CSGRK+UX2oVyCW-XOsq_U4ZQTYuYRC1n@mail.gmail.com>
Hi Rafał,
On Fri, Oct 08, 2010, Rafał Michalski wrote:
> From 40399b62ec62569213948f7eb77fd39d1ff42ea1 Mon Sep 17 00:00:00 2001
> From: Rafal Michalski <michalski.raf@gmail.com>
> Date: Fri, 8 Oct 2010 15:16:50 +0200
> Subject: [PATCH] Reduction memory leaks in phonebook module
>
> Memory, pointed by pointers home_addr and work_addr, is allocated
> temporarily and not freed. Only duplicates of this memory (made after
> invoking add_address function) are freed later.
> ---
> plugins/phonebook-tracker.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
Thanks. The patch has been pushed to the upstream obexd tree.
Johan
^ permalink raw reply
* Re: [PATCH] Add support for Attribute Write Request
From: Johan Hedberg @ 2010-10-09 15:23 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1286474561-23905-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Thu, Oct 07, 2010, Anderson Lizardo wrote:
> Implement encoders/decoders for Write Request/Response and the handling
> on attribute server. The attribute client still uses the Write Command
> because currently SetProperty() has no means to wait for the server
> response.
> ---
> attrib/att.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
> attrib/att.h | 4 ++++
> attrib/gatt.c | 11 +++++++++++
> attrib/gatt.h | 3 +++
> src/attrib-server.c | 12 +++++++++++-
> 5 files changed, 79 insertions(+), 1 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Sort TODO by priority
From: Johan Hedberg @ 2010-10-09 15:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286468515-20738-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 07, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Items shall be sorted by priority and latter by complexity so that tasks
> with higher priority and lower complexity always appear on top.
> ---
> TODO | 58 +++++++++++++++++++++++++++++-----------------------------
> 1 files changed, 29 insertions(+), 29 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Fix problem with invalid read from array
From: Johan Hedberg @ 2010-10-09 15:12 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTim4tHR+3ccDJi+X8jLDiZo+PXTQjfCWtZ85bhjZ@mail.gmail.com>
Hi Lukasz,
On Fri, Oct 08, 2010, Lukasz Pawlik wrote:
> Attaching patch without change in src/adapter.c file.
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* Upon Kernel Update Bluetooth Hardware is Not Functioning.
From: Brian Edward Benedict @ 2010-10-09 14:23 UTC (permalink / raw)
To: linux-bluetooth
I have reason to believe that 2.6.34.7-56 has bluetooth issues. I am
running an Imac with the standard form over function apple keyboard.
Previously this keyboard has worked flawlessly with ubuntu but upon my
update to the latest kernel in ubuntu 10.04 lucid the keyboard stopped
working and I had to continually use the previous kernel. I switched to
fedora to see if the problem would follow and sure enough upon updating
the kernel (from 2.6.33.3-85) the keyboard is non-functioning. This
problem appears on both ubuntu and fedora so I take that to mean it is
not distro specific.
To the best of my knowledge this is a bluetooth problem because when I
managed to login to my user account using the on-screen keyboard when I
then proceeeded to push keyboard buttons a little dialog popped up
asking if I would allow a bluetooth device to connect but no matter how
many times I clicked accept it would not work, I then proceeded to
install fedora and as I said before, it is still happening.
--
Regards,
Brian Benedict
^ permalink raw reply
* Re: [PATCH] Use a valid PSM as the default in l2test.
From: Marcel Holtmann @ 2010-10-09 8:09 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, johan.hedberg, rshaffer, gustavo
In-Reply-To: <alpine.DEB.2.00.1010080809510.31147@linux-sea-02>
Hi Mat,
> The Bluetooth spec requires PSMs to be odd numbers, with the least
> significant bit of the most significant byte set to 0. This
> change is a prerequisite for PSM validation in the kernel.
> ---
> test/l2test.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
it does not apply.
Applying: Use a valid PSM as the default in l2test.
error: patch failed: test/l2test.c:87
error: test/l2test.c: patch does not apply
Patch failed at 0001 Use a valid PSM as the default in l2test.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: update MAINTAINERS for Bluetooth subsys
From: Marcel Holtmann @ 2010-10-09 8:07 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1286540658-2890-1-git-send-email-padovan@profusion.mobi>
Hi Gustavo,
> Add myself to MAINTAINERS and update the git trees.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Marcel Holtmann @ 2010-10-09 8:06 UTC (permalink / raw)
To: Sven-Haegar Koch
Cc: Luis R. Rodriguez, Suraj Sumangala, Luis Rodriguez,
David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless
In-Reply-To: <alpine.DEB.2.02.1010090040240.19472@aurora.sdinet.de>
Hi Sven-Haeger,
> > > > I last tried to document a thread we had over this here:
> > > >
> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > > >
> >
> > Thanks, I've updated that link above to document bug fixing does not require
> > a filename change.
>
> I would summarize it as:
>
> If a new firmware version also works with an old driver, keep the filename.
correct.
> If a new firmware version also requires a new driver, change the name.
>
> If a new driver requires a new firmware, change the name.
These two depend. The exposed API stays the same. The firmware file
itself is the same. Just the loading procedure is different. So no need
to change the firmware name.
Let me repeat this. If the API of the firmware exposed after loading it,
breaks or is incompatible, then you need a new name.
If you have generic commands to detect features in the firmware, then
you should never be needed to change your firmware name. So you could
extend the API as much as you like with keeping the same name.
The different firmware names are for the driver to be able to detect the
API of the firmware. And only if that is only possible via the filename
you should use different filenames. Otherwise don't bother and use the
generic feature detection of the firmware itself.
And for Bluetooth in specific that is HCI. So any company needed
different firmware filenames for Bluetooth have done something really
really wrong in their development cycles.
Regards
Marcel
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Marcel Holtmann @ 2010-10-09 8:01 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Suraj Sumangala, David Woodhouse, linux-bluetooth, linux-kernel,
linux-wireless
In-Reply-To: <20101008170258.GJ10149@tux>
Hi Luis,
> What is the difference between ath3k-2.fw and ath3k-1.fw ?
>
> Won't the API change now that you are addressing the sflash
> configuration fix? Would it not help to identify the two
> different firmwares then?
>
> David, Marcel, what are your preferences for a firmware upgrade
> where the firmware does not change API (lets just pretend it does
> not for a moment) ? Do we keep the same filename?
that is what most companies do and that is what iwlwifi has done so far.
Only if the API breaks a different suffix is used.
With Bluetooth this should be never needed at all. The reason is that
you need to expose Bluetooth HCI. And that has generic version, support
commands and supported features commands.
We are not even using the version information for anything useful these
days since the firmware has to identify its features and its supported
commands with standard HCI commands. So it is pretty simple to detect
what Bluetooth subsystem needs to do.
> In this particular case I would assume our new sflash configuration
> fix that might be being worked on might change the re-enumerated
> USB device IDs so it seems to me a good idea to use a new filename.
> I should note ath3k-2.fw already made it to linux-firmware.git...
No it does not. The changed PID is not a breakage. It will just keep
working. So please fix this in linux-firmware.git right away and remove
the new firmware file.
And here is something that is wrong with your process as well. Don't
submit firmware files upstream before the upstream maintainers accepted
your driver or patch.
I know it is nice to have the firmware available quickly, but if your
driver gets rejected for the reason we have stated in this thread, you
have dangling firmware somewhere.
> I last tried to document a thread we had over this here:
>
> http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
>
> Does this sound sane? If so then the sflash configuration fix
> would seem to me like it would require a new filename. Now, while
> we're at it, how about bug fixes?
If your firmware files are identical and the exposed API is identical
(in this case Bluetooth HCI), then you do NO need a new filename.
Regards
Marcel
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Sven-Haegar Koch @ 2010-10-08 22:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Suraj Sumangala, Luis Rodriguez, David Woodhouse, Marcel Holtmann,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <20101008181508.GM10149@tux>
On Fri, 8 Oct 2010, Luis R. Rodriguez wrote:
> > > I last tried to document a thread we had over this here:
> > >
> > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > >
>
> Thanks, I've updated that link above to document bug fixing does not require
> a filename change.
I would summarize it as:
If a new firmware version also works with an old driver, keep the filename.
If a new firmware version also requires a new driver, change the name.
If a new driver requires a new firmware, change the name.
c'ya
sven-haegar
--
Three may keep a secret, if two of them are dead.
- Ben F.
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Luis R. Rodriguez @ 2010-10-08 18:15 UTC (permalink / raw)
To: Suraj Sumangala
Cc: Luis Rodriguez, David Woodhouse, Marcel Holtmann, linux-bluetooth,
linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <4CAF5488.3030706@Atheros.com>
On Fri, Oct 08, 2010 at 10:27:36AM -0700, Suraj Sumangala wrote:
> Hi Luis,
>
> On 10/8/2010 10:32 PM, Luis Rodriguez wrote:
> > Suraj,
> >
> > What is the difference between ath3k-2.fw and ath3k-1.fw ?
>
> This is the same question for which I have been trying to get an answer.
> The only information that I got was it fixes some critical bug and
> support shared antenna.
>
> If ath3k-2.fw is an upgrade of ath3k-1.fw why do we need to name it
> differently?
Sure, agreed, but what about the sflash configuration fix?
> > Won't the API change now that you are addressing the sflash
> > configuration fix? Would it not help to identify the two
> > different firmwares then?
> >
> > David, Marcel, what are your preferences for a firmware upgrade
> > where the firmware does not change API (lets just pretend it does
> > not for a moment) ? Do we keep the same filename?
>
> Marcel had answered me before. It makes sense to have same file name.
> Other ways we end up changing the driver whenever there is a firmware
> change.
> > I last tried to document a thread we had over this here:
> >
> > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> >
Thanks, I've updated that link above to document bug fixing does not require
a filename change.
Luis
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Suraj Sumangala @ 2010-10-08 17:27 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Suraj Sumangala, David Woodhouse, Marcel Holtmann,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <20101008170258.GJ10149@tux>
Hi Luis,
On 10/8/2010 10:32 PM, Luis Rodriguez wrote:
> Suraj,
>
> What is the difference between ath3k-2.fw and ath3k-1.fw ?
This is the same question for which I have been trying to get an answer.
The only information that I got was it fixes some critical bug and
support shared antenna.
If ath3k-2.fw is an upgrade of ath3k-1.fw why do we need to name it
differently?
>
> Won't the API change now that you are addressing the sflash
> configuration fix? Would it not help to identify the two
> different firmwares then?
>
> David, Marcel, what are your preferences for a firmware upgrade
> where the firmware does not change API (lets just pretend it does
> not for a moment) ? Do we keep the same filename?
Marcel had answered me before. It makes sense to have same file name.
Other ways we end up changing the driver whenever there is a firmware
change.
>
> In this particular case I would assume our new sflash configuration
> fix that might be being worked on might change the re-enumerated
> USB device IDs so it seems to me a good idea to use a new filename.
> I should note ath3k-2.fw already made it to linux-firmware.git...
>
> I last tried to document a thread we had over this here:
>
> http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
>
> Does this sound sane? If so then the sflash configuration fix
> would seem to me like it would require a new filename. Now, while
> we're at it, how about bug fixes?
>
> Suraj -- keep these discussions public please....
>
> Luis
Regards
Suraj
^ permalink raw reply
* Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Luis R. Rodriguez @ 2010-10-08 17:02 UTC (permalink / raw)
To: Suraj Sumangala, David Woodhouse, Marcel Holtmann
Cc: linux-bluetooth, linux-kernel, linux-wireless
Suraj,
What is the difference between ath3k-2.fw and ath3k-1.fw ?
Won't the API change now that you are addressing the sflash
configuration fix? Would it not help to identify the two
different firmwares then?
David, Marcel, what are your preferences for a firmware upgrade
where the firmware does not change API (lets just pretend it does
not for a moment) ? Do we keep the same filename?
In this particular case I would assume our new sflash configuration
fix that might be being worked on might change the re-enumerated
USB device IDs so it seems to me a good idea to use a new filename.
I should note ath3k-2.fw already made it to linux-firmware.git...
I last tried to document a thread we had over this here:
http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
Does this sound sane? If so then the sflash configuration fix
would seem to me like it would require a new filename. Now, while
we're at it, how about bug fixes?
Suraj -- keep these discussions public please....
Luis
^ permalink raw reply
* [PATCH] Use a valid PSM as the default in l2test.
From: Mat Martineau @ 2010-10-08 15:16 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, rshaffer, gustavo
---------- Forwarded message ----------
Date: Wed, 4 Aug 2010 15:31:13 -0700
From: Mat Martineau <mathewm@codeaurora.org>
To: linux-bluetooth@vger.kernel.org
Cc: marcel@holtmann.org, johan.hedberg@gmail.com, rshaffer@codeaurora.org,
Mat Martineau <mathewm@codeaurora.org>
Subject: [PATCH] Use a valid PSM as the default in l2test.
The Bluetooth spec requires PSMs to be odd numbers, with the least
significant bit of the most significant byte set to 0. This
change is a prerequisite for PSM validation in the kernel.
---
test/l2test.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test/l2test.c b/test/l2test.c
index 0bb46f3..32cd27a 100644
--- a/test/l2test.c
+++ b/test/l2test.c
@@ -87,7 +87,7 @@ static long buffer_size = 2048;
/* Default addr and psm */
static bdaddr_t bdaddr;
-static unsigned short psm = 10;
+static unsigned short psm = 0x1001;
/* Default number of frames to send (-1 = infinite) */
static int num_frames = -1;
--
1.7.1
Ping. Marcel requested this patch to go with the "Validate PSM values
in calls to connect() and bind()" change to the kernel code.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* RE: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Savoy, Pavan @ 2010-10-08 14:54 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo F. Padovan
Cc: linux-bluetooth@vger.kernel.org, greg@kroah.com,
linux-kernel@vger.kernel.org
In-Reply-To: <1286527062.6145.182.camel@aeonflux>
> -----Original Message-----
> From: Marcel Holtmann [mailto:marcel@holtmann.org]
> Sent: Friday, October 08, 2010 3:38 AM
> To: Gustavo F. Padovan
> Cc: Savoy, Pavan; linux-bluetooth@vger.kernel.org; greg@kroah.com; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
>=20
> Hi Gustavo,
>=20
> > Change the commit subject to "Bluetooth: TI_ST bluetooth driver"
> >
> > * pavan_savoy@ti.com <pavan_savoy@ti.com> [2010-10-07 14:47:16 -0400]:
> >
> > > From: Pavan Savoy <pavan_savoy@ti.com>
> > >
> > > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > like BT, FM, GPS and WLAN onto a single chip.
> > >
> > > This Bluetooth driver works on top of the TI_ST shared transport
> > > line discipline driver which also allows other drivers like
> > > FM V4L2 and GPS character driver to make use of the same UART interfa=
ce.
> > >
> > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > ---
> > > drivers/bluetooth/bt_ti.c | 489
> +++++++++++++++++++++++++++++++++++++++++++++
> > > 1 files changed, 489 insertions(+), 0 deletions(-)
> > > create mode 100644 drivers/bluetooth/bt_ti.c
> >
> > We don't have filename with bt_.. in drivers/bluetooth/. Maybe ti_st.c
> > should be a better name, or something like that.
>=20
> actually we have the bt prefix for company generic ones where they
> didn't wanna use the hardware name.
>=20
> So I prefer to use the hardware for a driver since it is much more clear
> that way. You acronym naming here is bad. It is confusing like hell.
>=20
> What about just calling this btwilink.c or something. I just spinning
> ideas here.
Ok, I like btwilink.c too. Does bt_wilink.c sound OK?
I have sent a patch with ti_st.c as of now.
Please review, and provide comments. I will incorporate comments and change
Name in the next version of the patch.
Thanks,
Pavan
> Regards
>=20
> Marcel
>=20
^ permalink raw reply
* RE: Sim Access profile server implementation
From: Waldemar.Rymarkiewicz @ 2010-10-08 14:27 UTC (permalink / raw)
To: marcel
Cc: suraj, linux-bluetooth, Jothikumar.Mothilal, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <1286466136.6145.159.camel@aeonflux>
Hi Marcel,=20
>in general I am fine if we do this similar to what we do with=20
>the different telephony backend. So yes, go ahead with this.
>
>However, please clean this up. The patch needs a lot of work=20
>before it would be ready upstream. And of course it requires a=20
>dummy SAP plugin as well. Same as we do have for telephony.
>
Then, I will prepare it for upstream.=20
Regards,
/Waldek
^ permalink raw reply
* [PATCH] Reduction memory leaks in phonebook module
From: Rafał Michalski @ 2010-10-08 14:00 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Reduction-memory-leaks-in-phonebook-module.patch --]
[-- Type: text/x-patch, Size: 965 bytes --]
From 40399b62ec62569213948f7eb77fd39d1ff42ea1 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Fri, 8 Oct 2010 15:16:50 +0200
Subject: [PATCH] Reduction memory leaks in phonebook module
Memory, pointed by pointers home_addr and work_addr, is allocated
temporarily and not freed. Only duplicates of this memory (made after
invoking add_address function) are freed later.
---
plugins/phonebook-tracker.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index c10491d..d0cea2e 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1007,6 +1007,9 @@ add_numbers:
add_address(contact, home_addr, ADDR_TYPE_HOME);
add_address(contact, work_addr, ADDR_TYPE_WORK);
+ g_free(home_addr);
+ g_free(work_addr);
+
DBG("contact %p", contact);
/* Adding contacts data to wrapper struct - this data will be used to
--
1.6.3.3
^ permalink raw reply related
* [PATCH] Bluetooth: update MAINTAINERS for Bluetooth subsys
From: Gustavo F. Padovan @ 2010-10-08 12:24 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel
Add myself to MAINTAINERS and update the git trees.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
MAINTAINERS | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ddb5ac..07ca793 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1351,16 +1351,19 @@ F: drivers/mtd/devices/block2mtd.c
BLUETOOTH DRIVERS
M: Marcel Holtmann <marcel@holtmann.org>
+M: Gustavo F. Padovan <padovan@profusion.mobi>
L: linux-bluetooth@vger.kernel.org
W: http://www.bluez.org/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
S: Maintained
F: drivers/bluetooth/
BLUETOOTH SUBSYSTEM
M: Marcel Holtmann <marcel@holtmann.org>
+M: Gustavo F. Padovan <padovan@profusion.mobi>
L: linux-bluetooth@vger.kernel.org
W: http://www.bluez.org/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
S: Maintained
F: net/bluetooth/
F: include/net/bluetooth/
--
1.7.3.1
^ permalink raw reply related
* Re: Peculiar stuff in hci_ath3k/badness in hci_uart
From: Alan Cox @ 2010-10-08 10:48 UTC (permalink / raw)
To: Suraj Sumangala
Cc: linux-kernel@vger.kernel.org, marcel@holtmann.org,
linux-bluetooth@vger.kernel.org
In-Reply-To: <4CAEE1DB.1070202@Atheros.com>
On Fri, 8 Oct 2010 14:48:19 +0530
Suraj Sumangala <suraj@Atheros.com> wrote:
> Hi Alan,
>
> On 10/8/2010 2:11 AM, Alan Cox wrote:
> > Noticed this while looking at Savoy's stuff
> >
> >
> > ath_wakeup_ar3k:
> >
> > int status = tty->driver->ops->tiocmget(tty, NULL);
> >
> I agree, it will be a problem if the underlying driver try to access the
> "struct file". Is there any other way I can get the MCR status here
> without providing user space pointer?
Currently no - that should get fixed in the tty layer and I will look
into it end of next week as a priority.
Alan
^ permalink raw reply
* Re: Peculiar stuff in hci_ath3k/badness in hci_uart
From: Suraj Sumangala @ 2010-10-08 9:18 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel@vger.kernel.org, marcel@holtmann.org,
linux-bluetooth@vger.kernel.org
In-Reply-To: <20101007214134.6bcd2e8f@lxorguk.ukuu.org.uk>
Hi Alan,
On 10/8/2010 2:11 AM, Alan Cox wrote:
> Noticed this while looking at Savoy's stuff
>
>
> ath_wakeup_ar3k:
>
> int status = tty->driver->ops->tiocmget(tty, NULL);
>
I agree, it will be a problem if the underlying driver try to access the
"struct file". Is there any other way I can get the MCR status here
without providing user space pointer?
>
> Fortunately I looked further and the further I looked the more fun it gets
>
> in hci_uart we have
>
> len = tty->ops->write(tty, skb->data, skb->len);
>
Regards
Suraj
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Marcel Holtmann @ 2010-10-08 8:37 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: pavan_savoy, linux-bluetooth, greg, linux-kernel
In-Reply-To: <20101007184534.GB13602@vigoh>
Hi Gustavo,
> Change the commit subject to "Bluetooth: TI_ST bluetooth driver"
>
> * pavan_savoy@ti.com <pavan_savoy@ti.com> [2010-10-07 14:47:16 -0400]:
>
> > From: Pavan Savoy <pavan_savoy@ti.com>
> >
> > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > Texas Instrument's WiLink chipsets combine wireless technologies
> > like BT, FM, GPS and WLAN onto a single chip.
> >
> > This Bluetooth driver works on top of the TI_ST shared transport
> > line discipline driver which also allows other drivers like
> > FM V4L2 and GPS character driver to make use of the same UART interface.
> >
> > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > ---
> > drivers/bluetooth/bt_ti.c | 489 +++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 489 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/bluetooth/bt_ti.c
>
> We don't have filename with bt_.. in drivers/bluetooth/. Maybe ti_st.c
> should be a better name, or something like that.
actually we have the bt prefix for company generic ones where they
didn't wanna use the hardware name.
So I prefer to use the hardware for a driver since it is much more clear
that way. You acronym naming here is bad. It is confusing like hell.
What about just calling this btwilink.c or something. I just spinning
ideas here.
Regards
Marcel
^ 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