* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-27 1:01 UTC (permalink / raw)
To: Mike Tsai; +Cc: BlueZ development
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F84405C72@SC1EXMB-MBCL.global.atheros.com>
Hi Mike,
On Tue, Oct 26, 2010 at 6:10 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
> [Mike Tsai]
> Hi Claudio,
>
> I look at the API and it is well-defined with high level of abstraction. However, I did have a few questions here, hopefully you can answer them,
>
> On Client side:
>
> 1. I see you didn't offer any service discovery API for client to discover the server service database (basically to get the attribute handles). So I assume that you consider GATT discovery procedure works the same way as SDP, done automatically by GATT after link is established without application's initiative. Am I correct?
>
> 2. The characteristic descriptor set via SetProperty API is limited to the 6 characteristic descriptors defined in GATT spec. However, there could be profile specific characteristic descriptors beyond these, will the SetProperty able to support these?
>
> 3. The characteristic monitoring is set up via 128 bits UUID. Do you have mechanism to handle duplicated characteristic within a server's database? How do you identify them via your API?
>
>
> On Server side:
>
> 1. Is there an API that allows server application to register new attributes? (primary service, characteristic, included service, et al),
>
> Regards,
>
> Mike
Client side:
Yes. ALL characteristics are fetched after "create the device"
procedure. This approach is wrong, some characteristics requires
encryption, authentication or authorization. Another aspect is that we
need to avoid excessive transactions. The idea now is try to search
for the primary service information only and "probe" the clients that
match with the registered service UUID. When "probed" the clients will
receive the GAttrib instance and the primary service handles range. It
is up to them to decide which attributes are relevant. Note that the
clients are only another "layer" implementing profile specific
features inside BlueZ.
It is a little bit unclear to me at the moment, but we can expose
Profile specific features. Such as threshold, alert level, ...
Is it allowed duplicated UUIDs for the same primary service? We are
not handling this right now.
It seems that you already have a proprietary implementation ;-)
Server side:
No API. We wrote an attribute server for testing purpose only. But we
will address this soon.
Regards,
Claudio
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-26 21:10 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTinnjXuAOBTY8VZz756VdrDFv0-OVKPNkwWbxi9-@mail.gmail.com>
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENsYXVkaW8gVGFrYWhhc2kgW21haWx0
bzpjbGF1ZGlvLnRha2FoYXNpQG9wZW5ib3NzYS5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVy
IDI1LCAyMDEwIDExOjU1IEFNDQpUbzogTWlrZSBUc2FpDQpDYzogQmx1ZVogZGV2ZWxvcG1lbnQN
ClN1YmplY3Q6IFJlOiBbUkZDXSBMRSBjb25uZWN0aW9ucyBhbmQgYWR2ZXJ0aXNpbmcgbWFuYWdl
bWVudA0KDQpPbiBNb24sIE9jdCAyNSwgMjAxMCBhdCAzOjE2IFBNLCBNaWtlIFRzYWkgPE1pa2Uu
VHNhaUBhdGhlcm9zLmNvbT4gd3JvdGU6DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IENsYXVkaW8gVGFrYWhhc2kgW21haWx0bzpjbGF1ZGlvLnRha2FoYXNpQG9w
ZW5ib3NzYS5vcmddDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCAxMDo1NiBBTQ0K
PiBUbzogTWlrZSBUc2FpDQo+IENjOiBCbHVlWiBkZXZlbG9wbWVudA0KPiBTdWJqZWN0OiBSZTog
W1JGQ10gTEUgY29ubmVjdGlvbnMgYW5kIGFkdmVydGlzaW5nIG1hbmFnZW1lbnQNCj4NCj4gT24g
TW9uLCBPY3QgMjUsIDIwMTAgYXQgMjoxMSBQTSwgTWlrZSBUc2FpIDxNaWtlLlRzYWlAYXRoZXJv
cy5jb20+IHdyb3RlOg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t
OiBsaW51eC1ibHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1
ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIENsYXVkaW8gVGFrYWhh
c2kNCj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCA1OjUzIEFNDQo+PiBUbzogQmx1
ZVogZGV2ZWxvcG1lbnQNCj4+IFN1YmplY3Q6IFtSRkNdIExFIGNvbm5lY3Rpb25zIGFuZCBhZHZl
cnRpc2luZyBtYW5hZ2VtZW50DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IEludGVybGVhdmUgQlIv
RURSL0xFIGRpc2NvdmVyeSBpcyBpbXBsZW1lbnRlZCwgdGhlIG5leHQgc3RlcCBpbiB0aGUNCj4+
IHVzZXIgc3BhY2UgaXMgaG93IHRvIG1hbmFnZSBhZHZlcnRpc2luZyBhbmQgTEUgY29ubmVjdGlv
bnMuDQo+Pg0KPj4gU29tZSBhc3BlY3RzOg0KPj4gMS4gT25seSBvbmUgTEUgY29ubmVjdGlvbiBp
cyBhbGxvd2VkKHBlciBwZWVyKSwgbWVhbmluZyBvbmx5IG9uZQ0KPj4gR0F0dHJpYiBpbnN0YW5j
ZSB3aWxsIGJlIGFsbG93ZWQgb3RoZXJ3aXNlIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvDQo+
PiBzZXJpYWxpemUgY29tbWFuZHMvZXZlbnRzDQo+PiAyLiBUaGUgcmVtb3RlL1BlcmlwaGVyYWwg
Y2FuIHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBHQVRUIHByaW1hcnkgc2VydmljZQ0KPj4gMy4gV2Ug
YXJlIHBsYW5uaW5nIHRvIHVzZSAiZGlyZWN0IiBjb25uZWN0aW9ucyBvbmx5LCBtZWFuaW5nIHRo
YXQgd2UNCj4+IHdpbGwgbm90IHVzZSB3aGl0ZWxpc3QgYW5kIHRoZSBhcHBsaWNhdGlvbiBpbnRl
cmVzdGVkIG11c3QgaW5mb3JtIHRoZQ0KPj4gcmVtb3RlIGFkZHJlc3Mvb2JqZWN0IHRvIGNvbm5l
Y3QgdG8uDQo+PiA0LiBLZXJuZWwgbWFuYWdlcyB0aGUgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50
LCBjdXJyZW50bHkgdGhlcmUgaXNuJ3QNCj4+IGEgwqB3YXkgdG8gY2hhbmdlIHRoZSBjb25uZWN0
aW9uIHBhcmFtZXRlcnMuIEJNSSBvciBpb2N0bHMgd2lsbCBiZQ0KPj4gcmVxdWlyZWQgdG8gY2hh
bmdlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgYW5kIGFsc28gdG8gdHJpZ2dlciBTTVANCj4+IG5l
Z290aWF0aW9uLg0KPj4NCj4+DQo+PiBTb21lIGlkZWFzOg0KPj4gMS4gaW1wbGVtZW50IGEgY2hh
cmFjdGVyaXN0aWMgZHJpdmVyOiBiYXNpY2FsbHkgdG8gcHJvdmlkZSBhbg0KPj4gYWJzdHJhY3Rp
b24gdG8gR0FUVCBjbGllbnRzLiBleDogUHJveGltaXR5LCBIZWFsdGgsIC4uLg0KPj4gMi4gV2Ug
ZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgUHJveGltaXR5IGFuZCBvdGhlciBHQVRUIGNsaWVudHMg
YXMgYQ0KPj4gcGx1Z2luIGF0IHRoZSBtb21lbnQsIGl0IGNhbiBiZSBlbmFibGVkIGF1dG9tYXRp
Y2FsbHkgYnkNCj4+IC0tZW5hYmxlLWF0dHJpYg0KPj4gMy4gR0FUVCBjbGllbnRzIGNvdWxkIHJl
Z2lzdGVyIGEgd2F0Y2hlci9maWx0ZXIgZm9yIGFkdmVydGlzaW5nIGV2ZW50cw0KPj4gNC4gR0FU
VCBjbGllbnRzIGRvZXNuJ3QgbmVlZCB0byBrbm93IEFUVCwgaW4gdGhlb3J5IGl0IGNhbiBoYW5k
bGUNCj4+IGNoYXJhY3RlcmlzdGljcyBvbmx5DQo+PiA1LiBHQVRUIGNsaWVudHMgbmVlZHMgdG8g
Y29udHJvbC9yZXF1ZXN0IExFIGNvbm5lY3Rpb25zIGJhc2VkIG9uIHRoZQ0KPj4gYWR2ZXJ0aXNl
bWVudCByZWNlaXZlZA0KPj4NCj4+IEFuIGluaXRpYWwgZHJhZnQgaW1wbGVtZW50aW5nIHBhcnQg
b2YgdGhpcyBpZGVhIGlzIGhlcmU6DQo+PiBnaXQ6Ly9naXQuaW5mcmFkZWFkLm9yZy91c2Vycy9j
a3Rha2FoYXNpL2JsdWV6LmdpdCBkZXZlbA0KPj4NCj4+IENvbW1lbnRzPw0KPj4NCj4+IFJlZ2Fy
ZHMsDQo+PiBDbGF1ZGlvDQo+Pj4+TVQgY29tbWVudHMsDQo+Pg0KPj4gMS4gT25seSBvbmUgTEUg
Y29ubmVjdGlvbiBpcyBhbGxvd2VkKHBlciBwZWVyKSwgbWVhbmluZyBvbmx5IG9uZQ0KPj4gR0F0
dHJpYiBpbnN0YW5jZSB3aWxsIGJlIGFsbG93ZWQgb3RoZXJ3aXNlIGl0IHdpbGwgbm90IGJlIHBv
c3NpYmxlIHRvDQo+PiBzZXJpYWxpemUgY29tbWFuZHMvZXZlbnRzDQo+Pg0KPj4+PiBZb3UgbWVh
biB0aGUgbWFzdGVyIChvciBjbGllbnQpIGNhbiBvbmx5IGNvbm5lY3QgdG8gMSBzbGF2ZSAob3Ig
c2VydmVyKSBvciBhIHNsYXZlIGNhbiBvbmx5IGNvbm5lY3QgdG8gMSBtYXN0ZXI/DQo+IFtDbGF1
ZGlvIFRha2FoYXNpXQ0KPiBUaGUgbWFzdGVyIGNhbiBiZSBjb25uZWN0ZWQgdG8gbW9yZSB0aGFu
IG9uZSBzbGF2ZS4gQnV0IGhlcmUsIEkgd2FubmENCj4gZW1waGFzaXplIHRoYXQgb25seSBvbmUg
aW5zdGFuY2Ugb2YgR0F0dHRyaWIgc2hhbGwgYmUgY3JlYXRlZCB0bw0KPiByZXByZXNlbnQgdGhl
IHBoeXNpY2FsIGNoYW5uZWwgYmV0d2VlbiB0d28gTEUgY2FwYWJsZSBkZXZpY2VzLiBHQXR0cmli
DQo+IGlzIHRoZSBhYnN0cmFjdGlvbiB0aGF0IHdlIGNyZWF0ZWQgaW4gQmx1ZVogdG8gcmVwcmVz
ZW50IHRoZSBHQVRUL0FUVA0KPiBjb25uZWN0aW9uLCBpdCBpcyBuZWNlc3NhcnkgdG8gYWRkcmVz
cyBtdWx0aXBsZSBhcHBsaWNhdGlvbnMvcHJvZmlsZXMNCj4gYW5kIHF1ZXVlIGNvbW1hbmRzL2V2
ZW50cy4NCj4gW01pa2UgVHNhaV0NCj4gSSBzZWUuIEluIG9yZGVyIHRvIGhhbmRsZSBtdWx0aXBs
ZSBwcm9maWxlcyAoYXMgbXVsdGlwbGUgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdG9wIG9mIHRo
ZSBHQXR0cmliKSBpbiBhIHNpbmdsZSBwaHlzaWNhbCBsaW5rLCB5b3Ugd2lsbCBuZWVkIHNvbWV0
aGluZyBsaWtlICJhcHBsaWNhdGlvbiBoYW5kbGUiIHRvIGRpc3BhdGNoIHRoZSByZXNwb25zZS9p
ZGVudGlmaWNhdGlvbiB0byB0aGUgYXBwcm9wcmlhdGUgYXBwbGljYXRpb24gY29ycmVjdGx5Lg0K
PiBNYXkgeW91IHJlZmVyIG1lIHRvIHRoZSBBUEkgZG9jdW1lbnQgdGhhdCB5b3UgYXJlIG9wZW5p
bmcgdG8gdGhlIEdBVFQgY2xpZW50KHMpIGZyb20gdGhpcyBHQXR0cmliPw0KW0NsYXVkaW8gVGFr
YWhhc2ldDQpIaSBNaWtlLA0KDQpBdCB0aGUgbW9tZW50IGl0IGlzIG5vdCBjbGVhciB0byBtZSBp
ZiBhbiAiYXBwbGljYXRpb24gaGFuZGxlIiB3aWxsIGJlDQpuZWVkZWQsIG1heWJlIHdlIGNhbiBh
bHNvIGhpZGUgaXQgZnJvbSB0aGUgaGlnaGVyIGxheWVycy4gQWxsIHJlcXVlc3RzDQphcmUgc2Vy
aWFsaXplZCBhbmQgZm9yIGVhY2ggcmVxdWVzdCB0aGVyZSBpcyBhIHJlc3BvbnNlLCB0aGUNCmV4
Y2VwdGlvbnMgYXJlIHdyaXRlIHdpdGhvdXQgcmVzcG9uc2UgYW5kIG5vdGlmaWNhdGlvbi4gRWFj
aCBwcmltYXJ5DQpzZXJ2aWNlIHJlcHJlc2VudGF0aW9uIHdpbGwgaGF2ZSBhbiBvYmplY3QgcGF0
aCwgbWVhbmluZyB0aGF0IG1heWJlIGl0DQppcyBwb3NzaWJsZSBmb3J3YXJkIHRoZSByZXNwb25z
ZSB0byB0aGUgcmlnaHQgc291cmNlIGJhc2VkIG9uIHRoZSBsYXN0DQpyZXF1ZXN0IGFuZCBoYW5k
bGUgaW5mb3JtYXRpb24uDQoNCkdBdHRyaWIgd2lsbCBub3QgYmUgZXhwb3NlZCB0byB0aGUgVUku
IFVJIG5lZWRzIHRvIGFjY2VzcyBCbHVlWiBHQVRUDQpjbGllbnRzIHNlcnZpY2VzIHVzaW5nIEQt
QnVzLg0KR0FUVCBjbGllbnRzIGluIGdlbmVyYWwgd2lsbCBoYXZlIHR3byBwaWVjZXM6DQogMS0g
VUk6IFF0LCBHVEssIHB5dGhvbiwgLi4uDQogMi0gIm1vZHVsZSIgaW4gdGhlIEJsdWVaIGZvciBw
cm9maWxlIHNwZWNpZmljIHRhc2tzIGFuZCBELUJ1cyBzZXJ2aWNlDQppbnRlcmZhY2UuDQoNCllv
dSBjYW4gZmluZCB0aGUgY3VycmVudCBhdHRyaWJ1dGUgQVBJIGluIHRoZSBmaWxlOiBkb2MvYXR0
cmlidXRlLWFwaS50eHQNCg0KQ2xhdWRpbw0KDQpbTWlrZSBUc2FpXQ0KSGkgQ2xhdWRpbywNCg0K
CUkgbG9vayBhdCB0aGUgQVBJIGFuZCBpdCBpcyB3ZWxsLWRlZmluZWQgd2l0aCBoaWdoIGxldmVs
IG9mIGFic3RyYWN0aW9uLiBIb3dldmVyLCBJIGRpZCBoYXZlIGEgZmV3IHF1ZXN0aW9ucyBoZXJl
LCBob3BlZnVsbHkgeW91IGNhbiBhbnN3ZXIgdGhlbSwNCg0KCU9uIENsaWVudCBzaWRlOg0KDQoJ
CTEuIEkgc2VlIHlvdSBkaWRuJ3Qgb2ZmZXIgYW55IHNlcnZpY2UgZGlzY292ZXJ5IEFQSSBmb3Ig
Y2xpZW50IHRvIGRpc2NvdmVyIHRoZSBzZXJ2ZXIgc2VydmljZSBkYXRhYmFzZSAoYmFzaWNhbGx5
IHRvIGdldCB0aGUgYXR0cmlidXRlIGhhbmRsZXMpLiBTbyBJIGFzc3VtZSB0aGF0IHlvdSBjb25z
aWRlciBHQVRUIGRpc2NvdmVyeSBwcm9jZWR1cmUgd29ya3MgdGhlIHNhbWUgd2F5IGFzIFNEUCwg
ZG9uZSBhdXRvbWF0aWNhbGx5IGJ5IEdBVFQgYWZ0ZXIgbGluayBpcyBlc3RhYmxpc2hlZCB3aXRo
b3V0IGFwcGxpY2F0aW9uJ3MgaW5pdGlhdGl2ZS4gQW0gSSBjb3JyZWN0Pw0KDQoJCTIuIFRoZSBj
aGFyYWN0ZXJpc3RpYyBkZXNjcmlwdG9yIHNldCB2aWEgU2V0UHJvcGVydHkgQVBJIGlzIGxpbWl0
ZWQgdG8gdGhlIDYgY2hhcmFjdGVyaXN0aWMgZGVzY3JpcHRvcnMgZGVmaW5lZCBpbiBHQVRUIHNw
ZWMuIEhvd2V2ZXIsIHRoZXJlIGNvdWxkIGJlIHByb2ZpbGUgc3BlY2lmaWMgY2hhcmFjdGVyaXN0
aWMgZGVzY3JpcHRvcnMgYmV5b25kIHRoZXNlLCB3aWxsIHRoZSBTZXRQcm9wZXJ0eSBhYmxlIHRv
IHN1cHBvcnQgdGhlc2U/DQoNCgkJMy4gVGhlIGNoYXJhY3RlcmlzdGljIG1vbml0b3JpbmcgaXMg
c2V0IHVwIHZpYSAxMjggYml0cyBVVUlELiBEbyB5b3UgaGF2ZSBtZWNoYW5pc20gdG8gaGFuZGxl
IGR1cGxpY2F0ZWQgY2hhcmFjdGVyaXN0aWMgd2l0aGluIGEgc2VydmVyJ3MgZGF0YWJhc2U/IEhv
dyBkbyB5b3UgaWRlbnRpZnkgdGhlbSB2aWEgeW91ciBBUEk/DQoNCg0KCU9uIFNlcnZlciBzaWRl
Og0KDQoJCTEuIElzIHRoZXJlIGFuIEFQSSB0aGF0IGFsbG93cyBzZXJ2ZXIgYXBwbGljYXRpb24g
dG8gcmVnaXN0ZXIgbmV3IGF0dHJpYnV0ZXM/IChwcmltYXJ5IHNlcnZpY2UsIGNoYXJhY3Rlcmlz
dGljLCBpbmNsdWRlZCBzZXJ2aWNlLCBldCBhbCksDQoNClJlZ2FyZHMsDQoNCk1pa2UNCg0KDQo+
DQo+Pg0KPj4gNC4gR0FUVCBjbGllbnRzIGRvZXNuJ3QgbmVlZCB0byBrbm93IEFUVCwgaW4gdGhl
b3J5IGl0IGNhbiBoYW5kbGUNCj4+IGNoYXJhY3RlcmlzdGljcyBvbmx5DQo+Pg0KPj4+PiBZb3Ug
bWVhbiBib3RoIGNoYXJhY3RlcmlzdGljIHZhbHVlIGFuZCBjaGFyYWN0ZXJpc3RpYyBkZXNjcmlw
dG9ycyBvZiBjaGFyYWN0ZXJpc3RpYz8NCj4gW0NsYXVkaW8gVGFrYWhhc2ldDQo+IEJvdGguIEZv
ciB0aGUgR0FUVCBjbGllbnQgcm9sZSwgYW4gaW50ZXJmYWNlIGNhbiBiZSBjcmVhdGVkIGV4cG9y
dGluZw0KPiBwcm9maWxlIHNwZWNpZmljIGRldGFpbHMuDQo+IFNvbWV0aW1lcyBHQVRUIGNsaWVu
dHMgd2lsbCBhbHNvIG5lZWQgdG8gYWNjZXNzIHNvbWUgbG93IGxldmVsIGluZm9ybWF0aW9uLg0K
PiBbTWlrZSBUc2FpXQ0KPiBZZXMsIEkgd2lsbCByZWFsbHkgYXBwcmVjaWF0ZSBpZiB5b3UgbWF5
IHNob3cgbWUgdGhlIHBsYW5uZWQgQVBJIGZvciB0aGlzIEdBdHRyaWIsDQo+DQo+DQo+IFJlZ2Fy
ZHMsDQo+IENsYXVkaW8NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IE1pa2UNCj4+DQo+PiAtLQ0K
Pj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2Ny
aWJlIGxpbnV4LWJsdWV0b290aCIgaW4NCj4+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpv
cmRvbW9Admdlci5rZXJuZWwub3JnDQo+PiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDov
L3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+Pg0KPg0KDQoNCg0KLS0gDQot
LQ0KQ2xhdWRpbyBUYWthaGFzaQ0KSW5zdGl0dXRvIE5va2lhIGRlIFRlY25vbG9naWENClJlY2lm
ZSAtIFBlcm5hbWJ1Y28gLSBCcmFzaWwNCis1NSA4MSAzMDg3OTk5OQ0K
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Brian Redding @ 2010-10-26 20:26 UTC (permalink / raw)
To: 'Claudio Takahasi'; +Cc: 'BlueZ development'
In-Reply-To: <AANLkTimTgRV=Ang1JFQpOKXc0bVA6PSOA8WAUo4B7_Wv@mail.gmail.com>
> -----Original Message-----
> From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
> Sent: Monday, October 25, 2010 9:52 PM
>
> Hi Brian,
>
> On Mon, Oct 25, 2010 at 4:27 PM, Brian Redding
> <bredding@codeaurora.org> wrote:
> > Hi Claudio,
> >
> > Are there still interfaces that need to be added to attribute-api.txt
> > to handle client and server characteristic configuration as well as
> > presentation and aggregate formats? I see those as TODO items but
> > wondered if the APIs for them have been defined yet.
> >
> > One thing to note on the server API is that a GATT-based profile
> > could specify behavior on a characteristic value that when the
> > characteristic value is read to perform some action in a similar way as
> > a hardware register. It appears that the notes I'm reading in the code
> > thus far only consider changes (or writes) to characteristic values for
> > the watch code.
> >
> > Also does the current API handle included services?
> >
> > The Bluetooth SIG is beginning to look at 3rd party application
> > developer API's for both client and servers for various platforms so
> > understanding what is currently defined in BlueZ and what still needs
> > to be added would be useful.
> >
> > Thanks,
> > Brian
>
> The API to address characteristic descriptors is still being defined.
> We are focusing in the advertising and connection management at the
> moment. If you have suggestion of how to represent the descriptors in
> the attribute API, suggestions are welcome!
Once I feel more comfortable with the current API approach, I will see
if I can suggest something. One thing to note is that GATT only list
the current characteristic descriptors. Profiles can specify additional
ones or a group of generic ones could also be adopted in the future.
One example of this is a characteristic descriptor that defines triggers
that cause a particular behavior to occur when a condition on the characteristic
value occurs.
>
> There isn't a server API at the moment, we implemented a server for
> testing purpose only. But we will need to define it soon.
> Which pages/section of the spec describes this read characteristic
> behavior?
The GATT does not specify the read characteristic behavior but it can be
specified by a profile. I just wanted to point that out so that the design
takes that into account. You may need to have a call back when a characteristic
value is read as well as written.
>
> Included services are not supported by our client. How important is
> it? It is mandatory for qualification?
It is only mandatory on the server.
>
> Regards,
> Claudio.
Cheers,
Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re[4]: 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Ilya Basin @ 2010-10-26 19:02 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20101026141913.GA11973@jh-x301>
Hi Johan. The patch works, many thanks.
^ permalink raw reply
* Re: [PATCH] Fix a2dp play when sample rate changed
From: Johan Hedberg @ 2010-10-26 15:57 UTC (permalink / raw)
To: John Crosbie; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikksLAeocFsM5vO0rnvphgOo_CoF1ZA_wkABY=c@mail.gmail.com>
Hi John,
On Tue, Oct 26, 2010, John Crosbie wrote:
> I have found that playing a 48KHz wav file immediately after playing a
> 44.1K file (or vice-versa) with aplay will fail. After this failure
> no a2dp stream will play. The problem is that after determining the
> current avdtp stream doesn't match the new configuration the stream is
> closed and a reconfiguration is attempted but fails because
> setup->rsep is null. The patch below fixes the reconfiguration.
Thanks for the patch. In the future, please follow the proper coding
style (e.g. space between "if" and "(") and prepare the patches using
git format-patch. I went ahead and did this work manually for you this
time instead of asking you to resend since we're in the process of
preparing the next bluez release.
Johan
^ permalink raw reply
* RE: [PATCH v4] Bluetooth: btwilink driver
From: Savoy, Pavan @ 2010-10-26 15:49 UTC (permalink / raw)
To: Pavan Savoy, padovan@profusion.mobi, marcel@holtmann.org
Cc: linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <AANLkTintn2pFAWP679=fmyEdGzMwZWdqyoG4YCdB_9Y9@mail.gmail.com>
> -----Original Message-----
> From: Pavan Savoy [mailto:pavan_savoy@sify.com]
> Sent: Thursday, October 21, 2010 8:26 AM
> To: padovan@profusion.mobi; marcel@holtmann.org
> Cc: linux-bluetooth@vger.kernel.org; linux-kernel@vger.kernel.org; Savoy,
> Pavan
> Subject: Re: [PATCH v4] Bluetooth: btwilink driver
>
Gustavo, Marcel,
Please review and provide comments.
If it is fine, please pull it in.
>
> On Tue, Oct 19, 2010 at 6:06 PM, <pavan_savoy@ti.com> wrote:
> > From: Pavan Savoy <pavan_savoy@ti.com>
> >
> > v4 comments
> >
> > module init now returns what platform_driver_register returns.
> > type casting of void* private data has been removed
>
> If there are no more critical comments, can it go in?
> Please review.
>
> Thanks,
> Pavan
>
> > v3 comments
> >
> > Lizardo,
> > I have taken care of most of the comments you had.
> > Have re-wrote some of the code commenting you've mentioned.
> > Thanks for the comments,
> >
> > Marcel, Gustavo, & list,
> > Please review this version of patch.
> >
> > The other few like -EPERM for platform driver registration is to keep
> > it similar to other drivers, type casting is maintained just to feel sa=
fe
> > and have style similar to other drivers.
> > BT_WILINK in Kconfig is similar to BT_MRVL.
> > I hope those aren't too critical.
> >
> > -- patch description --
> >
> > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > Texas Instrument's WiLink chipsets combine wireless technologies
> > like BT, FM, GPS and WLAN onto a single chip.
> >
> > This Bluetooth driver works on top of the TI_ST shared transport
> > line discipline driver which also allows other drivers like
> > FM V4L2 and GPS character driver to make use of the same UART interface=
.
> >
> > Kconfig and Makefile modifications to enable the Bluetooth
> > driver for Texas Instrument's WiLink 7 chipset.
> >
> > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > ---
> > drivers/bluetooth/Kconfig | 10 +
> > drivers/bluetooth/Makefile | 1 +
> > drivers/bluetooth/btwilink.c | 411
> ++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 422 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/bluetooth/btwilink.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index 02deef4..8e0de9a 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -219,4 +219,14 @@ config BT_ATH3K
> > Say Y here to compile support for "Atheros firmware download
> driver"
> > into the kernel or say M to compile it as module (ath3k).
> >
> > +config BT_WILINK
> > + tristate "Texas Instruments WiLink7 driver"
> > + depends on TI_ST
> > + help
> > + This enables the Bluetooth driver for Texas Instrument's BT/F=
M/GPS
> > + combo devices. This makes use of shared transport line discip=
line
> > + core driver to communicate with the BT core of the combo chip=
.
> > +
> > + Say Y here to compile support for Texas Instrument's WiLink7
> driver
> > + into the kernel or say M to compile it as module.
> > endmenu
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > index 71bdf13..f4460f4 100644
> > --- a/drivers/bluetooth/Makefile
> > +++ b/drivers/bluetooth/Makefile
> > @@ -18,6 +18,7 @@ obj-$(CONFIG_BT_HCIBTSDIO) +=3D btsdio.o
> > obj-$(CONFIG_BT_ATH3K) +=3D ath3k.o
> > obj-$(CONFIG_BT_MRVL) +=3D btmrvl.o
> > obj-$(CONFIG_BT_MRVL_SDIO) +=3D btmrvl_sdio.o
> > +obj-$(CONFIG_BT_WILINK) +=3D btwilink.o
> >
> > btmrvl-y :=3D btmrvl_main.o
> > btmrvl-$(CONFIG_DEBUG_FS) +=3D btmrvl_debugfs.o
> > diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.=
c
> > new file mode 100644
> > index 0000000..218efd6
> > --- /dev/null
> > +++ b/drivers/bluetooth/btwilink.c
> > @@ -0,0 +1,411 @@
> > +/*
> > + * Texas Instrument's Bluetooth Driver For Shared Transport.
> > + *
> > + * Bluetooth Driver acts as interface between HCI core and
> > + * TI Shared Transport Layer.
> > + *
> > + * Copyright (C) 2009-2010 Texas Instruments
> > + * Author: Raja Mani <raja_mani@ti.com>
> > + * Pavan Savoy <pavan_savoy@ti.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modi=
fy
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * 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-13=
07
> USA
> > + *
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <net/bluetooth/bluetooth.h>
> > +#include <net/bluetooth/hci_core.h>
> > +
> > +#include <linux/ti_wilink_st.h>
> > +
> > +/* Bluetooth Driver Version */
> > +#define VERSION "1.0"
> > +
> > +/* Number of seconds to wait for registration completion
> > + * when ST returns PENDING status.
> > + */
> > +#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
> > +
> > +/**
> > + * struct ti_st - driver operation structure
> > + * @hdev: hci device pointer which binds to bt driver
> > + * @reg_status: ST registration callback status
> > + * @st_write: write function provided by the ST driver
> > + * to be used by the driver during send_frame.
> > + * @wait_reg_completion - completion sync between ti_st_open
> > + * and ti_st_registration_completion_cb.
> > + */
> > +struct ti_st {
> > + struct hci_dev *hdev;
> > + char reg_status;
> > + long (*st_write) (struct sk_buff *);
> > + struct completion wait_reg_completion;
> > +};
> > +
> > +static int reset;
> > +
> > +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> > +static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
> > +{
> > + struct hci_dev *hdev;
> > + hdev =3D hst->hdev;
> > +
> > + /* Update HCI stat counters */
> > + switch (pkt_type) {
> > + case HCI_COMMAND_PKT:
> > + hdev->stat.cmd_tx++;
> > + break;
> > +
> > + case HCI_ACLDATA_PKT:
> > + hdev->stat.acl_tx++;
> > + break;
> > +
> > + case HCI_SCODATA_PKT:
> > + hdev->stat.sco_tx++;
> > + break;
> > + }
> > +}
> > +
> > +/* ------- Interfaces to Shared Transport ------ */
> > +
> > +/* Called by ST layer to indicate protocol registration completion
> > + * status.ti_st_open() function will wait for signal from this
> > + * API when st_register() function returns ST_PENDING.
> > + */
> > +static void st_registration_completion_cb(void *priv_data, char data)
> > +{
> > + struct ti_st *lhst =3D priv_data;
> > +
> > + /* Save registration status for use in ti_st_open() */
> > + lhst->reg_status =3D data;
> > + /* complete the wait in ti_st_open() */
> > + complete(&lhst->wait_reg_completion);
> > +}
> > +
> > +/* Called by Shared Transport layer when receive data is
> > + * available */
> > +static long st_receive(void *priv_data, struct sk_buff *skb)
> > +{
> > + int err;
> > + struct ti_st *lhst =3D priv_data;
> > +
> > + if (!skb)
> > + return -EFAULT;
> > +
> > + if (!lhst) {
> > + kfree_skb(skb);
> > + return -EFAULT;
> > + }
> > +
> > + skb->dev =3D (struct net_device *)lhst->hdev;
> > +
> > + /* Forward skb to HCI core layer */
> > + err =3D hci_recv_frame(skb);
> > + if (err) {
> > + kfree_skb(skb);
> > + BT_ERR("Unable to push skb to HCI core(%d)", err);
> > + return err;
> > + }
> > +
> > + lhst->hdev->stat.byte_rx +=3D skb->len;
> > +
> > + return 0;
> > +}
> > +
> > +/* ------- Interfaces to HCI layer ------ */
> > +/* protocol structure registered with shared transport */
> > +static struct st_proto_s ti_st_proto =3D {
> > + .type =3D ST_BT,
> > + .recv =3D st_receive,
> > + .reg_complete_cb =3D st_registration_completion_cb,
> > + .priv_data =3D NULL,
> > +};
> > +
> > +/* Called from HCI core to initialize the device */
> > +static int ti_st_open(struct hci_dev *hdev)
> > +{
> > + unsigned long timeleft;
> > + struct ti_st *hst;
> > + int err;
> > +
> > + BT_DBG("%s %p", hdev->name, hdev);
> > +
> > + /* provide contexts for callbacks from ST */
> > + hst =3D hdev->driver_data;
> > + ti_st_proto.priv_data =3D hst;
> > +
> > + err =3D st_register(&ti_st_proto);
> > + if (err =3D=3D -EINPROGRESS) {
> > + /* Prepare wait-for-completion handler data structures.
> > + * Needed to synchronize this and
> > + * st_registration_completion_cb() functions.
> > + */
> > + init_completion(&hst->wait_reg_completion);
> > +
> > + /* Reset ST registration callback status flag , this va=
lue
> > + * will be updated in ti_st_registration_completion_cb(=
)
> > + * function whenever it called from ST driver.
> > + */
> > + hst->reg_status =3D -EINPROGRESS;
> > +
> > + /* ST is busy with either protocol registration or firm=
ware
> > + * download. Wait until the registration callback is ca=
lled
> > + */
> > + BT_DBG(" waiting for registration completion signal fro=
m
> ST");
> > +
> > + timeleft =3D wait_for_completion_timeout
> > + (&hst->wait_reg_completion,
> > + msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> > + if (!timeleft) {
> > + BT_ERR("Timeout(%d sec),didn't get reg "
> > + "completion signal from ST",
> > + BT_REGISTER_TIMEOUT / 1000);
> > + return -ETIMEDOUT;
> > + }
> > +
> > + /* Is ST registration callback called with ERROR status=
? */
> > + if (hst->reg_status !=3D 0) {
> > + BT_ERR("ST registration completed with invalid =
"
> > + "status %d", hst->reg_status);
> > + return -EAGAIN;
> > + }
> > + err =3D 0;
> > + } else if (err =3D=3D -EPERM) {
> > + BT_ERR("st_register failed %d", err);
> > + return err;
> > + }
> > +
> > + hst->st_write =3D ti_st_proto.write;
> > + if (!hst->st_write) {
> > + BT_ERR("undefined ST write function");
> > +
> > + /* Undo registration with ST */
> > + err =3D st_unregister(ST_BT);
> > + if (err)
> > + BT_ERR("st_unregister() failed with error %d", =
err);
> > +
> > + hst->st_write =3D NULL;
> > + return err;
> > + }
> > +
> > + /* Registration with ST layer is successful,
> > + * hardware is ready to accept commands from HCI core.
> > + */
> > + set_bit(HCI_RUNNING, &hdev->flags);
> > +
> > + return err;
> > +}
> > +
> > +/* Close device */
> > +static int ti_st_close(struct hci_dev *hdev)
> > +{
> > + int err;
> > + struct ti_st *hst =3D hdev->driver_data;
> > +
> > + /* continue to unregister from transport */
> > + err =3D st_unregister(ST_BT);
> > + if (err)
> > + BT_ERR("st_unregister() failed with error %d", err);
> > +
> > + hst->st_write =3D NULL;
> > +
> > + return err;
> > +}
> > +
> > +static int ti_st_send_frame(struct sk_buff *skb)
> > +{
> > + struct hci_dev *hdev;
> > + struct ti_st *hst;
> > + long len;
> > +
> > + if (!skb)
> > + return -ENOMEM;
> > +
> > + hdev =3D (struct hci_dev *)skb->dev;
> > + if (!hdev)
> > + return -ENODEV;
> > +
> > + if (!test_bit(HCI_RUNNING, &hdev->flags))
> > + return -EBUSY;
> > +
> > + hst =3D hdev->driver_data;
> > +
> > + /* Prepend skb with frame type */
> > + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> > +
> > + BT_DBG(" %s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
> > + skb->len);
> > +
> > + /* Insert skb to shared transport layer's transmit queue.
> > + * Freeing skb memory is taken care in shared transport layer,
> > + * so don't free skb memory here.
> > + */
> > + if (!hst->st_write) {
> > + kfree_skb(skb);
> > + BT_ERR(" Could not write to ST (st_write is NULL)");
> > + return -EAGAIN;
> > + }
> > +
> > + len =3D hst->st_write(skb);
> > + if (len < 0) {
> > + kfree_skb(skb);
> > + BT_ERR(" ST write failed (%ld)", len);
> > + return -EAGAIN;
> > + }
> > +
> > + /* ST accepted our skb. So, Go ahead and do rest */
> > + hdev->stat.byte_tx +=3D len;
> > + ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> > +
> > + return 0;
> > +}
> > +
> > +static void ti_st_destruct(struct hci_dev *hdev)
> > +{
> > + if (!hdev)
> > + return;
> > +
> > + BT_DBG("%s", hdev->name);
> > +
> > + /* free ti_st memory */
> > + kfree(hdev->driver_data);
> > +
> > + return;
> > +}
> > +
> > +/* Creates new HCI device */
> > +static int ti_st_register_dev(struct ti_st *hst)
> > +{
> > + int err;
> > + struct hci_dev *hdev;
> > +
> > + /* Initialize and register HCI device */
> > + hdev =3D hci_alloc_dev();
> > + if (!hdev)
> > + return -ENOMEM;
> > +
> > + BT_DBG("hdev %p", hdev);
> > +
> > + hst->hdev =3D hdev;
> > + hdev->bus =3D HCI_UART;
> > + hdev->driver_data =3D hst;
> > + hdev->open =3D ti_st_open;
> > + hdev->close =3D ti_st_close;
> > + hdev->flush =3D NULL;
> > + hdev->send =3D ti_st_send_frame;
> > + hdev->destruct =3D ti_st_destruct;
> > + hdev->owner =3D THIS_MODULE;
> > +
> > + if (reset)
> > + set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
> > +
> > + err =3D hci_register_dev(hdev);
> > + if (err < 0) {
> > + BT_ERR("Can't register HCI device error %d", err);
> > + hci_free_dev(hdev);
> > + return err;
> > + }
> > +
> > + BT_DBG(" HCI device registered (hdev %p)", hdev);
> > + return 0;
> > +}
> > +
> > +
> > +static int bt_ti_probe(struct platform_device *pdev)
> > +{
> > + int err;
> > + static struct ti_st *hst;
> > +
> > + BT_DBG(" Bluetooth Driver Version %s", VERSION);
> > +
> > + hst =3D kzalloc(sizeof(struct ti_st), GFP_KERNEL);
> > + if (!hst)
> > + return -ENOMEM;
> > +
> > + /* Expose "hciX" device to user space */
> > + err =3D ti_st_register_dev(hst);
> > + if (err) {
> > + kfree(hst);
> > + return err;
> > + }
> > +
> > + dev_set_drvdata(&pdev->dev, hst);
> > + return err;
> > +}
> > +
> > +static int bt_ti_remove(struct platform_device *pdev)
> > +{
> > + struct ti_st *hst;
> > + struct hci_dev *hdev;
> > +
> > + hst =3D dev_get_drvdata(&pdev->dev);
> > +
> > + if (!hst)
> > + return -EFAULT;
> > +
> > + /* Deallocate local resource's memory */
> > + hdev =3D hst->hdev;
> > +
> > + if (!hdev) {
> > + BT_ERR("Invalid hdev memory");
> > + kfree(hst);
> > + return -EFAULT;
> > + }
> > +
> > + ti_st_close(hdev);
> > + hci_unregister_dev(hdev);
> > + /* Free HCI device memory */
> > + hci_free_dev(hdev);
> > +
> > + return 0;
> > +}
> > +
> > +static struct platform_driver btwilink_driver =3D {
> > + .probe =3D bt_ti_probe,
> > + .remove =3D bt_ti_remove,
> > + .driver =3D {
> > + .name =3D "btwilink",
> > + .owner =3D THIS_MODULE,
> > + },
> > +};
> > +
> > +/* ------- Module Init/Exit interfaces ------ */
> > +static int __init bt_drv_init(void)
> > +{
> > + long ret;
> > +
> > + ret =3D platform_driver_register(&btwilink_driver);
> > + if (ret !=3D 0) {
> > + BT_ERR("btwilink platform driver registration failed");
> > + return ret;
> > + }
> > + return 0;
> > +}
> > +
> > +static void __exit bt_drv_exit(void)
> > +{
> > + platform_driver_unregister(&btwilink_driver);
> > +}
> > +
> > +module_init(bt_drv_init);
> > +module_exit(bt_drv_exit);
> > +
> > +/* ------ Module Info ------ */
> > +
> > +module_param(reset, bool, 0644);
> > +MODULE_PARM_DESC(reset, "Send HCI reset command on initialization");
> > +MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
> > +MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION)=
;
> > +MODULE_VERSION(VERSION);
> > +MODULE_LICENSE("GPL");
> > --
> > 1.6.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetoo=
th"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* [PATCH] Fix a2dp play when sample rate changed
From: John Crosbie @ 2010-10-26 15:32 UTC (permalink / raw)
To: linux-bluetooth
I have found that playing a 48KHz wav file immediately after playing a
44.1K file (or vice-versa) with aplay will fail. After this failure
no a2dp stream will play. The problem is that after determining the
current avdtp stream doesn't match the new configuration the stream is
closed and a reconfiguration is attempted but fails because
setup->rsep is null. The patch below fixes the reconfiguration.
John Crosbie
Excelfore Corporation
diff --git a/audio/a2dp.c b/audio/a2dp.c
index 7a36132..b9b5e4a 100644
--- a/audio/a2dp.c
+++ b/audio/a2dp.c
@@ -1028,6 +1028,12 @@ static gboolean a2dp_reconfigure(gpointer data)
struct a2dp_sep *sep = setup->sep;
int posix_err;
+ if(!setup->rsep)
+ setup->rsep = avdtp_find_remote_sep(setup->session, sep->lsep);
posix_err = avdtp_set_configuration(setup->session, setup->rsep,
sep->lsep,
setup->client_caps,
^ permalink raw reply related
* Re: [PATCH 3/6] Bluetooth: Implement the first SMP commands
From: Luiz Augusto von Dentz @ 2010-10-26 15:22 UTC (permalink / raw)
To: Ville Tervo
Cc: ext Gustavo F. Padovan, Anderson Briglia,
linux-bluetooth@vger.kernel.org, Vinicius Costa Gomes
In-Reply-To: <20101026092623.GC15050@null>
Hi,
On Tue, Oct 26, 2010 at 2:26 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> On Mon, Oct 25, 2010 at 03:03:56PM +0200, ext Gustavo F. Padovan wrote:
>> Hi Vinicius,
>>
>> * Anderson Briglia <anderson.briglia@openbossa.org> [2010-10-22 19:56:57 -0400]:
>>
>> > From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>> >
>> > These simple commands will allow the SMP procedure to be started
>> > and terminated with a not supported error. This is the first step
>> > toward something useful.
>> >
>> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>> > ---
>> > net/bluetooth/l2cap.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
>> > 1 files changed, 117 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> > index 1ac44f4..ba87c84 100644
>> > --- a/net/bluetooth/l2cap.c
>> > +++ b/net/bluetooth/l2cap.c
>> > @@ -54,6 +54,7 @@
>> > #include <net/bluetooth/bluetooth.h>
>> > #include <net/bluetooth/hci_core.h>
>> > #include <net/bluetooth/l2cap.h>
>> > +#include <net/bluetooth/smp.h>
>> >
>> > #define VERSION "2.15"
>> >
>> > @@ -307,6 +308,85 @@ static void l2cap_chan_del(struct sock *sk, int err)
>> > }
>> > }
>> >
>> > +static struct sk_buff *smp_build_cmd(struct l2cap_conn *conn, u8 code,
>> > + u16 dlen, void *data)
>>
>> Call this l2cap_smp_build_cmd()
>
> Should the whole smp stuff be in separate file (smp.c)? It's not a l2cap feature but a
> protocol using l2cap. In that case smp_build_cmd would be good name.
+1
It is also much better for maintenance and development since there is
less patches touching the l2cap.c so less chances of conflicts,
rebases and regressions on l2cap.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Fix cache is invalid on empty listing response
From: Luiz Augusto von Dentz @ 2010-10-26 15:01 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1288082028-10014-1-git-send-email-dmitriy.paliy@nokia.com>
Hi,
On Tue, Oct 26, 2010 at 1:33 AM, Dmitriy Paliy <dmitriy.paliy@nokia.com> wrote:
> Fix cache marked as invalid when no data available in response to get phone
> book listing. This fixes obexd crash in 3-way calling scenario. Cache is
> created when there is second incoming call. If the call is rejected and
> retried again, valid empty cache is sent over obex stream that causes obexd
> crash. With this fix, the stream is aborted in such scenario. A new attempt
> to create cache is carried out on each new subsequent incoming call.
> ---
> plugins/pbap.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/pbap.c b/plugins/pbap.c
> index 11cb678..f7f3897 100644
> --- a/plugins/pbap.c
> +++ b/plugins/pbap.c
> @@ -407,7 +407,11 @@ static void cache_ready_notify(void *user_data)
> (const char *) pbap->params->searchval);
>
> if (sorted == NULL) {
> - pbap->cache.valid = TRUE;
> + /* When no data available from tracker, cache marked as
> + * invalid (new one will be tried to be created next time),
> + * no such file or directory error is set, and obex stream
> + * is aborted */
> + pbap->cache.valid = FALSE;
> obex_object_set_io_flags(pbap, G_IO_ERR, -ENOENT);
> return;
> }
We discussed about this offline and apparently when cache.valid is set
to FALSE it will create a new cache for the next requests so we need
to free the current cache otherwise it will leak.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Fix system crash bug of no send queue protect
From: haijun liu @ 2010-10-26 14:36 UTC (permalink / raw)
To: Haijun Liu; +Cc: linux-bluetooth
In-Reply-To: <1287644956-12602-2-git-send-email-haijun.liu@atheros.com>
Sorry, this patch has been discarded, please look at
[PATCH 1/2 v2] Bluetooth: Fix system crash caused by del_timer()
[PATCH 2/2 v2] Bluetooth: Fix system crash bug of no send queue protect
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Fix system crash caused by del_timer()
From: haijun liu @ 2010-10-26 14:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Haijun Liu, linux-bluetooth
In-Reply-To: <1288103093.3613.21.camel@aeonflux>
Hi Marcel,
>> At UPF37, during test session of bt3.0 with Marvel, found that in
>> l2cap_chan_del() using del_timer() caused l2cap_monitor_timeout()
>> be called after the sock was freed, so it raised a system crash.
>> So I just replaced del_timer() with del_timer_sync() to solve it.
>>
>> Signed-off-by: Haijun Liu <haijun.liu@atheros.com>
>
> looks good to me and if Gustavo agrees, then
>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
Sorry, I should note this patch has been discard, please look at
<[PATCH 1/2 v2] Bluetooth: Fix system crash caused by del_timer() >
<[PATCH 2/2 v2] Bluetooth: Fix system crash bug of no send queue protect>
Thank you.
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Fix system crash caused by del_timer()
From: Marcel Holtmann @ 2010-10-26 14:24 UTC (permalink / raw)
To: Haijun Liu; +Cc: linux-bluetooth
In-Reply-To: <1287644956-12602-1-git-send-email-haijun.liu@atheros.com>
Hi Haijun,
> At UPF37, during test session of bt3.0 with Marvel, found that in
> l2cap_chan_del() using del_timer() caused l2cap_monitor_timeout()
> be called after the sock was freed, so it raised a system crash.
> So I just replaced del_timer() with del_timer_sync() to solve it.
>
> Signed-off-by: Haijun Liu <haijun.liu@atheros.com>
looks good to me and if Gustavo agrees, then
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: Re[2]: 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Johan Hedberg @ 2010-10-26 14:19 UTC (permalink / raw)
To: Ilya Basin; +Cc: linux-bluetooth
In-Reply-To: <1602793498.20101026170445@gmail.com>
Hi Ilya,
On Tue, Oct 26, 2010, Ilya Basin wrote:
> JH> have all debug symbols enabled. Could you try to reproduce this with
> JH> latest bluez git. You don't need to install anything but just compile
>
> segfaults start after this commit:
> [d5e700051b1263b2028331d41d60de02a5a6f90e] Fix append_variant_array()
> to take a number of elements
>
> Not every BT program kills bluetoothd, but Smartcam does.
> http://sourceforge.net/projects/smartcam/
> [il@IL bluez]$ smartcam
> smartcam: registered DBUS service "org.gnome.smartcam"
> Found smartcam device file: /dev/video0
> smartcam: started comm thread
> smartcam: port = 1
> sdp_record_register: Protocol error
Thanks for the info. This program seems to add a somehow malformed
service record which is the cause of the crash. Before the patch you
pointed out a NULL pointer was used to detect the end of a pointer array
and so bt_uuid2string() returning NULL for this service record didn't
cause any bad behavior (since the code just stopped iterating a pointer
array after this). However after the patch the code uses an explicit
integer value for the list length and would try to dereference the NULL
pointer in the middle of the list.
I've now pushed a patch to git which should fix this:
http://git.kernel.org/?p=bluetooth/bluez.git;a=commitdiff;h=e31d21c7f238352893a365ab50642707c44087cd
Please do a git pull and see if it really fixes the issue for you.
Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Add separate queries for listing size in PBAP
From: Johan Hedberg @ 2010-10-26 14:07 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1288081792-15296-2-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Tue, Oct 26, 2010, Radoslaw Jablonski wrote:
> Previosly to get phonebook-size or call history size, full phonebook
> query was used and a lot of unnecessary operations need to be done on
> that returned data. Now separate query is used to get size of each
> listing so performance for "getPhonebookSize" operations improved a lot.
> ---
> plugins/phonebook-tracker.c | 105 ++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 103 insertions(+), 2 deletions(-)
Both patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Add separate queries for listing size in PBAP
From: Radoslaw Jablonski @ 2010-10-26 13:54 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1288078932-9547-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi,
On 10/26/2010 10:42 AM, Radoslaw Jablonski wrote:
> "nmo:to ?c ." \
> + "}"
> +
> +
> +#define COMBINED_CALLS_COUNT_QUERY \
> + "SELECT COUNT(?call) WHERE {" \
> + "{" \
>
Please ignore this patch.
I've noticed after sending that has unneeded 2 empty lines instead of
one between these queries.
I resend new version of this patch - so new version of this is the
correct one.
BR,
Radek
^ permalink raw reply
* Re: [RFC] SMP initial draft
From: Anderson Briglia @ 2010-10-26 13:48 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20101026093808.GE15050@null>
On 10/26/2010 05:38 AM, Ville Tervo wrote:
> Hi,
>
> On Sat, Oct 23, 2010 at 01:56:54AM +0200, ext Anderson Briglia wrote:
>
>> This RFC is about Security Manager Protocol (SMP).
>> Basically this patchset implements the initial negotiation over L2CAP and LE
>> connections between a Master and a Slave. TK and STK keys are not being generated
>> and/or exchanged yet, do not expect real encryption/decryption by now.
>> Actually, our next tasks are related to integrate current implementation and
>> Criptographic Toolbox ah, c1 and s1 functions for TK and STK key generation for
>> Just Works SMP pairing method.
>>
> I think some kind of mechanism to start encryption on already existing
> connection is needed. It depends on attribute if security is needed or not. One
> might read unsecure attributes and then needs to start encryption because it
> wants to read encrypted attribute.
>
> Is that already planned somehow?
>
Not yet. After we get the SMP keys generation and exchange working we
could start working on it.
>
>> To test this RFC you need to have the Ville Tervo[1] kernel tree with LE connection
>> patches. Of course you need LE devices and bluez git tree (master branch). Just run
>> the bluetoothd and try to list the primary services using gatttool over an LE channel.
>> eg.: gatttool --primary --le -i hci0 -b 00:17:E7:DD:08:FF
>>
> I guess I should take patches which are fixing plain LE (2/6) and (5/6)
> connection to my tree alread. How it sounds to you?
>
I think this is ok. Just update your kernel tree and we could make a
rebase here and separate the "pure" SMP patches on top of your patches.
>
>> Comments are welcome.
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/vtervo/bluetooth-le-2.6.git
>>
>> [PATCH 1/6] Bluetooth: Add SMP command structures
>> [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
>> [PATCH 3/6] Bluetooth: Implement the first SMP commands
>> [PATCH 4/6] Bluetooth: Start SMP procedure
>> [PATCH 5/6] Bluetooth: Fix initiated LE connections
>> [PATCH 6/6] Bluetooth: simple SMP pairing negotiation
>> --
>> 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[2]: 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Ilya Basin @ 2010-10-26 13:04 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20101025204015.GA19748@jh-x301>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
JH> have all debug symbols enabled. Could you try to reproduce this with
JH> latest bluez git. You don't need to install anything but just compile
segfaults start after this commit:
[d5e700051b1263b2028331d41d60de02a5a6f90e] Fix append_variant_array()
to take a number of elements
Not every BT program kills bluetoothd, but Smartcam does.
http://sourceforge.net/projects/smartcam/
[il@IL bluez]$ smartcam
smartcam: registered DBUS service "org.gnome.smartcam"
Found smartcam device file: /dev/video0
smartcam: started comm thread
smartcam: port = 1
sdp_record_register: Protocol error
--
[-- Attachment #2: gdb-new.txt --]
[-- Type: TEXT/PLAIN, Size: 20150 bytes --]
[root@IL bluez]# gdb --args ./src/.libs/bluetoothd -nd
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /.snapshots/persist/builds/bluez-git/bluez/src/.libs/bluetoothd...done.
(gdb) r
Starting program: /.snapshots/persist/builds/bluez-git/bluez/src/.libs/bluetoothd -nd
[Thread debugging using libthread_db enabled]
bluetoothd[5329]: Bluetooth deamon 4.76
bluetoothd[5329]: src/main.c:parse_config() parsing main.conf
bluetoothd[5329]: src/main.c:parse_config() discovto=0
bluetoothd[5329]: src/main.c:parse_config() pairto=0
bluetoothd[5329]: src/main.c:parse_config() pageto=8192
bluetoothd[5329]: src/main.c:parse_config() name=%h-%d
bluetoothd[5329]: src/main.c:parse_config() class=0x000100
bluetoothd[5329]: src/main.c:parse_config() discov_interval=0
bluetoothd[5329]: src/main.c:parse_config() Key file does not have key 'DeviceID'
bluetoothd[5329]: Starting SDP server
bluetoothd[5329]: src/plugin.c:plugin_init() Loading builtin plugins
bluetoothd[5329]: src/plugin.c:add_plugin() Loading audio plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading input plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading serial plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading network plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading service plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading hciops plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading formfactor plugin
bluetoothd[5329]: src/plugin.c:add_plugin() Loading storage plugin
bluetoothd[5329]: src/plugin.c:plugin_init() Loading plugins /usr/lib/bluetooth/plugins
bluetoothd[5329]: Version mismatch for netlink
bluetoothd[5329]: plugins/service.c:register_interface() path /org/bluez/5329/any
bluetoothd[5329]: plugins/service.c:register_interface() Registered interface org.bluez.Service on path /org/bluez/5329/any
bluetoothd[5329]: network/manager.c:read_config() /etc/bluetooth/network.conf: Key file does not have key 'DisableSecurity'
bluetoothd[5329]: network/manager.c:read_config() Config options: Security=true
bluetoothd[5329]: input/manager.c:input_manager_init() input.conf: Key file does not have key 'IdleTimeout'
bluetoothd[5329]: audio/manager.c:audio_manager_init() audio.conf: Key file does not have key 'AutoConnect'
bluetoothd[5329]: audio/unix.c:unix_init() Unix socket created: 10
bluetoothd[5329]: audio/headset.c:telephony_ready_ind() Telephony plugin initialized
bluetoothd[5329]: audio/headset.c:print_ag_features() HFP AG features: "Ability to reject a call" "Enhanced call status" "Extended Error Result Codes"
bluetoothd[5329]: HCI dev 0 registered
bluetoothd[5329]: plugins/hciops.c:init_device() child 5332 forked
bluetoothd[5329]: src/adapter.c:btd_adapter_ref() 0xb800d600: ref=1
bluetoothd[5329]: HCI dev 0 up
bluetoothd[5329]: Starting security manager 0
bluetoothd[5329]: src/adapter.c:btd_adapter_set_class() Changing Major/Minor class to 0x000100
bluetoothd[5329]: src/adapter.c:adapter_start() Stopping Inquiry at adapter startup
bluetoothd[5329]: plugins/service.c:register_interface() path /org/bluez/5329/hci0
bluetoothd[5329]: plugins/service.c:register_interface() Registered interface org.bluez.Service on path /org/bluez/5329/hci0
bluetoothd[5329]: network/manager.c:network_server_probe() path /org/bluez/5329/hci0
bluetoothd[5329]: src/adapter.c:btd_adapter_ref() 0xb800d600: ref=2
bluetoothd[5329]: network/server.c:server_register() Registered interface org.bluez.NetworkServer on path /org/bluez/5329/hci0
bluetoothd[5329]: serial/manager.c:proxy_probe() path /org/bluez/5329/hci0
bluetoothd[5329]: src/adapter.c:btd_adapter_ref() 0xb800d600: ref=3
bluetoothd[5329]: serial/proxy.c:proxy_register() Registered interface org.bluez.SerialProxyManager on path /org/bluez/5329/hci0
bluetoothd[5329]: src/adapter.c:btd_adapter_ref() 0xb800d600: ref=4
bluetoothd[5329]: audio/manager.c:headset_server_probe() path /org/bluez/5329/hci0
bluetoothd[5329]: src/adapter.c:btd_adapter_ref() 0xb800d600: ref=5
bluetoothd[5329]: audio/manager.c:audio_adapter_ref() 0xb800dd80: ref=1
bluetoothd[5329]: audio/manager.c:headset_server_init() audio.conf: Key file does not have key 'Master'
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Adding record with handle 0x10000
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000003-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000100-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001002-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001108-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001112-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001203-0000-1000-8000-00805f9
bluetoothd[5329]: audio/headset.c:headset_config_init() audio.conf: Key file does not have key 'SCORouting'
bluetoothd[5329]: audio/headset.c:headset_config_init() audio.conf: Key file does not have key 'FastConnectable'
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Adding record with handle 0x10001
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000003-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000100-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001002-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000111e-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000111f-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001203-0000-1000-8000-00805f9
bluetoothd[5329]: audio/manager.c:a2dp_server_probe() path /org/bluez/5329/hci0
bluetoothd[5329]: audio/manager.c:audio_adapter_ref() 0xb800dd80: ref=2
bluetoothd[5329]: audio/a2dp.c:a2dp_register() audio.conf: Key file does not have key 'Enable'
bluetoothd[5329]: audio/a2dp.c:a2dp_register() audio.conf: Key file does not have key 'Disable'
bluetoothd[5329]: audio/a2dp.c:a2dp_register() audio.conf: Key file does not have group 'A2DP'
bluetoothd[5329]: audio/a2dp.c:a2dp_register() audio.conf: Key file does not have group 'A2DP'
bluetoothd[5329]: audio/a2dp.c:a2dp_register() audio.conf: Key file does not have group 'A2DP'
bluetoothd[5329]: audio/a2dp.c:a2dp_register() audio.conf: Key file does not have group 'A2DP'
bluetoothd[5329]: audio/avdtp.c:avdtp_init() audio.conf: Key file does not have key 'Master'
bluetoothd[5329]: audio/avdtp.c:avdtp_register_sep() SEP 0xb800e730 registered: type:0 codec:0 seid:1
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Adding record with handle 0x10002
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000019-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000100-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001002-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000110a-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000110d-0000-1000-8000-00805f9
bluetoothd[5329]: audio/manager.c:avrcp_server_probe() path /org/bluez/5329/hci0
bluetoothd[5329]: audio/manager.c:audio_adapter_ref() 0xb800dd80: ref=3
bluetoothd[5329]: audio/control.c:avrcp_register() audio.conf: Key file does not have key 'Master'
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Adding record with handle 0x10003
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000017-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000100-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001002-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000110c-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000110e-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Adding record with handle 0x10004
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000017-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00000100-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 00001002-0000-1000-8000-00805f9
bluetoothd[5329]: src/sdpd-service.c:add_record_to_server() Record pattern UUID 0000110e-0000-1000-8000-00805f9
bluetoothd[5329]: plugins/formfactor.c:formfactor_probe() Setting 0x000100 for major/minor device class
bluetoothd[5329]: Clearing blocked list failed: Invalid argument (22)
bluetoothd[5329]: src/device.c:device_create() Creating device /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: src/device.c:btd_device_ref() 0xb80299e0: ref=1
bluetoothd[5329]: src/device.c:device_probe_drivers() Probe drivers for /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: 00001101-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/port.c:create_serial_device() Registered interface org.bluez.Serial on path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: 00001103-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: 00001105-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: 00001106-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: 00001112-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: 0000111f-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B: db1d8f12-95f3-402c-9b97-bc504c9a55c4
bluetoothd[5329]: input/manager.c:headset_probe() path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: probe failed with driver input-headset for device /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: src/adapter.c:adapter_get_device() 00:1B:98:A3:A5:2B
bluetoothd[5329]: src/device.c:btd_device_ref() 0xb80299e0: ref=2
bluetoothd[5329]: audio/device.c:audio_device_register() Registered interface org.bluez.Audio on path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 00001112-0000-1000-8000-00805f9b34fb (0x1112)
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 0000111f-0000-1000-8000-00805f9b34fb (0x111f)
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 0000110a-0000-1000-8000-00805f9b34fb (0x110a)
bluetoothd[5329]: audio/manager.c:handle_uuid() Found AV Target
bluetoothd[5329]: audio/control.c:control_init() Registered interface org.bluez.Control on path /org/bluez/5329/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[5329]: audio/manager.c:handle_uuid() Found AV Target
bluetoothd[5329]: src/device.c:device_create() Creating device /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: src/device.c:btd_device_ref() 0xb802cf08: ref=1
bluetoothd[5329]: src/device.c:device_probe_drivers() Probe drivers for /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00000002-0000-1000-8000-0002ee000002
bluetoothd[5329]: serial/port.c:create_serial_device() Registered interface org.bluez.Serial on path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00001103-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00001105-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00001106-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00001112-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 0000111b-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 0000111f-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00005005-0000-1000-8000-0002ee000001
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA: 00005601-0000-1000-8000-0002ee000001
bluetoothd[5329]: input/manager.c:headset_probe() path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: probe failed with driver input-headset for device /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: src/adapter.c:adapter_get_device() 00:1D:6E:4F:54:EA
bluetoothd[5329]: src/device.c:btd_device_ref() 0xb802cf08: ref=2
bluetoothd[5329]: audio/device.c:audio_device_register() Registered interface org.bluez.Audio on path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 00001112-0000-1000-8000-00805f9b34fb (0x1112)
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 0000111f-0000-1000-8000-00805f9b34fb (0x111f)
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 0000110a-0000-1000-8000-00805f9b34fb (0x110a)
bluetoothd[5329]: audio/manager.c:handle_uuid() Found AV Target
bluetoothd[5329]: audio/control.c:control_init() Registered interface org.bluez.Control on path /org/bluez/5329/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[5329]: audio/manager.c:handle_uuid() Found AV Target
bluetoothd[5329]: src/device.c:device_create() Creating device /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: src/device.c:btd_device_ref() 0xb8031df0: ref=1
bluetoothd[5329]: src/device.c:device_probe_drivers() Probe drivers for /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00000002-0000-1000-8000-0002ee000002
bluetoothd[5329]: serial/port.c:create_serial_device() Registered interface org.bluez.Serial on path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00000004-0000-1000-8000-0002ee000002
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00001103-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00001105-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00001106-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00001112-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 0000111b-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 0000111f-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 0000112f-0000-1000-8000-00805f9b34fb
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00005005-0000-1000-8000-0002ee000001
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00005557-0000-1000-8000-0002ee000001
bluetoothd[5329]: serial/manager.c:serial_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB: 00005601-0000-1000-8000-0002ee000001
bluetoothd[5329]: input/manager.c:headset_probe() path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: probe failed with driver input-headset for device /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: src/adapter.c:adapter_get_device() A8:7E:33:D7:29:DB
bluetoothd[5329]: src/device.c:btd_device_ref() 0xb8031df0: ref=2
bluetoothd[5329]: audio/device.c:audio_device_register() Registered interface org.bluez.Audio on path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 00001112-0000-1000-8000-00805f9b34fb (0x1112)
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 0000111f-0000-1000-8000-00805f9b34fb (0x111f)
bluetoothd[5329]: audio/manager.c:handle_uuid() server not enabled for 0000110a-0000-1000-8000-00805f9b34fb (0x110a)
bluetoothd[5329]: audio/manager.c:handle_uuid() Found AV Target
bluetoothd[5329]: audio/control.c:control_init() Registered interface org.bluez.Control on path /org/bluez/5329/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[5329]: audio/manager.c:handle_uuid() Found AV Remote
bluetoothd[5329]: Adapter /org/bluez/5329/hci0 has been enabled
bluetoothd[5329]: src/main.c:main() Entering main loop
bluetoothd[5329]: plugins/hciops.c:child_exit() child 5332 exited
bluetoothd[5329]: src/rfkill.c:rfkill_event() RFKILL event idx 0 type 2 op 0 soft 0 hard 0
bluetoothd[5329]: src/rfkill.c:rfkill_event() RFKILL event idx 1 type 1 op 0 soft 0 hard 0
bluetoothd[5329]: Inquiry Failed with status 0x12
Program received signal SIGSEGV, Segmentation fault.
0xb7d2a653 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7d2a653 in strlen () from /lib/libc.so.6
#1 0xb7e53b10 in ?? () from /usr/lib/libdbus-1.so.3
#2 0xb7e3f34b in ?? () from /usr/lib/libdbus-1.so.3
#3 0xb7e437a9 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
#4 0xb7feebb4 in append_array_variant (iter=0xbffff584, type=115, val=0xbffff5f0, n_elements=6) at src/dbus-common.c:228
#5 0xb7feee58 in emit_array_property_changed (conn=0xb8009eb8, path=0xb8015860 "/org/bluez/5329/hci0", interface=0xb7ffd4b8 "org.bluez.Adapter",
name=0xb7ffd638 "UUIDs", type=115, value=0xbffff5f0, num=6) at src/dbus-common.c:320
#6 0xb7fe400e in adapter_emit_uuids_updated (adapter=0xb800d600) at src/adapter.c:1107
#7 0xb7fe40fb in adapter_service_ins_rem (bdaddr=0xbffff770, rec=0xb800d5d8, insert=1) at src/adapter.c:1146
#8 0xb7fe4133 in adapter_service_insert (bdaddr=0xbffff770, rec=0xb800d5d8) at src/adapter.c:1153
#9 0xb7fd596a in sdp_record_add (device=0xbffff770, rec=0xb800d5d8) at src/sdpd-database.c:188
#10 0xb7fd520e in service_register_req (req=0xbffff770, rsp=0xbffff70c) at src/sdpd-service.c:684
#11 0xb7fd3ab2 in process_request (req=0xbffff770) at src/sdpd-request.c:992
#12 0xb7fd3de1 in handle_request (sk=25, data=0xb8029890 "u", len=119) at src/sdpd-request.c:1087
#13 0xb7fd1e01 in io_session_event (chan=0xb800cda0, cond=G_IO_IN, data=0xb8004990) at src/sdpd-server.c:188
#14 0xb7eeca2b in ?? () from /usr/lib/libglib-2.0.so.0
#15 0xb7ea5b72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0xb7ea6350 in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xb7ea6a1b in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#18 0xb7fce93c in main (argc=1, argv=0xbffffad4) at src/main.c:486
(gdb)
^ permalink raw reply
* Re: [PATCH 1/9] mfd: Add support for the ST-Ericsson CG2900.
From: Arnd Bergmann @ 2010-10-26 12:06 UTC (permalink / raw)
To: Par-Gunnar Hjalmdahl; +Cc: linus.walleij, linux-bluetooth, linux-kernel
In-Reply-To: <AANLkTinY0qmt6uFo4PZ3xH2BF5-AJ0C7ptctzNdOkRU2@mail.gmail.com>
On Tuesday 26 October 2010, Par-Gunnar Hjalmdahl wrote:
> 2010/10/22 Arnd Bergmann <arnd@arndb.de>:
> > On Friday 22 October 2010 12:35:16 Par-Gunnar Hjalmdahl wrote:
> >> This patch adds support for the ST-Ericsson CG2900 Connectivity
> >> Combo controller.
> >> This patch adds the central framework to be able to register CG2900 users,
> >> transports, and chip handlers.
> >>
> >> Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
> >
> > Looks ok from a coding style perspective, but some important information is
> > missing from the description:
> >
> > * What is a CG2900?
> > * Why is it a MFD device rather than e.g. a bus or a subsystem?
> >
>
> I will add some more info:
> - CG2900 is a GPS, Bluetooth, FM controller
> - I do not really know what makes a device qualify as a certain type,
> but at least for us this is a multifunction device. But I can't really
> say that it isn't really a bus (could be stated as multifunction HCI
> bus). I guess it could be qualified as a subsystem as well, but I
> cannot give you a reason to have it as either.
It's not often completely clear, but I would draw the distinction like
this:
* A multi-function device is a single device that sits on a given bus
with one host I/O interface and provides functionality to different
logical subsystems like serial or alsa. A typical case for an MFD would
be a to solve the problem of sharing resources between the child drivers
because you cannot bind one device to two drivers. If CG2900 is a single
piece of silicon that always looks the same way, it's probably an MFD.
* A bus is a much more general abstraction which has multiple devices
and multiple device types behind it. The bus has no idea what devices
are attached to it at compile time, so you either probe the devices at
boot time or define a set of devices in a board definition (platform
devices). Driver modules then register a struct device_driver for the
bus, which gives all matching devices to the bus. If you can have
future CG2900 compatible devices that need to have other drivers, e.g.
for HID or video, it should probably be a bus.
* A subsystem is less clearly defined, I would call bluetooth a subsystem
instead of just a bus because it not only matches devices with drivers
but also has its own user-level interfaces for raw communication.
If you want to be able to have drivers in the kernel and in user space,
you might want to consider starting a new drivers/cg2900 subsystem, or
integrating into the bluetooth subsystem if that makes sense.
> >> +config MFD_CG2900
> >> + tristate "Support ST-Ericsson CG2900 main structure"
> >> + depends on NET
> >> + help
> >> + Support for ST-Ericsson CG2900 Connectivity Combo controller main structure.
> >> + Supports multiple functionalities muxed over a Bluetooth HCI H:4 interface.
> >> + CG2900 support Bluetooth, FM radio, and GPS.
> >> +
> >
> > Can you explain what it means to mux over a H:4 interface? Does this mean
> > you use bluetooth infrastructure that is designed for wireless communication
> > in order to connect on-board or on-chip devices?
> >
>
> The H:4 protocol is defined in the Bluetooth Core specification. It
> uses a single byte first in the data packet to determine an HCI
> channel. In the Bluetooth Core specification there are 4 channels
> specified, 0x01-0x04 (0x01 is BT command, etc). The rest of the
> channels are reserved, but these have been used on a proprietary basis
> to transport data to different IPs within the controller. In our API
> we have chosen to have a channel separation on an API basis and the
> H:4 byte is then added within the driver. So we have multiple channels
> coming in from the users that we mux onto a single data transport.
> That's what I mean in the text. I guess I could rewrite it a bit to
> make it clearer.
I still don't understand it, though that may be a problem on my side.
Does that mean that cg2900 is to the host side a standard bluetooth HCI,
but it uses extensions to the HCI in order to make the other functions
available to the host?
What chapter in the bluetooth core specification describes this?
> >> +
> >> +/**
> >> + * add_h4_user() - Add H4 user to user storage based on supplied H4 channel.
> >> + * @dev: Stored CG2900 device.
> >> + * @name: Device name to identify different devices that are using
> >> + * the same H4 channel.
> >> + *
> >> + * Returns:
> >> + * 0 if there is no error.
> >> + * -EINVAL if NULL pointer or bad channel is supplied.
> >> + * -EBUSY if there already is a user for supplied channel.
> >> + */
> >> +static int add_h4_user(struct cg2900_device *dev, const char * const name)
> >> +{
> >
> > Where does that name come from? Why not just use an enum if the name is
> > only use for strncmp?
> >
>
> At a point in time we used to have an enum, but from what I can see it
> is easier to keep an API stable if you use name lookup instead. If we
> want to have minimal changes to the API in the future this is quite a
> flexible solution, but this code should be moved to each respective
> chip handler.
You haven't really answered the first question, where the name comes from
(I guess the question was not too clear). Does this e.g. get passed by a
user application, or does it come from a hardware description of some
sort?
It looks a bit like a handcoded version of the code we use for device/driver
matching in drivers/core. If that's the case, it would be better to use
the existing infrastructure and create a bus with devices that can be
matched with drivers.
> >> +static ssize_t test_char_dev_read(struct file *filp, char __user *buf,
> >> + size_t count, loff_t *f_pos)
> >> +{
> >> + struct sk_buff *skb;
> >> + int bytes_to_copy;
> >> + int err;
> >> + struct sk_buff_head *rx_queue = &core_info->test_char_dev->rx_queue;
> >
> > What is this read/write interface used for?
> >
> > The name suggests that this is only for testing and not an essential
> > part of your driver. Could this be made a separate driver?
> >
> > It also looks like you do socket communication here, can't you use
> > a proper AF_BLUETOOTH socket to do the same?
> >
>
> This interface can be used for module testing where you can have a
> test engine in user space that acts as a chip. Yes, it could be made
> into a separate driver but it would be a very small driver. Don't know
> if it will be worth having it in a separate file...
I don't think file size is a major argument here. If it's used for
testing, I'd make it a separate module that defaults to not being
built, in order to prevent people from relying on what you intended
as a testing interface.
> We use the sk_buffer, which I guess is the reason that you mention
> sockets. We could of course use a socket instead of a char dev, both
> here and in the cg2900_char_dev file (which of course then would be
> renamed). It was just a choice we made during development. We think
> that the transport as such is more like a streaming interface, but I
> see no real problem to have sockets. We already have several users
> using char dev though so I would prefer to keep char dev rather than
> switching to sockets unless you have a strong reason for this.
> I see no reason to use AF_BLUETOOTH though, the transport is not only
> for Bluetooth.
The question here is what is appropriate. My guess was that the frame
format was the one used in bluetooth sockets. If that's not the
case, AF_BLUETOOTH would obviously be wrong.
For the test interface, it doesn't matter that much what you use, but
for the cg2900_char_dev we should make sure that you considered all
the options and made a reasonable decision. What does the data format
look like there? My impression is that the character device might be
too low-level and it could be better to use some structured interface
like a socket, but it really depends on what it actually does.
In particular, if you can address multiple hardware units over one
character device, it may be better to have separate devices for each
of them.
> >> + CG2900_INFO("test_char_dev_read");
> >> +
> >> + if (skb_queue_empty(rx_queue))
> >> + wait_event_interruptible(char_wait_queue,
> >> + !(skb_queue_empty(rx_queue)));
> >> +
> >> + skb = skb_dequeue(rx_queue);
> >> + if (!skb) {
> >> + CG2900_INFO("skb queue is empty - return with zero bytes");
> >> + bytes_to_copy = 0;
> >> + goto finished;
> >> + }
> >> +
> >> + bytes_to_copy = min(count, skb->len);
> >> + err = copy_to_user(buf, skb->data, bytes_to_copy);
> >> + if (err) {
> >> + skb_queue_head(rx_queue, skb);
> >> + return -EFAULT;
> >> + }
> >> +
> >> + skb_pull(skb, bytes_to_copy);
> >> +
> >> + if (skb->len > 0)
> >> + skb_queue_head(rx_queue, skb);
> >> + else
> >> + kfree_skb(skb);
> >> +
> >> +finished:
> >> + return bytes_to_copy;
> >> +}
> >
> > This does not handle short/continued reads.
> >
>
> As I mentioned above this interface is used for testing and we
> therefore have some restriction of usage. I don't think we need to
> impose all things necessary for a full interface upon it.
This is where it gets complicated. We don't normally add interfaces
to the kernel unless we expect to fully support them for the forseeable
future. It has happened more than enough in the past that somebody
introduced a debugging interface which subsequently became a supported
ABI because some application started relying on it.
Is the code that uses the test interface even publically available?
If not, I would recommend saving the trouble of arguing about it
and leaving out the interface.
> >> + #define CG2900_ERR(fmt, arg...) \
> >> + do { \
> >> + if (cg2900_debug_level >= 1) \
> >> + pr_err("CG2900 %s: " fmt "\n" , __func__ , ## arg); \
> >> + } while (0)
> >> +
> >> +#endif /* NDEBUG */
> >
> > You'll feel relieved when all this is gone...
> >
>
> The only thing is it's been pretty nice to have it, but I will remove it.
> Is it OK to keep defines so we can have "CG2900" in front and "\n"
> after the text?
Ideally, you would use the dev_* functions instead of the pr_* functions,
which print the name of the device before the message. I also wouldn't
add the "\n" in the macro because all the regular printing functions don't
do it. It will likely only confuse people and the binary remains the same.
Arnd
^ permalink raw reply
* Re: [PATCH 2/2 v2] Bluetooth: Fix system crash bug of no send queue protect
From: haijun liu @ 2010-10-26 11:50 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Haijun Liu, linux-bluetooth
In-Reply-To: <20101025110908.GB7721@vigoh>
Hi Gustavo,
> sk->sk_send_head is also protected by the socket lock.
>
I thought you mean sk->tx_queue.lock, actually it's sk->sk_lock.slock.
But there could be some paths have not been covered.
> This dump shows that the crash happens for a code that is not mainline
> yet. I can't take a patch that fix a bug for code not in mainline. You
> have to show the bug using mainline code.
>
Yes, it is not mainline code, but this issue could be common issue.
OK, let me try use sk->sk_lock.slock to solve this bug.
--
Haijun Liu
^ permalink raw reply
* Re: [RFC] SMP initial draft
From: Ville Tervo @ 2010-10-26 9:38 UTC (permalink / raw)
To: ext Anderson Briglia; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1287791820-22693-1-git-send-email-anderson.briglia@openbossa.org>
Hi,
On Sat, Oct 23, 2010 at 01:56:54AM +0200, ext Anderson Briglia wrote:
> This RFC is about Security Manager Protocol (SMP).
> Basically this patchset implements the initial negotiation over L2CAP and LE
> connections between a Master and a Slave. TK and STK keys are not being generated
> and/or exchanged yet, do not expect real encryption/decryption by now.
> Actually, our next tasks are related to integrate current implementation and
> Criptographic Toolbox ah, c1 and s1 functions for TK and STK key generation for
> Just Works SMP pairing method.
I think some kind of mechanism to start encryption on already existing
connection is needed. It depends on attribute if security is needed or not. One
might read unsecure attributes and then needs to start encryption because it
wants to read encrypted attribute.
Is that already planned somehow?
>
> To test this RFC you need to have the Ville Tervo[1] kernel tree with LE connection
> patches. Of course you need LE devices and bluez git tree (master branch). Just run
> the bluetoothd and try to list the primary services using gatttool over an LE channel.
> eg.: gatttool --primary --le -i hci0 -b 00:17:E7:DD:08:FF
I guess I should take patches which are fixing plain LE (2/6) and (5/6)
connection to my tree alread. How it sounds to you?
> Comments are welcome.
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/vtervo/bluetooth-le-2.6.git
>
> [PATCH 1/6] Bluetooth: Add SMP command structures
> [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
> [PATCH 3/6] Bluetooth: Implement the first SMP commands
> [PATCH 4/6] Bluetooth: Start SMP procedure
> [PATCH 5/6] Bluetooth: Fix initiated LE connections
> [PATCH 6/6] Bluetooth: simple SMP pairing negotiation
> --
> 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 5/6] Bluetooth: Fix initiated LE connections
From: Ville Tervo @ 2010-10-26 9:28 UTC (permalink / raw)
To: ext Anderson Briglia
Cc: linux-bluetooth@vger.kernel.org, Vinicius Costa Gomes
In-Reply-To: <1287791820-22693-6-git-send-email-anderson.briglia@openbossa.org>
Hi,
On Sat, Oct 23, 2010 at 01:56:59AM +0200, ext Anderson Briglia wrote:
> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> Fix LE connections not being marked as master.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/hci_conn.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index c7309e4..1a48c6a 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -52,6 +52,7 @@ void hci_le_connect(struct hci_conn *conn)
>
> conn->state = BT_CONNECT;
> conn->out = 1;
> + conn->link_mode |= HCI_LM_MASTER;
conn->out and conn->link_mode are redutant information. The role cannot be changed.
>
> memset(&cp, 0, sizeof(cp));
> cp.scan_interval = cpu_to_le16(0x0004);
> --
> 1.7.0.4
--
Ville
^ permalink raw reply
* Re: [PATCH 3/6] Bluetooth: Implement the first SMP commands
From: Ville Tervo @ 2010-10-26 9:26 UTC (permalink / raw)
To: ext Gustavo F. Padovan
Cc: Anderson Briglia, linux-bluetooth@vger.kernel.org,
Vinicius Costa Gomes
In-Reply-To: <20101025130356.GA8862@vigoh>
On Mon, Oct 25, 2010 at 03:03:56PM +0200, ext Gustavo F. Padovan wrote:
> Hi Vinicius,
>
> * Anderson Briglia <anderson.briglia@openbossa.org> [2010-10-22 19:56:57 -0400]:
>
> > From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> >
> > These simple commands will allow the SMP procedure to be started
> > and terminated with a not supported error. This is the first step
> > toward something useful.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> > ---
> > net/bluetooth/l2cap.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 117 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> > index 1ac44f4..ba87c84 100644
> > --- a/net/bluetooth/l2cap.c
> > +++ b/net/bluetooth/l2cap.c
> > @@ -54,6 +54,7 @@
> > #include <net/bluetooth/bluetooth.h>
> > #include <net/bluetooth/hci_core.h>
> > #include <net/bluetooth/l2cap.h>
> > +#include <net/bluetooth/smp.h>
> >
> > #define VERSION "2.15"
> >
> > @@ -307,6 +308,85 @@ static void l2cap_chan_del(struct sock *sk, int err)
> > }
> > }
> >
> > +static struct sk_buff *smp_build_cmd(struct l2cap_conn *conn, u8 code,
> > + u16 dlen, void *data)
>
> Call this l2cap_smp_build_cmd()
Should the whole smp stuff be in separate file (smp.c)? It's not a l2cap feature but a
protocol using l2cap. In that case smp_build_cmd would be good name.
--
Ville
^ permalink raw reply
* [PATCH] Fix cache is invalid on empty listing response
From: Dmitriy Paliy @ 2010-10-26 8:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
Fix cache marked as invalid when no data available in response to get phone
book listing. This fixes obexd crash in 3-way calling scenario. Cache is
created when there is second incoming call. If the call is rejected and
retried again, valid empty cache is sent over obex stream that causes obexd
crash. With this fix, the stream is aborted in such scenario. A new attempt
to create cache is carried out on each new subsequent incoming call.
---
plugins/pbap.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/plugins/pbap.c b/plugins/pbap.c
index 11cb678..f7f3897 100644
--- a/plugins/pbap.c
+++ b/plugins/pbap.c
@@ -407,7 +407,11 @@ static void cache_ready_notify(void *user_data)
(const char *) pbap->params->searchval);
if (sorted == NULL) {
- pbap->cache.valid = TRUE;
+ /* When no data available from tracker, cache marked as
+ * invalid (new one will be tried to be created next time),
+ * no such file or directory error is set, and obex stream
+ * is aborted */
+ pbap->cache.valid = FALSE;
obex_object_set_io_flags(pbap, G_IO_ERR, -ENOENT);
return;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] Add separate queries for listing size in PBAP
From: Radoslaw Jablonski @ 2010-10-26 8:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
In-Reply-To: <1288081792-15296-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Previosly to get phonebook-size or call history size, full phonebook
query was used and a lot of unnecessary operations need to be done on
that returned data. Now separate query is used to get size of each
listing so performance for "getPhonebookSize" operations improved a lot.
---
plugins/phonebook-tracker.c | 105 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 103 insertions(+), 2 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 277290c..3367e49 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -45,6 +45,7 @@
#define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
#define CONTACTS_ID_COL 38
#define PULL_QUERY_COL_AMOUNT 39
+#define COUNT_QUERY_COL_AMOUNT 1
#define COL_HOME_NUMBER 0
#define COL_HOME_EMAIL 7
#define COL_WORK_NUMBER 8
@@ -579,6 +580,59 @@
"<%s> nco:hasPhoneNumber ?t . " \
"} "
+#define CONTACTS_COUNT_QUERY \
+ "SELECT COUNT(?c) " \
+ "WHERE {" \
+ "?c a nco:PersonContact ." \
+ "FILTER (regex(str(?c), \"contact:\") || " \
+ "regex(str(?c), \"nco#default-contact-me\"))" \
+ "}"
+
+#define MISSED_CALLS_COUNT_QUERY \
+ "SELECT COUNT(?call) WHERE {" \
+ "?c a nco:Contact ;" \
+ "nco:hasPhoneNumber ?h ." \
+ "?call a nmo:Call ;" \
+ "nmo:isSent false ;" \
+ "nmo:from ?c ;" \
+ "nmo:isAnswered false ." \
+ "}"
+
+#define INCOMING_CALLS_COUNT_QUERY \
+ "SELECT COUNT(?call) WHERE {" \
+ "?c a nco:Contact ;" \
+ "nco:hasPhoneNumber ?h ." \
+ "?call a nmo:Call ;" \
+ "nmo:isSent false ;" \
+ "nmo:from ?c ;" \
+ "nmo:isAnswered true ." \
+ "}"
+
+#define OUTGOING_CALLS_COUNT_QUERY \
+ "SELECT COUNT(?call) WHERE {" \
+ "?c a nco:Contact ;" \
+ "nco:hasPhoneNumber ?h ." \
+ "?call a nmo:Call ;" \
+ "nmo:isSent true ;" \
+ "nmo:to ?c ." \
+ "}"
+
+#define COMBINED_CALLS_COUNT_QUERY \
+ "SELECT COUNT(?call) WHERE {" \
+ "{" \
+ "?c a nco:Contact ;" \
+ "nco:hasPhoneNumber ?h ." \
+ "?call a nmo:Call ;" \
+ "nmo:isSent true ;" \
+ "nmo:to ?c ." \
+ "}UNION {" \
+ "?c a nco:Contact ;" \
+ "nco:hasPhoneNumber ?h ." \
+ "?call a nmo:Call ;" \
+ "nmo:from ?c ." \
+ "}" \
+ "}"
+
typedef void (*reply_list_foreach_t) (char **reply, int num_fields,
void *user_data);
@@ -633,6 +687,22 @@ static const char *name2query(const char *name)
return NULL;
}
+static const char *name2count_query(const char *name)
+{
+ if (g_str_equal(name, "telecom/pb.vcf"))
+ return CONTACTS_COUNT_QUERY;
+ else if (g_str_equal(name, "telecom/ich.vcf"))
+ return INCOMING_CALLS_COUNT_QUERY;
+ else if (g_str_equal(name, "telecom/och.vcf"))
+ return OUTGOING_CALLS_COUNT_QUERY;
+ else if (g_str_equal(name, "telecom/mch.vcf"))
+ return MISSED_CALLS_COUNT_QUERY;
+ else if (g_str_equal(name, "telecom/cch.vcf"))
+ return COMBINED_CALLS_COUNT_QUERY;
+
+ return NULL;
+}
+
static gboolean folder_is_valid(const char *folder)
{
if (folder == NULL)
@@ -1022,6 +1092,26 @@ static GString *gen_vcards(GSList *contacts,
return vcards;
}
+static void pull_contacts_size (char **reply, int num_fields, void *user_data)
+{
+ struct phonebook_data *data = user_data;
+
+ if (num_fields < 0) {
+ data->cb(NULL, 0, num_fields, 0, data->user_data);
+ goto fail;
+ }
+
+ if (reply != NULL) {
+ data->index = atoi(reply[0]);
+ return;
+ }
+
+ data->cb(NULL, 0, data->index, 0, data->user_data);
+
+fail:
+ g_free(data);
+}
+
static void pull_contacts(char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
@@ -1284,10 +1374,21 @@ int phonebook_pull(const char *name, const struct apparam_field *params,
{
struct phonebook_data *data;
const char *query;
+ reply_list_foreach_t pull_cb;
+ int col_amount;
DBG("name %s", name);
- query = name2query(name);
+ if (params->maxlistcount == 0) {
+ query = name2count_query(name);
+ col_amount = COUNT_QUERY_COL_AMOUNT;
+ pull_cb = pull_contacts_size;
+ } else {
+ query = name2query(name);
+ col_amount = PULL_QUERY_COL_AMOUNT;
+ pull_cb = pull_contacts;
+ }
+
if (query == NULL)
return -ENOENT;
@@ -1296,7 +1397,7 @@ int phonebook_pull(const char *name, const struct apparam_field *params,
data->user_data = user_data;
data->cb = cb;
- return query_tracker(query, PULL_QUERY_COL_AMOUNT, pull_contacts, data);
+ return query_tracker(query, col_amount, pull_cb, data);
}
int phonebook_get_entry(const char *folder, const char *id,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Remove unnecessary empty line in phonebook-tracker
From: Radoslaw Jablonski @ 2010-10-26 8:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
---
plugins/phonebook-tracker.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index a6e21f8..277290c 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -531,7 +531,6 @@
"}" \
"} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call))"
-
#define CONTACTS_QUERY_FROM_URI \
"SELECT ?v nco:fullname(<%s>) " \
"nco:nameFamily(<%s>) nco:nameGiven(<%s>) " \
--
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