* RE: [PATCH 1/2] Sim Access Profile API
From: Waldemar.Rymarkiewicz @ 2010-12-01 11:12 UTC (permalink / raw)
To: marcel; +Cc: johan.hedberg, linux-bluetooth
In-Reply-To: <1291200591.4795.95.camel@aeonflux>
Hi Marcel,=20
>From: Marcel Holtmann [mailto:marcel@holtmann.org]=20
>Hi Waldemar,
>
>
>do we want this really as property? Wouldn't be configuration=20
>option be better to enable this. None of the other profiles=20
>has this anymore.=20
Well, that is actually a proposal and I don't see any problems if we go for=
conf options in here. Even more, that would be if fact more usef-ull. Is =
the main.conf a right place for say EnableSAP=3Dtrue option ?
>And if their server depends on external=20
>programs then it either goes via an agent or some method call=20
>that can be easily tracked.
>
I'm not sure I get it. Do you mean if an external program needs to enable s=
ap they will use method call?=20
Regards,
/Waldek
^ permalink raw reply
* Re: [PATCH 1/2] Sim Access Profile API
From: Marcel Holtmann @ 2010-12-01 10:49 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <1291113364-6401-2-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi Waldemar,
> New API for Sim Access Profile.
> ---
> Makefile.am | 2 +-
> doc/sap-api.txt | 47 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 48 insertions(+), 1 deletions(-)
> create mode 100644 doc/sap-api.txt
>
> diff --git a/Makefile.am b/Makefile.am
> index 5f96975..97345a3 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -354,7 +354,7 @@ EXTRA_DIST += doc/manager-api.txt \
> doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
> doc/serial-api.txt doc/network-api.txt \
> doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
> - doc/hfp-api.txt doc/assigned-numbers.txt
> + doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
>
> AM_YFLAGS = -d
>
> diff --git a/doc/sap-api.txt b/doc/sap-api.txt
> new file mode 100644
> index 0000000..4e5626e
> --- /dev/null
> +++ b/doc/sap-api.txt
> @@ -0,0 +1,47 @@
> +BlueZ D-Bus Sim Access Profile API description
> +***********************************
> +
> +Copyright (C) 2010 ST-Ericsson SA
> +
> +
> +Sim Access Profile hierarchy
> +============================
> +
> +Service org.bluez
> +Interface org.bluez.SimAccess
> +Object path [variable prefix]/{hci0,hci1,...}
> +
> +Methods void Disconnect()
> +
> + Disconnects SAP client from the server.
> +
> + Possible errors: org.bluez.Error.Failed
> +
> + void SetProperty(string name, variant value)
> +
> + Changes the value of the specified property. Only
> + properties that are listed a read-write are changeable.
> +
> + Possible Errors: org.bluez.Error.DoesNotExist
> + org.bluez.Error.InvalidArguments
> +
> + dict GetProperties()
> +
> + Return all properties for the interface. See the
> + properties section for available properties.
> +
> + Possible Errors: org.bluez.Error.Failed
> +
> +Signals PropertyChanged(string name, variant value)
> +
> + This signal indicates a changed value of the given
> + property.
> +
> +Properties boolean Enabled [readwrite]
> +
> + Set to true to start-up SAP server and register SDP record for
> + it. Set to false to shutdown SAP server and remove the SDP record.
do we want this really as property? Wouldn't be configuration option be
better to enable this. None of the other profiles has this anymore. And
if their server depends on external programs then it either goes via an
agent or some method call that can be easily tracked.
Regards
Marcel
^ permalink raw reply
* Re: [RFC 2/4] Bluetooth: clean up rfcomm code
From: Marcel Holtmann @ 2010-12-01 10:45 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Gustavo F. Padovan, linux-bluetooth
In-Reply-To: <AANLkTimDn_oVX2YMHhEAqyw=YpeYZuX5WL6mr_F463dC@mail.gmail.com>
Hi Andrei,
> > * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-11-26 17:22:43 +0200]:
> >
> >> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >>
> >> Remove extra spaces, assignments in if statement, zeroing static
> >> variables.
> >>
> >> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >> ---
> >> include/net/bluetooth/rfcomm.h | 18 +++++++++---------
> >> net/bluetooth/rfcomm/core.c | 8 ++++----
> >> net/bluetooth/rfcomm/sock.c | 5 +++--
> >> net/bluetooth/rfcomm/tty.c | 28 ++++++++++++++++------------
> >> 4 files changed, 32 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
> >> index 71047bc..6eac4a7 100644
> >> --- a/include/net/bluetooth/rfcomm.h
> >> +++ b/include/net/bluetooth/rfcomm.h
> >> @@ -1,5 +1,5 @@
> >> -/*
> >> - RFCOMM implementation for Linux Bluetooth stack (BlueZ).
> >> +/*
> >> + RFCOMM implementation for Linux Bluetooth stack (BlueZ)
> >> Copyright (C) 2002 Maxim Krasnyansky <maxk@qualcomm.com>
> >> Copyright (C) 2002 Marcel Holtmann <marcel@holtmann.org>
> >>
> >> @@ -11,13 +11,13 @@
> >> OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
> >> IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
> >> - CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
> >> - WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> >> - ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> >> + CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
> >> + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> >> + ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> >> OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >>
> >> - ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
> >> - COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> >> + ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
> >> + COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> >> SOFTWARE IS DISCLAIMED.
> >
> > Marcel refused a patch from me in the past because its was touching legal
> > stuff, so or you remove these changes for your patches or wait for
> > Marcel's comments here.
>
> I fixed extra spaces at the end of the sentences, no legal stuff
> touched in legal terms :-)
> I believe that it is better to have legal text identical to other
> parts of the kernel otherwise
> the legal stuff looks different when comparing with diff tools.
make it a separate patch and not just fix it while at it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add new PID for Atheros 3011
From: Marcel Holtmann @ 2010-12-01 10:44 UTC (permalink / raw)
To: Bala Shanmugam; +Cc: linux-bluetooth
In-Reply-To: <1290773146-4705-1-git-send-email-sbalashanmugam@atheros.com>
Hi Bala,
> Atheros 3011 has small sflash firmware and needs to be
> blacklisted in transport driver to load actual firmware
> in DFU driver.
>
> Signed-off-by: Bala Shanmugam <sbalashanmugam@atheros.com>
> ---
> drivers/bluetooth/ath3k.c | 4 ++++
> drivers/bluetooth/btusb.c | 3 +++
> 2 files changed, 7 insertions(+), 0 deletions(-)
looks good to me now.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] btusb: Fix log spamming due to autosuspend
From: Marcel Holtmann @ 2010-12-01 10:42 UTC (permalink / raw)
To: stefan.seyfried; +Cc: gregkh, linux-bluetooth, Stefan Seyfried, Oliver Neukum
In-Reply-To: <1291150148-14376-1-git-send-email-stefan.seyfried@googlemail.com>
Hi Stefan,
> If a device is autosuspended an inability to resubmit URBs is
> to be expected. Check the error code and only log real errors.
> (Now that autosuspend is default enabled for btusb, those log
> messages were happening all the time e.g. with a BT mouse)
>
> Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
we had a similar one some time ago, but I am fine with this one as well.
Actually this one might be a bit better since it still keeps some
errors.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] btusb: Fix log spamming due to autosuspend
From: Greg KH @ 2010-11-30 23:47 UTC (permalink / raw)
To: stefan.seyfried; +Cc: linux-bluetooth, Stefan Seyfried, Oliver Neukum
In-Reply-To: <1291150148-14376-1-git-send-email-stefan.seyfried@googlemail.com>
On Tue, Nov 30, 2010 at 09:49:08PM +0100, stefan.seyfried@googlemail.com wrote:
> From: Stefan Seyfried <seife+kernel@b1-systems.com>
>
> If a device is autosuspended an inability to resubmit URBs is
> to be expected. Check the error code and only log real errors.
> (Now that autosuspend is default enabled for btusb, those log
> messages were happening all the time e.g. with a BT mouse)
>
> Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> ---
> drivers/bluetooth/btusb.c | 9 ++++++---
This one doesn't go through me, sorry:
> ./scripts/get_maintainer.pl --file --roles drivers/bluetooth/btusb.c
Marcel Holtmann <marcel@holtmann.org> (maintainer:BLUETOOTH DRIVERS)
"Gustavo F. Padovan" <padovan@profusion.mobi> (maintainer:BLUETOOTH DRIVERS)
linux-bluetooth@vger.kernel.org (open list:BLUETOOTH DRIVERS)
linux-kernel@vger.kernel.org (open list)
Marcel and Gustavo are the ones that need to handle it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] btusb: Fix log spamming due to autosuspend
From: Stefan Seyfried @ 2010-11-30 21:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1291150148-14376-1-git-send-email-stefan.seyfried@googlemail.com>
On Tue, 30 Nov 2010 21:49:08 +0100
stefan.seyfried@googlemail.com wrote:
> From: Stefan Seyfried <seife+kernel@b1-systems.com>
>
> If a device is autosuspended an inability to resubmit URBs is
> to be expected. Check the error code and only log real errors.
> (Now that autosuspend is default enabled for btusb, those log
> messages were happening all the time e.g. with a BT mouse)
>
> Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
As Greg has told me, this needs to go through the bluetooth Maintainer.
Personally, with 2.6.37 having autosuspend enabled by default I think this
is pretty urgent, as it spams the log continuously when using a Bluetooth
mouse. So please forward this if deemed acceptable.
Thanks
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
^ permalink raw reply
* RE: [PATCHv4 0/7] Support for out of band association model
From: Mike Tsai @ 2010-11-30 21:26 UTC (permalink / raw)
To: Mike Tsai, Szymon Janc, linux-bluetooth@vger.kernel.org
In-Reply-To: <35B17FE5076C7040809188FBE7913F98406D68CFAB@SC1EXMB-MBCL.global.atheros.com>
Hi Szymon,
Correction on my comments below,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Mike Tsai
Sent: Tuesday, November 30, 2010 8:02 AM
To: Szymon Janc; linux-bluetooth@vger.kernel.org
Subject: RE: [PATCHv4 0/7] Support for out of band association model
Hi Szymon,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Szymon Janc
Sent: Tuesday, November 23, 2010 2:53 AM
To: linux-bluetooth@vger.kernel.org
Cc: Szymon Janc
Subject: [PATCHv4 0/7] Support for out of band association model
Changes in this version:
- code style/flow comments from Johan included
- changes in D-Bus OOB api - ReadLocalOobData and provider
register/unregister moved to adapter path (OobManager interface), provider
is registered per adapter now
- some bug fixes
Some things I'd like to collect comments about:
- OobManager interface could be only available on 2.1 or higher adapters
(this would require some adapter interface to be able check this in
dbusoob plugin)
- Agent's RequestPairing method name
- RequestPairing is called only on device accepting incoming connection when
it has OOB data for remote device (on RequestRemoteOobData event).
Consequence is that when only initiator has OOB data RequestPairing is not
called. We could store initiator's OOB capability in device structure (now
only auth and cap are stored) to be able to know if initiator has OOB data.
Yet, in such case RequestRemoteOobData on accepting device will not be
called and I have no idea where/when OOB capability should be check to call
RequestPairing (and reject pairing if necessary)..
[MTsai]7.7.44 Remote OOB Data Request Event.
If host has received remote peer's OOB data before pairing, the host shall set the "OOB present" flag of the peer device. This "OOB present" flag will be sent over the air as part of pairing process with lmp_ioCap_Req or lmp_iocap_rsp.
If either one of the devices have OOB data, then OOB shall be used to do the pairing.
The event "Remote OOB Data Request Event" shall be sent to host before calculating the commitment value.
The LM state machine shall call "device_request_oob_data" when either local or remote peer has "OOB data present". I think this part of the code is not present.
[Mtsai correction]
The local OOB data present is set when host send HCI command "Read Local OOB Data". And this "OOB data present" flag is sent over the air to peer device during pairing.
The LM state machine is inside the controller firmware, so there is no issue on the stack code you submitted.
Comments are welcome.
BR,
Szymon Janc
on behalf of ST-Ericsson
Szymon Janc (7):
Add support for Out of Band (OOB) association model
Add D-Bus OOB plugin
Add D-Bus OOB API documentation
Add simple-oobprovider for testing
Add request for accepting incoming pairing requests with OOB
mechanism
Update D-Bus OOB API with RequestPairing method
Add RequestPairing method in simple-agent for accepting incoming OOB
pairing requests
Makefile.am | 10 +-
acinclude.m4 | 6 +
doc/oob-api.txt | 76 +++++++++
doc/oob-api.txt.orig | 79 +++++++++
lib/hci.h | 3 +
plugins/dbusoob.c | 412 +++++++++++++++++++++++++++++++++++++++++++++++
plugins/hciops.c | 107 +++++++++++--
src/adapter.c | 21 +++-
src/adapter.h | 10 ++
src/agent.c | 59 +++++++-
src/agent.h | 3 +
src/device.c | 96 +++++++++++
src/device.h | 13 ++
src/event.c | 89 ++++++++---
src/event.h | 4 +-
src/oob.c | 67 ++++++++
src/oob.h | 47 ++++++
test/simple-agent | 10 ++
test/simple-oobprovider | 57 +++++++
19 files changed, 1131 insertions(+), 38 deletions(-)
create mode 100644 doc/oob-api.txt
create mode 100644 doc/oob-api.txt.orig
create mode 100644 plugins/dbusoob.c
create mode 100644 src/oob.c
create mode 100644 src/oob.h
create mode 100755 test/simple-oobprovider
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] btusb: Fix log spamming due to autosuspend
From: stefan.seyfried @ 2010-11-30 20:49 UTC (permalink / raw)
To: gregkh; +Cc: linux-bluetooth, Stefan Seyfried, Oliver Neukum
From: Stefan Seyfried <seife+kernel@b1-systems.com>
If a device is autosuspended an inability to resubmit URBs is
to be expected. Check the error code and only log real errors.
(Now that autosuspend is default enabled for btusb, those log
messages were happening all the time e.g. with a BT mouse)
Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
Signed-off-by: Oliver Neukum <oneukum@suse.de>
---
drivers/bluetooth/btusb.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ab3894f..d323c1a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -239,7 +239,8 @@ static void btusb_intr_complete(struct urb *urb)
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err < 0) {
- BT_ERR("%s urb %p failed to resubmit (%d)",
+ if (err != -EPERM)
+ BT_ERR("%s urb %p failed to resubmit (%d)",
hdev->name, urb, -err);
usb_unanchor_urb(urb);
}
@@ -323,7 +324,8 @@ static void btusb_bulk_complete(struct urb *urb)
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err < 0) {
- BT_ERR("%s urb %p failed to resubmit (%d)",
+ if (err != -EPERM)
+ BT_ERR("%s urb %p failed to resubmit (%d)",
hdev->name, urb, -err);
usb_unanchor_urb(urb);
}
@@ -412,7 +414,8 @@ static void btusb_isoc_complete(struct urb *urb)
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err < 0) {
- BT_ERR("%s urb %p failed to resubmit (%d)",
+ if (err != -EPERM)
+ BT_ERR("%s urb %p failed to resubmit (%d)",
hdev->name, urb, -err);
usb_unanchor_urb(urb);
}
--
1.7.3.1
^ permalink raw reply related
* Re: [RFC 2/4] Bluetooth: clean up rfcomm code
From: Gustavo F. Padovan @ 2010-11-30 18:22 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, marcel
In-Reply-To: <AANLkTimDn_oVX2YMHhEAqyw=YpeYZuX5WL6mr_F463dC@mail.gmail.com>
Hi Andrei,
* Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-11-30 10:41:=
56 +0200]:
> Gustavo,
>=20
> On Tue, Nov 30, 2010 at 3:09 AM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> > Hi Andrei,
> >
> > * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-11-26 17=
:22:43 +0200]:
> >
> >> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >>
> >> Remove extra spaces, assignments in if statement, zeroing static
> >> variables.
> >>
> >> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >> ---
> >> =A0include/net/bluetooth/rfcomm.h | =A0 18 +++++++++---------
> >> =A0net/bluetooth/rfcomm/core.c =A0 =A0| =A0 =A08 ++++----
> >> =A0net/bluetooth/rfcomm/sock.c =A0 =A0| =A0 =A05 +++--
> >> =A0net/bluetooth/rfcomm/tty.c =A0 =A0 | =A0 28 ++++++++++++++++-------=
-----
> >> =A04 files changed, 32 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rf=
comm.h
> >> index 71047bc..6eac4a7 100644
> >> --- a/include/net/bluetooth/rfcomm.h
> >> +++ b/include/net/bluetooth/rfcomm.h
> >> @@ -1,5 +1,5 @@
> >> -/*
> >> - =A0 RFCOMM implementation for Linux Bluetooth stack (BlueZ).
> >> +/*
> >> + =A0 RFCOMM implementation for Linux Bluetooth stack (BlueZ)
> >> =A0 =A0 Copyright (C) 2002 Maxim Krasnyansky <maxk@qualcomm.com>
> >> =A0 =A0 Copyright (C) 2002 Marcel Holtmann <marcel@holtmann.org>
> >>
> >> @@ -11,13 +11,13 @@
> >> =A0 =A0 OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MER=
CHANTABILITY,
> >> =A0 =A0 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD =
PARTY RIGHTS.
> >> =A0 =A0 IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIA=
BLE FOR ANY
> >> - =A0 CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY =
DAMAGES
> >> - =A0 WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER =
IN AN
> >> - =A0 ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING=
OUT OF
> >> + =A0 CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY =
DAMAGES
> >> + =A0 WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER =
IN AN
> >> + =A0 ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING=
OUT OF
> >> =A0 =A0 OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >>
> >> - =A0 ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATEN=
TS,
> >> - =A0 COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> >> + =A0 ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATEN=
TS,
> >> + =A0 COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> >> =A0 =A0 SOFTWARE IS DISCLAIMED.
> >
> > Marcel refused a patch from me in the past because its was touching leg=
al
> > stuff, so or you remove these changes for your patches or wait for
> > Marcel's comments here.
>=20
> I fixed extra spaces at the end of the sentences, no legal stuff
> touched in legal terms :-)
> I believe that it is better to have legal text identical to other
> parts of the kernel otherwise
> the legal stuff looks different when comparing with diff tools.
I know, but I did the same in the past and got a NACK from Marcel. :)
--=20
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* RE: [PATCHv4 0/7] Support for out of band association model
From: Mike Tsai @ 2010-11-30 16:02 UTC (permalink / raw)
To: Szymon Janc, linux-bluetooth@vger.kernel.org
In-Reply-To: <1290509592-9262-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Szymon Janc
Sent: Tuesday, November 23, 2010 2:53 AM
To: linux-bluetooth@vger.kernel.org
Cc: Szymon Janc
Subject: [PATCHv4 0/7] Support for out of band association model
Changes in this version:
- code style/flow comments from Johan included
- changes in D-Bus OOB api - ReadLocalOobData and provider
register/unregister moved to adapter path (OobManager interface), provider
is registered per adapter now
- some bug fixes
Some things I'd like to collect comments about:
- OobManager interface could be only available on 2.1 or higher adapters
(this would require some adapter interface to be able check this in
dbusoob plugin)
- Agent's RequestPairing method name
- RequestPairing is called only on device accepting incoming connection when
it has OOB data for remote device (on RequestRemoteOobData event).
Consequence is that when only initiator has OOB data RequestPairing is not
called. We could store initiator's OOB capability in device structure (now
only auth and cap are stored) to be able to know if initiator has OOB data.
Yet, in such case RequestRemoteOobData on accepting device will not be
called and I have no idea where/when OOB capability should be check to call
RequestPairing (and reject pairing if necessary)..
[MTsai]7.7.44 Remote OOB Data Request Event.
If host has received remote peer's OOB data before pairing, the host shall set the "OOB present" flag of the peer device. This "OOB present" flag will be sent over the air as part of pairing process with lmp_ioCap_Req or lmp_iocap_rsp.
If either one of the devices have OOB data, then OOB shall be used to do the pairing.
The event "Remote OOB Data Request Event" shall be sent to host before calculating the commitment value.
The LM state machine shall call "device_request_oob_data" when either local or remote peer has "OOB data present". I think this part of the code is not present.
Comments are welcome.
BR,
Szymon Janc
on behalf of ST-Ericsson
Szymon Janc (7):
Add support for Out of Band (OOB) association model
Add D-Bus OOB plugin
Add D-Bus OOB API documentation
Add simple-oobprovider for testing
Add request for accepting incoming pairing requests with OOB
mechanism
Update D-Bus OOB API with RequestPairing method
Add RequestPairing method in simple-agent for accepting incoming OOB
pairing requests
Makefile.am | 10 +-
acinclude.m4 | 6 +
doc/oob-api.txt | 76 +++++++++
doc/oob-api.txt.orig | 79 +++++++++
lib/hci.h | 3 +
plugins/dbusoob.c | 412 +++++++++++++++++++++++++++++++++++++++++++++++
plugins/hciops.c | 107 +++++++++++--
src/adapter.c | 21 +++-
src/adapter.h | 10 ++
src/agent.c | 59 +++++++-
src/agent.h | 3 +
src/device.c | 96 +++++++++++
src/device.h | 13 ++
src/event.c | 89 ++++++++---
src/event.h | 4 +-
src/oob.c | 67 ++++++++
src/oob.h | 47 ++++++
test/simple-agent | 10 ++
test/simple-oobprovider | 57 +++++++
19 files changed, 1131 insertions(+), 38 deletions(-)
create mode 100644 doc/oob-api.txt
create mode 100644 doc/oob-api.txt.orig
create mode 100644 plugins/dbusoob.c
create mode 100644 src/oob.c
create mode 100644 src/oob.h
create mode 100755 test/simple-oobprovider
--
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 v7] Bluetooth: btwilink driver
From: Pavan Savoy @ 2010-11-30 16:00 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: marcel, linux-bluetooth, linux-kernel
In-Reply-To: <20101130154654.GE5919@vigoh>
Gustavo,
On Tue, Nov 30, 2010 at 9:16 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Pavan,
>
> * pavan_savoy@ti.com <pavan_savoy@ti.com> [2010-11-26 04:20:57 -0500]:
>
>> From: Pavan Savoy <pavan_savoy@ti.com>
>>
>> Marcel, Gustavo,
>>
>> comments attended to from v5 and v6,
>>
>> 1. Inside ti_st_open, I previously only checked for EINPROGRESS & EPERM,
>> Now I handle for EINPROGRESS - which is not really an error and
>> return during all other error cases.
>>
>> 2. _write is still a function pointer and not an exported function, I
>> need to change the underlying driver's code for this.
>> However, previous lkml comments on the underlying driver's code
>> suggested it to be kept as a function pointer and not EXPORT.
>> Gustavo, Marcel - Please comment on this.
>> Is this absolutely required? If so why?
>>
>> 3. test_and_set_bit of HCI_RUNNING is done at beginning of
>> ti_st_open, and did not see issues during firmware download.
>> However ideally I would still like to set HCI_RUNNING once the firmware
>> download is done, because I don't want to allow a _send_frame during
>> firmware download - Marcel, Gustavo - Please comment.
>>
>> 4. test_and_clear of HCI_RUNNING now done @ beginning of close.
>>
>> 5. EAGAIN on failure of st_write is to suggest to try and write again.
>> I have never this happen - However only if UART goes bad this case may
>> occur.
>>
>> 6. ti_st_tx_complete is very similar to hci_ldisc's tx_complete - in
>> fact the code is pretty much borrowed from there.
>> Marcel, Gustavo - Please suggest where should it be done? If not here.
>>
>> 7. comments cleaned-up + hst memory leak fixed when hci_alloc_dev fails.
>>
>> 8. platform_driver registration inside module_init now is similar to
>> other drivers.
>>
>> 9. Dan Carpenter's comments on leaking hst memory on failed
>> hci_register_dev and empty space after quotes in debug statements
>> fixed.
>>
>> Thanks for the comments...
>> Sorry, for previously not being very clear on which comments were
>> handled and which were not.
>>
>> -- patch description --
>>
>> 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.
>>
>> Kconfig and Makefile modifications to enable the Bluetooth
>> driver for Texas Instrument's WiLink 7 chipset.
>>
>> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
>> ---
>> =C2=A0drivers/bluetooth/Kconfig =C2=A0 =C2=A0| =C2=A0 10 ++
>> =C2=A0drivers/bluetooth/Makefile =C2=A0 | =C2=A0 =C2=A01 +
>> =C2=A0drivers/bluetooth/btwilink.c | =C2=A0363 +++++++++++++++++++++++++=
+++++++++++++++++
>> =C2=A03 files changed, 374 insertions(+), 0 deletions(-)
>> =C2=A0create mode 100644 drivers/bluetooth/btwilink.c
>
> So as part of reviewing this I took a look at your underlying driver and
> I didn't like what I saw there, you are handling Bluetooth stuff inside
> the core driver and that is just wrong. You have a Bluetooth driver here
> then you have to leave the Bluetooth data handling to the Bluetooth
> driver and do not do that in the core.
Thanks for reviewing this and the underlying driver.
yes, we do have Bluetooth/FM/GPS handling inside the TI ST driver, on
addition of further technologies
we do plan to have them inside the ST driver too.
The understanding of BT or FM or GPS is required for the ST driver
because, the data coming from the chip
can either be of these technologies, further-more the data might not
come in a set.
As in, an a2dp/ftp ACL frame might come in 2 frames instead of 1, and
in other cases,
there might be a HCI-EVENT + FM CH8 data in a single frame received by the =
UART.
> So I'm going to clear NACK this. Your TI ST driver architecture is
> a mess, Ideally you should not have any #include <net/bluetoooth/...>
> there. Implement a core driver that only gets the Shared Transport
> data and pass it to the right driver without look into the data and
> process it. Process the data is not the role of the core driver.
So as I see it the tty_receive which translates to st_int_recv() in
TI-ST is the area of concern for
you ...
So any suggestions as to how we can go about just abstracting the BT,
FM and GPS data part to their individual drivers?
> Please fix this and come back when you have a proper solution for your
> driver.
>
> --
> Gustavo F. Padovan
> 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 =C2=A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v7] Bluetooth: btwilink driver
From: Gustavo F. Padovan @ 2010-11-30 15:46 UTC (permalink / raw)
To: pavan_savoy; +Cc: marcel, linux-bluetooth, linux-kernel
In-Reply-To: <1290763257-12382-1-git-send-email-pavan_savoy@ti.com>
Hi Pavan,
* pavan_savoy@ti.com <pavan_savoy@ti.com> [2010-11-26 04:20:57 -0500]:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
> Marcel, Gustavo,
>
> comments attended to from v5 and v6,
>
> 1. Inside ti_st_open, I previously only checked for EINPROGRESS & EPERM,
> Now I handle for EINPROGRESS - which is not really an error and
> return during all other error cases.
>
> 2. _write is still a function pointer and not an exported function, I
> need to change the underlying driver's code for this.
> However, previous lkml comments on the underlying driver's code
> suggested it to be kept as a function pointer and not EXPORT.
> Gustavo, Marcel - Please comment on this.
> Is this absolutely required? If so why?
>
> 3. test_and_set_bit of HCI_RUNNING is done at beginning of
> ti_st_open, and did not see issues during firmware download.
> However ideally I would still like to set HCI_RUNNING once the firmware
> download is done, because I don't want to allow a _send_frame during
> firmware download - Marcel, Gustavo - Please comment.
>
> 4. test_and_clear of HCI_RUNNING now done @ beginning of close.
>
> 5. EAGAIN on failure of st_write is to suggest to try and write again.
> I have never this happen - However only if UART goes bad this case may
> occur.
>
> 6. ti_st_tx_complete is very similar to hci_ldisc's tx_complete - in
> fact the code is pretty much borrowed from there.
> Marcel, Gustavo - Please suggest where should it be done? If not here.
>
> 7. comments cleaned-up + hst memory leak fixed when hci_alloc_dev fails.
>
> 8. platform_driver registration inside module_init now is similar to
> other drivers.
>
> 9. Dan Carpenter's comments on leaking hst memory on failed
> hci_register_dev and empty space after quotes in debug statements
> fixed.
>
> Thanks for the comments...
> Sorry, for previously not being very clear on which comments were
> handled and which were not.
>
> -- patch description --
>
> 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.
>
> Kconfig and Makefile modifications to enable the Bluetooth
> driver for Texas Instrument's WiLink 7 chipset.
>
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
> drivers/bluetooth/Kconfig | 10 ++
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/btwilink.c | 363 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 374 insertions(+), 0 deletions(-)
> create mode 100644 drivers/bluetooth/btwilink.c
So as part of reviewing this I took a look at your underlying driver and
I didn't like what I saw there, you are handling Bluetooth stuff inside
the core driver and that is just wrong. You have a Bluetooth driver here
then you have to leave the Bluetooth data handling to the Bluetooth
driver and do not do that in the core.
So I'm going to clear NACK this. Your TI ST driver architecture is
a mess, Ideally you should not have any #include <net/bluetoooth/...>
there. Implement a core driver that only gets the Shared Transport
data and pass it to the right driver without look into the data and
process it. Process the data is not the role of the core driver.
Please fix this and come back when you have a proper solution for your
driver.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: hidp_output_raw_report, HID_OUTPUT_REPORT and Sixaxis
From: Antonio Ospite @ 2010-11-30 14:06 UTC (permalink / raw)
To: linux-input
Cc: linux-bluetooth, Bastien Nocera, Marcel Holtmann, Jiri Kosina,
Alan Ott
In-Reply-To: <20101130145405.d8142bc3.ospite@studenti.unina.it>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Tue, 30 Nov 2010 14:54:05 +0100
Antonio Ospite <ospite@studenti.unina.it> wrote:
> Hi,
>
> another piece in the Sixaxis jigsaw:
> in commit d4bfa033ed84e0ae446eff445d107ffd5ee78df3 support for setting
> different report types was added to hidp, however in my Sixaxis
> experiments setting leds (sending and output report) was not working
sending _an_ output report.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* hidp_output_raw_report, HID_OUTPUT_REPORT and Sixaxis
From: Antonio Ospite @ 2010-11-30 13:54 UTC (permalink / raw)
To: linux-input
Cc: linux-bluetooth, Bastien Nocera, Marcel Holtmann, Jiri Kosina,
Alan Ott
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
Hi,
another piece in the Sixaxis jigsaw:
in commit d4bfa033ed84e0ae446eff445d107ffd5ee78df3 support for setting
different report types was added to hidp, however in my Sixaxis
experiments setting leds (sending and output report) was not working
until I made this change:
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index b68a608..0c443b7 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -402,7 +402,7 @@ static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, s
report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_FEATURE;
break;
case HID_OUTPUT_REPORT:
- report_type = HIDP_TRANS_DATA | HIDP_DATA_RTYPE_OUPUT;
+ report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_OUPUT;
break;
default:
return -EINVAL;
Is it only the Sixaxis which needs the output report as a SET_REPORT
operation, or the change above is an actual fix?
I don't know bluetooth at all, sorry.
In case this is a sixaxis specific behavior then I guess I'll be
overriding hidp_output_raw_report() in hid-sony.c just like I did for the
usbhid counterpart.
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH 3/3 v2] Fix not canceling pending calls on maemo6 telephony driver exit
From: Johan Hedberg @ 2010-11-30 12:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1291120709-20658-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Nov 30, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This happens when the driver exit is called quickly after init due to
> adapter power changes.
> ---
> audio/telephony-maemo6.c | 21 ++++++++++++++++++++-
> 1 files changed, 20 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 3/3 v2] Fix not canceling pending calls on maemo6 telephony driver exit
From: Luiz Augusto von Dentz @ 2010-11-30 12:38 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
This happens when the driver exit is called quickly after init due to
adapter power changes.
---
audio/telephony-maemo6.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 7853bae..f671a42 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -150,6 +150,7 @@ static DBusConnection *connection = NULL;
static GSList *calls = NULL;
static GSList *watches = NULL;
+static GSList *pending = NULL;
/* Reference count for determining the call indicator status */
static GSList *active_calls = NULL;
@@ -592,7 +593,7 @@ static int send_method_call(const char *dest, const char *path,
}
dbus_pending_call_set_notify(call, cb, user_data, NULL);
- dbus_pending_call_unref(call);
+ pending = g_slist_prepend(pending, call);
dbus_message_unref(msg);
return 0;
@@ -1312,6 +1313,12 @@ static gboolean iter_get_basic_args(DBusMessageIter *iter,
return type == DBUS_TYPE_INVALID ? TRUE : FALSE;
}
+static void remove_pending(DBusPendingCall *call)
+{
+ pending = g_slist_remove(pending, call);
+ dbus_pending_call_unref(call);
+}
+
static void hal_battery_level_reply(DBusPendingCall *call, void *user_data)
{
DBusError err;
@@ -1360,8 +1367,10 @@ static void hal_battery_level_reply(DBusPendingCall *call, void *user_data)
telephony_update_indicator(maemo_indicators, "battchg", new);
}
+
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
static void hal_get_integer(const char *path, const char *key, void *user_data)
@@ -1556,6 +1565,7 @@ static void get_property_reply(DBusPendingCall *call, void *user_data)
done:
g_free(prop);
dbus_message_unref(reply);
+ remove_pending(call);
}
static int get_property(const char *iface, const char *prop)
@@ -1615,6 +1625,7 @@ static void call_info_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
@@ -1665,6 +1676,7 @@ static void phonebook_read_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
static void csd_init(void)
@@ -1843,6 +1855,7 @@ static void modem_state_reply(DBusPendingCall *call, void *user_data)
handle_modem_state(reply);
dbus_message_unref(reply);
+ remove_pending(call);
}
static gboolean signal_filter(DBusConnection *conn, DBusMessage *msg,
@@ -1940,6 +1953,7 @@ static void hal_find_device_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
int telephony_init(void)
@@ -2016,6 +2030,11 @@ void telephony_exit(void)
g_slist_free(calls);
calls = NULL;
+ g_slist_foreach(pending, (GFunc) dbus_pending_call_cancel, NULL);
+ g_slist_foreach(pending, (GFunc) dbus_pending_call_unref, NULL);
+ g_slist_free(pending);
+ pending = NULL;
+
g_slist_foreach(watches, (GFunc) remove_watch, NULL);
g_slist_free(watches);
watches = NULL;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 3/3] Fix not canceling pending calls on maemo6 telephony driver exit
From: Johan Hedberg @ 2010-11-30 12:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1291119975-9460-3-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Nov 30, 2010, Luiz Augusto von Dentz wrote:
> + g_slist_foreach(pending, (GFunc) remove_pending, NULL);
> + g_slist_free(pending);
Maybe GLib can handle removing the items in the foreach callback, but I
think it'd be better to just use pending_call_unref in this case.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] Fix interface name of modem states on maemo6 telephony driver
From: Johan Hedberg @ 2010-11-30 12:31 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1291119975-9460-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Nov 30, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> ---
> audio/telephony-maemo6.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
The first two patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 3/3] Fix not canceling pending calls on maemo6 telephony driver exit
From: Luiz Augusto von Dentz @ 2010-11-30 12:26 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1291119975-9460-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
This happens when the driver exit is called quickly after init due to
adapter power changes.
---
audio/telephony-maemo6.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 7853bae..bfd3ba1 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -150,6 +150,7 @@ static DBusConnection *connection = NULL;
static GSList *calls = NULL;
static GSList *watches = NULL;
+static GSList *pending = NULL;
/* Reference count for determining the call indicator status */
static GSList *active_calls = NULL;
@@ -592,7 +593,7 @@ static int send_method_call(const char *dest, const char *path,
}
dbus_pending_call_set_notify(call, cb, user_data, NULL);
- dbus_pending_call_unref(call);
+ pending = g_slist_prepend(pending, call);
dbus_message_unref(msg);
return 0;
@@ -1312,6 +1313,12 @@ static gboolean iter_get_basic_args(DBusMessageIter *iter,
return type == DBUS_TYPE_INVALID ? TRUE : FALSE;
}
+static void remove_pending(DBusPendingCall *call)
+{
+ pending = g_slist_remove(pending, call);
+ dbus_pending_call_unref(call);
+}
+
static void hal_battery_level_reply(DBusPendingCall *call, void *user_data)
{
DBusError err;
@@ -1360,8 +1367,10 @@ static void hal_battery_level_reply(DBusPendingCall *call, void *user_data)
telephony_update_indicator(maemo_indicators, "battchg", new);
}
+
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
static void hal_get_integer(const char *path, const char *key, void *user_data)
@@ -1556,6 +1565,7 @@ static void get_property_reply(DBusPendingCall *call, void *user_data)
done:
g_free(prop);
dbus_message_unref(reply);
+ remove_pending(call);
}
static int get_property(const char *iface, const char *prop)
@@ -1615,6 +1625,7 @@ static void call_info_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
@@ -1665,6 +1676,7 @@ static void phonebook_read_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
static void csd_init(void)
@@ -1843,6 +1855,7 @@ static void modem_state_reply(DBusPendingCall *call, void *user_data)
handle_modem_state(reply);
dbus_message_unref(reply);
+ remove_pending(call);
}
static gboolean signal_filter(DBusConnection *conn, DBusMessage *msg,
@@ -1940,6 +1953,7 @@ static void hal_find_device_reply(DBusPendingCall *call, void *user_data)
done:
dbus_message_unref(reply);
+ remove_pending(call);
}
int telephony_init(void)
@@ -2016,6 +2030,11 @@ void telephony_exit(void)
g_slist_free(calls);
calls = NULL;
+ g_slist_foreach(pending, (GFunc) dbus_pending_call_cancel, NULL);
+ g_slist_foreach(pending, (GFunc) remove_pending, NULL);
+ g_slist_free(pending);
+ pending = NULL;
+
g_slist_foreach(watches, (GFunc) remove_watch, NULL);
g_slist_free(watches);
watches = NULL;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] Use specific members in D-Bus match rules on telephony maemo6 driver
From: Luiz Augusto von Dentz @ 2010-11-30 12:26 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1291119975-9460-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
This reduces the amount of unnecessary wake-ups without breaking anything
---
audio/telephony-maemo6.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 0240957..7853bae 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -1960,9 +1960,9 @@ int telephony_init(void)
add_watch(NULL, NULL, CSD_CALL_INTERFACE, NULL);
add_watch(NULL, NULL, CSD_CALL_INSTANCE, NULL);
add_watch(NULL, NULL, CSD_CALL_CONFERENCE, NULL);
- add_watch(NULL, NULL, CSD_CSNET_REGISTRATION, NULL);
- add_watch(NULL, NULL, CSD_CSNET_OPERATOR, NULL);
- add_watch(NULL, NULL, CSD_CSNET_SIGNAL, NULL);
+ add_watch(NULL, NULL, CSD_CSNET_REGISTRATION, "RegistrationChanged");
+ add_watch(NULL, NULL, CSD_CSNET_OPERATOR, "OperatorNameChanged");
+ add_watch(NULL, NULL, CSD_CSNET_SIGNAL, "SignalBarsChanged");
add_watch(NULL, NULL, SSC_DBUS_IFACE, "modem_state_changed_ind");
if (send_method_call(SSC_DBUS_NAME, SSC_DBUS_PATH, SSC_DBUS_IFACE,
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] Fix interface name of modem states on maemo6 telephony driver
From: Luiz Augusto von Dentz @ 2010-11-30 12:26 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
audio/telephony-maemo6.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 2e01fb1..0240957 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -1963,7 +1963,7 @@ int telephony_init(void)
add_watch(NULL, NULL, CSD_CSNET_REGISTRATION, NULL);
add_watch(NULL, NULL, CSD_CSNET_OPERATOR, NULL);
add_watch(NULL, NULL, CSD_CSNET_SIGNAL, NULL);
- add_watch(NULL, NULL, CSD_CSNET_SIGNAL, "modem_state_changed_ind");
+ add_watch(NULL, NULL, SSC_DBUS_IFACE, "modem_state_changed_ind");
if (send_method_call(SSC_DBUS_NAME, SSC_DBUS_PATH, SSC_DBUS_IFACE,
"get_modem_state", modem_state_reply,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Populate adapter services list
From: Johan Hedberg @ 2010-11-30 11:50 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimwgPtxRVKuDHT0DZa2MhqOqFFDKiEzAJ3opv_W@mail.gmail.com>
Hi Daniel,
On Tue, Nov 30, 2010, Daniel Örstadius wrote:
> In case service records have been added to bluetoothd before a new
> adapter is registered, the records which are shared by all adapters
> (indicated by having the address set to BDADDR_ANY) need to be added
> to the services list of the new adapter. This patch adds a function
> for this on adapter initialization.
>
> The issue could be reproduced by running bluetoothd and obexd on a
> PC and briefly removing the BT dongle. The service records from
> obexd would not be present in the adapter's local list (which is
> used to set the class of device).
> ---
> src/adapter.c | 1 +
> src/sdpd-database.c | 24 ++++++++++++++++++++++++
> src/sdpd.h | 2 ++
> 3 files changed, 27 insertions(+), 0 deletions(-)
Thanks. Pushed upstream after a few minor cosmetic changes.
Johan
^ permalink raw reply
* Re: [PATCH] Populate adapter services list
From: Daniel Örstadius @ 2010-11-30 11:33 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTik7su9-KfW-+ZC-yc_SrXq+5K3PvZtu5kKxiJhG@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 58 bytes --]
Updated patch after offline feedback from Johan.
/Daniel
[-- Attachment #2: 0001-Initialize-adapter-services-list.patch --]
[-- Type: text/x-patch, Size: 2248 bytes --]
From 42edf146231aa053bbcc97d80fd9dd3aa3f247ec Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Tue, 30 Nov 2010 13:27:57 +0200
Subject: [PATCH] Initialize adapter services list
In case service records have been added to bluetoothd before a new
adapter is registered, the records which are shared by all adapters
(indicated by having the address set to BDADDR_ANY) need to be added
to the services list of the new adapter. This patch adds a function
for this on adapter initialization.
The issue could be reproduced by running bluetoothd and obexd on a
PC and briefly removing the BT dongle. The service records from
obexd would not be present in the adapter's local list (which is
used to set the class of device).
---
src/adapter.c | 1 +
src/sdpd-database.c | 24 ++++++++++++++++++++++++
src/sdpd.h | 2 ++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 999f369..62afc0c 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2319,6 +2319,7 @@ proceed:
return err;
if (adapter->initialized == FALSE) {
+ sdp_init_services_list(&adapter->bdaddr);
load_drivers(adapter);
clear_blocked(adapter);
load_devices(adapter);
diff --git a/src/sdpd-database.c b/src/sdpd-database.c
index da3bc7d..f3538ae 100644
--- a/src/sdpd-database.c
+++ b/src/sdpd-database.c
@@ -306,3 +306,27 @@ uint32_t sdp_next_handle(void)
return handle;
}
+
+void sdp_init_services_list(bdaddr_t *device)
+{
+ sdp_list_t *p;
+
+ SDPDBG("");
+
+ for (p = access_db; p != NULL; p = p->next) {
+ sdp_record_t *rec;
+ sdp_access_t *access = p->data;
+
+ if (bacmp(BDADDR_ANY, &access->device))
+ continue;
+
+ rec = sdp_record_find(access->handle);
+
+ if (rec == NULL)
+ continue;
+
+ SDPDBG("adding record with handle %x", access->handle);
+
+ adapter_service_insert(device, rec);
+ }
+}
diff --git a/src/sdpd.h b/src/sdpd.h
index f8e6ee7..0e3dddf 100644
--- a/src/sdpd.h
+++ b/src/sdpd.h
@@ -106,3 +106,5 @@ int remove_record_from_server(uint32_t handle);
void create_ext_inquiry_response(const char *name,
int8_t tx_power, sdp_list_t *services,
uint8_t *data);
+
+void sdp_init_services_list(bdaddr_t *device);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/2] Sim Access Profile API
From: Waldemar Rymarkiewicz @ 2010-11-30 10:36 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, linux-bluetooth; +Cc: Waldemar Rymarkiewicz
In-Reply-To: <1291113364-6401-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
New API for Sim Access Profile.
---
Makefile.am | 2 +-
doc/sap-api.txt | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 1 deletions(-)
create mode 100644 doc/sap-api.txt
diff --git a/Makefile.am b/Makefile.am
index 5f96975..97345a3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -354,7 +354,7 @@ EXTRA_DIST += doc/manager-api.txt \
doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
doc/serial-api.txt doc/network-api.txt \
doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
- doc/hfp-api.txt doc/assigned-numbers.txt
+ doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
AM_YFLAGS = -d
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..4e5626e
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,47 @@
+BlueZ D-Bus Sim Access Profile API description
+***********************************
+
+Copyright (C) 2010 ST-Ericsson SA
+
+
+Sim Access Profile hierarchy
+============================
+
+Service org.bluez
+Interface org.bluez.SimAccess
+Object path [variable prefix]/{hci0,hci1,...}
+
+Methods void Disconnect()
+
+ Disconnects SAP client from the server.
+
+ Possible errors: org.bluez.Error.Failed
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed a read-write are changeable.
+
+ Possible Errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+
+ dict GetProperties()
+
+ Return all properties for the interface. See the
+ properties section for available properties.
+
+ Possible Errors: org.bluez.Error.Failed
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties boolean Enabled [readwrite]
+
+ Set to true to start-up SAP server and register SDP record for
+ it. Set to false to shutdown SAP server and remove the SDP record.
+
+ boolean Connected [readonly]
+
+ Indicates if SAP client is connected to the server.
--
1.7.0.4
^ permalink raw reply related
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