* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Marcel Holtmann @ 2010-09-16 23:04 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: suraj, Suraj.Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448097968EDE3@EXMB04.eu.tieto.com>
Hi Waldemar,
> >if we talk about the SAP server role found in a mobile phone,
> >then that support clearly needs to interact with the telephony
> >stack. Since when SAP is active the telephony stack needs to
> >be suspended and all SIM transaction being forwarded.
>
> I agree, but a telephony stack needs to care about its state when SAP is active. Not all linux based mobile platforms use ofono.
I think they should use oFono of course since that is the only way to be
modem hardware agnostic in the long run.
> >Currently I would be thinking that the SAP implementation
> >should be done inside oFono actually. Since then you have
> >direct access to the hardware. The D-Bus approach just doesn't
> >sound correct to me. I could be of course wrong, but I can't
> >wrap my mind around on how you can make this work.
>
> I assume that ofono should handle sap transactions (as it's kind of hardware abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did for sap transactions in spec (http://www.wirelessmodemapi.com/), and not implement sap profile itself. Again, not all use ofono as telephony stack.
>
> Sorry, I don't know ofono well. What's the interface between ofono and bluez?
In this case there will be no direct interface besides oFono registering
the SDP records for SAP.
> >Even with file descriptor passing this doesn't look like the
> >right approach. If we need a hardware abstraction than we
> >either use oFono or we have to create some SAP hardware access
> >abstraction.
>
> I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api.
> Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim.
I still don't see this as a really good idea. We want modem abstraction
inside oFono and not all over the place.
Regards
Marcel
^ permalink raw reply
* Fwd: [PATCH] Bluetooth: Replace hard code of fixed channels bit mask
From: haijun liu @ 2010-09-17 1:08 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTik244A2zNFL-yL7CvBKdf3UZDDKq1Ap7HR5+aCR@mail.gmail.com>
Hi Gustavo,
On Thu, Sep 16, 2010 at 10:16 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Haijun,
>
> * haijun liu <liuhaijun.er@gmail.com> [2010-09-16 15:15:18 +0800]:
>
>> This patch add fixed channels bit mask definition for
>> L2CAP_FIXCHAN_NULLID
>> L2CAP_FIXCHAN_SIGNAL
>> L2CAP_FIXCHAN_CONNLESS
>> L2CAP_FIXCHAN_A2MP
>> And replace hard code in source file with the macro.
>>
>> Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
>> ---
>> include/net/bluetooth/l2cap.h | 6 ++++++
>> net/bluetooth/l2cap.c | 2 +-
>> 2 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
>> index 6c24144..e4fe2c7 100644
>> --- a/include/net/bluetooth/l2cap.h
>> +++ b/include/net/bluetooth/l2cap.h
>> @@ -97,6 +97,12 @@ struct l2cap_conninfo {
>> #define L2CAP_FEAT_FCS 0x00000020
>> #define L2CAP_FEAT_FIXED_CHAN 0x00000080
>>
>> +/* L2CAP fixed channel bitmask */
>> +#define L2CAP_FIXCHAN_NULLID 0x00
>> +#define L2CAP_FIXCHAN_SIGNAL 0x02
>> +#define L2CAP_FIXCHAN_CONNLESS 0x04
>> +#define L2CAP_FIXCHAN_A2MP 0x08
>
> That's wrong, signaling channel is 0x01, connless is 0x02 and A2MP is
> 0x03. And if you haven't noted we already have macros for the signaling
> and connectionless channels:
>
> #define L2CAP_CID_SIGNALING 0x0001
> #define L2CAP_CID_CONN_LESS 0x0002
>
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
>
These are not channel id definition, these are feature bit mask values.
And they are used in information exchange process to present FIXED
CHANNELS SUPPORTED.
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix unaligned access to l2cap conf data
From: real mz @ 2010-09-17 3:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: linux-kernel-commits, realmz
In-Reply-To: <1283149112-22164-1-git-send-email-realmz6@gmail.com>
ping
On Mon, Aug 30, 2010 at 2:18 PM, steven.miao <realmz6@gmail.com> wrote:
> From: realmz <realmz6@gmail.com>
>
> In function l2cap_get_conf_opt() and l2cap_add_conf_opt() the address of
> opt->val sometimes is not at the edge of 2-bytes/4-bytes, so 2-bytes/4 bytes
> access will cause data misalignment exeception. Use get_unaligned_le16/32
> and put_unaligned_le16/32 function to avoid data misalignment execption.
> ---
> net/bluetooth/l2cap.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index fadf26b..a07dad8 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -2406,11 +2406,11 @@ static inline int l2cap_get_conf_opt(void **ptr, int *type, int *olen, unsigned
> break;
>
> case 2:
> - *val = __le16_to_cpu(*((__le16 *) opt->val));
> + *val = get_unaligned_le16(opt->val);
> break;
>
> case 4:
> - *val = __le32_to_cpu(*((__le32 *) opt->val));
> + *val = get_unaligned_le32(opt->val);
> break;
>
> default:
> @@ -2437,11 +2437,11 @@ static void l2cap_add_conf_opt(void **ptr, u8 type, u8 len, unsigned long val)
> break;
>
> case 2:
> - *((__le16 *) opt->val) = cpu_to_le16(val);
> + put_unaligned_le16(cpu_to_le16(val), opt->val);
> break;
>
> case 4:
> - *((__le32 *) opt->val) = cpu_to_le32(val);
> + put_unaligned_le32(cpu_to_le32(val), opt->val);
> break;
>
> default:
> --
> 1.5.6.5
>
>
^ permalink raw reply
* [PATCH] Change the for loop to read blutooth clock in MCAP CSP
From: Santiago Carot-Nemesio @ 2010-09-17 7:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
This is only a cosmetic change. Using a do..while loop
we avoid direct manipulation of counter loop variable
when error happens reading the BT clock.
---
health/mcap_sync.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index bc1ffcd..78cb163 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -406,18 +406,18 @@ static void initialize_caps(struct mcap_mcl *mcl)
/* Do clock read a number of times and measure latency */
avg = 0;
- for (i = 0; i < 20; ++i) {
+ i = 0;
+ do {
clock_gettime(CLK, &t1);
- if (!read_btclock(mcl, &btclock, &btaccuracy)) {
- --i;
+ if (!read_btclock(mcl, &btclock, &btaccuracy))
continue;
- }
clock_gettime(CLK, &t2);
latency = time_us(&t2) - time_us(&t1);
latencies[i] = latency;
avg += latency;
- }
+ i++;
+ } while (i < 20);
avg /= 20;
/* Calculate deviation */
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 2/3] bluetooth: Remove some unnecessary error messages
From: Andrei Emeltchenko @ 2010-09-17 8:33 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-bluetooth, linux-usb, marcel
In-Reply-To: <1284659895-27984-2-git-send-email-mjg@redhat.com>
Hi Matthew,
On Thu, Sep 16, 2010 at 8:58 PM, Matthew Garrett <mjg@redhat.com> wrote:
> The main reason for these urbs to error out on submission is that runtime
> pm has kicked in, which is unnecessary noise. Let's just drop them.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
> ---
> =A0drivers/bluetooth/btusb.c | =A0 15 +++------------
> =A01 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index d22ce3c..3ace025 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -229,11 +229,8 @@ static void btusb_intr_complete(struct urb *urb)
> =A0 =A0 =A0 =A0usb_anchor_urb(urb, &data->intr_anchor);
>
> =A0 =A0 =A0 =A0err =3D usb_submit_urb(urb, GFP_ATOMIC);
> - =A0 =A0 =A0 if (err < 0) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 BT_ERR("%s urb %p failed to resubmit (%d)",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 hdev->name, urb, -err);
> + =A0 =A0 =A0 if (err < 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usb_unanchor_urb(urb);
> - =A0 =A0 =A0 }
> =A0}
>
I do not get the point here. Cannot you just undef BT_ERR if you
enabled debug? I believe this is standard behavior.
IMO NACK
Regards,
Andrei
> =A0static int btusb_submit_intr_urb(struct hci_dev *hdev, gfp_t mem_flags=
)
> @@ -313,11 +310,8 @@ static void btusb_bulk_complete(struct urb *urb)
> =A0 =A0 =A0 =A0usb_mark_last_busy(data->udev);
>
> =A0 =A0 =A0 =A0err =3D usb_submit_urb(urb, GFP_ATOMIC);
> - =A0 =A0 =A0 if (err < 0) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 BT_ERR("%s urb %p failed to resubmit (%d)",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 hdev->name, urb, -err);
> + =A0 =A0 =A0 if (err < 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usb_unanchor_urb(urb);
> - =A0 =A0 =A0 }
> =A0}
>
> =A0static int btusb_submit_bulk_urb(struct hci_dev *hdev, gfp_t mem_flags=
)
> @@ -402,11 +396,8 @@ static void btusb_isoc_complete(struct urb *urb)
> =A0 =A0 =A0 =A0usb_anchor_urb(urb, &data->isoc_anchor);
>
> =A0 =A0 =A0 =A0err =3D usb_submit_urb(urb, GFP_ATOMIC);
> - =A0 =A0 =A0 if (err < 0) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 BT_ERR("%s urb %p failed to resubmit (%d)",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 hdev->name, urb, -err);
> + =A0 =A0 =A0 if (err < 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usb_unanchor_urb(urb);
> - =A0 =A0 =A0 }
> =A0}
>
> =A0static void inline __fill_isoc_descriptor(struct urb *urb, int len, in=
t mtu)
> --
> 1.7.2.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 =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/3] bluetooth: Take a runtime pm reference on hid connections
From: Oliver Neukum @ 2010-09-17 8:39 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-bluetooth, linux-usb, marcel
In-Reply-To: <1284659895-27984-1-git-send-email-mjg@redhat.com>
Am Donnerstag, 16. September 2010, 19:58:13 schrieb Matthew Garrett:
> Bluetooth runtime PM interacts badly with input devices - the connection
> will be dropped if the device becomes idle, resulting in noticable lag when
> the user interacts with the input device again. Bump the pm runtime count
> when the device is associated and release it when it's disassociated in
> order to avoid this.
What is the effect on battery live of the external devices?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] Bluetooth: Replace hard code of fixed channels bit mask
From: Ville Tervo @ 2010-09-17 8:50 UTC (permalink / raw)
To: ext Gustavo F. Padovan
Cc: haijun liu, linux-bluetooth@vger.kernel.org, Mat Martineau,
dantian.ip
In-Reply-To: <20100916141654.GB15000@vigoh>
Hi Gustavo,
On Thu, Sep 16, 2010 at 04:16:54PM +0200, ext Gustavo F. Padovan wrote:
> Hi Haijun,
>
> * haijun liu <liuhaijun.er@gmail.com> [2010-09-16 15:15:18 +0800]:
>
> > This patch add fixed channels bit mask definition for
> > L2CAP_FIXCHAN_NULLID
> > L2CAP_FIXCHAN_SIGNAL
> > L2CAP_FIXCHAN_CONNLESS
> > L2CAP_FIXCHAN_A2MP
> > And replace hard code in source file with the macro.
> >
> > Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
> > ---
> > include/net/bluetooth/l2cap.h | 6 ++++++
> > net/bluetooth/l2cap.c | 2 +-
> > 2 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> > index 6c24144..e4fe2c7 100644
> > --- a/include/net/bluetooth/l2cap.h
> > +++ b/include/net/bluetooth/l2cap.h
> > @@ -97,6 +97,12 @@ struct l2cap_conninfo {
> > #define L2CAP_FEAT_FCS 0x00000020
> > #define L2CAP_FEAT_FIXED_CHAN 0x00000080
> >
> > +/* L2CAP fixed channel bitmask */
> > +#define L2CAP_FIXCHAN_NULLID 0x00
> > +#define L2CAP_FIXCHAN_SIGNAL 0x02
> > +#define L2CAP_FIXCHAN_CONNLESS 0x04
> > +#define L2CAP_FIXCHAN_A2MP 0x08
>
> That's wrong, signaling channel is 0x01, connless is 0x02 and A2MP is
> 0x03. And if you haven't noted we already have macros for the signaling
> and connectionless channels:
But these are bit masks and looks ok to me except L2CAP_FIXCHAN_A2MP which I
could not find from the list.. Check Vol 3 Part A 4.13.
> #define L2CAP_CID_SIGNALING 0x0001
> #define L2CAP_CID_CONN_LESS 0x0002
These are channel ids.
--
Ville
^ permalink raw reply
* Re: [PATCH 2/3] bluetooth: Remove some unnecessary error messages
From: Oliver Neukum @ 2010-09-17 8:59 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Matthew Garrett, linux-bluetooth, linux-usb, marcel
In-Reply-To: <AANLkTi=NBrb70ZvafQxZMnLZZcmuGEPeon4Vqq4vkpce@mail.gmail.com>
Am Freitag, 17. September 2010, 10:33:30 schrieb Andrei Emeltchenko:
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index d22ce3c..3ace025 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -229,11 +229,8 @@ static void btusb_intr_complete(struct urb *urb)
> > usb_anchor_urb(urb, &data->intr_anchor);
> >
> > err = usb_submit_urb(urb, GFP_ATOMIC);
> > - if (err < 0) {
> > - BT_ERR("%s urb %p failed to resubmit (%d)",
> > - hdev->name, urb, -err);
> > + if (err < 0)
> > usb_unanchor_urb(urb);
> > - }
> > }
> >
>
> I do not get the point here. Cannot you just undef BT_ERR if you
> enabled debug? I believe this is standard behavior.
You can undefine BT_ERR, but then you'll miss error reports.
This message may indicate an error, but usually doesn't if
you use runtime pm.
Regards
Oliver
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Nicolas GUILBAUD @ 2010-09-17 11:01 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, Suraj Sumangala, linux-bluetooth,
Jothikumar Mothilal
In-Reply-To: <1284678016.2405.145.camel@localhost.localdomain>
Hi Marcel,
-----Message d'origine-----
De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth-owner@vger.kernel.org] De la part de Marcel =
Holtmann
Envoy=E9=A0: vendredi 17 septembre 2010 01:00
=C0=A0: Nicolas GUILBAUD
Cc=A0: Suraj Sumangala; Suraj Sumangala; =
linux-bluetooth@vger.kernel.org; Jothikumar Mothilal
Objet=A0: RE: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>>that is just because we haven't gotten there yet. Of course if SAP =
takes
over we have to shutdown oFono's handling of the modem. This could be
done similar to the support for Lockdown we have in the oFono TODO list.
Do you have information about the release date of this feature? And =
about the interface to lockdown, is it a D-BUS message?=20
>There is a framework for card services in general, but I think that is
just pure overhead for this.
>And to be honest, my current thinking is that even for pure SIM card
readers with APDU mode, we might wanna support them via oFono anyway.
Having to add SAP support in multiple levels is a bad idea.
Yes but an APDU interface is needed in the SIM driver of oFono, I don't =
see any interface of this kind in the source code.
Maybe it's not the good place to speak about that.
>However in the end this all depends on the hardware and right now I =
have
not had access to SAP capable hardware. Or maybe I did and I didn't know
it yet. Do we have any target hardware in mind?
Yes we have, it's Renesas Modem solution.
Regards
Nicolas
--
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] Bluetooth: Replace hard code of fixed channels bit mask
From: haijun liu @ 2010-09-17 11:39 UTC (permalink / raw)
To: Ville Tervo
Cc: ext Gustavo F. Padovan, linux-bluetooth@vger.kernel.org,
Mat Martineau, dantian.ip
In-Reply-To: <20100917085047.GN14330@null>
Hi Ville,
On Fri, Sep 17, 2010 at 4:50 PM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Gustavo,
>
> On Thu, Sep 16, 2010 at 04:16:54PM +0200, ext Gustavo F. Padovan wrote:
>> Hi Haijun,
>>
>> * haijun liu <liuhaijun.er@gmail.com> [2010-09-16 15:15:18 +0800]:
>>
>> > This patch add fixed channels bit mask definition for
>> > L2CAP_FIXCHAN_NULLID
>> > L2CAP_FIXCHAN_SIGNAL
>> > L2CAP_FIXCHAN_CONNLESS
>> > L2CAP_FIXCHAN_A2MP
>> > And replace hard code in source file with the macro.
>> >
>> > Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
>> > ---
>> > include/net/bluetooth/l2cap.h | 6 ++++++
>> > net/bluetooth/l2cap.c | 2 +-
>> > 2 files changed, 7 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
>> > index 6c24144..e4fe2c7 100644
>> > --- a/include/net/bluetooth/l2cap.h
>> > +++ b/include/net/bluetooth/l2cap.h
>> > @@ -97,6 +97,12 @@ struct l2cap_conninfo {
>> > #define L2CAP_FEAT_FCS 0x00000020
>> > #define L2CAP_FEAT_FIXED_CHAN 0x00000080
>> >
>> > +/* L2CAP fixed channel bitmask */
>> > +#define L2CAP_FIXCHAN_NULLID 0x00
>> > +#define L2CAP_FIXCHAN_SIGNAL 0x02
>> > +#define L2CAP_FIXCHAN_CONNLESS 0x04
>> > +#define L2CAP_FIXCHAN_A2MP 0x08
>>
>> That's wrong, signaling channel is 0x01, connless is 0x02 and A2MP is
>> 0x03. And if you haven't noted we already have macros for the signaling
>> and connectionless channels:
>
> But these are bit masks and looks ok to me except L2CAP_FIXCHAN_A2MP which I
> could not find from the list.. Check Vol 3 Part A 4.13.
>
>> #define L2CAP_CID_SIGNALING 0x0001
>> #define L2CAP_CID_CONN_LESS 0x0002
>
> These are channel ids.
>
>
> --
> Ville
>
A2MP means AMP Manager Protocol, it's from <<Core_V3.0 + HS.pdf>>
--
Haijun Liu
^ permalink raw reply
* [PATCH] Bluetooth: Check for SCO type before setting retr. effort
From: Emeltchenko Andrei @ 2010-09-17 11:46 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Check eSCO / SCO type before setting retransmission effort flag
in Setup SCO command. We found that 0x01 is better for power
consupmtion but we cannot use it always since controller tries
to setup eSCO even for old devices.
Might be controller-specific.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/hci_conn.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 0b1e460..145993f 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -150,7 +150,13 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
cp.rx_bandwidth = cpu_to_le32(0x00001f40);
cp.max_latency = cpu_to_le16(0xffff);
cp.voice_setting = cpu_to_le16(hdev->voice_setting);
- cp.retrans_effort = 0xff;
+
+ /* If remote device supports eSCO use optimization for power
+ retransmission effort, otherwise use standard flag do-not-care */
+ if (conn->link->features[3] & LMP_ESCO)
+ cp.retrans_effort = 0x01;
+ else
+ cp.retrans_effort = 0xff;
hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Change the for loop to read blutooth clock in MCAP CSP
From: Elvis Pfützenreuter @ 2010-09-17 11:56 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1284709950-5302-1-git-send-email-sancane@gmail.com>
On Sep 17, 2010, at 4:52 AM, Santiago Carot-Nemesio wrote:
> This is only a cosmetic change. Using a do..while loop
> we avoid direct manipulation of counter loop variable
> when error happens reading the BT clock.
> ---
> health/mcap_sync.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/health/mcap_sync.c b/health/mcap_sync.c
> index bc1ffcd..78cb163 100644
> --- a/health/mcap_sync.c
> +++ b/health/mcap_sync.c
> @@ -406,18 +406,18 @@ static void initialize_caps(struct mcap_mcl *mcl)
>
> /* Do clock read a number of times and measure latency */
> avg = 0;
> - for (i = 0; i < 20; ++i) {
> + i = 0;
> + do {
> clock_gettime(CLK, &t1);
> - if (!read_btclock(mcl, &btclock, &btaccuracy)) {
> - --i;
> + if (!read_btclock(mcl, &btclock, &btaccuracy))
> continue;
> - }
> clock_gettime(CLK, &t2);
>
> latency = time_us(&t2) - time_us(&t1);
> latencies[i] = latency;
> avg += latency;
> - }
> + i++;
> + } while (i < 20);
> avg /= 20;
>
> /* Calculate deviation */
> --
> 1.7.2.3
Looking again now, this (the logic, not the patch) may lead to an infinite loop, if for some reason the clock simply can't be read. One more thing to be fixed.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Check for SCO type before setting retr. effort
From: Ville Tervo @ 2010-09-17 12:04 UTC (permalink / raw)
To: ext Emeltchenko Andrei; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1284724018-26731-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
On Fri, Sep 17, 2010 at 01:46:58PM +0200, ext Emeltchenko Andrei wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Check eSCO / SCO type before setting retransmission effort flag
> in Setup SCO command. We found that 0x01 is better for power
> consupmtion but we cannot use it always since controller tries
> to setup eSCO even for old devices.
>
> Might be controller-specific.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Revieved-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/hci_conn.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 0b1e460..145993f 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -150,7 +150,13 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
> cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> cp.max_latency = cpu_to_le16(0xffff);
> cp.voice_setting = cpu_to_le16(hdev->voice_setting);
> - cp.retrans_effort = 0xff;
> +
> + /* If remote device supports eSCO use optimization for power
> + retransmission effort, otherwise use standard flag do-not-care */
> + if (conn->link->features[3] & LMP_ESCO)
> + cp.retrans_effort = 0x01;
> + else
> + cp.retrans_effort = 0xff;
>
> hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
> }
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] bluetooth: Take a runtime pm reference on hid connections
From: Matthew Garrett @ 2010-09-17 12:24 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-bluetooth, linux-usb, marcel
In-Reply-To: <201009171039.54110.oneukum@suse.de>
On Fri, Sep 17, 2010 at 10:39:54AM +0200, Oliver Neukum wrote:
> Am Donnerstag, 16. September 2010, 19:58:13 schrieb Matthew Garrett:
> > Bluetooth runtime PM interacts badly with input devices - the connection
> > will be dropped if the device becomes idle, resulting in noticable lag when
> > the user interacts with the input device again. Bump the pm runtime count
> > when the device is associated and release it when it's disassociated in
> > order to avoid this.
>
> What is the effect on battery live of the external devices?
That's a reasonable question. I'll see what I can measure.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH] Change the for loop to read blutooth clock in MCAP CSP
From: Santiago Carot-Nemesio @ 2010-09-17 12:37 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <F43E63DF-F78C-403B-B960-F302339BF7C3@signove.com>
Hi Elvis,
On 09/17/10 13:56, Elvis Pfützenreuter wrote:
> On Sep 17, 2010, at 4:52 AM, Santiago Carot-Nemesio wrote:
>
>> This is only a cosmetic change. Using a do..while loop
>> we avoid direct manipulation of counter loop variable
>> when error happens reading the BT clock.
>> ---
>> health/mcap_sync.c | 10 +++++-----
>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/health/mcap_sync.c b/health/mcap_sync.c
>> index bc1ffcd..78cb163 100644
>> --- a/health/mcap_sync.c
>> +++ b/health/mcap_sync.c
>> @@ -406,18 +406,18 @@ static void initialize_caps(struct mcap_mcl *mcl)
>>
>> /* Do clock read a number of times and measure latency */
>> avg = 0;
>> - for (i = 0; i< 20; ++i) {
>> + i = 0;
>> + do {
>> clock_gettime(CLK,&t1);
>> - if (!read_btclock(mcl,&btclock,&btaccuracy)) {
>> - --i;
>> + if (!read_btclock(mcl,&btclock,&btaccuracy))
>> continue;
>> - }
>> clock_gettime(CLK,&t2);
>>
>> latency = time_us(&t2) - time_us(&t1);
>> latencies[i] = latency;
>> avg += latency;
>> - }
>> + i++;
>> + } while (i< 20);
>> avg /= 20;
>>
>> /* Calculate deviation */
>> --
>> 1.7.2.3
>
> Looking again now, this (the logic, not the patch) may lead to an infinite loop, if for some reason the clock simply can't be read. One more thing to be fixed.--
Yes, you are rigth, I saw it too but I was waiting to speak with you. It
may be better set a maximum number of attempts and return a CSP error
code if it is not possible synchronize with remote device.
For now I think that this patch looks better than use a for loop here :P
^ permalink raw reply
* Re: [PATCH] Bluetooth: Replace hard code of fixed channels bit mask
From: Gustavo F. Padovan @ 2010-09-17 18:07 UTC (permalink / raw)
To: Ville Tervo
Cc: haijun liu, linux-bluetooth@vger.kernel.org, Mat Martineau,
dantian.ip
In-Reply-To: <20100917085047.GN14330@null>
Hi Ville,
* Ville Tervo <ville.tervo@nokia.com> [2010-09-17 11:50:47 +0300]:
> Hi Gustavo,
>
> On Thu, Sep 16, 2010 at 04:16:54PM +0200, ext Gustavo F. Padovan wrote:
> > Hi Haijun,
> >
> > * haijun liu <liuhaijun.er@gmail.com> [2010-09-16 15:15:18 +0800]:
> >
> > > This patch add fixed channels bit mask definition for
> > > L2CAP_FIXCHAN_NULLID
> > > L2CAP_FIXCHAN_SIGNAL
> > > L2CAP_FIXCHAN_CONNLESS
> > > L2CAP_FIXCHAN_A2MP
> > > And replace hard code in source file with the macro.
> > >
> > > Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
> > > ---
> > > include/net/bluetooth/l2cap.h | 6 ++++++
> > > net/bluetooth/l2cap.c | 2 +-
> > > 2 files changed, 7 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> > > index 6c24144..e4fe2c7 100644
> > > --- a/include/net/bluetooth/l2cap.h
> > > +++ b/include/net/bluetooth/l2cap.h
> > > @@ -97,6 +97,12 @@ struct l2cap_conninfo {
> > > #define L2CAP_FEAT_FCS 0x00000020
> > > #define L2CAP_FEAT_FIXED_CHAN 0x00000080
> > >
> > > +/* L2CAP fixed channel bitmask */
> > > +#define L2CAP_FIXCHAN_NULLID 0x00
> > > +#define L2CAP_FIXCHAN_SIGNAL 0x02
> > > +#define L2CAP_FIXCHAN_CONNLESS 0x04
> > > +#define L2CAP_FIXCHAN_A2MP 0x08
> >
> > That's wrong, signaling channel is 0x01, connless is 0x02 and A2MP is
> > 0x03. And if you haven't noted we already have macros for the signaling
> > and connectionless channels:
>
> But these are bit masks and looks ok to me except L2CAP_FIXCHAN_A2MP which I
> could not find from the list.. Check Vol 3 Part A 4.13.
>
> > #define L2CAP_CID_SIGNALING 0x0001
> > #define L2CAP_CID_CONN_LESS 0x0002
>
> These are channel ids.
Yes, you guys are completely right. I was misunderstanding that piece of
code about fixed channels. Thanks for clarify. ;)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* [PATCH 1/2] bluetooth: add support for controller in MacBookPro7,1
From: Will Woods @ 2010-09-17 20:38 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, kernel, Will Woods
As with iMac11,1 the device class is ff(vend.) instead of e0(wlcon).
output from 'usb-devices':
T: Bus=04 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8213 Rev=01.86
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
S: SerialNumber=58B0359C28ED
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
---
drivers/bluetooth/btusb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d22ce3c..eac44e4 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -59,6 +59,9 @@ static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ /* Apple MacBookPro7,1 */
+ { USB_DEVICE(0x05ac, 0x8213) },
+
/* Apple iMac11,1 */
{ USB_DEVICE(0x05ac, 0x8215) },
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] bluetooth: add support for controller in MacBookPro6,2
From: Will Woods @ 2010-09-17 20:38 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, kernel, Will Woods
In-Reply-To: <1284755883-10795-1-git-send-email-wwoods@redhat.com>
Once again the device class is ff(vend.) instead of e0(wlcon).
output from 'usb-devices':
T: Bus=01 Lev=03 Prnt=03 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8218 Rev=00.22
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
---
drivers/bluetooth/btusb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index eac44e4..320e798 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -65,6 +65,9 @@ static struct usb_device_id btusb_table[] = {
/* Apple iMac11,1 */
{ USB_DEVICE(0x05ac, 0x8215) },
+ /* Apple MacBookPro6,2 */
+ { USB_DEVICE(0x05ac, 0x8218) },
+
/* AVM BlueFRITZ! USB v2.0 */
{ USB_DEVICE(0x057c, 0x3800) },
--
1.7.2.3
^ permalink raw reply related
* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-17 21:08 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel
In-Reply-To: <alpine.DEB.2.00.1009160840080.4394@linux-sea-02>
Hi Mat,
* Mat Martineau <mathewm@codeaurora.org> [2010-09-16 09:40:54 -0700]:
>
> Gustavo -
>
> Since this is now a only a discussion of blocking behavior with ERTM
> (and not a regression with skb_clone()), I've removed linux-kernel and
> netdev from the cc list. If you think they still need to see this
> thread, please add them back in.
>
>
> On Wed, 15 Sep 2010, Gustavo F. Padovan wrote:
>
> > * Gustavo F. Padovan <padovan@profusion.mobi> [2010-09-10 16:45:09 -0300]:
> >
> >> Hi Mat,
> >>
> >> * Mat Martineau <mathewm@codeaurora.org> [2010-09-10 09:53:31 -0700]:
> >>
> >>>
> >>> Gustavo -
> >>>
> >>> I'm not sure why the streaming code used to work, but this does not
> >>> look like an skb_clone() problem. Your patch to remove the
> >>> skb_clone() call in l2cap_streaming_send() addresses the root cause of
> >>> this crash.
> >>>
> >>> On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
> >>>
> >>>> I've been experiencing some problems when running the L2CAP Streaming mode in
> >>>> 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> >>>> wasn't happening before, so I think we may have a regression here (I didn't
> >>>> find where yet). The crash log is below.
> >>>>
> >>>> The following patch does not fix the regression, but shows that removing the
> >>>> skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> >>>> patch is good anyway because it saves memory and time.
> >>>>
> >>>> By now I have no idea on how to fix this.
> >>>>
> >>>> <snip>
> >>>
> >>> This has to do with the sk->sk_wmem_alloc accounting that controls the
> >>> amount of write buffer space used on the socket.
> >>>
> >>> When the L2CAP streaming mode socket segments its data, it allocates
> >>> memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
> >>> that allocation call returns, skb_set_owner_w() is called on the new
> >>> skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
> >>> sk->sk_wmem_alloc is correctly updated when the skb is freed.
> >>>
> >>> When that skb is cloned, the clone is not "owned" by the write buffer.
> >>> The clone's destructor is set to NULL in __skb_clone(). The version
> >>> of l2cap_streaming_send() that runs out of memory is passing the
> >>> non-owned skb clone down to the HCI layer. The original skb (the one
> >>> that's "owned by w") is immediately freed, which adjusts
> >>> sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
> >>> buffer space. As a result, bt_skb_send_alloc() never blocks waiting
> >>> for buffer space (or returns EAGAIN for nonblocking writes) and the
> >>> HCI send queue keeps growing.
> >>
> >> If the problem is what you are saying, add a skb_set_owner_w(skb, sk) on
> >> the cloned skb should solve the problem, but it doesn't. That's exactly
> >> what tcp_transmit_skb() does. Also that just appeared in 2.6.36, is was
> >> working fine before, i.e, we have a regression here.
> >>
> >>>
> >>> This isn't a problem for the ERTM sends, because the original skbs are
> >>> kept in the ERTM tx queue until they are acked. Once they're acked,
> >>> the write buffer space is freed and additional skbs can be allocated.
> >>
> >> It affects ERTM as well, but in that case the kernel doesn't crash
> >> because ERTM block on sending trying to allocate memory. Then we are not
> >> able to receive any ack (everything stays queued in sk_backlog_queue as
> >> the sk is owned by the user) and ERTM stalls.
> >
> > By reverting
> >
> > commit 218bb9dfd21472128f86b38ad2eab123205c2991
> > Author: Gustavo F. Padovan <padovan@profusion.mobi>
> > Date: Mon Jun 21 18:53:22 2010 -0300
> >
> > Bluetooth: Add backlog queue to ERTM code
> >
> > backlog queue is the canonical mechanism to avoid race conditions due
> > interrupts in bottom half context. After the socket lock is released the
> > net core take care of push all skb in its backlog queue.
> >
> > Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> > Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> >
> >
> > we can workaround the bug. It's not the real cause of the bug because the
> > backlog queue was working before 2.6.36, but removing the backlog queue scheme
> > make L2CAP works again and also give us more time to find the real cause of the
> > problem.
> >
> > Before implement the backlog queue L2CAP had his own lock scheme to avoid race
> > conditions. The point is that the backlog queue adds too much serialization to
> > L2CAP, that was the cause of the ERTM bug. The old scheme (the one we are going
> > to use after revert this commit) just serialize access to some places.
> >
> > By not using the backlog queue, we can receive the acknowledgement frames more
> > quickly and then free the acked frames quickly. In fact the old scheme is
> > looks better than backlog queue.
> >
> > I think we should proceed with the revert with this commit in mainline, and at the
> > same time try to find the root cause of the problem.
>
> I don't think the backlog patch should be reverted. Although the old
> code would appear to get things working again, it's only because locks
> were being ignored in some important cases. Maybe it seems ok most of
> the time, but the ERTM socket state was not being properly protected.
> The backlog is the right way to do it, but also depends on correct
> lock handling in the rest of L2CAP.
>
>
> I think this is one of the locking issues from this message to
> linux-bluetooth ("ERTM known bugs/regressions (was Re: [PATCH 0/8]
> ...)") on August 2:
>
> http://www.spinics.net/lists/linux-bluetooth/msg06734.html
>
>
> We've both arrived at the root cause already: incoming frames
> (including acks) get stuck on the backlog queue while the socket is
> locked waiting for memory -- and no memory gets freed until the acks
> are processed.
>
> The only time the socket lock is held for a long time is when waiting
> for memory, so I think the best solution is to not hold the lock while
> allocating. This should be safe, since the only socket state that's
> changed during bt_skb_send_alloc() is sk->sk_wmem_alloc, which is an
> atomic_t.
>
> Then some changes are needed to these functions:
>
> l2cap_sar_segment_sdu() and l2cap_create_iframe_pdu(): Take some args
> on the stack (like remote_mps) instead of accessing l2cap_pinfo.
> Don't add to TX_QUEUE(sk) within these functions (let the caller do
> that).
>
> l2cap_sock_sendmsg(): Copy necessary data to local variables from
> l2cap_pinfo while the lock is held. release_sock(sk), then call
> l2cap_sar_segment_sdu() (which will work for the "one PDU" case too)
> with the new args for mps, fcs, etc. After l2cap_sar_segment_sdu()
> returns, check the socket state again (like the code at the beginning
> of l2cap_sock_sendmsg()) and then lock_sock(sk), queue the data, and
> send it.
If we are going to release the lock before alloc memory we are assuming
the no one will change the mps, fcs and other things we need inside
those functions, so in the big picture just add a release_lock() before
alloc memory and after that lock the socket again should work nicely and
we won't need any local variable.
However I did find any other code in net/ that release the lock before
alloc memory. ERTM is a similar (and simplified) version of TCP. TCP
uses backlog queues as well and alloc memory with the socket locked.
I'm not completely conviced that this is the better way to fix that, I'm
also looking to others solutions, but haven't figured out them yet. ;)
>
> (I know it would be better and clearer to send a patch for this, but
> I have some other things to fix right now!)
>
>
> The other locking problem (with ERTM timers) also deserves some
> attention, but maybe in a new email thread!
Yes, we need to look to it. Let's start a new mail thread.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* bluetooth: add support for btusb devices in recent MacBook Pros
From: Will Woods @ 2010-09-17 21:09 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, kernel
These two patches add support for the USB bluetooth controllers found
in recent MacBook Pro systems. In both cases the device class is
ff (vend.) rather than the usual e0. The iMac11,1 has the same
problem and is handled with an explicit USB_DEVICE() entry, so
these two devices are handled the same way.
(Apologies for sending the patches again - I forgot the Signed-off-by:
lines the first time.)
-w
^ permalink raw reply
* [PATCH 1/2] bluetooth: add support for controller in MacBookPro7,1
From: Will Woods @ 2010-09-17 21:09 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, kernel, Will Woods
In-Reply-To: <1284757761-11994-1-git-send-email-wwoods@redhat.com>
As with iMac11,1 the device class is ff(vend.) instead of e0(wlcon).
output from 'usb-devices':
T: Bus=04 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8213 Rev=01.86
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
S: SerialNumber=58B0359C28ED
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
Signed-off-by: Will Woods <wwoods@redhat.com>
---
drivers/bluetooth/btusb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d22ce3c..eac44e4 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -59,6 +59,9 @@ static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ /* Apple MacBookPro7,1 */
+ { USB_DEVICE(0x05ac, 0x8213) },
+
/* Apple iMac11,1 */
{ USB_DEVICE(0x05ac, 0x8215) },
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] bluetooth: add support for controller in MacBookPro6,2
From: Will Woods @ 2010-09-17 21:09 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, kernel, Will Woods
In-Reply-To: <1284757761-11994-1-git-send-email-wwoods@redhat.com>
Once again the device class is ff(vend.) instead of e0(wlcon).
output from 'usb-devices':
T: Bus=01 Lev=03 Prnt=03 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8218 Rev=00.22
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Will Woods <wwoods@redhat.com>
---
drivers/bluetooth/btusb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index eac44e4..320e798 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -65,6 +65,9 @@ static struct usb_device_id btusb_table[] = {
/* Apple iMac11,1 */
{ USB_DEVICE(0x05ac, 0x8215) },
+ /* Apple MacBookPro6,2 */
+ { USB_DEVICE(0x05ac, 0x8218) },
+
/* AVM BlueFRITZ! USB v2.0 */
{ USB_DEVICE(0x057c, 0x3800) },
--
1.7.2.3
^ permalink raw reply related
* Re: Possible regression with skb_clone() in 2.6.36
From: Andrew Morton @ 2010-09-17 22:34 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, netdev, linux-kernel, marcel
In-Reply-To: <1283209824-8795-1-git-send-email-padovan@profusion.mobi>
On Mon, 30 Aug 2010 20:10:23 -0300
"Gustavo F. Padovan" <padovan@profusion.mobi> wrote:
> I've been experiencing some problems when running the L2CAP Streaming mode in
> 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> wasn't happening before, so I think we may have a regression here (I didn't find
> where yet). The crash log is below.
So 2.6.35 was OK?
> The following patch does not fix the regression, but shows that removing the
> skb_clone() call from l2cap_streaming_send() makes the problem goes away. The
> patch is good anyway since it saves memory and time when sending Streaming mode
> packets.
How does "make it go away" differ from "fix the regression" :)
But yes, if we don't understand the source of the bug then it may well
still be there. Did you make any progress in understanding the cause?
>
> [ 5066.137533] Bluetooth: L2CAP ver 2.15
> [ 5066.137873] Bluetooth: L2CAP socket layer initialized
> [ 5066.545179] Bluetooth: RFCOMM TTY layer initialized
> [ 5066.545879] Bluetooth: RFCOMM socket layer initialized
> [ 5066.546582] Bluetooth: RFCOMM ver 1.11
> [ 5092.268021] l2test invoked oom-killer: gfp_mask=0x4d0, order=0, oom_adj=0, oom_score_adj=0
> [ 5092.268872] Pid: 3897, comm: l2test Not tainted 2.6.36-rc3 #5
> [ 5092.269863] Call Trace:
> [ 5092.270265] [<ffffffff8138b6a6>] ? _raw_spin_unlock+0x26/0x30
> [ 5092.270878] [<ffffffff810c0827>] T.427+0x77/0x1e0
> [ 5092.271874] [<ffffffff811b85e7>] ? security_real_capable_noaudit+0x37/0x60
> [ 5092.272956] [<ffffffff810c0e3a>] out_of_memory+0x2ca/0x2f0
> [ 5092.273894] [<ffffffff810c3d43>] __alloc_pages_nodemask+0x693/0x6b0
> [ 5092.274871] [<ffffffff810ea3e6>] cache_alloc_refill+0x2d6/0x5c0
> [ 5092.275864] [<ffffffff810ea805>] __kmalloc+0x135/0x150
> [ 5092.276876] [<ffffffff8130f2ae>] __alloc_skb+0x6e/0x150
> [ 5092.277865] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.278652] [<ffffffff8130ace2>] sock_alloc_send_pskb+0x1c2/0x320
> [ 5092.278927] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.279864] [<ffffffff81312add>] ? memcpy_fromiovec+0x6d/0x90
> [ 5092.280864] [<ffffffff8130ae50>] sock_alloc_send_skb+0x10/0x20
> [ 5092.281867] [<ffffffffa00e600f>] l2cap_create_iframe_pdu+0x9f/0x2c0 [l2cap]
> [ 5092.282865] [<ffffffffa00e84b9>] l2cap_sock_sendmsg+0x5d9/0x910 [l2cap]
> [ 5092.283932] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
> [ 5092.284865] [<ffffffff8130725b>] sock_sendmsg+0xdb/0x100
> [ 5092.285652] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
> [ 5092.285864] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
> [ 5092.286864] [<ffffffff813073c0>] sys_sendto+0xf0/0x130
> [ 5092.287864] [<ffffffff8138b60b>] ? _raw_spin_unlock_irq+0x2b/0x40
> [ 5092.288872] [<ffffffff81093cfd>] ? trace_hardirqs_on_caller+0x13d/0x180
> [ 5092.289927] [<ffffffff81093d4d>] ? trace_hardirqs_on+0xd/0x10
> [ 5092.290864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.291649] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.291864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.292864] [<ffffffff8130740f>] sys_send+0xf/0x20
> [ 5092.293870] [<ffffffff8132ccd6>] compat_sys_socketcall+0x146/0x1f0
> [ 5092.294875] [<ffffffff81053ee4>] sysenter_dispatch+0x7/0x30
That's a pretty serious regression.
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Marcel Holtmann @ 2010-09-18 0:16 UTC (permalink / raw)
To: Nicolas GUILBAUD
Cc: Suraj Sumangala, Suraj Sumangala, linux-bluetooth,
Jothikumar Mothilal
In-Reply-To: <A9AC1023FCA4654D92AC24C2A8F6A09201AA816C@renesas4bis.renesas-rdf.local>
Hi Nicolas,
> >>that is just because we haven't gotten there yet. Of course if SAP takes
> over we have to shutdown oFono's handling of the modem. This could be
> done similar to the support for Lockdown we have in the oFono TODO list.
>
> Do you have information about the release date of this feature? And about the interface to lockdown, is it a D-BUS message?
good one ;)
We know that we need such or similar feature for firmware updates where
we have to essentially shutdown oFono from driving the modem for a
period of time. The details are not 100% clear. For firmware updates
this has to be a D-Bus method, actually D-Bus property on the modem
interface.
In theory we can even extend this to do this internally as well. So that
an oFono plugin could lock down the modem. Things we clearly have to
figure out at some point.
> >There is a framework for card services in general, but I think that is
> just pure overhead for this.
>
> >And to be honest, my current thinking is that even for pure SIM card
> readers with APDU mode, we might wanna support them via oFono anyway.
> Having to add SAP support in multiple levels is a bad idea.
>
> Yes but an APDU interface is needed in the SIM driver of oFono, I don't see any interface of this kind in the source code.
Because we haven't had any hardware that does this so far. You will only
see code in oFono once we had hardware in our hands that is able of
doing this and we know how to drive it.
> Maybe it's not the good place to speak about that.
Essentially the oFono mailing list is a better place for such a
discussion.
> >However in the end this all depends on the hardware and right now I have
> not had access to SAP capable hardware. Or maybe I did and I didn't know
> it yet. Do we have any target hardware in mind?
>
> Yes we have, it's Renesas Modem solution.
Any chance you guys could add Renesas Modem support to oFono and then us
some samples?
Regards
Marcel
^ permalink raw reply
* [PATCH] Remove --enable-mcap from configure command line options
From: Santiago Carot-Nemesio @ 2010-09-18 7:58 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, Santiago Carot-Nemesio
Only plugins are in charge of switch on MCAP if they require
it to work.
---
acinclude.m4 | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/acinclude.m4 b/acinclude.m4
index 1df93db..287f07d 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -176,7 +176,6 @@ AC_DEFUN([AC_ARG_BLUEZ], [
network_enable=yes
service_enable=yes
health_enable=no
- mcap_enable=no
pnat_enable=no
attrib_enable=no
tracer_enable=no
@@ -231,10 +230,6 @@ AC_DEFUN([AC_ARG_BLUEZ], [
health_enable=${enableval}
])
- AC_ARG_ENABLE(mcap, AC_HELP_STRING([--enable-mcap], [enable mcap support]), [
- mcap_enable=${enableval}
- ])
-
AC_ARG_ENABLE(pnat, AC_HELP_STRING([--enable-pnat], [enable pnat plugin]), [
pnat_enable=${enableval}
])
@@ -358,7 +353,7 @@ AC_DEFUN([AC_ARG_BLUEZ], [
AM_CONDITIONAL(NETWORKPLUGIN, test "${network_enable}" = "yes")
AM_CONDITIONAL(SERVICEPLUGIN, test "${service_enable}" = "yes")
AM_CONDITIONAL(HEALTHPLUGIN, test "${health_enable}" = "yes")
- AM_CONDITIONAL(MCAP, test "${mcap_enable}" = "yes" || test "${health_enable}" = "yes")
+ AM_CONDITIONAL(MCAP, test "${health_enable}" = "yes")
AM_CONDITIONAL(HAL, test "${hal_enable}" = "yes")
AM_CONDITIONAL(ATTRIBPLUGIN, test "${attrib_enable}" = "yes")
AM_CONDITIONAL(ECHOPLUGIN, test "no" = "yes")
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox