* 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
* [PATCH 0/2] Sim Access Prifile API
From: Waldemar Rymarkiewicz @ 2010-11-30 10:36 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, linux-bluetooth; +Cc: Waldemar Rymarkiewicz
Hi,
I'am posting modified SAP API again in a seperate mail to keep better track of this.
Comments and new ideas will be appreciated.
Thanks,
/Waldek
^ permalink raw reply
* [PATCH] Populate adapter services list
From: Daniel Örstadius @ 2010-11-30 9:51 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 46 bytes --]
Attaching patch proposal for review.
/Daniel
[-- Attachment #2: 0001-Populate-adapter-services-list.patch --]
[-- Type: text/x-patch, Size: 2841 bytes --]
From aa9b2a347d19f50575e6b2864f503e9d4540369c Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Tue, 30 Nov 2010 11:42:08 +0200
Subject: [PATCH] Populate adapter services list
In case that service records have been added to bluetoothd before
a new adapter is registered, the added records which are shared by
all adapters (indicated by having an 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 | 43 +++++++++++++++++++++++++++++++++++++++++++
src/sdpd.h | 2 ++
3 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 999f369..7d05098 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2319,6 +2319,7 @@ proceed:
return err;
if (adapter->initialized == FALSE) {
+ sdp_populate_services(&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..111371d 100644
--- a/src/sdpd-database.c
+++ b/src/sdpd-database.c
@@ -81,6 +81,19 @@ static int access_sort(const void *r1, const void *r2)
return rec1->handle - rec2->handle;
}
+static int find_device(const void *r1, const void *r2)
+{
+ const sdp_access_t *rec1 = r1;
+ const sdp_access_t *rec2 = r2;
+
+ if (!rec1 || !rec2) {
+ error("NULL RECORD LIST FATAL");
+ return -1;
+ }
+
+ return bacmp(&rec1->device, &rec2->device);
+}
+
static void access_free(void *p)
{
free(p);
@@ -306,3 +319,33 @@ uint32_t sdp_next_handle(void)
return handle;
}
+
+void sdp_populate_services(bdaddr_t *device)
+{
+ sdp_record_t *rec;
+ sdp_list_t *p;
+ sdp_access_t ref_adr;
+ sdp_access_t *access;
+
+ SDPDBG("");
+
+ if (!access_db)
+ return;
+
+ bacpy(&ref_adr.device, BDADDR_ANY);
+ p = sdp_list_find(access_db, &ref_adr, find_device);
+
+ while (p) {
+ access = (sdp_access_t*) (p->data);
+
+ rec = sdp_record_find(access->handle);
+
+ if (rec) {
+ SDPDBG("adding record with handle %d", access->handle);
+ adapter_service_insert(device, rec);
+ }
+
+ p = p->next ?
+ (sdp_list_find(p->next, &ref_adr, find_device)) : NULL;
+ }
+}
diff --git a/src/sdpd.h b/src/sdpd.h
index f8e6ee7..b69034a 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_populate_services(bdaddr_t *device);
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] ath3k: reduce memory usage
From: Alexander Holler @ 2010-11-30 8:50 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Alicke Xu, Luis R. Rodriguez, Vikram Kandukuri, linux-bluetooth
In-Reply-To: <20101130015200.GD5919@vigoh>
Hello,
Am 30.11.2010 02:52, schrieb Gustavo F. Padovan:
>> - if ((usb_control_msg(data->udev, pipe,
>> + send_buf = kmalloc(BULK_SIZE, GFP_ATOMIC);
>> + if (!send_buf) {
>> + BT_ERR("Can't allocate memory chunk for firmware");
>> + return -ENOMEM;
>> + }
>> +
>> + memcpy(send_buf, firmware->data, 20);
>> + if ((err = usb_control_msg(udev, pipe,
>> USB_REQ_DFU_DNLOAD,
>> USB_TYPE_VENDOR, 0, 0,
>> - firmware, 20, USB_CTRL_SET_TIMEOUT))< 0) {
>> + send_buf, 20, USB_CTRL_SET_TIMEOUT))< 0) {
>> BT_ERR("Can't change to loading configuration err");
>> - return -EBUSY;
>> + goto error;
>> }
>> sent += 20;
>> count -= 20;
>
> Patch looks good to me, but I have a question here: what's 20 here? I
> didn't figured out.
I don't know. I assume it's a stub which has to be send before the real
firmware. It already was there and I haven't touched that.
Regards,
Alexander
^ permalink raw reply
* Re: [RFC 2/4] Bluetooth: clean up rfcomm code
From: Andrei Emeltchenko @ 2010-11-30 8:41 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, marcel
In-Reply-To: <20101130010939.GB5919@vigoh>
Gustavo,
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:2=
2: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/rfco=
mm.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 MERCH=
ANTABILITY,
>> =A0 =A0 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PA=
RTY RIGHTS.
>> =A0 =A0 IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABL=
E FOR ANY
>> - =A0 CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DA=
MAGES
>> - =A0 WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN=
AN
>> - =A0 ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING O=
UT OF
>> + =A0 CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DA=
MAGES
>> + =A0 WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN=
AN
>> + =A0 ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING O=
UT OF
>> =A0 =A0 OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>>
>> - =A0 ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS=
,
>> - =A0 COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
>> + =A0 ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS=
,
>> + =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 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.
Regards,
Andrei
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
>
^ permalink raw reply
* Re: [PATCH v7] Bluetooth: btwilink driver
From: Pavan Savoy @ 2010-11-30 7:29 UTC (permalink / raw)
To: padovan, marcel; +Cc: linux-bluetooth, linux-kernel, Pavan Savoy
In-Reply-To: <1290763257-12382-1-git-send-email-pavan_savoy@ti.com>
On Fri, Nov 26, 2010 at 2:50 PM, <pavan_savoy@ti.com> wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
Marcel, Gustavo,
Please find some time to comment and also answer some of the
concerns I have below,
Thanks & Regards,
Pavan Savoy.
> 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
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 02deef4..8e0de9a 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -219,4 +219,14 @@ config BT_ATH3K
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Say Y here to compile support for "Athe=
ros firmware download driver"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0into the kernel or say M to compile it =
as module (ath3k).
>
> +config BT_WILINK
> + =C2=A0 =C2=A0 =C2=A0 tristate "Texas Instruments WiLink7 driver"
> + =C2=A0 =C2=A0 =C2=A0 depends on TI_ST
> + =C2=A0 =C2=A0 =C2=A0 help
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 This enables the Bluetooth driver for Texas=
Instrument's BT/FM/GPS
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 combo devices. This makes use of shared tra=
nsport line discipline
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 core driver to communicate with the BT core=
of the combo chip.
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 Say Y here to compile support for Texas Ins=
trument's WiLink7 driver
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 into the kernel or say M to compile it as m=
odule.
> =C2=A0endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 71bdf13..f4460f4 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_BT_HCIBTSDIO) =C2=A0 =C2=A0+=3D btsdio.o
> =C2=A0obj-$(CONFIG_BT_ATH3K) =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=3D ath3k.o
> =C2=A0obj-$(CONFIG_BT_MRVL) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=3D btmrvl=
.o
> =C2=A0obj-$(CONFIG_BT_MRVL_SDIO) =C2=A0 =C2=A0 +=3D btmrvl_sdio.o
> +obj-$(CONFIG_BT_WILINK) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0+=3D btwilink.o
>
> =C2=A0btmrvl-y =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 :=3D btmrvl_main.o
> =C2=A0btmrvl-$(CONFIG_DEBUG_FS) =C2=A0 =C2=A0 =C2=A0+=3D btmrvl_debugfs.o
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> new file mode 100644
> index 0000000..71e69f8
> --- /dev/null
> +++ b/drivers/bluetooth/btwilink.c
> @@ -0,0 +1,363 @@
> +/*
> + * =C2=A0Texas Instrument's Bluetooth Driver For Shared Transport.
> + *
> + * =C2=A0Bluetooth Driver acts as interface between HCI core and
> + * =C2=A0TI Shared Transport Layer.
> + *
> + * =C2=A0Copyright (C) 2009-2010 Texas Instruments
> + * =C2=A0Author: Raja Mani <raja_mani@ti.com>
> + * =C2=A0 =C2=A0 Pavan Savoy <pavan_savoy@ti.com>
> + *
> + * =C2=A0This program is free software; you can redistribute it and/or m=
odify
> + * =C2=A0it under the terms of the GNU General Public License version 2 =
as
> + * =C2=A0published by the Free Software Foundation.
> + *
> + * =C2=A0This program is distributed in the hope that it will be useful,
> + * =C2=A0but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * =C2=A0MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =C2=A0See =
the
> + * =C2=A0GNU General Public License for more details.
> + *
> + * =C2=A0You should have received a copy of the GNU General Public Licen=
se
> + * =C2=A0along with this program; if not, write to the Free Software
> + * =C2=A0Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA =C2=A0=
02111-1307 =C2=A0USA
> + *
> + */
> +
> +#include <linux/platform_device.h>
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include <linux/ti_wilink_st.h>
> +
> +/* Bluetooth Driver Version */
> +#define VERSION =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "1.0"
> +
> +/* Number of seconds to wait for registration completion
> + * when ST returns PENDING status.
> + */
> +#define BT_REGISTER_TIMEOUT =C2=A0 6000 =C2=A0 =C2=A0 /* 6 sec */
> +
> +/**
> + * struct ti_st - driver operation structure
> + * @hdev: hci device pointer which binds to bt driver
> + * @reg_status: ST registration callback status
> + * @st_write: write function provided by the ST driver
> + * =C2=A0 =C2=A0 to be used by the driver during send_frame.
> + * @wait_reg_completion - completion sync between ti_st_open
> + * =C2=A0 =C2=A0 and ti_st_registration_completion_cb.
> + */
> +struct ti_st {
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 char reg_status;
> + =C2=A0 =C2=A0 =C2=A0 long (*st_write) (struct sk_buff *);
> + =C2=A0 =C2=A0 =C2=A0 struct completion wait_reg_completion;
> +};
> +
> +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> +static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev =3D hst->hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Update HCI stat counters */
> + =C2=A0 =C2=A0 =C2=A0 switch (pkt_type) {
> + =C2=A0 =C2=A0 =C2=A0 case HCI_COMMAND_PKT:
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hdev->stat.cmd_tx++;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> +
> + =C2=A0 =C2=A0 =C2=A0 case HCI_ACLDATA_PKT:
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hdev->stat.acl_tx++;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> +
> + =C2=A0 =C2=A0 =C2=A0 case HCI_SCODATA_PKT:
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hdev->stat.sco_tx++;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> + =C2=A0 =C2=A0 =C2=A0 }
> +}
> +
> +/* ------- Interfaces to Shared Transport ------ */
> +
> +/* Called by ST layer to indicate protocol registration completion
> + * status.ti_st_open() function will wait for signal from this
> + * API when st_register() function returns ST_PENDING.
> + */
> +static void st_registration_completion_cb(void *priv_data, char data)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *lhst =3D priv_data;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Save registration status for use in ti_st_open(=
) */
> + =C2=A0 =C2=A0 =C2=A0 lhst->reg_status =3D data;
> + =C2=A0 =C2=A0 =C2=A0 /* complete the wait in ti_st_open() */
> + =C2=A0 =C2=A0 =C2=A0 complete(&lhst->wait_reg_completion);
> +}
> +
> +/* Called by Shared Transport layer when receive data is
> + * available */
> +static long st_receive(void *priv_data, struct sk_buff *skb)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *lhst =3D priv_data;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!skb)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EFAULT;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!lhst) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree_skb(skb);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EFAULT;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 skb->dev =3D (void *) lhst->hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Forward skb to HCI core layer */
> + =C2=A0 =C2=A0 =C2=A0 err =3D hci_recv_frame(skb);
> + =C2=A0 =C2=A0 =C2=A0 if (err < 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("Unable to push=
skb to HCI core(%d)", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 lhst->hdev->stat.byte_rx +=3D skb->len;
> +
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +/* ------- Interfaces to HCI layer ------ */
> +/* protocol structure registered with shared transport */
> +static struct st_proto_s ti_st_proto =3D {
> + =C2=A0 =C2=A0 =C2=A0 .type =3D ST_BT,
> + =C2=A0 =C2=A0 =C2=A0 .recv =3D st_receive,
> + =C2=A0 =C2=A0 =C2=A0 .reg_complete_cb =3D st_registration_completion_cb=
,
> +};
> +
> +/* Called from HCI core to initialize the device */
> +static int ti_st_open(struct hci_dev *hdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 unsigned long timeleft;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("%s %p", hdev->name, hdev);
> + =C2=A0 =C2=A0 =C2=A0 if (test_and_set_bit(HCI_RUNNING, &hdev->flags)) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("btwilink alrea=
dy opened");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EBUSY;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /* provide contexts for callbacks from ST */
> + =C2=A0 =C2=A0 =C2=A0 hst =3D hdev->driver_data;
> + =C2=A0 =C2=A0 =C2=A0 ti_st_proto.priv_data =3D hst;
> +
> + =C2=A0 =C2=A0 =C2=A0 err =3D st_register(&ti_st_proto);
> + =C2=A0 =C2=A0 =C2=A0 if (err =3D=3D -EINPROGRESS) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* ST is busy with eit=
her protocol registration or firmware
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* download.
> + =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 /* Prepare wait-for-co=
mpletion handler data structures.
> + =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 init_completion(&hst->=
wait_reg_completion);
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Reset ST registrati=
on callback status flag , this value
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* will be update=
d in ti_st_registration_completion_cb()
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* function whene=
ver it called from ST driver.
> + =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 hst->reg_status =3D -E=
INPROGRESS;
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_DBG("waiting for re=
gistration completion signal from ST");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timeleft =3D wait_for_=
completion_timeout
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (&hst->wait_reg_completion,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!timeleft) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 clear_bit(HCI_RUNNING, &hdev->flags);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("Timeout(%d sec),didn't get reg "
> + =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=A0 "completion =
signal from ST",
> + =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=A0 BT_REGISTER_=
TIMEOUT / 1000);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return -ETIMEDOUT;
> + =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 /* Is ST registration =
callback called with ERROR status? */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (hst->reg_status !=
=3D 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 clear_bit(HCI_RUNNING, &hdev->flags);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("ST registration completed with invalid "
> + =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=A0 "status %d",=
hst->reg_status);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return -EAGAIN;
> + =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 err =3D 0;
> + =C2=A0 =C2=A0 =C2=A0 } else if (err !=3D 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clear_bit(HCI_RUNNING,=
&hdev->flags);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("st_register fa=
iled %d", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /* ti_st_proto.write is filled up by the underlyin=
g shared
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* transport driver upon registration
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D ti_st_proto.write;
> + =C2=A0 =C2=A0 =C2=A0 if (!hst->st_write) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("undefined ST w=
rite function");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clear_bit(HCI_RUNNING,=
&hdev->flags);
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Undo registration w=
ith ST */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D st_unregister(=
ST_BT);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (err)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("st_unregister() failed with error %d", err);
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D NULL=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +
> +/* Close device */
> +static int ti_st_close(struct hci_dev *hdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 int err;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst =3D hdev->driver_data;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags)=
)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* continue to unregister from transport */
> + =C2=A0 =C2=A0 =C2=A0 err =3D st_unregister(ST_BT);
> + =C2=A0 =C2=A0 =C2=A0 if (err)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("st_unregister(=
) failed with error %d", err);
> +
> + =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D NULL;
> +
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +
> +static int ti_st_send_frame(struct sk_buff *skb)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 long len;
> +
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D (struct hci_dev *)skb->dev;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!test_bit(HCI_RUNNING, &hdev->flags))
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EBUSY;
> +
> + =C2=A0 =C2=A0 =C2=A0 hst =3D hdev->driver_data;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Prepend skb with frame type */
> + =C2=A0 =C2=A0 =C2=A0 memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1)=
;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("%s: type %d len %d", hdev->name, bt_cb(skb=
)->pkt_type,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 skb->len);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Insert skb to shared transport layer's transmit=
queue.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* Freeing skb memory is taken care in shared=
transport layer,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* so don't free skb memory here.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 len =3D hst->st_write(skb);
> + =C2=A0 =C2=A0 =C2=A0 if (len < 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree_skb(skb);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("ST write faile=
d (%ld)", len);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Try Again, would on=
ly fail if UART has gone bad */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EAGAIN;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /* ST accepted our skb. So, Go ahead and do rest *=
/
> + =C2=A0 =C2=A0 =C2=A0 hdev->stat.byte_tx +=3D len;
> + =C2=A0 =C2=A0 =C2=A0 ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> +
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +static void ti_st_destruct(struct hci_dev *hdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("%s", hdev->name);
> + =C2=A0 =C2=A0 =C2=A0 kfree(hdev->driver_data);
> +}
> +
> +static int bt_ti_probe(struct platform_device *pdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 static struct ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 hst =3D kzalloc(sizeof(struct ti_st), GFP_KERNEL);
> + =C2=A0 =C2=A0 =C2=A0 if (!hst)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Expose "hciX" device to user space */
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D hci_alloc_dev();
> + =C2=A0 =C2=A0 =C2=A0 if (!hdev) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(hst);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("hdev %p", hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 hst->hdev =3D hdev;
> + =C2=A0 =C2=A0 =C2=A0 hdev->bus =3D HCI_UART;
> + =C2=A0 =C2=A0 =C2=A0 hdev->driver_data =3D hst;
> + =C2=A0 =C2=A0 =C2=A0 hdev->open =3D ti_st_open;
> + =C2=A0 =C2=A0 =C2=A0 hdev->close =3D ti_st_close;
> + =C2=A0 =C2=A0 =C2=A0 hdev->flush =3D NULL;
> + =C2=A0 =C2=A0 =C2=A0 hdev->send =3D ti_st_send_frame;
> + =C2=A0 =C2=A0 =C2=A0 hdev->destruct =3D ti_st_destruct;
> + =C2=A0 =C2=A0 =C2=A0 hdev->owner =3D THIS_MODULE;
> +
> + =C2=A0 =C2=A0 =C2=A0 err =3D hci_register_dev(hdev);
> + =C2=A0 =C2=A0 =C2=A0 if (err < 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("Can't register=
HCI device error %d", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(hst);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hci_free_dev(hdev);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("HCI device registered (hdev %p)", hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 dev_set_drvdata(&pdev->dev, hst);
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +
> +static int bt_ti_remove(struct platform_device *pdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst =3D dev_get_drvdata(&pdev->dev);
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!hst)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EFAULT;
> +
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D hst->hdev;
> + =C2=A0 =C2=A0 =C2=A0 ti_st_close(hdev);
> + =C2=A0 =C2=A0 =C2=A0 hci_unregister_dev(hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 hci_free_dev(hdev);
> + =C2=A0 =C2=A0 =C2=A0 kfree(hst);
> +
> + =C2=A0 =C2=A0 =C2=A0 dev_set_drvdata(&pdev->dev, NULL);
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +static struct platform_driver btwilink_driver =3D {
> + =C2=A0 =C2=A0 =C2=A0 .probe =3D bt_ti_probe,
> + =C2=A0 =C2=A0 =C2=A0 .remove =3D bt_ti_remove,
> + =C2=A0 =C2=A0 =C2=A0 .driver =3D {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .name =3D "btwilink",
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .owner =3D THIS_MODULE=
,
> + =C2=A0 =C2=A0 =C2=A0 },
> +};
> +
> +/* ------- Module Init/Exit interfaces ------ */
> +static int __init btwilink_init(void)
> +{
> + =C2=A0 =C2=A0 =C2=A0 BT_INFO("Bluetooth Driver for TI WiLink - Version =
%s", VERSION);
> +
> + =C2=A0 =C2=A0 =C2=A0 return platform_driver_register(&btwilink_driver);
> +}
> +
> +static void __exit btwilink_exit(void)
> +{
> + =C2=A0 =C2=A0 =C2=A0 platform_driver_unregister(&btwilink_driver);
> +}
> +
> +module_init(btwilink_init);
> +module_exit(btwilink_exit);
> +
> +/* ------ Module Info ------ */
> +
> +MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
> +MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
> +MODULE_VERSION(VERSION);
> +MODULE_LICENSE("GPL");
> --
> 1.5.6.3
>
> --
> 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] Bluetooth: Add new PID for Atheros 3011
From: Bala Shanmugam @ 2010-11-30 5:59 UTC (permalink / raw)
To: Alexander Holler
Cc: Shanmugamkamatchi Balashanmugam, Marcel Holtmann,
linux-bluetooth@vger.kernel.org
In-Reply-To: <4CF38E4B.9070807@ahsoftware.de>
Alexander Holler wrote:
> Am 29.11.2010 07:09, schrieb Bala Shanmugam:
>
>
>> This patch is for Atheros 3011 with sflash firmware.
>> This device gets identified Generic bluetooth USB device when plugged in.
>> We are blacklisting 3002 in btusb to load actual firmware in ath3k.
>> Latest firmware comes up with PID 3005 and not 3002.
>>
>
> Thanks for the explanation. Is there a place in the web where the latest
> firmware could be found?
>
> The only place I've found to look at was the linux-firmware repository
> and that repo currently has no new firmware for the ath3k.
>
> Btw., did you have a look at the small patch for ath3k I posted lately:
>
> http://marc.info/?l=linux-bluetooth&m=129045856314243
>
> This avoids storing the firmware in RAM (I don't see a reason to do
> that, it is never used again) and simplifies the small driver a bit.
>
> Regards,
>
> Alexander
>
Alex,
I am waiting for official release for the firmware and will upload the
same today or tomorrow.
I had look at your patch its good. I did these changes few months
before and it didn't work for me.
I couldn't find time to debug it that time.
Will test it now and update you.
Regards,
Bala.
^ permalink raw reply
* Re: wi2wi bluecore4
From: Brad Midgley @ 2010-11-30 5:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=VPn1k=kLdo7QbM4epc88fdcW2XsbLyFeYt9y4@mail.gmail.com>
Hey
I think I am a little closer, just wanted to see if anyone has any ideas.
I rebuilt bccmd so it would connect at 115k instead of 38k. Not sure
why it's hardcoded if the chip cares (this chip refuses to respond at
38k). In any case, now bccmd can set and reset the chip apparently:
# cat pskey.psr
// PSKEY_UART_BAUDRATE
&01be = 0ebf
// PSKEY_SCO_MAPPING
&01ab = 0
# bccmd.115 -t H4 -d /dev/ttyS1 psload -r pskey.psr
Loading PSKEY_UART_BAUDRATE ... done
Loading PSKEY_HOSTIO_MAP_SCO_PCM ... done
#
But the hciattach still fails with "Initialization timed out.". The
chip returns a single byte...
# strace -s 64 hciattach ttyS1 csr 921600 noflow
...
open("/dev/ttyS1", O_RDWR|O_NOCTTY) = 3
ioctl(3, TCFLSH, 0x2) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(3, TCFLSH, 0x2) = 0
write(3, "\1\0\374\27\302\0\0\t\0\0\0\31(\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 27) = 27
read(3, "\374", 1) = 1
read(3, 0xbed819dc, 1) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
What is the chip saying to us when we read \374? Why is hciattach
initializing at 115k when i told it to use 921k? So I tried setting
the init speed too:
# strace -s 64 hciattach -s 921600 ttyS1 csr 921600 noflow
...
open("/dev/ttyS1", O_RDWR|O_NOCTTY) = 3
ioctl(3, TCFLSH, 0x2) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B921600 -opost -isig -icanon
-echo ...}) = 0
ioctl(3, TCFLSH, 0x2) = 0
write(3, "\1\0\374\27\302\0\0\t\0\0\0\31(\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 27) = 27
read(3, 0xbeebf9cc, 1) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
this time it didn't even get one junk byte. Is there anything else I can check?
Brad
^ 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