* Re: pull request: bluetooth-next-2.6 2010-10-13
From: Luis R. Rodriguez @ 2010-10-13 21:41 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linville, marcel, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20101013034808.GA3205@vigoh>
On Tue, Oct 12, 2010 at 8:48 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> One notable change is in the MAINTAINERS file, From now and on I'm going
> to maintain the Bluetooth trees as well as send the pull requests to you.
I noted here you mentioned "as well", does this mean there may be
updates from two people now instead of just one?
> Despite this maintenance change, Marcel will remain helping with patch
> review, and ACK/NAK in the Bluetooth subsystem as he always did. Not a
> big change in the end. ;)
Luis
^ permalink raw reply
* Re: [PATCH] TODO: Device Name Characteristic for Low Energy
From: Johan Hedberg @ 2010-10-13 19:27 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286991867-26866-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> ---
> TODO | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Kevin Hayes @ 2010-10-13 18:41 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Marcel Holtmann, Henry Ptasinski, Suraj Sumangala,
David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless
In-Reply-To: <AANLkTik9oYwspVG4KFbMMq63SpBp++iZe=vxOSQhxRki@mail.gmail.com>
SGkgTHVpcywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1i
bHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1ZXRvb3RoLQ0K
PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBMdWlzIFIuIFJvZHJpZ3Vleg0K
PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTMsIDIwMTAgMTE6MTAgQU0NCj4gVG86IEtldmlu
IEhheWVzDQo+IENjOiBMdWlzIFJvZHJpZ3VlejsgTWFyY2VsIEhvbHRtYW5uOyBIZW5yeSBQdGFz
aW5za2k7IFN1cmFqIFN1bWFuZ2FsYTsNCj4gRGF2aWQgV29vZGhvdXNlOyBsaW51eC1ibHVldG9v
dGg7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiB3aXJlbGVzcw0KPiBT
dWJqZWN0OiBSZTogRmlybXdhcmUgdmVyc2lvbmluZyBiZXN0IHByYWN0aWNlczogYXRoM2stMi5m
dyByZW5hbWUgb3INCj4gcmVwbGFjZSBhdGgzay0xLmZ3ID8NCj4gDQo+IE9uIFdlZCwgT2N0IDEz
LCAyMDEwIGF0IDEwOjU0IEFNLCBLZXZpbiBIYXllcyA8a2V2aW5AYXRoZXJvcy5jb20+DQo+IHdy
b3RlOg0KPiA+IEhpIEx1aXMsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiA+PiBGcm9tOiBsaW51eC1ibHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFtt
YWlsdG86bGludXgtYmx1ZXRvb3RoLQ0KPiA+PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJl
aGFsZiBPZiBMdWlzIFIuIFJvZHJpZ3Vleg0KPiA+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIg
MTMsIDIwMTAgMTA6NDMgQU0NCj4gPj4gVG86IE1hcmNlbCBIb2x0bWFubg0KPiA+PiBDYzogSGVu
cnkgUHRhc2luc2tpOyBTdXJhaiBTdW1hbmdhbGE7IEx1aXMgUm9kcmlndWV6OyBEYXZpZA0KPiBX
b29kaG91c2U7DQo+ID4+IGxpbnV4LWJsdWV0b290aDsgbGludXgta2VybmVsQHZnZXIua2VybmVs
Lm9yZzsgbGludXgtd2lyZWxlc3MNCj4gPj4gU3ViamVjdDogUmU6IEZpcm13YXJlIHZlcnNpb25p
bmcgYmVzdCBwcmFjdGljZXM6IGF0aDNrLTIuZncgcmVuYW1lDQo+IG9yDQo+ID4+IHJlcGxhY2Ug
YXRoM2stMS5mdyA/DQo+ID4+DQo+ID4+IE9uIFdlZCwgT2N0IDEzLCAyMDEwIGF0IDM6MDYgQU0s
IE1hcmNlbCBIb2x0bWFubg0KPiA8bWFyY2VsQGhvbHRtYW5uLm9yZz4NCj4gPj4gd3JvdGU6DQo+
ID4+ID4gSGkgSGVucnksDQo+ID4+ID4NCj4gPj4gPj4gPiA+IE1hcmNlbCBoYWQgYW5zd2VyZWQg
bWUgYmVmb3JlLiBJdCBtYWtlcyBzZW5zZSB0byBoYXZlIHNhbWUNCj4gZmlsZQ0KPiA+PiBuYW1l
Lg0KPiA+PiA+PiA+ID4gT3RoZXIgd2F5cyB3ZSBlbmQgdXAgY2hhbmdpbmcgdGhlIGRyaXZlciB3
aGVuZXZlciB0aGVyZSBpcyBhDQo+ID4+IGZpcm13YXJlDQo+ID4+ID4+ID4gPiBjaGFuZ2UuDQo+
ID4+ID4+ID4NCj4gPj4gPj4gPiA+ID4gSSBsYXN0IHRyaWVkIHRvIGRvY3VtZW50IGEgdGhyZWFk
IHdlIGhhZCBvdmVyIHRoaXMgaGVyZToNCj4gPj4gPj4gPiA+ID4NCj4gPj4gPj4gPiA+ID4NCj4g
Pj4gaHR0cDovL3dpcmVsZXNzLmtlcm5lbC5vcmcvZW4vZGV2ZWxvcGVycy9Eb2N1bWVudGF0aW9u
L2Zpcm13YXJlLQ0KPiA+PiB2ZXJzaW9uaW5nDQo+ID4+ID4+ID4gPiA+DQo+ID4+ID4+ID4NCj4g
Pj4gPj4gPiBUaGFua3MsIEkndmUgdXBkYXRlZCB0aGF0IGxpbmsgYWJvdmUgdG8gZG9jdW1lbnQg
YnVnIGZpeGluZw0KPiBkb2VzDQo+ID4+IG5vdCByZXF1aXJlDQo+ID4+ID4+ID4gYSBmaWxlbmFt
ZSBjaGFuZ2UuDQo+ID4+ID4+DQo+ID4+ID4+IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2h5
IHlvdSB3b3VsZCBub3Qgd2FudCB0byBjaGFuZ2UgdGhlDQo+IGNvZGUNCj4gPj4gcmV2aXNpb24N
Cj4gPj4gPj4gcGFydCBvZiB0aGUgZmlsZW5hbWUuDQo+ID4+ID4+DQo+ID4+ID4+IEkgdG90YWxs
eSBhZ3JlZSB0aGF0IHlvdSBkb24ndCB3YW50IHRvIGNoYW5nZSB0aGUgZHJpdmVyIGV2ZXJ5DQo+
IHRpbWUNCj4gPj4gdGhlDQo+ID4+ID4+IGZpcm13YXJlIGdldHMgYSBidWcgZml4LCBidXQgd2Fz
bid0IHRoYXQgdGhlIHdob2xlIHBvaW50IG9mDQo+ID4+IHNwbGl0dGluZyB0aGUgbmFtZQ0KPiA+
PiA+PiBpbnRvIEFQSSBhbmQgY29kZSByZXZpc2lvbnMgcG9ydGlvbnMsIGFuZCBzeW1saW5raW5n
IHRoZSBmaWxlIHRvDQo+IG9uZQ0KPiA+PiB0aGF0IGp1c3QNCj4gPj4gPj4gaGFzIHRoZSBBUEkg
dmVyc2lvbj8NCj4gPj4gPj4NCj4gPj4gPj4gV2hhdCdzIHRoZSBpc3N1ZSB3aXRoIHVzaW5nIHRo
ZSBwcm9jZXNzIGFzIG9yaWdpbmFsbHkgZG9jdW1lbnRlZD8NCj4gPj4gPg0KPiA+PiA+IGFzIEkg
c3RhdGVkIGJlZm9yZSwgZm9yIEJsdWV0b290aCB0aGlzIG1ha2VzIG5vIHNlbnNlLiBZb3UgZG9u
J3QNCj4gbmVlZA0KPiA+PiA+IEFQSSB2ZXJzaW9uIG51bWJlcnMgc2luY2UgdGhlIEFQSSBpcyBh
IFNUQU5EQVJELiBJdCBpcyBjYWxsZWQgSENJLg0KPiBTbw0KPiA+PiA+IHBsZWFzZSBkb24ndCB1
c2UgQVBJIHZlcnNpb24gbnVtYmVycyBpbiB0aGUgZmlybXdhcmUgZmlsZXMuDQo+ID4+ID4NCj4g
Pj4gPiBJIHdpbGwgcmVqZWN0IGZpcm13YXJlIGZpbGUgdmVyc2lvbnMgZm9yIHVwc3RyZWFtIGRy
aXZlcnMuDQo+ID4+DQo+ID4+IERvZXMgdGhlIEhDSSBzdGFuZGFyZCBldmVyIGdldCBpbXByb3Zl
ZCB1cG9uPyBJZiBzbywgaG93IGRvIGRldmljZXMNCj4gPj4gbmV2ZXIgZ2V0IGZpcm13YXJlIHVw
ZGF0ZXMgdGhhdCB3b3VsZCBhbGxvdyB0aGVtIHRvIHVzZSBzb21lIG5ld2VyDQo+IEhDSQ0KPiA+
PiBBUElzPw0KPiA+Pg0KPiA+PiBJJ3ZlIHVwZGF0ZWQgdGhlIGRvY3VtZW50YXRpb24gYWJvdmUg
Zm9yIDgwMi4xMSBhbmQgQmx1ZXRvb3RoIHdpdGgNCj4gdGhlDQo+ID4+IGFib3ZlLCBwbGVhc2Ug
ZmVlbCBmcmVlIHRvIGZ1cnRoZXIgZXh0ZW5kIGl0IGFzIHlvdSBzZWUgZml0Lg0KPiA+Pg0KPiA+
PiDCoCBMdWlzDQo+ID4NCj4gPiBIQ0kgaXMgYWx3YXlzIGJhY2t3YXJkIGNvbXBhdGlibGUuIMKg
TmV3ZXIgY29tbWFuZHMgYXJlIHByb3Blcmx5DQo+IGRpc2NvdmVyYWJsZSBieSBib3RoIHNpZGVz
IG9mIHRoZSBIQ0kgbGluay4NCj4gPiBBcyBsb25nIGFzIHRoZSBwcm9jZWR1cmUgdG8gZG93bmxv
YWQgZmlybXdhcmUgZG9lcyBub3QgZGVwZW5kIG9uIG5ldw0KPiBIQ0kgY29tbWFuZHMgKGl0IGRv
ZXMgbm90KSwgdGhlbiB0aGUgZmlybXdhcmUgaXRzZWxmIGNhbiB0ZWFjaCBhbiBvbGQNCj4gY29u
dHJvbGxlciB0byBsZWFybiBuZXcgdHJpY2tzLg0KPiANCj4gRG9lcyBIQ0kgc3VwcG9ydCB1cGxv
YWRpbmcgZmlybXdhcmU/IENhbid0IHdlIHJlc29sdmUgdGhpcyBibGFja2xpc3QNCj4gY3JhcCBp
c3N1ZSBpZiBkZXZpY2VzIGp1c3QgdXNlZCBIQ0kgdG8gdXBsb2FkIGZpcm13YXJlPw0KPiANCj4g
ICBMdWlzDQo+IC0tDQoNCk5vdCByZWFsbHkgYmVjYXVzZSB0aGVyZSBpcyBub3QgZW5vdWdoIHNw
YWNlIGluIHRoZSBzZmxhc2ggdG8gZG8gbXVjaCBvZiBhbnl0aGluZyBleGNlcHQgcmVwb3J0IHRo
ZSBQSUQuDQpJdCBtdXN0IGJlIHNvbWUgZXh0ZXJuYWwgY29kZSB0aGF0IHBpY2tzIHRoZSBmaXJt
d2FyZSB0byBsb2FkIGFuZCBpbmplY3QgaXQgaW50byB0aGUgY29udHJvbGxlci4NClRoYXQgZXh0
ZXJuYWwgY29kZSBpcyB0aGUgREZVIGJpdC4gIFdlIG11c3QgYmxhY2tsaXN0IHRoZSBkZXZpY2Ug
c28gdGhhdCBidHVzYiBkb2VzIG5vdCBjbGFpbSBpdCwgc28gd2UgY2FuIHVzZSB0aGUgREZVLg0K
DQogICAgSysrDQoNCltQYXJkb24gdGhlIGdhcmJhZ2UgdGhhdCBvdXIgbWFpbCBzZXJ2ZXIgYWRk
cy4uLl0NCg0KDQoNCg0KDQo=
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Luis R. Rodriguez @ 2010-10-13 18:09 UTC (permalink / raw)
To: Kevin Hayes
Cc: Luis Rodriguez, Marcel Holtmann, Henry Ptasinski, Suraj Sumangala,
David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless
In-Reply-To: <B7132A25476D334D9130FE7532F2A56314B5929629@SC1EXMB-MBCL.global.atheros.com>
On Wed, Oct 13, 2010 at 10:54 AM, Kevin Hayes <kevin@atheros.com> wrote:
> Hi Luis,
>
>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
>> Sent: Wednesday, October 13, 2010 10:43 AM
>> To: Marcel Holtmann
>> Cc: Henry Ptasinski; Suraj Sumangala; Luis Rodriguez; David Woodhouse;
>> linux-bluetooth; linux-kernel@vger.kernel.org; linux-wireless
>> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename or
>> replace ath3k-1.fw ?
>>
>> On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <marcel@holtmann.org>
>> wrote:
>> > Hi Henry,
>> >
>> >> > > Marcel had answered me before. It makes sense to have same file
>> name.
>> >> > > Other ways we end up changing the driver whenever there is a
>> firmware
>> >> > > change.
>> >> >
>> >> > > > I last tried to document a thread we had over this here:
>> >> > > >
>> >> > > >
>> http://wireless.kernel.org/en/developers/Documentation/firmware-
>> versioning
>> >> > > >
>> >> >
>> >> > Thanks, I've updated that link above to document bug fixing does
>> not require
>> >> > a filename change.
>> >>
>> >> I don't really understand why you would not want to change the code
>> revision
>> >> part of the filename.
>> >>
>> >> I totally agree that you don't want to change the driver every time
>> the
>> >> firmware gets a bug fix, but wasn't that the whole point of
>> splitting the name
>> >> into API and code revisions portions, and symlinking the file to one
>> that just
>> >> has the API version?
>> >>
>> >> What's the issue with using the process as originally documented?
>> >
>> > as I stated before, for Bluetooth this makes no sense. You don't need
>> > API version numbers since the API is a STANDARD. It is called HCI. So
>> > please don't use API version numbers in the firmware files.
>> >
>> > I will reject firmware file versions for upstream drivers.
>>
>> Does the HCI standard ever get improved upon? If so, how do devices
>> never get firmware updates that would allow them to use some newer HCI
>> APIs?
>>
>> I've updated the documentation above for 802.11 and Bluetooth with the
>> above, please feel free to further extend it as you see fit.
>>
>> =C2=A0 Luis
>
> HCI is always backward compatible. =C2=A0Newer commands are properly disc=
overable by both sides of the HCI link.
> As long as the procedure to download firmware does not depend on new HCI =
commands (it does not), then the firmware itself can teach an old controlle=
r to learn new tricks.
Does HCI support uploading firmware? Can't we resolve this blacklist
crap issue if devices just used HCI to upload firmware?
Luis
^ permalink raw reply
* RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Kevin Hayes @ 2010-10-13 17:54 UTC (permalink / raw)
To: Luis Rodriguez, Marcel Holtmann
Cc: Henry Ptasinski, Suraj Sumangala, Luis Rodriguez, David Woodhouse,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <AANLkTimAeoS2Vi7GhKSTrghqaOQ=XKSzjcou15dn+YDR@mail.gmail.com>
SGkgTHVpcywNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4
LWJsdWV0b290aC1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1ibHVldG9vdGgt
DQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEx1aXMgUi4gUm9kcmlndWV6
DQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMywgMjAxMCAxMDo0MyBBTQ0KPiBUbzogTWFy
Y2VsIEhvbHRtYW5uDQo+IENjOiBIZW5yeSBQdGFzaW5za2k7IFN1cmFqIFN1bWFuZ2FsYTsgTHVp
cyBSb2RyaWd1ZXo7IERhdmlkIFdvb2Rob3VzZTsNCj4gbGludXgtYmx1ZXRvb3RoOyBsaW51eC1r
ZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC13aXJlbGVzcw0KPiBTdWJqZWN0OiBSZTogRmly
bXdhcmUgdmVyc2lvbmluZyBiZXN0IHByYWN0aWNlczogYXRoM2stMi5mdyByZW5hbWUgb3INCj4g
cmVwbGFjZSBhdGgzay0xLmZ3ID8NCj4gDQo+IE9uIFdlZCwgT2N0IDEzLCAyMDEwIGF0IDM6MDYg
QU0sIE1hcmNlbCBIb2x0bWFubiA8bWFyY2VsQGhvbHRtYW5uLm9yZz4NCj4gd3JvdGU6DQo+ID4g
SGkgSGVucnksDQo+ID4NCj4gPj4gPiA+IE1hcmNlbCBoYWQgYW5zd2VyZWQgbWUgYmVmb3JlLiBJ
dCBtYWtlcyBzZW5zZSB0byBoYXZlIHNhbWUgZmlsZQ0KPiBuYW1lLg0KPiA+PiA+ID4gT3RoZXIg
d2F5cyB3ZSBlbmQgdXAgY2hhbmdpbmcgdGhlIGRyaXZlciB3aGVuZXZlciB0aGVyZSBpcyBhDQo+
IGZpcm13YXJlDQo+ID4+ID4gPiBjaGFuZ2UuDQo+ID4+ID4NCj4gPj4gPiA+ID4gSSBsYXN0IHRy
aWVkIHRvIGRvY3VtZW50IGEgdGhyZWFkIHdlIGhhZCBvdmVyIHRoaXMgaGVyZToNCj4gPj4gPiA+
ID4NCj4gPj4gPiA+ID4NCj4gaHR0cDovL3dpcmVsZXNzLmtlcm5lbC5vcmcvZW4vZGV2ZWxvcGVy
cy9Eb2N1bWVudGF0aW9uL2Zpcm13YXJlLQ0KPiB2ZXJzaW9uaW5nDQo+ID4+ID4gPiA+DQo+ID4+
ID4NCj4gPj4gPiBUaGFua3MsIEkndmUgdXBkYXRlZCB0aGF0IGxpbmsgYWJvdmUgdG8gZG9jdW1l
bnQgYnVnIGZpeGluZyBkb2VzDQo+IG5vdCByZXF1aXJlDQo+ID4+ID4gYSBmaWxlbmFtZSBjaGFu
Z2UuDQo+ID4+DQo+ID4+IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2h5IHlvdSB3b3VsZCBu
b3Qgd2FudCB0byBjaGFuZ2UgdGhlIGNvZGUNCj4gcmV2aXNpb24NCj4gPj4gcGFydCBvZiB0aGUg
ZmlsZW5hbWUuDQo+ID4+DQo+ID4+IEkgdG90YWxseSBhZ3JlZSB0aGF0IHlvdSBkb24ndCB3YW50
IHRvIGNoYW5nZSB0aGUgZHJpdmVyIGV2ZXJ5IHRpbWUNCj4gdGhlDQo+ID4+IGZpcm13YXJlIGdl
dHMgYSBidWcgZml4LCBidXQgd2Fzbid0IHRoYXQgdGhlIHdob2xlIHBvaW50IG9mDQo+IHNwbGl0
dGluZyB0aGUgbmFtZQ0KPiA+PiBpbnRvIEFQSSBhbmQgY29kZSByZXZpc2lvbnMgcG9ydGlvbnMs
IGFuZCBzeW1saW5raW5nIHRoZSBmaWxlIHRvIG9uZQ0KPiB0aGF0IGp1c3QNCj4gPj4gaGFzIHRo
ZSBBUEkgdmVyc2lvbj8NCj4gPj4NCj4gPj4gV2hhdCdzIHRoZSBpc3N1ZSB3aXRoIHVzaW5nIHRo
ZSBwcm9jZXNzIGFzIG9yaWdpbmFsbHkgZG9jdW1lbnRlZD8NCj4gPg0KPiA+IGFzIEkgc3RhdGVk
IGJlZm9yZSwgZm9yIEJsdWV0b290aCB0aGlzIG1ha2VzIG5vIHNlbnNlLiBZb3UgZG9uJ3QgbmVl
ZA0KPiA+IEFQSSB2ZXJzaW9uIG51bWJlcnMgc2luY2UgdGhlIEFQSSBpcyBhIFNUQU5EQVJELiBJ
dCBpcyBjYWxsZWQgSENJLiBTbw0KPiA+IHBsZWFzZSBkb24ndCB1c2UgQVBJIHZlcnNpb24gbnVt
YmVycyBpbiB0aGUgZmlybXdhcmUgZmlsZXMuDQo+ID4NCj4gPiBJIHdpbGwgcmVqZWN0IGZpcm13
YXJlIGZpbGUgdmVyc2lvbnMgZm9yIHVwc3RyZWFtIGRyaXZlcnMuDQo+IA0KPiBEb2VzIHRoZSBI
Q0kgc3RhbmRhcmQgZXZlciBnZXQgaW1wcm92ZWQgdXBvbj8gSWYgc28sIGhvdyBkbyBkZXZpY2Vz
DQo+IG5ldmVyIGdldCBmaXJtd2FyZSB1cGRhdGVzIHRoYXQgd291bGQgYWxsb3cgdGhlbSB0byB1
c2Ugc29tZSBuZXdlciBIQ0kNCj4gQVBJcz8NCj4gDQo+IEkndmUgdXBkYXRlZCB0aGUgZG9jdW1l
bnRhdGlvbiBhYm92ZSBmb3IgODAyLjExIGFuZCBCbHVldG9vdGggd2l0aCB0aGUNCj4gYWJvdmUs
IHBsZWFzZSBmZWVsIGZyZWUgdG8gZnVydGhlciBleHRlbmQgaXQgYXMgeW91IHNlZSBmaXQuDQo+
IA0KPiAgIEx1aXMNCg0KSENJIGlzIGFsd2F5cyBiYWNrd2FyZCBjb21wYXRpYmxlLiAgTmV3ZXIg
Y29tbWFuZHMgYXJlIHByb3Blcmx5IGRpc2NvdmVyYWJsZSBieSBib3RoIHNpZGVzIG9mIHRoZSBI
Q0kgbGluay4NCkFzIGxvbmcgYXMgdGhlIHByb2NlZHVyZSB0byBkb3dubG9hZCBmaXJtd2FyZSBk
b2VzIG5vdCBkZXBlbmQgb24gbmV3IEhDSSBjb21tYW5kcyAoaXQgZG9lcyBub3QpLCB0aGVuIHRo
ZSBmaXJtd2FyZSBpdHNlbGYgY2FuIHRlYWNoIGFuIG9sZCBjb250cm9sbGVyIHRvIGxlYXJuIG5l
dyB0cmlja3MuDQoNCglLKysNCg==
^ permalink raw reply
* [PATCH] TODO: Device Name Characteristic for Low Energy
From: Claudio Takahasi @ 2010-10-13 17:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
TODO | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 0a7b482..2c17c6b 100644
--- a/TODO
+++ b/TODO
@@ -14,6 +14,20 @@ Background
Higher complexity tasks should be refined into several lower complexity tasks
once the task is better understood.
+LE Generic Access Profile
+=========================
+
+- Device Name Characteristic is a GAP characteristic for Low Energy. This
+ characteristic shall be integrated/used in the discovery procedure. The
+ ideia is to report the value of this characteristic using DeviceFound signals.
+ Discussion with the community is needed before to start this task. Other GAP
+ characteristics for LE needs to follow a similar approach. It is not clear
+ if all GAP characteristics can be exposed using properties instead of a primary
+ service characteristics.
+ See Volume 3, Part C, section 12.1 for more information.
+
+ Priority: Low
+ Complexity: C2
ATT/GATT
========
--
1.7.3.1
^ permalink raw reply related
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Luis R. Rodriguez @ 2010-10-13 17:42 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Henry Ptasinski, Suraj Sumangala, Luis Rodriguez, David Woodhouse,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1286964370.3316.6.camel@aeonflux>
On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Henry,
>
>> > > Marcel had answered me before. It makes sense to have same file name.
>> > > Other ways we end up changing the driver whenever there is a firmware
>> > > change.
>> >
>> > > > I last tried to document a thread we had over this here:
>> > > >
>> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
>> > > >
>> >
>> > Thanks, I've updated that link above to document bug fixing does not require
>> > a filename change.
>>
>> I don't really understand why you would not want to change the code revision
>> part of the filename.
>>
>> I totally agree that you don't want to change the driver every time the
>> firmware gets a bug fix, but wasn't that the whole point of splitting the name
>> into API and code revisions portions, and symlinking the file to one that just
>> has the API version?
>>
>> What's the issue with using the process as originally documented?
>
> as I stated before, for Bluetooth this makes no sense. You don't need
> API version numbers since the API is a STANDARD. It is called HCI. So
> please don't use API version numbers in the firmware files.
>
> I will reject firmware file versions for upstream drivers.
Does the HCI standard ever get improved upon? If so, how do devices
never get firmware updates that would allow them to use some newer HCI
APIs?
I've updated the documentation above for 802.11 and Bluetooth with the
above, please feel free to further extend it as you see fit.
Luis
^ permalink raw reply
* Re: [PATCH] TODO: Implement Server Characteristic Configuration
From: Johan Hedberg @ 2010-10-13 17:00 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286987833-25972-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> ---
> TODO | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
And this one has also been pushed. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] TODO: Implement Client Characteristic Configuration
From: Johan Hedberg @ 2010-10-13 16:59 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286987650-25914-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> ---
> TODO | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
Thanks. This one has also been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Disable automatic notification/indication in the attribute server
From: Johan Hedberg @ 2010-10-13 16:59 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286987539-25833-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 13, 2010, Claudio Takahasi wrote:
> Attribute server shall not send automatic indication/notification
> messages if the client didn't request them. Client shall use Client
> /Server Characteristic Configuration descriptors to be notified about
> attribute changes. If the server doesn't support these descriptors,
> the client shall implement a polling mechanism to check for attribute
> value changes.
> ---
> TODO | 7 ------
> src/attrib-server.c | 60 ++++----------------------------------------------
> 2 files changed, 5 insertions(+), 62 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] TODO: Implement Server Characteristic Configuration
From: Claudio Takahasi @ 2010-10-13 16:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286460773-25436-1-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 7939d9d..0a7b482 100644
--- a/TODO
+++ b/TODO
@@ -78,6 +78,14 @@ ATT/GATT
Priority: Low
Complexity: C1
+- Implement Server characteristic Configuration support in the attribute
+ server to manage characteristic value broadcasting. There is a single
+ instance of the Server Characteristic Configuration for all clients.
+ See Volume 3, Part G, section 3.3.3.4 for more information.
+
+ Priority: Low
+ Complexity: C1
+
- Long reads/writes don't work (consisting of multiple request packets)
Priority: Low
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/2] TODO: Implement Client Characteristic Configuration
From: Claudio Takahasi @ 2010-10-13 16:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286459639-25194-2-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 3e62518..7939d9d 100644
--- a/TODO
+++ b/TODO
@@ -89,3 +89,12 @@ ATT/GATT
Priority: Low
Complexity: C2
+
+- Implement Client Characteristic Configuration support in the attribute
+ server to manage indications and notications. This is a per client attribute
+ to control how the client wants to receive reports of changes in a given
+ characteristic value.
+ See Volume 3, Part G, section 3.3.3.3 for more information
+
+ Priority: Low
+ Complexity: C2
--
1.7.3.1
^ permalink raw reply related
* [PATCH 1/2] Disable automatic notification/indication in the attribute server
From: Claudio Takahasi @ 2010-10-13 16:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286459639-25194-1-git-send-email-claudio.takahasi@openbossa.org>
Attribute server shall not send automatic indication/notification
messages if the client didn't request them. Client shall use Client
/Server Characteristic Configuration descriptors to be notified about
attribute changes. If the server doesn't support these descriptors,
the client shall implement a polling mechanism to check for attribute
value changes.
---
TODO | 7 ------
src/attrib-server.c | 60 ++++----------------------------------------------
2 files changed, 5 insertions(+), 62 deletions(-)
diff --git a/TODO b/TODO
index 3885c78..3e62518 100644
--- a/TODO
+++ b/TODO
@@ -18,13 +18,6 @@ Background
ATT/GATT
========
-- Sample server shouldn't send any indications or notifications without
- the client requesting them
-
- Priority: Medium
- Complexity: C2
- Owner: Claudio Takahasi <claudio.takahasi@openbossa.org>
-
- Add ATT/GATT parsing to hcidump
Priority: Medium
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 666b5fa..1fc1c18 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -590,54 +590,6 @@ static void confirm_event(GIOChannel *io, void *user_data)
return;
}
-static gboolean send_notification(gpointer user_data)
-{
- uint8_t pdu[ATT_MAX_MTU];
- guint handle = GPOINTER_TO_UINT(user_data);
- struct attribute *a;
- GSList *l;
- uint16_t length;
-
- l = g_slist_find_custom(database, GUINT_TO_POINTER(handle), handle_cmp);
- if (!l)
- return FALSE;
-
- a = l->data;
-
- for (l = clients; l; l = l->next) {
- struct gatt_channel *channel = l->data;
-
- length = enc_notification(a, pdu, channel->mtu);
- g_attrib_send(channel->attrib, pdu[0], pdu, length, NULL, NULL, NULL);
- }
-
- return FALSE;
-}
-
-static gboolean send_indication(gpointer user_data)
-{
- uint8_t pdu[ATT_MAX_MTU];
- guint handle = GPOINTER_TO_UINT(user_data);
- struct attribute *a;
- GSList *l;
- uint16_t length;
-
- l = g_slist_find_custom(database, GUINT_TO_POINTER(handle), handle_cmp);
- if (!l)
- return FALSE;
-
- a = l->data;
-
- for (l = clients; l; l = l->next) {
- struct gatt_channel *channel = l->data;
-
- length = enc_indication(a, pdu, channel->mtu);
- g_attrib_send(channel->attrib, pdu[0], pdu, length, NULL, NULL, NULL);
- }
-
- return FALSE;
-}
-
int attrib_server_init(void)
{
GError *gerr = NULL;
@@ -757,14 +709,12 @@ int attrib_db_update(uint16_t handle, uuid_t *uuid, const uint8_t *value,
memcpy(a->data, value, len);
/*
- * Characteristic configuration descriptor is not being used yet.
- * If the attribute changes, all connected clients will be notified.
- * For testing purposes, we send a Notification and a Indication for
- * each update.
+ * <<Client/Server Characteristic Configuration>> descriptors are
+ * not supported yet. If a given attribute changes, the attribute
+ * server shall report the new values using the mechanism selected
+ * by the client. Notification/Indication shall not be automatically
+ * sent if the client didn't request them.
*/
- g_idle_add(send_notification, GUINT_TO_POINTER(h));
-
- g_idle_add(send_indication, GUINT_TO_POINTER(h));
return 0;
}
--
1.7.3.1
^ permalink raw reply related
* Enabling SCO mode
From: Greg Mercurio @ 2010-10-13 15:45 UTC (permalink / raw)
To: linux-bluetooth
I am new to Bluez and have a question about sco audio. I am using Bluez version 4.47 in an Android environment.
The Bluetooth chip I’m using is initialized to use the PCM interface for sco audio data. So, the chip should be ready to transmit the sco audio when enabled.
>From what I can tell by looking at the Android code, the Bluetooth Handsfree Java application in initiates a sco connection by opening a sco socket connection with the stack.
I assume that opening the sco connection will send vendor independent HCI commands to the Bluetooth chip to put it into sco mode. I don’t see in the code where this is done.
Can someone confirm my assumptions and point me to the place in the code where enabling the sco commands are sent to the chip?
Thanks,
Greg
^ permalink raw reply
* Re: [PATCH] Fix problem with operator name length
From: Johan Hedberg @ 2010-10-13 15:09 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: Lukasz Pawlik, linux-bluetooth@vger.kernel.org
In-Reply-To: <1286981571.2142.5.camel@dp-x301>
Hi Dmitriy,
First of all, don't top-post on this list.
On Wed, Oct 13, 2010, Dmitriy Paliy wrote:
> At the moment it is received in ascii from csd since not all car kits
> can handle utf8.
Ok, in that case it should be safe. I went ahead and and pushed the
patch along with a clarification in the commit message about this
guarantee that the csd API gives.
Johan
^ permalink raw reply
* Re: [PATCH] Fix problem with operator name length
From: Dmitriy Paliy @ 2010-10-13 14:52 UTC (permalink / raw)
To: ext Johan Hedberg, Lukasz Pawlik; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20101013141921.GB4828@jh-x301>
Hi,
At the moment it is received in ascii from csd since not all car kits
can handle utf8.
Br,
Dmitriy
On Wed, 2010-10-13 at 16:19 +0200, ext Johan Hedberg wrote:
> Hi Lukasz,
>
> On Wed, Oct 13, 2010, Lukasz Pawlik wrote:
> > - net.operator_name = g_strdup(name);
> > -
> > + net.operator_name = g_strndup(name, 16);
>
> Is it possible that the the format of the name would be such that byte
> boundaries are not always the same as character boundaries (e.g. UTF-8)?
> If so, using g_strndup sounds dangerous since it assumes one byte per
> character.
>
> Johan
> --
> 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] Some code cleanup in hdp
From: Johan Hedberg @ 2010-10-13 14:43 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1286978044-16484-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Wed, Oct 13, 2010, Jose Antonio Santos Cadenas wrote:
> ---
> health/hdp.c | 38 ++++++++++++++++++++++----------------
> health/hdp_util.c | 29 ++++++++++++++++++-----------
> 2 files changed, 40 insertions(+), 27 deletions(-)
Thanks. Pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Fix X-IRMC-CALL-DATETIME format
From: Johan Hedberg @ 2010-10-13 14:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286975756-13134-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Wed, Oct 13, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Use the format suggested in the spec:
>
> "For instance, a call that was missed on March 20th, 2005 at 10 am would
> be stamped: X-IRMC-CALL-DATETIME;MISSED:20050320T100000"
> ---
> plugins/phonebook-tracker.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Adjust mce_bt_set flag to gboolean type values
From: Johan Hedberg @ 2010-10-13 14:24 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1286975300-2832-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Wed, Oct 13, 2010, Rafal Michalski wrote:
> - mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH);
> + mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH ?
> + TRUE : FALSE;
Ok, that's basically a coding style fix.
> - mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH;
> + mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH ? TRUE : FALSE;
And that's a clear bug fix (since there's no guarantee that the binary
and results in the value 1 or TRUE).
In principle I'd prefer having coding style patches separate from real
bug fixes (even for trivial changes), but since these are related I've
let it go for now and pushed the patch upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Fix problem with operator name length
From: Johan Hedberg @ 2010-10-13 14:19 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1286974170-12282-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lukasz,
On Wed, Oct 13, 2010, Lukasz Pawlik wrote:
> - net.operator_name = g_strdup(name);
> -
> + net.operator_name = g_strndup(name, 16);
Is it possible that the the format of the name would be such that byte
boundaries are not always the same as character boundaries (e.g. UTF-8)?
If so, using g_strndup sounds dangerous since it assumes one byte per
character.
Johan
^ permalink raw reply
* Re: [PATCH] Fix telephony-maemo6: call notification with call on hold
From: Johan Hedberg @ 2010-10-13 14:16 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimb82Ykv9fg2Oew4YoN1767e5_NX4Tid+3wHOzE@mail.gmail.com>
Hi Daniel,
On Wed, Oct 13, 2010, Daniel Örstadius wrote:
> BlueZ sends +CLIP and RING when there is an incoming call and no
> currently active call. If there is an active call it sends AT+CCWA
> (call waiting notification).
>
> Modification to send AT+CCWA instead of +CLIP and RING also when
> there is a call on hold (the incoming call goes into the waiting
> state).
> ---
> audio/telephony-maemo6.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Some code cleanup in hdp
From: Jose Antonio Santos Cadenas @ 2010-10-13 13:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
---
health/hdp.c | 38 ++++++++++++++++++++++----------------
health/hdp_util.c | 29 ++++++++++++++++++-----------
2 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index 4a6da78..954b6d6 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -305,11 +305,12 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
const char *name;
DBusMessageIter iter;
GError *err = NULL;
- DBusMessage *reply;
dbus_message_iter_init(msg, &iter);
app = hdp_get_app_config(&iter, &err);
if (err) {
+ DBusMessage *reply;
+
reply = g_dbus_create_error(msg,
ERROR_INTERFACE ".InvalidArguments",
"Invalid arguments: %s", err->message);
@@ -439,12 +440,13 @@ static void abort_mdl_cb(GError *err, gpointer data)
static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
{
struct hdp_tmp_dc_data *dc_data = data;
- struct hdp_channel *chan = dc_data->hdp_chann;
- GError *gerr = NULL;
DBusMessage *reply;
int fd;
if (err) {
+ struct hdp_channel *chan = dc_data->hdp_chann;
+ GError *gerr = NULL;
+
error("%s", err->message);
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
@@ -633,12 +635,13 @@ static void health_channel_destroy(void *data)
{
struct hdp_channel *hdp_chan = data;
struct hdp_device *dev = hdp_chan->dev;
- char *empty_path;
DBG("Destroy Health Channel %s", hdp_chan->path);
dev->channels = g_slist_remove(dev->channels, hdp_chan);
if (hdp_chan == dev->fr) {
+ char *empty_path;
+
dev->fr = NULL;
empty_path = "";
emit_property_changed(dev->conn, device_get_path(dev->dev),
@@ -754,8 +757,6 @@ static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
{
struct hdp_device *dev = data;
struct hdp_channel *chan;
- GIOChannel *io_chan;
- int fd;
DBG("hdp_mcap_mdl_connected_cb");
if (!dev->ndc)
@@ -769,16 +770,19 @@ static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
dev->channels = g_slist_prepend(dev->channels, chan);
if (chan->mdep == HDP_MDEP_ECHO) {
+ GIOChannel *io;
+ int fd;
+
fd = mcap_mdl_get_fd(chan->mdl);
if (fd < 0)
return;
chan->echo_done = FALSE;
- io_chan = g_io_channel_unix_new(fd);
- chan->wid = g_io_add_watch(io_chan,
+ io = g_io_channel_unix_new(fd);
+ chan->wid = g_io_add_watch(io,
G_IO_ERR | G_IO_HUP | G_IO_NVAL | G_IO_IN,
serve_echo, chan);
- g_io_channel_unref(io_chan);
+ g_io_channel_unref(io);
return;
}
@@ -859,8 +863,6 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
{
struct hdp_device *dev = data;
struct hdp_application *app;
- struct hdp_channel *chan;
- char *path;
GSList *l;
DBG("Data channel request");
@@ -922,7 +924,9 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
l = g_slist_find_custom(dev->channels, &mdlid, cmp_chan_mdlid);
if (l) {
- chan = l->data;
+ struct hdp_channel *chan = l->data;
+ char *path;
+
path = g_strdup(chan->path);
g_dbus_unregister_interface(dev->conn, path, HEALTH_CHANNEL);
g_free(path);
@@ -981,16 +985,17 @@ gboolean hdp_set_mcl_cb(struct hdp_device *device, GError **err)
static void mcl_connected(struct mcap_mcl *mcl, gpointer data)
{
- struct hdp_adapter *hdp_adapter = data;
struct hdp_device *hdp_device;
- struct btd_device *device;
bdaddr_t addr;
- char str[18];
GSList *l;
mcap_mcl_get_addr(mcl, &addr);
l = g_slist_find_custom(devices, &addr, cmp_dev_addr);
if (!l) {
+ struct hdp_adapter *hdp_adapter = data;
+ struct btd_device *device;
+ char str[18];
+
ba2str(&addr, str);
device = adapter_get_device(connection,
hdp_adapter->btd_adapter, str);
@@ -1088,7 +1093,6 @@ static void check_devices_mcl()
{
struct hdp_device *dev;
GSList *l, *to_delete = NULL;
- const char *path;
for (l = devices; l; l = l->next) {
dev = l->data;
@@ -1101,6 +1105,8 @@ static void check_devices_mcl()
}
for (l = to_delete; l; l = l->next) {
+ const char *path;
+
path = device_get_path(dev->dev);
g_dbus_unregister_interface(dev->conn, path, HEALTH_DEVICE);
}
diff --git a/health/hdp_util.c b/health/hdp_util.c
index ef76b15..c5dfb01 100644
--- a/health/hdp_util.c
+++ b/health/hdp_util.c
@@ -141,12 +141,14 @@ static gboolean parse_data_type(DBusMessageIter *iter, gpointer data,
GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *value, variant;
+ DBusMessageIter *value;
int ctype;
ctype = dbus_message_iter_get_arg_type(iter);
value = iter;
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -167,13 +169,14 @@ static gboolean parse_data_type(DBusMessageIter *iter, gpointer data,
static gboolean parse_role(DBusMessageIter *iter, gpointer data, GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter value;
DBusMessageIter *string;
int ctype;
const char *role;
ctype = dbus_message_iter_get_arg_type(iter);
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter value;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &value);
ctype = dbus_message_iter_get_arg_type(&value);
@@ -206,12 +209,14 @@ static gboolean parse_role(DBusMessageIter *iter, gpointer data, GError **err)
static gboolean parse_desc(DBusMessageIter *iter, gpointer data, GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *string, variant;
+ DBusMessageIter *string;
int ctype;
const char *desc;
ctype = dbus_message_iter_get_arg_type(iter);
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -234,12 +239,14 @@ static gboolean parse_chan_type(DBusMessageIter *iter, gpointer data,
GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *value, variant;
+ DBusMessageIter *value;
int ctype;
ctype = dbus_message_iter_get_arg_type(iter);
value = iter;
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -294,11 +301,11 @@ fail:
static gboolean is_app_role(GSList *app_list, HdpRole role)
{
- struct hdp_application *app;
GSList *l;
for (l = app_list; l; l = l->next) {
- app = l->data;
+ struct hdp_application *app = l->data;
+
if (app->role == role)
return TRUE;
}
@@ -732,7 +739,7 @@ static gboolean check_role(uint8_t rec_role, uint8_t app_role)
static gboolean get_mdep_from_rec(const sdp_record_t *rec, uint8_t role,
uint16_t d_type, uint8_t *mdep, char **desc)
{
- sdp_data_t *list, *feat, *data_type, *mdepid, *role_t, *desc_t;
+ sdp_data_t *list, *feat;
if (!desc && !mdep)
return TRUE;
@@ -744,6 +751,8 @@ static gboolean get_mdep_from_rec(const sdp_record_t *rec, uint8_t role,
return FALSE;
for (feat = list->val.dataseq; feat; feat = feat->next) {
+ sdp_data_t *data_type, *mdepid, *role_t, *desc_t;
+
if (feat->dtd != SDP_SEQ8 && feat->dtd != SDP_SEQ16 &&
feat->dtd != SDP_SEQ32)
continue;
@@ -931,10 +940,9 @@ static gboolean hdp_get_add_prot_desc_list(const sdp_record_t *rec,
static gboolean get_ccpsm(sdp_list_t *recs, uint16_t *ccpsm)
{
sdp_list_t *l;
- sdp_record_t *rec;
for (l = recs; l; l = l->next) {
- rec = l->data;
+ sdp_record_t *rec = l->data;
if (hdp_get_prot_desc_list(rec, ccpsm, NULL))
return TRUE;
@@ -946,10 +954,9 @@ static gboolean get_ccpsm(sdp_list_t *recs, uint16_t *ccpsm)
static gboolean get_dcpsm(sdp_list_t *recs, uint16_t *dcpsm)
{
sdp_list_t *l;
- sdp_record_t *rec;
for (l = recs; l; l = l->next) {
- rec = l->data;
+ sdp_record_t *rec = l->data;
if (hdp_get_add_prot_desc_list(rec, dcpsm))
return TRUE;
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix X-IRMC-CALL-DATETIME format
From: Luiz Augusto von Dentz @ 2010-10-13 13:15 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Use the format suggested in the spec:
"For instance, a call that was missed on March 20th, 2005 at 10 am would
be stamped: X-IRMC-CALL-DATETIME;MISSED:20050320T100000"
---
plugins/phonebook-tracker.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index d0cea2e..39e4c81 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -705,7 +705,7 @@ static char *iso8601_utc_to_localtime(const char *datetime)
memset(&tm, 0, sizeof(tm));
- nr = sscanf(datetime, "%04u-%02u-%02uT%02u:%02u:%02u%c",
+ nr = sscanf(datetime, "%04u%02u%02uT%02u%02u%02u%c",
&tm.tm_year, &tm.tm_mon, &tm.tm_mday,
&tm.tm_hour, &tm.tm_min, &tm.tm_sec,
&tz);
@@ -726,7 +726,7 @@ static char *iso8601_utc_to_localtime(const char *datetime)
local = localtime(&time);
- strftime(localdate, sizeof(localdate), "%Y-%m-%dT%H:%M:%S", local);
+ strftime(localdate, sizeof(localdate), "%Y%m%dT%H%M%S", local);
return g_strdup(localdate);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] Adjust mce_bt_set flag to gboolean type values
From: Rafal Michalski @ 2010-10-13 13:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
This patch makes assignment to mce_bt_set flag more readable and makes
sure that it takes only TRUE or FALSE value from gboolean type.
---
plugins/maemo6.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/plugins/maemo6.c b/plugins/maemo6.c
index c396db0..0a1e551 100644
--- a/plugins/maemo6.c
+++ b/plugins/maemo6.c
@@ -71,7 +71,8 @@ static gboolean mce_signal_callback(DBusConnection *connection,
/* set the adapter according to the mce signal
and remember the value */
- mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH);
+ mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH ?
+ TRUE : FALSE;
if (mce_bt_set)
btd_adapter_switch_online(adapter);
@@ -111,7 +112,7 @@ static void read_radio_states_cb(DBusPendingCall *call, void *user_data)
DBG("radio_states: %d", radio_states);
- mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH;
+ mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH ? TRUE : FALSE;
/* check if the adapter has not completed the initial power
* cycle, if so delay action to mce_notify_powered */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] gdbus: fix not handling bus disconnects
From: Marcel Holtmann @ 2010-10-13 12:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286971606-11790-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
> We where not dispatching data when a bus disconnects which cause
> Disconnected signal to not be processed and thus causing the process to
> either not exit or to not trigger callbacks registered with
> g_dbus_set_disconnect_function.
>
> To fix this now we always schedule a dispatch which will make sure data
> still not processed will make its way to the proper handlers even if
> disconnected.
this looks fine to me. Went ahead and applied to all repositories.
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox