* Openmoko and HFP
From: dehqan65 @ 2010-03-14 16:45 UTC (permalink / raw)
To: linux-bluetooth
In The Name Of God The compassionate merciful
Good day all ;
There is a tool for converting laptop as headset . Tool >
http://nohands.sourceforge.net
Humble tested it with sony ericson phone and it worked , so was able
to dial and talk from laptop .
But it does not work with Freerunner phone (SHR os) .
Does this can solve it ??
http://marc.info/?l=linux-bluetooth&m=126810597223611&w=2
How to make it works ?
Regards dehqan
^ permalink raw reply
* Re: Bug in parsing of SDP_ServiceSearchAttributeResponse?
From: Daniel Abraham @ 2010-03-14 13:50 UTC (permalink / raw)
To: Iain Hibbert; +Cc: linux-bluetooth
In-Reply-To: <1268352254.586562.6662.nullmailer@galant.ukfsn.org>
> > So I'm guessing this is a parsing error or interoperability weakness in
> > BlueZ...? (Or, less likely but possible, a bug in the other 2 stacks?)
>
> The PDU that the remote computer sends is truncated at the end of the
> first L2CAP frame (all the 0's that hcidump shows are just empty buffer as
> it does not check the actual frame length). But, each L2CAP frame is
> supposed to contain an entire PDU and when the data exceeds the MTU it
> sends a non zero Continuation State to enable the client to request more
> data.
>
> It might be that this computer was not expecting that the response would
> overflow the L2CAP frame and they didn't write the code to handle that,
> but in the meantime many services were added..
Thanks! This is exactly the pointer I was looking for. I didn't
understand your answer at first, but it led me to study the right
section in the BT spec, so now I get it.
> You can probably use "sdptool search" to find specific services ok?
Actually "sdptool" is just an example, the real problem is that when
BlueZ discovers that device, the SDP PDU truncation causes it to appear
to be profile-less, so I can't actively connect to any service, only
passively accept connections.
> Although sdptool has no way to increase the "Incoming MTU" on the SDP
> connection, if you could work out how to do that it might allow more
> information to be received (in lib/sdp.c:sdp_connect_l2cap() set
> L2CAP_OPTIONS with imtu at some large number than 672, before the
> connect())
Although the PDU truncation is a bug not in BlueZ, I still think it uncovers a point for improvement in BlueZ.
Up until the truncation point, the PDU still contains 6-7 valid attribute lists, which are discarded. Why not use them despite the malformed PDU?
Thanks again
^ permalink raw reply
* Re: RFC: QuIC's AMP + eL2CAP Technical Plans
From: Gustavo F. Padovan @ 2010-03-13 17:30 UTC (permalink / raw)
To: tmonahan; +Cc: linux-bluetooth, Marcel Holtmann
In-Reply-To: <1267753300.29510.25.camel@localhost.localdomain>
Hi Tim,
* Marcel Holtmann <marcel@holtmann.org> [2010-03-04 17:41:40 -0800]:
> Hi Tim,
>
> > QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora Forum)
> > is planning an implementation of AMP for BlueZ. Here are some details of
> > our technical approach. We are interested in comments from the BlueZ
> > development community on validity and whether there are areas we have
> > missed.
> >
> > Features:
> > - Completion of L2CAP with ERTM
> >
> > - Addition of L2CAP Channel Management and AMP Manager
> >
> > - DBUS support to access AMP features, control AMP settings, etc.
> >
> > - Updates to Test Programs (hcidump, hciemu, l2test, ...)
> >
> > - Creation of a Fake PAL to facilitate desktop development using wired TCP
> >
> > - Legacy L2CAP sockets take advantage of AMP, if so enabled using new
> > controls (sockopts or DBUS)
> >
> > - Key Management extended for AMP Controller Keys
> >
> >
> > L2CAP and ERTM
> > --------------
> >
> > A prerequisite for AMP support is a fully functional L2CAP ERTM
> > implementation, including optional L2CAP features not currently included
> > in BlueZ.
> >
> > Our overall approach is to build on the existing ERTM code in the
> > bluetooth-testing tree, extending the present socket interfaces that are
> > visible to userspace. The extensions we foresee are sockopt configuration
> > of MPS (max PDU size), TX window size (currently hard coded), and a simple
> > AMP control policy ("BR/EDR only", "initiate on or move to AMP", or
> > "initiate on or move to BR/EDR, allow incoming move").
>
> I was under the impression it is best to match the MPS with the ACL MTU
> from the controller? So do we need really an option less. Less options
> are less confusing for users.
MaxTransmit should be in the sockopt too.
>
> > There are a few protocol-level enhancements required. One is to support
> > L2CAP lockstep configuration, in addition to the present standard
> > configuration process. Another addition is support for the extended TX
> > window option.
> >
> > Core ERTM functionality (without the proposed additional features) is
> > still a work in progress, and the main area that needs attention is the
> > implementation of the transmitter (XMIT and WAIT_F) and receiver (RECV and
> > SREJ_SENT) state tables as defined in the ERTM spec.
> >
> >
> > L2CAP and Channel Management for AMP
> > ------------------------------------
> >
> > Once ERTM is working without AMP, the state machine will have to be
> > extended to account for the extra demands of creating channels directly on
> > an AMP controller and AMP channel moves. L2CAP will have to deal with two
> > controllers (BR/EDR and AMP) while the channel move is taking place, and
> > correctly handle lockstep reconfiguration of the L2CAP channel when the
> > move is completing.
> >
> > To enable AMP, L2CAP itself will need to be enhanced to support the A2MP
> > fixed channel and to use the AMP Manager to create/disconnect physical and
> > logical links on an AMP controller. Additionally L2CAP will need to
> > manage channels according to the new AMP control, moving them as
> > appropriate and handling remote move requests.
> >
> > The AMP Manager function will need to be created. It will support
> > signaling on the A2MP channel and the create/disconnect of AMP physical
> > and logical links.
> >
> > HCI will need to be extended to support data-block-based flow control. AMP
> > Controllers will be presented to BlueZ as HCI devices of a new type.
>
> The block-based flow control is a missing piece, but the AMP type
> extension has been merged upstream. We can create HCI_BREDR and
> HCI_80211 controllers now. The AMP controllers are for now forced to be
> raw devices, but that can be changed easily once we have the controller
> init for AMP up and ready.
>
> > DBUS Additions (bluetoothd)
> > ---------------------------
> >
> > org.bluez.Adapter : A new property is added, containing a list of the
> > associated org.bluez.AmpAdapter objects ("/org/bluez/amp{0, 1, 2, ...}").
> > Associating a given AmpAdapter to a parent BR/EDR device
> > ("/org/bluez/hci{n}") is one method of org.bluez.AmpAdapter . AmpAdapter
> > has other methods to obtain the local controller's type and status, and
> > the number of physical links it carries, and to mark whether it is
> > available for use by the Amp Manager.
> >
> > org.bluez.Device : A new method begins the AMP Discovery procedure for
> > that Device; an alternative would be to add the procedure to what
> > DiscoverServices() does. A new property contains the cached remote AMP
> > Device list.
>
> I have to reject this. I don't seen any need to expose this. We could
> just do this all internally inside the kernel. The AMP policy should
> trigger these automatically and if AMP usage is allowed, we just pick
> the right AMP. Involving the user in AMP discovery makes no sense and
> complicates the user cases.
>
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* builtin bluetooth dongle not in PSCAN mode at startup anymore, though it was in 4.42
From: Alexander Markov @ 2010-03-13 12:13 UTC (permalink / raw)
To: linux-bluetooth
Hi everybody,
i've installed Fedora 12 on my laptop recently (in addition to Fedora
11) and have got a problem with my bluetooth mouse. it didnt want to
connect AT STARTUP.
in F11 it works just fine. ive started researching the problem and found
that in F11 hciconfig output is as follow:
hci0: Type: USB
BD Address: 00:0B:6B:90:0B:7C ACL MTU: 377:10 SCO MTU: 64:8
UP RUNNING PSCAN
...
...
while in F12
hci0: Type: USB
BD Address: 00:0B:6B:90:0B:7C ACL MTU: 377:10 SCO MTU: 64:8
UP RUNNING
...
...
So. it's the same laptop, the same builtin dongle.
but in F11 it is bluez-4.42, and in F12 it is bluez-4.58
Ive tried to install the last available bluez-4.62 at my F11, and got
what was expected: hci0: UP RUNNING. (no PSCAN)
Ive tried using bluetoothd binary from F11 on my F12 and again i got
what expected: hci0: UP RUNNING PSCAN.
I could not use it that way as it's difficult to downgrade to 4.42 on
F12 and probably it's not the best way to solve problems :)
So, my question is can i overcome it by use of any conf files or can
anybody fix this bug(?) ?
^ permalink raw reply
* Re: lockdep warns: inconsistent lock state ({IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W})
From: Andrei Emeltchenko @ 2010-03-12 14:14 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1268153872.3712.54.camel@localhost.localdomain>
Hi Marcel,
On Tue, Mar 9, 2010 at 6:57 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Andrei,
>
>> > is this still present with 2.6.34-rc1 kernel?
>>
>> We are using 2.6.32-XX kernel so far.
>
> please check with 2.6.34-rc1 to ensure it is still present. And do you
> have instructions on how to re-produce it?
One strange here is that I see this when
CONFIG_PROVE_LOCKING is enabled and CONFIG_DEBUG_LOCKDEP is not enabled.
When I enabled both CONFIG_DEBUG_LOCKDEP and CONFIG_PROVE_LOCKING I
see no warnings.
We use stress tests so I am not sure that it is easy to reproduce.
Regards,
Andrei
^ permalink raw reply
* Re: patch for firmware download to Qualcomm Bluetooth chip
From: Matt Wilson @ 2010-03-12 13:33 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1267142545.30787.6.camel@linux-champ-06.qualcomm.com>
Any comments for this patch?
Sorry to send only CC: to the list before.
I assume that error makes a review difficult.
I have an update for this patch for setting baud rate and do not know if
I should update the original or make a new separate patch.
Please also find the original ones (download patch and firmware patch)
here:
https://www.codeaurora.org/patches/quic/chrome/0001-Firmware-download-for-Qualcomm-Bluetooth-devices.patch
https://www.codeaurora.org/patches/quic/chrome/0001-Firmware-for-Qualcomm-Bluetooth-BTS4025.patch
These are from the Code Aurora Forum partner Qualcomm Innovation Center,
Inc.
Best regards,
Matt Wilson
^ permalink raw reply
* RE: [bluetooth-next V2] bluetooth: hci_sysfs: use strict_strtoul instead of simple_strtoul
From: Marcel Holtmann @ 2010-03-12 0:28 UTC (permalink / raw)
To: Winkler, Tomas
Cc: linux-bluetooth@vger.kernel.org, Cohen, Guy, Rindjunsky, Ron
In-Reply-To: <6F5C1D715B2DA5498A628E6B9C124F04016C0E9798@hasmsx504.ger.corp.intel.com>
Hi Tomas,
> > > use strict_strtoul as suggested by checkpatch.pl
> > >
> > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > ---
> > > V2:
> > > 1. more verbose commit message
> > > 2. return the error code that was produced by strict_strtoul
> >
> > why do you bother actually. Reading the comment about struct_strtoul it
> > will only return -EINVAL or 0. So using my proposal would be just fine.
> > I also don't prefer to differ the return value to user space until it
> > actually makes sense. Invalid argument is just fine for all error cases.
> >
> Yes I know but I've use of this over the kernel code and what I've used is the mostly used idiom
I choose to have it as I originally proposed. Patch has been pushed into
bluetooth-testing tree.
Regards
Marcel
^ permalink raw reply
* Re: Bug in parsing of SDP_ServiceSearchAttributeResponse?
From: Iain Hibbert @ 2010-03-12 0:04 UTC (permalink / raw)
To: Daniel Abraham; +Cc: linux-bluetooth
In-Reply-To: <1268344653.9884.42.camel@dabraham-mobl>
On Thu, 11 Mar 2010, Daniel Abraham wrote:
> Hi, this is my first time here, so I'm not sure about etiquette, or
> if/where there's a BlueZ bug repository...
>
> I'm using BlueZ 4.62, and I ran the command line "sdptool browse <BD
> address>" against a remote computer. I got this error output: "Service
> search failed: Success".
what computer is that?
> According to hcidump (attached), the SDP_ServiceSearchAttributeResponse
> is malformed, but a different Bluetooth stack (IVT on Windows) is able
> to report correctly the remote computer's available services.
It could be that the different Bluetooth stacks fetch that information via
a different request than ServiceSearchAttributes, or that it queries the
services that it hopes to see individually rather than just the
PublicBrowseGroup to get everything as in this case.
> So I'm guessing this is a parsing error or interoperability weakness in
> BlueZ...? (Or, less likely but possible, a bug in the other 2 stacks?)
The PDU that the remote computer sends is truncated at the end of the
first L2CAP frame (all the 0's that hcidump shows are just empty buffer as
it does not check the actual frame length). But, each L2CAP frame is
supposed to contain an entire PDU and when the data exceeds the MTU it
sends a non zero Continuation State to enable the client to request more
data.
It might be that this computer was not expecting that the response would
overflow the L2CAP frame and they didn't write the code to handle that,
but in the meantime many services were added..
You can probably use "sdptool search" to find specific services ok?
Although sdptool has no way to increase the "Incoming MTU" on the SDP
connection, if you could work out how to do that it might allow more
information to be received (in lib/sdp.c:sdp_connect_l2cap() set
L2CAP_OPTIONS with imtu at some large number than 672, before the
connect())
regards,
iain
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
From: Gustavo F. Padovan @ 2010-03-11 22:41 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, marcel
In-Reply-To: <508e92ca1002160236k34c18949jc7d7187645ef4aa0@mail.gmail.com>
Hi Andrei,
* Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-02-16 12:36:47 +0200]:
> From 0135f732cb45e5e91062aca84a61a40b172200a4 Mon Sep 17 00:00:00 2001
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> Date: Tue, 16 Feb 2010 10:52:33 +0200
> Subject: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
>
> Added very simple check that req buffer has enough space to
> fit configuration parameters. Shall be enough to reject packets
> with configuration size more than req buffer.
>
> Crash trace below
>
> [ 6069.659393] Unable to handle kernel paging request at virtual
> address 02000205
> [ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
> ...
> [ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
> [ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
> ...
> [ 6070.030303] Backtrace:
> [ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
> [<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
> [ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
> [ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
> [<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
> [ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
> [<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth])
> [ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740
> [ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from
> [<c006b9fc>] (tasklet_action+0x78/0xd8)
> [ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>]
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 400efa2..69b7280 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -2830,6 +2830,12 @@ static inline int l2cap_config_rsp(struct
> l2cap_conn *conn, struct l2cap_cmd_hdr
> int len = cmd->len - sizeof(*rsp);
> char req[64];
>
> + if (len > sizeof(req) - sizeof(struct l2cap_conf_req)) {
> + BT_ERR("Config response is too big");
Remove the BT_ERR, normally we don't print any error on
l2cap_send_disconn_req.
> + l2cap_send_disconn_req(conn, sk);
> + goto done;
> + }
> +
> /* throw out any old stored conf requests */
> result = L2CAP_CONF_SUCCESS;
> len = l2cap_parse_conf_rsp(sk, rsp->data,
Also, this is very rare crash. Even if we add all configure options to
req we won't overwrite it. Doesn't make sense to me send a
configuration option more than once in the same config_{rsp,req}. The
only way to crash l2cap is using a bugous remote stack or a stress test
tools. We need to be protected against those bugous stacks so I'll
ack your patch after you send the updated patch without the BT_ERR.
--
Gustavo F. Padovan
http://padovan.org
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Bug in parsing of SDP_ServiceSearchAttributeResponse?
From: Daniel Abraham @ 2010-03-11 21:57 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Hi, this is my first time here, so I'm not sure about etiquette, or
if/where there's a BlueZ bug repository...
I'm using BlueZ 4.62, and I ran the command line "sdptool browse <BD
address>" against a remote computer. I got this error output: "Service
search failed: Success".
According to hcidump (attached), the SDP_ServiceSearchAttributeResponse
is malformed, but a different Bluetooth stack (IVT on Windows) is able
to report correctly the remote computer's available services.
So I'm guessing this is a parsing error or interoperability weakness in
BlueZ...? (Or, less likely but possible, a bug in the other 2 stacks?)
Thanks
[-- Attachment #2: sdptool-browse-error.hcidump --]
[-- Type: application/octet-stream, Size: 1699 bytes --]
^ permalink raw reply
* Re: [PATCH] Added support for Atheros AR300x Bluetooth Chip
From: Luis R. Rodriguez @ 2010-03-11 17:35 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Vikram Kandukuri, Luis Rodriguez, Jothikumar Mothilal
In-Reply-To: <1268327744.3712.88.camel@localhost.localdomain>
On Thu, Mar 11, 2010 at 09:15:44AM -0800, Marcel Holtmann wrote:
> Hi Suraj,
>
> > Signed-off-by: Suraj <suraj@atheros.com>
> >
> > ---
> > drivers/bluetooth/Kconfig | 11 ++
> > drivers/bluetooth/Makefile | 1 +
> > drivers/bluetooth/hci_ath.c | 353 +++++++++++++++++++++++++++++++++++++++++
> > drivers/bluetooth/hci_ldisc.c | 6 +
> > drivers/bluetooth/hci_uart.h | 8 +-
> > 5 files changed, 378 insertions(+), 1 deletions(-)
> > create mode 100755 drivers/bluetooth/hci_ath.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index 058fbcc..81abeff 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -58,6 +58,17 @@ config BT_HCIUART_BCSP
> >
> > Say Y here to compile support for HCI BCSP protocol.
> >
> > +config BT_HCIUART_ATH
> > + bool "Atheros AR300x Board support"
> > + depends on BT_HCIUART
> > + help
> > + HCIATH (HCI Atheros) is a serial protocol for communication
> > + between Bluetooth device and host with support for Atheros AR300x
> > + power management feature. This protocol is required for
> > + serial Bluetooth devices that are based on Atheros AR300x chips.
> > +
> > + Say Y here to compile support for Atheros AR300x Chips.
>
> your patch is messed up. Make sure your mailer doesn't mess with tabs
> and whitespaces.
I had issues with our Exchange server for patches but that was only for
receiving patches [1], but that is now fixed. I don't think the SMTP
server should screw with patches on their way out. Suraj, did you
actually intend for the patch to go out as is?
[1] http://bombadil.infradead.org/~mcgrof/MS-exchange-sucks-for-patches/
Luis
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
From: Marcel Holtmann @ 2010-03-11 17:16 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Gustavo F. Padovan, linux-bluetooth
In-Reply-To: <508e92ca1003110654t45cfc9d7j9704b60f9f2b4af2@mail.gmail.com>
Hi Andrei,
please no top posting. It is never a good idea.
> What is the status of this patch proposed?
I like see Gustavo's ack or nak on this one.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Added support for Atheros AR300x Bluetooth Chip
From: Marcel Holtmann @ 2010-03-11 17:15 UTC (permalink / raw)
To: Suraj Sumangala
Cc: linux-bluetooth@vger.kernel.org, Vikram Kandukuri,
Suraj Sumangala, Luis Rodriguez, Jothikumar Mothilal
In-Reply-To: <4B98ED8F.2020000@atheros.com>
Hi Suraj,
> Signed-off-by: Suraj <suraj@atheros.com>
>
> ---
> drivers/bluetooth/Kconfig | 11 ++
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/hci_ath.c | 353 +++++++++++++++++++++++++++++++++++++++++
> drivers/bluetooth/hci_ldisc.c | 6 +
> drivers/bluetooth/hci_uart.h | 8 +-
> 5 files changed, 378 insertions(+), 1 deletions(-)
> create mode 100755 drivers/bluetooth/hci_ath.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 058fbcc..81abeff 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -58,6 +58,17 @@ config BT_HCIUART_BCSP
>
> Say Y here to compile support for HCI BCSP protocol.
>
> +config BT_HCIUART_ATH
> + bool "Atheros AR300x Board support"
> + depends on BT_HCIUART
> + help
> + HCIATH (HCI Atheros) is a serial protocol for communication
> + between Bluetooth device and host with support for Atheros AR300x
> + power management feature. This protocol is required for
> + serial Bluetooth devices that are based on Atheros AR300x chips.
> +
> + Say Y here to compile support for Atheros AR300x Chips.
your patch is messed up. Make sure your mailer doesn't mess with tabs
and whitespaces.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
From: Andrei Emeltchenko @ 2010-03-11 14:54 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <508e92ca1002180818n4fd0e277qf845e19596d0cf48@mail.gmail.com>
Hei,
What is the status of this patch proposed?
-- Andrei
On Thu, Feb 18, 2010 at 6:18 PM, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
> Hi Gustavo
>
> On Thu, Feb 18, 2010 at 1:57 AM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
>> Hi Andrei,
>>
>> * Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-02-16 13:58:34 +0200]:
>>
>>> On Tue, Feb 16, 2010 at 1:34 PM, Gustavo F. Padovan
>>> <padovan@profusion.mobi> wrote:
>>> > Hi Andrei,
>>> >
>>> > * Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-02-16 12:36:47 +0200]:
>>> >
>>> >> From 0135f732cb45e5e91062aca84a61a40b172200a4 Mon Sep 17 00:00:00 2001
>>> >> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>> >> Date: Tue, 16 Feb 2010 10:52:33 +0200
>>> >> Subject: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
>>> >>
>>> >> Added very simple check that req buffer has enough space to
>>> >> fit configuration parameters. Shall be enough to reject packets
>>> >> with configuration size more than req buffer.
>>> >>
>>> >> Crash trace below
>>> >>
>>> >> [ 6069.659393] Unable to handle kernel paging request at virtual
>>> >> address 02000205
>>> >> [ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
>>> >> ...
>>> >> [ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
>>> >> [ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
>>> >> ...
>>> >> [ 6070.030303] Backtrace:
>>> >> [ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
>>> >> [<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
>>> >> [ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
>>> >> [ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
>>> >> [<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
>>> >> [ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
>>> >> [<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth])
>>> >> [ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740
>>> >> [ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from
>>> >> [<c006b9fc>] (tasklet_action+0x78/0xd8)
>>> >> [ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>]
>>> >
>>> > Are you using ERTM or Streaming mode? If yes, I have a guess about the
>>> > source of the problem. On l2cap_parse_conf_rsp we check for:
>>> >
>>> > while (len >= L2CAP_CONF_OPT_SIZE) {
>>> > len -= l2cap_get_conf_opt(&rsp, &type, &olen, &val);
>>> >
>>> > But on case L2CAP_CONF_RFC olen is greater than L2CAP_CONF_OPT_SIZE we
>>> > can exceed the buffer size. So the right fix will be check if len >=
>>> > olen in that case.
>
> Is len always bigger then olen?
>
> in l2cap_get_conf_opt :
>
> len = L2CAP_CONF_OPT_SIZE + opt->len;
>
> opt->len is olen
>
> -- Andrei
>
>>>
>>> We use test tool which sends "Configure Response" packet with size 262
>>> bytes. So "req" buffer gets overwritten. But in the code nobody checks
>>> that "req" might be overwritten.
>>
>> So I have found another issue. ;)
>> Have to fix it.
>>
>>>
>>> -- Andrei
>>>
>>> >
>>> >
>>> >>
>>> >> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>> >> ---
>>> >> net/bluetooth/l2cap.c | 6 ++++++
>>> >> 1 files changed, 6 insertions(+), 0 deletions(-)
>>> >>
>>> >> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>>> >> index 400efa2..69b7280 100644
>>> >> --- a/net/bluetooth/l2cap.c
>>> >> +++ b/net/bluetooth/l2cap.c
>>> >> @@ -2830,6 +2830,12 @@ static inline int l2cap_config_rsp(struct
>>> >> l2cap_conn *conn, struct l2cap_cmd_hdr
>>> >> int len = cmd->len - sizeof(*rsp);
>>> >> char req[64];
>>> >>
>>> >> + if (len > sizeof(req) - sizeof(struct l2cap_conf_req)) {
>>> >> + BT_ERR("Config response is too big");
>>> >> + l2cap_send_disconn_req(conn, sk);
>>> >> + goto done;
>>> >> + }
>>> >> +
>>> >> /* throw out any old stored conf requests */
>>> >> result = L2CAP_CONF_SUCCESS;
>>> >> len = l2cap_parse_conf_rsp(sk, rsp->data,
>>> >> --
>>> >> 1.6.0.4
>>> >
>>> >
>>> > --
>>> > Gustavo F. Padovan
>>> > http://padovan.org
>>> >
>>> > ProFUSION embedded systems - http://profusion.mobi
>>> >
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Gustavo F. Padovan
>> http://padovan.org
>>
>> ProFUSION embedded systems - http://profusion.mobi
>>
>
^ permalink raw reply
* [PATCH] Added support for Atheros AR300x Bluetooth Chip
From: Suraj Sumangala @ 2010-03-11 13:18 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Cc: Vikram Kandukuri, marcel@holtmann.org, Suraj Sumangala,
Luis Rodriguez, Jothikumar Mothilal
In-Reply-To: <20100209114231.GA6587@ATH-LT-538>
Signed-off-by: Suraj <suraj@atheros.com>
---
drivers/bluetooth/Kconfig | 11 ++
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/hci_ath.c | 353 +++++++++++++++++++++++++++++++++++++++++
drivers/bluetooth/hci_ldisc.c | 6 +
drivers/bluetooth/hci_uart.h | 8 +-
5 files changed, 378 insertions(+), 1 deletions(-)
create mode 100755 drivers/bluetooth/hci_ath.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 058fbcc..81abeff 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -58,6 +58,17 @@ config BT_HCIUART_BCSP
Say Y here to compile support for HCI BCSP protocol.
+config BT_HCIUART_ATH
+ bool "Atheros AR300x Board support"
+ depends on BT_HCIUART
+ help
+ HCIATH (HCI Atheros) is a serial protocol for communication
+ between Bluetooth device and host with support for Atheros AR300x
+ power management feature. This protocol is required for
+ serial Bluetooth devices that are based on Atheros AR300x chips.
+
+ Say Y here to compile support for Atheros AR300x Chips.
+
config BT_HCIUART_LL
bool "HCILL protocol support"
depends on BT_HCIUART
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 7e5aed5..1481faa 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -26,4 +26,5 @@ hci_uart-y := hci_ldisc.o
hci_uart-$(CONFIG_BT_HCIUART_H4) += hci_h4.o
hci_uart-$(CONFIG_BT_HCIUART_BCSP) += hci_bcsp.o
hci_uart-$(CONFIG_BT_HCIUART_LL) += hci_ll.o
+hci_uart-$(CONFIG_BT_HCIUART_ATH) += hci_ath.o
hci_uart-objs := $(hci_uart-y)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
new file mode 100755
index 0000000..13e4404
--- /dev/null
+++ b/drivers/bluetooth/hci_ath.c
@@ -0,0 +1,353 @@
+/*
+ * Copyright (c) 2009-2010 Atheros Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/errno.h>
+#include <linux/ioctl.h>
+#include <linux/skbuff.h>
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "hci_uart.h"
+
+
+/* HCIATH receiver States */
+#define HCIATH_W4_PACKET_TYPE 0
+#define HCIATH_W4_EVENT_HDR 1
+#define HCIATH_W4_ACL_HDR 2
+#define HCIATH_W4_SCO_HDR 3
+#define HCIATH_W4_DATA 4
+
+struct ath_struct {
+ struct hci_uart *hu;
+ unsigned int rx_state;
+ unsigned int rx_count;
+ unsigned int cur_sleep;
+
+ spinlock_t hciath_lock;
+ struct sk_buff *rx_skb;
+ struct sk_buff_head txq;
+ wait_queue_head_t wqevt;
+ struct work_struct ctxtsw;
+};
+
+int ath_wakeup_ar3001(struct tty_struct *tty)
+{
+ struct termios settings;
+ int status = 0x00;
+ mm_segment_t oldfs;
+ status = tty->driver->ops->tiocmget(tty, NULL);
+
+ if ((status & TIOCM_CTS))
+ return status;
+
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+ n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
+
+ settings.c_cflag &= ~CRTSCTS;
+ n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
+ set_fs(oldfs);
+ status = tty->driver->ops->tiocmget(tty, NULL);
+
+ /* Wake up board */
+ tty->driver->ops->tiocmset(tty, NULL, 0x00, TIOCM_RTS);
+ mdelay(20);
+
+ status = tty->driver->ops->tiocmget(tty, NULL);
+
+ tty->driver->ops->tiocmset(tty, NULL, TIOCM_RTS, 0x00);
+ mdelay(20);
+
+ status = tty->driver->ops->tiocmget(tty, NULL);
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+ n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
+
+ settings.c_cflag |= CRTSCTS;
+ n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
+ set_fs(oldfs);
+ return status;
+}
+
+static void ath_context_switch(struct work_struct *work)
+{
+ int status;
+ struct ath_struct *ath;
+ struct hci_uart *hu;
+ struct tty_struct *tty;
+
+ ath = container_of(work, struct ath_struct, ctxtsw);
+
+ hu = ath->hu;
+ tty = hu->tty;
+
+ /* verify and wake up controller */
+ if (ath->cur_sleep) {
+
+ status = ath_wakeup_ar3001(tty);
+ if (!(status & TIOCM_CTS))
+ return;
+ }
+
+ /* Ready to send Data */
+ clear_bit(HCI_UART_SENDING, &hu->tx_state);
+ hci_uart_tx_wakeup(hu);
+}
+
+int ath_check_sleep_cmd(struct ath_struct *ath, unsigned char *packet)
+{
+ if (packet[0] == 0x04 && packet[1] == 0xFC)
+ ath->cur_sleep = packet[3];
+
+ return 0;
+}
+
+
+/* Initialize protocol */
+static int ath_open(struct hci_uart *hu)
+{
+ struct ath_struct *ath;
+ BT_DBG("hu %p", hu);
+
+ ath = kzalloc(sizeof(*ath), GFP_ATOMIC);
+ if (!ath)
+ return -ENOMEM;
+
+ skb_queue_head_init(&ath->txq);
+ spin_lock_init(&ath->hciath_lock);
+
+ ath->cur_sleep = 0;
+ hu->priv = ath;
+ ath->hu = hu;
+
+ init_waitqueue_head(&ath->wqevt);
+ INIT_WORK(&ath->ctxtsw, ath_context_switch);
+ return 0;
+}
+
+/* Flush protocol data */
+static int ath_flush(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ BT_DBG("hu %p", hu);
+ skb_queue_purge(&ath->txq);
+
+ return 0;
+}
+
+/* Close protocol */
+static int ath_close(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ BT_DBG("hu %p", hu);
+
+ skb_queue_purge(&ath->txq);
+
+ if (ath->rx_skb)
+ kfree_skb(ath->rx_skb);
+
+ wake_up_interruptible(&ath->wqevt);
+ hu->priv = NULL;
+ kfree(ath);
+ return 0;
+}
+
+/* Enqueue frame for transmittion */
+static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb)
+{
+ struct ath_struct *ath = hu->priv;
+ if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) {
+
+ /* Discard SCO packet.AR3001 does not support SCO over HCI */
+ BT_DBG("SCO Packet over HCI received Dropping\n");
+ kfree(skb);
+ return 0;
+ }
+ BT_DBG("hu %p skb %p", hu, skb);
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
+
+ skb_queue_tail(&ath->txq, skb);
+ set_bit(HCI_UART_SENDING, &hu->tx_state);
+
+ schedule_work(&ath->ctxtsw);
+ return 0;
+}
+
+static struct sk_buff *ath_dequeue(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ struct sk_buff *skbuf;
+
+ skbuf = skb_dequeue(&ath->txq);
+ if (skbuf != NULL)
+ ath_check_sleep_cmd(ath, &skbuf->data[1]);
+
+ return skbuf;
+}
+
+static inline int ath_check_data_len(struct ath_struct *ath, int len)
+{
+ register int room = skb_tailroom(ath->rx_skb);
+ BT_DBG("len %d room %d", len, room);
+
+ if (len > room) {
+ BT_ERR("Data length is too large");
+ kfree_skb(ath->rx_skb);
+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
+ ath->rx_skb = NULL;
+ ath->rx_count = 0;
+ } else {
+ ath->rx_state = HCIATH_W4_DATA;
+ ath->rx_count = len;
+ return len;
+ }
+
+ return 0;
+}
+
+/* Recv data */
+static int ath_recv(struct hci_uart *hu, void *data, int count)
+{
+ struct ath_struct *ath = hu->priv;
+ register char *ptr;
+ struct hci_event_hdr *eh;
+ struct hci_acl_hdr *ah;
+ struct hci_sco_hdr *sh;
+ struct sk_buff *skbuf;
+ register int len, type, dlen;
+
+ skbuf = NULL;
+ BT_DBG("hu %p count %d rx_state %d rx_count %d", hu, count,
+ ath->rx_state, ath->rx_count);
+ ptr = data;
+ while (count) {
+ if (ath->rx_count) {
+
+ len = min_t(unsigned int, ath->rx_count, count);
+ memcpy(skb_put(ath->rx_skb, len), ptr, len);
+ ath->rx_count -= len;
+ count -= len;
+ ptr += len;
+
+ if (ath->rx_count)
+ continue;
+ switch (ath->rx_state) {
+ case HCIATH_W4_DATA:
+ hci_recv_frame(ath->rx_skb);
+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
+ ath->rx_skb = NULL;
+ ath->rx_count = 0;
+ continue;
+ case HCIATH_W4_EVENT_HDR:
+ eh = (struct hci_event_hdr *)ath->rx_skb->data;
+ BT_DBG("Event header: evt 0x%2.2x plen %d",
+ eh->evt, eh->plen);
+ ath_check_data_len(ath, eh->plen);
+ continue;
+ case HCIATH_W4_ACL_HDR:
+ ah = (struct hci_acl_hdr *)ath->rx_skb->data;
+ dlen = __le16_to_cpu(ah->dlen);
+ BT_DBG("ACL header: dlen %d", dlen);
+ ath_check_data_len(ath, dlen);
+ continue;
+ case HCIATH_W4_SCO_HDR:
+ sh = (struct hci_sco_hdr *)ath->rx_skb->data;
+ BT_DBG("SCO header: dlen %d", sh->dlen);
+ ath_check_data_len(ath, sh->dlen);
+ continue;
+ }
+ }
+
+ /* HCIATH_W4_PACKET_TYPE */
+ switch (*ptr) {
+ case HCI_EVENT_PKT:
+ BT_DBG("Event packet");
+ ath->rx_state = HCIATH_W4_EVENT_HDR;
+ ath->rx_count = HCI_EVENT_HDR_SIZE;
+ type = HCI_EVENT_PKT;
+ break;
+ case HCI_ACLDATA_PKT:
+ BT_DBG("ACL packet");
+ ath->rx_state = HCIATH_W4_ACL_HDR;
+ ath->rx_count = HCI_ACL_HDR_SIZE;
+ type = HCI_ACLDATA_PKT;
+ break;
+ case HCI_SCODATA_PKT:
+ BT_DBG("SCO packet");
+ ath->rx_state = HCIATH_W4_SCO_HDR;
+ ath->rx_count = HCI_SCO_HDR_SIZE;
+ type = HCI_SCODATA_PKT;
+ break;
+ default:
+ BT_ERR("Unknown HCI packet type %2.2x", (__u8) *ptr);
+ hu->hdev->stat.err_rx++;
+ ptr++;
+ count--;
+ continue;
+ };
+ ptr++;
+ count--;
+
+ /* Allocate packet */
+ ath->rx_skb = bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
+ if (!ath->rx_skb) {
+ BT_ERR("Can't allocate mem for new packet");
+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
+ ath->rx_count = 0;
+ return -ENOMEM;
+ }
+ ath->rx_skb->dev = (void *)hu->hdev;
+ bt_cb(ath->rx_skb)->pkt_type = type;
+ } return count;
+}
+
+static struct hci_uart_proto athp = {
+ .id = HCI_UART_ATH,
+ .open = ath_open,
+ .close = ath_close,
+ .recv = ath_recv,
+ .enqueue = ath_enqueue,
+ .dequeue = ath_dequeue,
+ .flush = ath_flush,
+};
+
+int ath_init(void)
+{
+ int err = hci_uart_register_proto(&athp);
+ if (!err)
+ BT_INFO("HCIATH protocol initialized");
+
+ else
+ BT_ERR("HCIATH protocol registration failed");
+ return err;
+}
+
+int ath_deinit(void)
+{
+ return hci_uart_unregister_proto(&athp);
+}
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 76a1abb..7dd76d1 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -542,6 +542,9 @@ static int __init hci_uart_init(void)
#ifdef CONFIG_BT_HCIUART_LL
ll_init();
#endif
+#ifdef CONFIG_BT_HCIUART_ATH
+ ath_init();
+#endif
return 0;
}
@@ -559,6 +562,9 @@ static void __exit hci_uart_exit(void)
#ifdef CONFIG_BT_HCIUART_LL
ll_deinit();
#endif
+#ifdef CONFIG_BT_HCIUART_ATH
+ ath_deinit();
+#endif
/* Release tty registration of line discipline */
if ((err = tty_unregister_ldisc(N_HCI)))
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 50113db..385537f 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -33,13 +33,14 @@
#define HCIUARTGETDEVICE _IOR('U', 202, int)
/* UART protocols */
-#define HCI_UART_MAX_PROTO 5
+#define HCI_UART_MAX_PROTO 6
#define HCI_UART_H4 0
#define HCI_UART_BCSP 1
#define HCI_UART_3WIRE 2
#define HCI_UART_H4DS 3
#define HCI_UART_LL 4
+#define HCI_UART_ATH 5
struct hci_uart;
@@ -91,3 +92,8 @@ int bcsp_deinit(void);
int ll_init(void);
int ll_deinit(void);
#endif
+
+#ifdef CONFIG_BT_HCIUART_ATH
+int ath_init(void);
+int ath_deinit(void);
+#endif
--
1.6.3.3
^ permalink raw reply related
* RE: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Mike Tsai @ 2010-03-11 2:27 UTC (permalink / raw)
To: shy
Cc: Pavel Machek, Marcel Holtmann, Luis R. Rodriguez, linux-wireless,
linux-bluetooth, linux-kernel@vger.kernel.org, Dan Tian
In-Reply-To: <a11267f31003101733q50d8755bmae7b6812d1e5e6b4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]
Shy,
There are 3 sources of channel map inputs that LM has to consider for an optimal channel map. Host input is the one that LM must obey, the other 2 are optional (internal and peer device channel map),
BR,
Mike
________________________________
From: shy [mailto:shyboysby@gmail.com]
Sent: Wednesday, March 10, 2010 5:33 PM
To: Mike Tsai
Cc: Pavel Machek; Marcel Holtmann; Luis R. Rodriguez; linux-wireless; linux-bluetooth; linux-kernel@vger.kernel.org; Dan Tian
Subject: Re: Linux Bluetooth Coexistence documentation in general and for ath9k
Mike,
This is done by controller. If host take the charge of channel map, then it must act as LMP role.
Best regards
shy
2010/3/11 Mike Tsai <Mike.Tsai@atheros.com<mailto:Mike.Tsai@atheros.com>>
Hi,
I think host shall provide channel map to controller because it is considered to be much more accurate than the channel map generated by controller based on the RSSI reading.
Mike
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org<mailto:linux-bluetooth-owner@vger.kernel.org> [mailto:linux-bluetooth-owner@vger.kernel.org<mailto:linux-bluetooth-owner@vger.kernel.org>] On Behalf Of Pavel Machek
Sent: Wednesday, March 10, 2010 12:48 PM
To: Marcel Holtmann
Cc: Luis R. Rodriguez; linux-wireless; linux-bluetooth; linux-kernel@vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; Dan Tian
Subject: Re: Linux Bluetooth Coexistence documentation in general and for ath9k
Hi!
> > The question of Bluetooth coexistence pops up here, on IRC and on bug
> > reports quite too often so I've stuffed what I could onto a page with
> > a few references / code and about ath9k's schemes for BT coexistence,
> > feel free to extend or correct:
> >
> > http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
> > http://wireless.kernel.org/en/users/Drivers/ath9k/btcoex
> >
> > I'm still not sure if "2-wire" and "3-wire" are generic terms and if
> > someone owns a trademark on them or what, but looking down the road I
> > think it would be nice to export this information through nl80211, if
> > a device supports any of these BT-coex schemes and if so, perhaps
> > display the current signal status of:
> >
> > * WLAN_ACTIVE
> > * BT_PRIORITY
> > * BT_STATE
...
> the only thing the host has control over is AFH channel map, and even
> modifying that is not really needed. The Bluetooth controller will do
> AFH automatically and it is on by default. We never switch that off
> actually.
>
> Normally the co-ex stuff is hard-wired between the Bluetooth and WiFi
> and thus out of control to the host OS.
I believe that 'internal wifi, usb bluetooth' is still quite common
setup...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek<http://www.livejournal.com/%7Epavelmachek>
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html<http://atrey.karlin.mff.cuni.cz/%7Epavel/picture/horses/blog.html>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org<mailto: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<mailto:majordomo@vger.kernel.org>
More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Type: text/html, Size: 9124 bytes --]
^ permalink raw reply
* Re: Linux Bluetooth Coexistence documentation in general and for ath9k
From: shy @ 2010-03-11 1:33 UTC (permalink / raw)
To: Mike Tsai
Cc: Pavel Machek, Marcel Holtmann, Luis R. Rodriguez, linux-wireless,
linux-bluetooth, linux-kernel@vger.kernel.org, Dan Tian
In-Reply-To: <35B17FE5076C7040809188FBE7913F983A1CC44471@SC1EXMB-MBCL.global.atheros.com>
[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]
Mike,
This is done by controller. If host take the charge of channel map, then it
must act as LMP role.
Best regards
shy
2010/3/11 Mike Tsai <Mike.Tsai@atheros.com>
> Hi,
>
> I think host shall provide channel map to controller because it is
> considered to be much more accurate than the channel map generated by
> controller based on the RSSI reading.
>
> Mike
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:
> linux-bluetooth-owner@vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Wednesday, March 10, 2010 12:48 PM
> To: Marcel Holtmann
> Cc: Luis R. Rodriguez; linux-wireless; linux-bluetooth;
> linux-kernel@vger.kernel.org; Dan Tian
> Subject: Re: Linux Bluetooth Coexistence documentation in general and for
> ath9k
>
> Hi!
>
> > > The question of Bluetooth coexistence pops up here, on IRC and on bug
> > > reports quite too often so I've stuffed what I could onto a page with
> > > a few references / code and about ath9k's schemes for BT coexistence,
> > > feel free to extend or correct:
> > >
> > >
> http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
> > > http://wireless.kernel.org/en/users/Drivers/ath9k/btcoex
> > >
> > > I'm still not sure if "2-wire" and "3-wire" are generic terms and if
> > > someone owns a trademark on them or what, but looking down the road I
> > > think it would be nice to export this information through nl80211, if
> > > a device supports any of these BT-coex schemes and if so, perhaps
> > > display the current signal status of:
> > >
> > > * WLAN_ACTIVE
> > > * BT_PRIORITY
> > > * BT_STATE
> ...
> > the only thing the host has control over is AFH channel map, and even
> > modifying that is not really needed. The Bluetooth controller will do
> > AFH automatically and it is on by default. We never switch that off
> > actually.
> >
> > Normally the co-ex stuff is hard-wired between the Bluetooth and WiFi
> > and thus out of control to the host OS.
>
> I believe that 'internal wifi, usb bluetooth' is still quite common
> setup...
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek<http://www.livejournal.com/%7Epavelmachek>
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html<http://atrey.karlin.mff.cuni.cz/%7Epavel/picture/horses/blog.html>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: Type: text/html, Size: 4155 bytes --]
^ permalink raw reply
* RE: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Mike Tsai @ 2010-03-10 22:11 UTC (permalink / raw)
To: Pavel Machek, Marcel Holtmann
Cc: Luis R. Rodriguez, linux-wireless, linux-bluetooth,
linux-kernel@vger.kernel.org, Dan Tian
In-Reply-To: <20100310204818.GF1394@ucw.cz>
Hi,
I think host shall provide channel map to controller because it is consider=
ed to be much more accurate than the channel map generated by controller ba=
sed on the RSSI reading.=20
Mike
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@v=
ger.kernel.org] On Behalf Of Pavel Machek
Sent: Wednesday, March 10, 2010 12:48 PM
To: Marcel Holtmann
Cc: Luis R. Rodriguez; linux-wireless; linux-bluetooth; linux-kernel@vger.k=
ernel.org; Dan Tian
Subject: Re: Linux Bluetooth Coexistence documentation in general and for a=
th9k
Hi!
> > The question of Bluetooth coexistence pops up here, on IRC and on bug
> > reports quite too often so I've stuffed what I could onto a page with
> > a few references / code and about ath9k's schemes for BT coexistence,
> > feel free to extend or correct:
> >=20
> > http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
> > http://wireless.kernel.org/en/users/Drivers/ath9k/btcoex
> >=20
> > I'm still not sure if "2-wire" and "3-wire" are generic terms and if
> > someone owns a trademark on them or what, but looking down the road I
> > think it would be nice to export this information through nl80211, if
> > a device supports any of these BT-coex schemes and if so, perhaps
> > display the current signal status of:
> >=20
> > * WLAN_ACTIVE
> > * BT_PRIORITY
> > * BT_STATE
...
> the only thing the host has control over is AFH channel map, and even
> modifying that is not really needed. The Bluetooth controller will do
> AFH automatically and it is on by default. We never switch that off
> actually.
>=20
> Normally the co-ex stuff is hard-wired between the Bluetooth and WiFi
> and thus out of control to the host OS.
I believe that 'internal wifi, usb bluetooth' is still quite common
setup...
Pavel
--=20
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo=
g.html
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Bluetooth Dongle version mismatch Confusion
From: Mike Tsai @ 2010-03-10 21:40 UTC (permalink / raw)
To: nirav rabara, linux-bluetooth@vger.kernel.org
In-Reply-To: <912bb79a1003100144g7d14c3daj9560dc0ae0dc8e31@mail.gmail.com>
Hi Nirav,
2.1 HS shall be able to operate with 2.0 dongle and vise versa. The major difference between 2.0 and 2.1 devices is the pairing method.
I think the issue most likely is due to the compatibility between different vendors, not the version miss match issue.
BTW, do you know what are the SCO parameters negotiated? Also, is sniff running at the same time?
Thanks,
Mike
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of nirav rabara
Sent: Wednesday, March 10, 2010 1:44 AM
To: linux-bluetooth@vger.kernel.org
Subject: Bluetooth Dongle version mismatch Confusion
Hi,
I have been using bluez 4.58 with 2.6.30 on ARM platform , I am newbie
and found problem with Headset & Dongle version mismatch.
I can use v2.0 Dongle with v2.0 Headset & v2.1 Dongle with v2.1
Headset.( result is good I can hear voice on HS)
But if I use v2.0 Dongle with v2.1 HS & v2.1 Dongle with v2.0 HS
result is unpredictable some time noise or No voice).
I am doing anything wrong with SCO implementation? OR Bluetooth have
limitation with version mismatch. OR I must use same version Dongle &
HS(why ?).
Thanks in Advance
--
With Regards,
Nirav Rabara
--
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: Linux Bluetooth Coexistence documentation in general and for ath9k
From: Pavel Machek @ 2010-03-10 20:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Luis R. Rodriguez, linux-wireless, linux-bluetooth, linux-kernel,
Kevin Hayes <kevin@atheros.com>, Dan Tian
In-Reply-To: <1267715451.29510.20.camel@localhost.localdomain>
Hi!
> > The question of Bluetooth coexistence pops up here, on IRC and on bug
> > reports quite too often so I've stuffed what I could onto a page with
> > a few references / code and about ath9k's schemes for BT coexistence,
> > feel free to extend or correct:
> >
> > http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
> > http://wireless.kernel.org/en/users/Drivers/ath9k/btcoex
> >
> > I'm still not sure if "2-wire" and "3-wire" are generic terms and if
> > someone owns a trademark on them or what, but looking down the road I
> > think it would be nice to export this information through nl80211, if
> > a device supports any of these BT-coex schemes and if so, perhaps
> > display the current signal status of:
> >
> > * WLAN_ACTIVE
> > * BT_PRIORITY
> > * BT_STATE
...
> the only thing the host has control over is AFH channel map, and even
> modifying that is not really needed. The Bluetooth controller will do
> AFH automatically and it is on by default. We never switch that off
> actually.
>
> Normally the co-ex stuff is hard-wired between the Bluetooth and WiFi
> and thus out of control to the host OS.
I believe that 'internal wifi, usb bluetooth' is still quite common
setup...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* RE: [bluetooth-next V2] Bluetooth: handle device reset event
From: Winkler, Tomas @ 2010-03-10 19:35 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, Cohen, Guy, Rindjunsky, Ron,
Paskar, Gregory
In-Reply-To: <1268239760.3712.84.camel@localhost.localdomain>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyY2VsIEhvbHRtYW5u
IFttYWlsdG86bWFyY2VsQGhvbHRtYW5uLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAx
MCwgMjAxMCA2OjQ5IFBNDQo+IFRvOiBXaW5rbGVyLCBUb21hcw0KPiBDYzogbGludXgtYmx1ZXRv
b3RoQHZnZXIua2VybmVsLm9yZzsgQ29oZW4sIEd1eTsgUmluZGp1bnNreSwgUm9uOyBQYXNrYXIs
DQo+IEdyZWdvcnkNCj4gU3ViamVjdDogUkU6IFtibHVldG9vdGgtbmV4dCBWMl0gQmx1ZXRvb3Ro
OiBoYW5kbGUgZGV2aWNlIHJlc2V0IGV2ZW50DQo+IA0KPiBIaSBUb21hcywNCj4gDQo+ID4gPiA+
IEEgQmx1ZXRvb3RoIGRldmljZSBleHBlcmllbmNpbmcgaGFyZHdhcmUgZmFpbHVyZSBtYXkgaXNz
dWUNCj4gPiA+ID4gYSBIQVJEV0FSRV9FUlJPUiBoY2kgZXZlbnQuIFRoZSByZWFjdGlvbiB0byB0
aGlzIGV2ZW50IGlzIGRldmljZQ0KPiA+ID4gPiByZXNldCBmbG93IGltcGxlbWVudGVkIGluIGZv
bGxvd2luZyBzZXF1ZW5jZS4NCj4gPiA+ID4NCj4gPiA+ID4gMS4gTm90aWZ5OiBIQ0lfREVWX0RP
V04NCj4gPiA+ID4gMi4gUmVpbml0aWFsaXplIGludGVybmFsIHN0cnVjdHVyZXMuDQo+ID4gPiA+
IDMuIENhbGwgZHJpdmVyIGZsdXNoIGZ1bmN0aW9uDQo+ID4gPiA+IDQuIFNlbmQgSENJIHJlc2V0
IHJlcXVlc3QgdG8gdGhlIGRldmljZS4NCj4gPiA+ID4gNS4gU2VuZCBIQ0kgaW5pdCBzZXF1ZW5j
ZSByZXNldCB0byB0aGUgZGV2aWNlLg0KPiA+ID4gPiA2LiBOb3RpZnkgSENJX0RFVl9VUC4NCj4g
PiA+DQo+ID4gPiBJIHByZWZlciBpZiB3ZSBjcmVhdGUgYSBnZW5lcmljIHBlciBjb250cm9sbGVy
IHdvcmtxdWV1ZSBmaXJzdCBiZWZvcmUNCj4gPiA+IGhhdmluZyBhIHdvcmtxdWV1ZSBmb3IgZXZl
cnkgdGFzay4gU29tZXRoaW5nIHNpbWlsYXIgdG8gd2hhdCB0aGUNCj4gPiA+IG1hYzgwMjExIGxh
eWVyIG9mZmVycyByaWdodCBub3cuDQo+ID4NCj4gPiBUaGF0IHdvdWxkIGJlIGdvb2QgYXBwcm9h
Y2ggYnV0IHdlIGFyZSB1c2luZyBkZWZhdWx0IGtlcm5lbCB3b3JrcXVldWUgaW4NCj4gdGhpcyBz
b2x1dGlvbiBzbyB0aGVyZSBpcyBubyB3b3JrcXVldWUgZm9yIGV2ZXJ5IHRhc2suDQo+ID4gSSdt
IG5vdCBzdXJlIGlmIHRoaXMgZWZmb3J0IHNob3VsZCBibG9jayB0aGlzIHBhdGNoLg0KPiANCj4g
SSBoYXZlIGFuIGluaXRpYWwgcGF0Y2ggdGhhdCBJIGhhdmUgdG8gZGlnIG91dC4gSXQgaXMgYWN0
dWFsbHkgbm90IHRoYXQNCj4gY29tcGxpY2F0ZWQuIEFuZCBJIHdvdWxkIHByZWZlciB0byBnZXQg
dGhhdCBvbmUgZmlyc3QgYmVmb3JlIHdlIGFwcGx5DQo+IHRoaXMgcGF0Y2guDQoNCk9rYXksIEkg
Y2FuIHRlc3QgdGhpcyBwYXJ0aWN1bGFyIGZsb3cgd2l0aCB5b3VyIHBhdGNoIGlmIHlvdSBzZW5k
IGl0IHRvIG1lLg0KDQo+IFRoZSByZWFzb24gd2h5IEkgcmVhbGx5IHdhbm5hIHNvbHZlIHRoaXMg
aXMgYmVjYXVzZSBvZiBwb3RlbnRpYWwgcmFjZQ0KPiBjb25kaXRpb25zIGJldHdlZW4gdGhlIHdv
cmtxdWV1ZSBhbmQgYSBkZXZpY2UgcmVtb3ZhbC4gSSBoYXZlIGEgYmFkDQo+IGZlZWxpbmcgdGhh
dCBldmVuIHdpdGggdGhlIGN1cnJlbnQgc3lzZnMgd29ya3F1ZXVlIHdlIGhhdmUgYSByYWNlDQo+
IGNvbmRpdGlvbiBoaWRpbmcgc29tZXdoZXJlLiBTbyBpZiBnb2luZyBmb3J3YXJkIHdlIGhhdmUg
dG8gc2hpZnQgbW9yZQ0KPiBhbmQgbW9yZSBjb2RlIGludG8gd29ya3F1ZXVlcyB3ZSBuZWVkIGEg
c2luZ2xlIHBvaW50IHdoZXJlIHRoaXMgY2FuIGJlDQo+IGZpeGVkLg0KDQpVbmRlcnN0b29kLg0K
DQpJbiB0aGF0IGNvbnRleHQgSSB3b3VsZCBuZWVkIHRvIGRvIHNvbWUgbW9yZSBpbnN0cnVtZW50
YXRpb24gdG8gdGVzdCB0aGlzIGtpbmQgb2YgcmFjZSBmb3IgdGhpcyBmZWF0dXJlLiANCg0KPiA+
ID4gQWxzbyBpbiBhIHNlY29uZCBzdGVwIHdlIG1pZ2h0IHdhbm5hIG1vdmUgdGhlIEhDSSBldmVu
dCBwcm9jZXNzaW5nDQo+ID4gPiBjb21wbGV0ZWx5IGludG8gYSB3b3JrcXVldWUuIElmIHdlIGdl
dCBubyBwZXJmb3JtYW5jZSBoaXQgd2l0aCB0aGF0LA0KPiA+ID4gdGhlbiBzeXNmcyBoYW5kbGlu
ZyBhbmQgZGV2aWNlIHJlc2V0IGJlY29tZXMgYSBsb3Qgc2ltcGxlciBhbmQgbGVzcw0KPiA+ID4g
cHJvbmUgdG8gcmFjZSBjb25kaXRpb25zIHdpdGggZGV2aWNlIHJlbW92YWwuDQo+ID4NCj4gPiBM
b29rcyBnb29kIHRvIG1lLiBTbyB3aGVuIHRoaXMgaXMgcmVhZHkgd2UgY2FuIG1vdmUgYWxzbyB0
aGUgcmVzZXQgYWxzbyB0bw0KPiBwZXIgY29udHJvbGxlciBxdWV1ZS4NCj4gDQo+IEkgaGF2ZW4n
dCBkb25lIGFueSBwZXJmb3JtYW5jZSB0ZXN0aW5nIHdpdGggdGhpcyBhcHByb2FjaC4gU28gSSBo
b3BlIHdlDQo+IGFyZSBub3Qgc2hvb3Rpbmcgb3Vyc2VsdmVzIGluIHRoZSBmb290IHdpdGggaXQu
DQoNClRoYW5rcw0KVG9tYXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJbnRlbCBJc3JhZWwgKDc0KSBMaW1pdGVk
CgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku
IEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp
dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50LCBwbGVhc2UgY29udGFj
dCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K
^ permalink raw reply
* Re: [PATCH] Expose wacom pen tablet battery and ac thru power_supply class
From: Przemo Firszt @ 2010-03-10 19:03 UTC (permalink / raw)
To: Jiri Kosina
Cc: Bastien Nocera, linux-bluetooth, marcel, Peter Hutterer, Ping,
Peter Huewe
In-Reply-To: <alpine.LNX.2.00.1003092220160.17799@pobox.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
Dnia 2010-03-09, wto o godzinie 22:22 +0100, Jiri Kosina pisze:
Hi,
[..]
> Anyway, you'll have to sort out the new dependency on CONFIG_POWER_SUPPLY
> somehow (compiling the battery code out from the driver if
> CONFIG_POWER_SUPPLY is unset, or selecting it directly from Kconfig).
Thanks for checking the patch.
See attached updated version - is it OK?
Does it make sense to add a line to Kconfig to explain that
CONFIG_POWER_SUPPLY/CONFIG_POWER_SUPPLY_MODULE is required to enable
monitoring battery/ac state?
Cheers,
Przemo
[-- Attachment #2: 0001-Expose-wacom-pen-tablet-battery-and-ac-thru-power_su.patch --]
[-- Type: text/x-patch, Size: 4979 bytes --]
>From f5eb6397ebd3a001289f676383df5adaaa17f8ea Mon Sep 17 00:00:00 2001
From: Przemo Firszt <przemo@firszt.eu>
Date: Fri, 5 Mar 2010 17:19:44 +0000
Subject: [PATCH] Expose wacom pen tablet battery and ac thru power_supply class
This patch exposes wacom pen tablet battery capacity and ac state thru
power_supply class is sysfs.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
---
drivers/hid/hid-wacom.c | 128 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 128 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index 8d3b46f..5c9cfe4 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -21,14 +21,89 @@
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/module.h>
+#if defined(CONFIG_POWER_SUPPLY) || defined(CONFIG_POWER_SUPPLY_MODULE)
+#define ENABLE_POWER_SUPPLY
+#include <linux/power_supply.h>
+#endif
#include "hid-ids.h"
struct wacom_data {
__u16 tool;
unsigned char butstate;
+#ifdef ENABLE_POWER_SUPPLY
+ int battery_capacity;
+ struct power_supply battery;
+ struct power_supply ac;
+#endif
};
+#ifdef ENABLE_POWER_SUPPLY
+/*percent of battery capacity, 0 means AC online*/
+static unsigned short batcap[8] = { 1, 15, 25, 35, 50, 70, 100, 0 };
+
+static enum power_supply_property wacom_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_CAPACITY
+};
+
+static enum power_supply_property wacom_ac_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE
+};
+
+static int wacom_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct wacom_data *wdata = container_of(psy,
+ struct wacom_data, battery);
+ int power_state = batcap[wdata->battery_capacity];
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = 1;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ /* show 100% battery capacity when charging */
+ if (power_state == 0)
+ val->intval = 100;
+ else
+ val->intval = power_state;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int wacom_ac_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct wacom_data *wdata = container_of(psy, struct wacom_data, ac);
+ int power_state = batcap[wdata->battery_capacity];
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ /* fall through */
+ case POWER_SUPPLY_PROP_ONLINE:
+ if (power_state == 0)
+ val->intval = 1;
+ else
+ val->intval = 0;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+#endif
+
static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report,
u8 *raw_data, int size)
{
@@ -147,6 +222,12 @@ static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report,
input_sync(input);
}
+#ifdef ENABLE_POWER_SUPPLY
+ /* Store current battery capacity */
+ rw = (data[7] >> 2 & 0x07);
+ if (rw != wdata->battery_capacity)
+ wdata->battery_capacity = rw;
+#endif
return 1;
}
@@ -206,6 +287,45 @@ static int wacom_probe(struct hid_device *hdev,
if (ret < 0)
dev_warn(&hdev->dev, "failed to poke device #2, %d\n", ret);
+#ifdef ENABLE_POWER_SUPPLY
+ wdata->battery.properties = wacom_battery_props;
+ wdata->battery.num_properties = ARRAY_SIZE(wacom_battery_props);
+ wdata->battery.get_property = wacom_battery_get_property;
+ wdata->battery.name = "wacom_battery";
+ wdata->battery.type = POWER_SUPPLY_TYPE_BATTERY;
+ wdata->battery.use_for_apm = 0;
+
+ ret = power_supply_register(&hdev->dev, &wdata->battery);
+ if (ret) {
+ dev_warn(&hdev->dev,
+ "can't create sysfs battery attribute, err: %d\n", ret);
+ /*
+ * battery attribute is not critical for the tablet, but if it
+ * failed then there is no need to create ac attribute
+ */
+ goto move_on;
+ }
+
+ wdata->ac.properties = wacom_ac_props;
+ wdata->ac.num_properties = ARRAY_SIZE(wacom_ac_props);
+ wdata->ac.get_property = wacom_ac_get_property;
+ wdata->ac.name = "wacom_ac";
+ wdata->ac.type = POWER_SUPPLY_TYPE_MAINS;
+ wdata->ac.use_for_apm = 0;
+
+ ret = power_supply_register(&hdev->dev, &wdata->ac);
+ if (ret) {
+ dev_warn(&hdev->dev,
+ "can't create ac battery attribute, err: %d\n", ret);
+ /*
+ * ac attribute is not critical for the tablet, but if it
+ * failed then we don't want to battery attribute to exist
+ */
+ power_supply_unregister(&wdata->battery);
+ }
+
+move_on:
+#endif
hidinput = list_entry(hdev->inputs.next, struct hid_input, list);
input = hidinput->input;
@@ -250,7 +370,15 @@ err_free:
static void wacom_remove(struct hid_device *hdev)
{
+#ifdef ENABLE_POWER_SUPPLY
+ struct wacom_data *wdata = hid_get_drvdata(hdev);
+#endif
hid_hw_stop(hdev);
+
+#ifdef ENABLE_POWER_SUPPLY
+ power_supply_unregister(&wdata->battery);
+ power_supply_unregister(&wdata->ac);
+#endif
kfree(hid_get_drvdata(hdev));
}
--
1.7.0.1
^ permalink raw reply related
* RE: [bluetooth-next V2] Bluetooth: handle device reset event
From: Marcel Holtmann @ 2010-03-10 16:49 UTC (permalink / raw)
To: Winkler, Tomas
Cc: linux-bluetooth@vger.kernel.org, Cohen, Guy, Rindjunsky, Ron,
Paskar, Gregory
In-Reply-To: <6F5C1D715B2DA5498A628E6B9C124F04016C0E97A6@hasmsx504.ger.corp.intel.com>
Hi Tomas,
> > > A Bluetooth device experiencing hardware failure may issue
> > > a HARDWARE_ERROR hci event. The reaction to this event is device
> > > reset flow implemented in following sequence.
> > >
> > > 1. Notify: HCI_DEV_DOWN
> > > 2. Reinitialize internal structures.
> > > 3. Call driver flush function
> > > 4. Send HCI reset request to the device.
> > > 5. Send HCI init sequence reset to the device.
> > > 6. Notify HCI_DEV_UP.
> >
> > I prefer if we create a generic per controller workqueue first before
> > having a workqueue for every task. Something similar to what the
> > mac80211 layer offers right now.
>
> That would be good approach but we are using default kernel workqueue in this solution so there is no workqueue for every task.
> I'm not sure if this effort should block this patch.
I have an initial patch that I have to dig out. It is actually not that
complicated. And I would prefer to get that one first before we apply
this patch.
The reason why I really wanna solve this is because of potential race
conditions between the workqueue and a device removal. I have a bad
feeling that even with the current sysfs workqueue we have a race
condition hiding somewhere. So if going forward we have to shift more
and more code into workqueues we need a single point where this can be
fixed.
> > Also in a second step we might wanna move the HCI event processing
> > completely into a workqueue. If we get no performance hit with that,
> > then sysfs handling and device reset becomes a lot simpler and less
> > prone to race conditions with device removal.
>
> Looks good to me. So when this is ready we can move also the reset also to per controller queue.
I haven't done any performance testing with this approach. So I hope we
are not shooting ourselves in the foot with it.
Regards
Marcel
^ permalink raw reply
* Sixaxis paring and connection works, but no input data
From: Christian Birchinger @ 2010-03-10 16:35 UTC (permalink / raw)
To: linux-bluetooth
Hello
I'm trying to use a SixAxis controller with bluez 4.61 and the cable
pairing patch. Pairing and connecting (PS press) fully works.
However i do not get any input data from the Sixaxis Pad no matter
what buttons i press or what axes i wiggle.
I see in the kernel log that the joystick got connected as BT HID
device and the device files get created and buttons and axes are
reported by jstest.
I noticed that bluez 4.61 doesn't have the sony_set_operational_bt
stuff anymore and applied a recently here posted kernel patch here
to compensate. I even added a printk to fully verify that function
gets executed when the BT HID device appears.
"Unpluging" works. I use the legacy hidd command with --unplug for
this. I only use this command for --show and --unplug and _NOT_
as a daemon of course.
I tried it on 2 different BT hosts. This one here was fully working
with old bluez 3.x with hidd hacks, so i doubt it's a bt hardware
dongle limitation. Controller works in USB mode and on a PS3 with
with bluetooth too. As i said, the hardware was working before.
Below are some infos that might be of interests.
Thanks a lot for your help
Christian Birchinger
--[ dmesg ]--------------------------------------------------------------------
input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/usb1/1-3/1-3.1/1-3.1:1.0/bluetooth/hci0/hci0:11/input44
generic-bluetooth 0005:054C:0268.002A: input: BLUETOOTH HID v0.00 Joystick [PLAYSTATION(R)3 Controller] on 00:16:38:3A:3E:DD
-------------------------------------------------------------------------------
--[ hidd --show ]---------------------------------------------------------------
00:23:06:C9:DE:69 PLAYSTATION(R)3 Controller [054c:0268] connected
-------------------------------------------------------------------------------
--[ hcidump (PS button press)]-------------------------------------------------
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0048
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0048 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0048 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0048 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0048 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0049
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0049 result 1 status 2
Connection pending - Authorization pending
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0049 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 36
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 24
QoS 0x02 (Guaranteed)
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0049 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0049 flags 0x00 clen 0
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
> HCI Event: Number of Completed Packets (0x13) plen 5
-------------------------------------------------------------------------------
--[ hcidump (hidd --unplug)]---------------------------------
< ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x0048 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0049
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0049
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0048
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0048
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Disconn Complete (0x05) plen 4
-------------------------------------------------------------------------------
--[ jstest ]-------------------------------------------------------------------
Driver version is 2.1.0.
Joystick (PLAYSTATION(R)3 Controller) has 28 axes (X, Y, Z, Rz, (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null), (null))
and 19 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6, BtnDead, BtnA, BtnB, BtnC, BtnX, BtnY, BtnZ).
Testing ... (interrupt to exit)
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22:-32767 23: 0 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22:-32767 23:-32767 24: 0 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22:-32767 23:-32767 24:-32767 25: 0 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22:-32767 23:-32767 24:-32767 25:-32767 26: 0 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22:-32767 23:-32767 24:-32767 25:-32767 26:-32767 27: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
Axes: 0:-32767 1:-32767 2:-32767 3:-32767 4:-32767 5:-32767 6:-32767 7:-32767 8:-32767 9:-32767 10:-32767 11:-32767 12:-32767 13:-32767 14:-32767 15:-32767 16:-32767 17:-32767 18:-32767 19:-32767 20:-32767 21:-32767 22:-32767 23:-32767 24:-32767 25:-32767 26:-32767 27:-32767 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off 12:off 13:off 14:off 15:off 16:off 17:off 18:off
-------------------------------------------------------------------------------
--[ lsusb ]--------------------------------------------------------------------
Bus 001 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
-------------------------------------------------------------------------------
^ permalink raw reply
* Bluetooth Dongle version mismatch Confusion
From: nirav rabara @ 2010-03-10 9:44 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I have been using bluez 4.58 with 2.6.30 on ARM platform , I am newbie
and found problem with Headset & Dongle version mismatch.
I can use v2.0 Dongle with v2.0 Headset & v2.1 Dongle with v2.1
Headset.( result is good I can hear voice on HS)
But if I use v2.0 Dongle with v2.1 HS & v2.1 Dongle with v2.0 HS
result is unpredictable some time noise or No voice).
I am doing anything wrong with SCO implementation? OR Bluetooth have
limitation with version mismatch. OR I must use same version Dongle &
HS(why ?).
Thanks in Advance
--
With Regards,
Nirav Rabara
^ 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