* Re: [PATCH 1/4]: Check EEPROM before tweaking SERDES
From: Nick Kossifidis @ 2009-07-31 18:18 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: ath5k-devel, linux-wireless, linville, jirislaby, me, nbd
In-Reply-To: <43e72e890907311111k10cce08et84510866c68e0297@mail.gmail.com>
2009/7/31 Luis R. Rodriguez <mcgrof@gmail.com>:
>
> Can the changes for the code be done before the move, or after so that
> way the actual code changes to the section can be easily readable?
>
Since we use EEPROM infos we must move this after eeprom initialization.
>
> This is just comment-picky mind using this style for comments for > 1 lines?
>
> /*
> * foo bleh buh
> * bar
> * qwerty
> */
>
> Luis
I use it mostly on large functions (such as attach/reset) to mark sections, we
don't execute a single command here but a bunch of reg writes. I find it easier
to read this way.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Luis R. Rodriguez @ 2009-07-31 18:15 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731181020.GE7963@makis>
On Fri, Jul 31, 2009 at 11:10 AM, Nick
Kossifidis<mick@madwifi-project.org> wrote:
> * Get rid of calibration timer, instead use a software interrupt
> to schedule the calibration tasklet.
An example of itemizing one change. Explain the why, not the how.
Luis
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: Wakeup fixes
From: Luis R. Rodriguez @ 2009-07-31 18:14 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731180805.GD7963@makis>
T24gRnJpLCBKdWwgMzEsIDIwMDkgYXQgMTE6MDggQU0sIE5pY2sKS29zc2lmaWRpczxtaWNrQG1h
ZHdpZmktcHJvamVjdC5vcmc+IHdyb3RlOgo+IMKgKiBEb24ndCBwdXQgY2hpcCB0byBmdWxsIHNs
ZWVwIGJlY2F1c2UgdGhlcmUgYXJlIHByb2JsZW1zIGR1cmluZwo+IMKgIHdha2V1cC4gSW5zdGVh
ZCBob2xkIE1BQy9CYXNlYmFuZCBvbiB3YXJtIHJlc2V0IHN0YXRlIHZpYSBhIG5ldwo+IMKgIGZ1
bmN0aW9uIGF0aDVrX2h3X29uX2hvbGQuCj4KPiDCoCogRHVycmluZyBhdHRhY2ggcHJlc2VydmUg
cGNpY2ZnIGJpdHMgd2hlbiBlbmFibGluZyBwY2kgY29yZQo+IMKgIHN3IHJldHJ5IGZpeC4KPgo+
IMKgKiBNaW5vciBjbGVhbnVwcwoKQ2FuIHlvdSBhZGRyZXNzIHRoZXNlIGNoYW5nZXMgc2VwYXJh
dGVseT8gSSBzZWUgeW91IHRlbmQgdG8gaXRlbWl6ZQp0aGUgdGhpbmdzIHlvdSBjaGFuZ2UsIGV2
ZW4gd2hlbiB5b3UganVzdCBtYWtlIG9uZSBjaGFuZ2UuIFBsZWFzZQpjb25zaWRlciBhZGRyZXNz
aW5nIG9uZSBjaGFuZ2UgcGVyIGNvbW1pdCBhbmQganVzdCBlbnN1cmUgdGhlIHdoeSBpcwpjcnlz
dGFsIGNsZWFyLgoKICBMdWlzCgo+IC0tLQo+IMKgZHJpdmVycy9uZXQvd2lyZWxlc3MvYXRoL2F0
aDVrL2F0aDVrLmggwqB8IMKgIMKgMSArCj4gwqBkcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRo
NWsvYXR0YWNoLmMgfCDCoCDCoDQgKy0KPiDCoGRyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGg1
ay9iYXNlLmMgwqAgfCDCoCA0NCArKysrKy0tLS0KPiDCoGRyaXZlcnMvbmV0L3dpcmVsZXNzL2F0
aC9hdGg1ay9yZXNldC5jIMKgfCDCoDE1NSArKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0t
Cj4gwqA0IGZpbGVzIGNoYW5nZWQsIDE0MSBpbnNlcnRpb25zKCspLCA2MyBkZWxldGlvbnMoLSkK
Pgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRoNWsvYXRoNWsuaCBi
L2RyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGg1ay9hdGg1ay5oCj4gaW5kZXggOTEzNzUxMS4u
MTA0N2E2YyAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRoNWsvYXRo
NWsuaAo+ICsrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGg1ay9hdGg1ay5oCj4gQEAg
LTExNTcsNiArMTE1Nyw3IEBAIGV4dGVybiB2b2lkIGF0aDVrX3VucmVnaXN0ZXJfbGVkcyhzdHJ1
Y3QgYXRoNWtfc29mdGMgKnNjKTsKPgo+IMKgLyogUmVzZXQgRnVuY3Rpb25zICovCj4gwqBleHRl
cm4gaW50IGF0aDVrX2h3X25pY193YWtldXAoc3RydWN0IGF0aDVrX2h3ICphaCwgaW50IGZsYWdz
LCBib29sIGluaXRpYWwpOwo+ICtleHRlcm4gaW50IGF0aDVrX2h3X29uX2hvbGQoc3RydWN0IGF0
aDVrX2h3ICphaCk7Cj4gwqBleHRlcm4gaW50IGF0aDVrX2h3X3Jlc2V0KHN0cnVjdCBhdGg1a19o
dyAqYWgsIGVudW0gbmw4MDIxMV9pZnR5cGUgb3BfbW9kZSwgc3RydWN0IGllZWU4MDIxMV9jaGFu
bmVsICpjaGFubmVsLCBib29sIGNoYW5nZV9jaGFubmVsKTsKPiDCoC8qIFBvd2VyIG1hbmFnZW1l
bnQgZnVuY3Rpb25zICovCj4gwqBleHRlcm4gaW50IGF0aDVrX2h3X3NldF9wb3dlcihzdHJ1Y3Qg
YXRoNWtfaHcgKmFoLCBlbnVtIGF0aDVrX3Bvd2VyX21vZGUgbW9kZSwgYm9vbCBzZXRfY2hpcCwg
dTE2IHNsZWVwX2R1cmF0aW9uKTsKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvd2lyZWxlc3Mv
YXRoL2F0aDVrL2F0dGFjaC5jIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvYXRoL2F0aDVrL2F0dGFj
aC5jCj4gaW5kZXggNjI2MzA2NS4uNjVkNDM4YiAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL25ldC93
aXJlbGVzcy9hdGgvYXRoNWsvYXR0YWNoLmMKPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9h
dGgvYXRoNWsvYXR0YWNoLmMKPiBAQCAtMTQ1LDcgKzE0NSw3IEBAIHN0cnVjdCBhdGg1a19odyAq
YXRoNWtfaHdfYXR0YWNoKHN0cnVjdCBhdGg1a19zb2Z0YyAqc2MsIHU4IG1hY192ZXJzaW9uKQo+
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ290byBlcnJfZnJlZTsKPgo+IMKgIMKgIMKgIMKgLyog
QnJpbmcgZGV2aWNlIG91dCBvZiBzbGVlcCBhbmQgcmVzZXQgaXQncyB1bml0cyAqLwo+IC0gwqAg
wqAgwqAgcmV0ID0gYXRoNWtfaHdfbmljX3dha2V1cChhaCwgQ0hBTk5FTF9CLCB0cnVlKTsKPiAr
IMKgIMKgIMKgIHJldCA9IGF0aDVrX2h3X25pY193YWtldXAoYWgsIDAsIHRydWUpOwo+IMKgIMKg
IMKgIMKgaWYgKHJldCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvdG8gZXJyX2ZyZWU7Cj4K
PiBAQCAtMjYxLDcgKzI2MSw3IEBAIHN0cnVjdCBhdGg1a19odyAqYXRoNWtfaHdfYXR0YWNoKHN0
cnVjdCBhdGg1a19zb2Z0YyAqc2MsIHU4IG1hY192ZXJzaW9uKQo+Cj4gwqAgwqAgwqAgwqAvKiBF
bmFibGUgcGNpIGNvcmUgcmV0cnkgZml4IG9uIEhhaW5hbiAoNTIxM0EpIGFuZCBsYXRlciBjaGlw
cyAqLwo+IMKgIMKgIMKgIMKgaWYgKHNyZXYgPj0gQVI1S19TUkVWX0FSNTIxM0EpCj4gLSDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBhdGg1a19od19yZWdfd3JpdGUoYWgsIEFSNUtfUENJQ0ZHX1JFVFJZ
X0ZJWCwgQVI1S19QQ0lDRkcpOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQVI1S19SRUdfRU5B
QkxFX0JJVFMoYWgsIEFSNUtfUENJQ0ZHLCBBUjVLX1BDSUNGR19SRVRSWV9GSVgpOwo+Cj4gwqAg
wqAgwqAgwqAvKgo+IMKgIMKgIMKgIMKgICogR2V0IGNhcmQgY2FwYWJpbGl0aWVzLCBjYWxpYnJh
dGlvbiB2YWx1ZXMgZXRjCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9h
dGg1ay9iYXNlLmMgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRoNWsvYmFzZS5jCj4gaW5k
ZXggN2RiMzJjZS4uYjY0NzMxYiAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9h
dGgvYXRoNWsvYmFzZS5jCj4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvYXRoL2F0aDVrL2Jh
c2UuYwo+IEBAIC0yNDQ4LDI3ICsyNDQ4LDI5IEBAIGF0aDVrX3N0b3BfaHcoc3RydWN0IGF0aDVr
X3NvZnRjICpzYykKPiDCoCDCoCDCoCDCoHJldCA9IGF0aDVrX3N0b3BfbG9ja2VkKHNjKTsKPiDC
oCDCoCDCoCDCoGlmIChyZXQgPT0gMCAmJiAhdGVzdF9iaXQoQVRIX1NUQVRfSU5WQUxJRCwgc2Mt
PnN0YXR1cykpIHsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC8qCj4gLSDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogU2V0IHRoZSBjaGlwIGluIGZ1bGwgc2xlZXAgbW9kZS4gwqBOb3RlIHRoYXQg
d2UgYXJlCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogY2FyZWZ1bCB0byBkbyB0aGlzIG9u
bHkgd2hlbiBicmluZ2luZyB0aGUgaW50ZXJmYWNlCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCogY29tcGxldGVseSB0byBhIHN0b3AuIMKgV2hlbiB0aGUgY2hpcCBpcyBpbiB0aGlzIHN0YXRl
Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogaXQgbXVzdCBiZSBjYXJlZnVsbHkgd29rZW4g
dXAgb3IgcmVmZXJlbmNlcyB0bwo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHJlZ2lzdGVy
cyBpbiB0aGUgUENJIGNsb2NrIGRvbWFpbiBtYXkgZnJlZXplIHRoZSBidXMKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgKiAoYW5kIHN5c3RlbSkuIMKgVGhpcyB2YXJpZXMgYnkgY2hpcCBhbmQg
aXMgbW9zdGx5IGFuCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogaXNzdWUgd2l0aCBuZXdl
ciBwYXJ0cyB0aGF0IGdvIHRvIHNsZWVwIG1vcmUgcXVpY2tseS4KPiAtIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgKi8KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChzYy0+YWgtPmFoX21hY19z
cmV2ID49IDB4NzgpIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC8qCj4g
LSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogWFhYCj4gLSDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZG9uJ3QgcHV0IG5ld2VyIE1BQyByZXZpc2lvbnMg
PiA3LjggdG8gc2xlZXAgYmVjYXVzZQo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAqIG9mIHRoZSBhYm92ZSBtZW50aW9uZWQgcHJvYmxlbXMKPiAtIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgKi8KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIEFUSDVLX0RCRyhzYywgQVRINUtfREVCVUdfUkVTRVQsICJtYWMgdmVyc2lvbiA+IDcuOCwg
Igo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgIm5vdCBw
dXR0aW5nIGRldmljZSB0byBzbGVlcFxuIik7Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9IGVs
c2Ugewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQVRINUtfREJHKHNjLCBB
VEg1S19ERUJVR19SRVNFVCwKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgICJwdXR0aW5nIGRldmljZSB0byBmdWxsIHNsZWVwXG4iKTsKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGF0aDVrX2h3X3NldF9wb3dlcihzYy0+YWgsIEFSNUtf
UE1fRlVMTF9TTEVFUCwgdHJ1ZSwgMCk7Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Cj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogRG9uJ3Qgc2V0IHRoZSBjYXJkIGluIGZ1bGwgc2xlZXAg
bW9kZSEKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKgo+ICsgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAqIGEpIFdoZW4gdGhlIGRldmljZSBpcyBpbiB0aGlzIHN0YXRlIGl0IG11c3QgYmUgY2Fy
ZWZ1bGx5Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogd29rZW4gdXAgb3IgcmVmZXJlbmNl
cyB0byByZWdpc3RlcnMgaW4gdGhlIFBDSSBjbG9jawo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAqIGRvbWFpbiBtYXkgZnJlZXplIHRoZSBidXMgKGFuZCBzeXN0ZW0pLiDCoFRoaXMgdmFyaWVz
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogYnkgY2hpcCBhbmQgaXMgbW9zdGx5IGFuIGlz
c3VlIHdpdGggbmV3ZXIgcGFydHMKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiAobWFkd2lm
aSBzb3VyY2VzIG1lbnRpb25lZCBzcmV2ID49IDB4NzgpIHRoYXQgZ28gdG8KPiArIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgKiBzbGVlcCBtb3JlIHF1aWNrbHkuCj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCoKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBiKSBPbiBvbGRlciBjaGlwcyBm
dWxsIHNsZWVwIHJlc3VsdHMgYSB3ZWlyZCBiZWhhdmlvdXIKPiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgKiBkdXJpbmcgd2FrZXVwLiBJIHRlc3RlZCB2YXJpb3VzIGNhcmRzIHdpdGggc3JldiA8
IDB4NzgKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBhbmQgdGhleSBkb24ndCB3YWtlIHVw
IGFmdGVyIG1vZHVsZSByZWxvYWQsIGEgc2Vjb25kCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCogbW9kdWxlIHJlbG9hZCBpcyBuZWVkZWQgdG8gYnJpbmcgdGhlIGNhcmQgdXAgYWdhaW4uCj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCoKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBV
bnRpbCB3ZSBmaWd1cmUgb3V0IHdoYXQncyBnb2luZyBvbiBkb24ndCBlbmFibGUKPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgKiBmdWxsIGNoaXAgcmVzZXQgb24gYW55IGNoaXAgKHRoaXMgaXMg
d2hhdCBMZWdhY3kgSEFMCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogYW5kIFNhbSdzIEhB
TCBkbyBhbnl3YXkpLiBJbnN0ZWFkIFBlcmZvcm0gYSBmdWxsIHJlc2V0Cj4gKyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCogb24gdGhlIGRldmljZSAoc2FtZSBhcyBpbml0aWFsIHN0YXRlIGFmdGVy
IGF0dGFjaCkgYW5kCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogbGVhdmUgaXQgaWRsZSAo
a2VlcCBNQUMvQkIgb24gd2FybSByZXNldCkgKi8KPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJl
dCA9IGF0aDVrX2h3X29uX2hvbGQoc2MtPmFoKTsKPiArCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBBVEg1S19EQkcoc2MsIEFUSDVLX0RFQlVHX1JFU0VULAo+ICsgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgInB1dHRpbmcgZGV2aWNlIHRvIHNsZWVwXG4iKTsK
PiDCoCDCoCDCoCDCoH0KPiDCoCDCoCDCoCDCoGF0aDVrX3R4YnVmX2ZyZWUoc2MsIHNjLT5iYnVm
KTsKPgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRoNWsvcmVzZXQu
YyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGg1ay9yZXNldC5jCj4gaW5kZXggODY3MzNm
ZC4uMzRlMTNjNyAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRoNWsv
cmVzZXQuYwo+ICsrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGg1ay9yZXNldC5jCj4g
QEAgLTI1OCwyOSArMjU4LDM1IEBAIGludCBhdGg1a19od19zZXRfcG93ZXIoc3RydWN0IGF0aDVr
X2h3ICphaCwgZW51bSBhdGg1a19wb3dlcl9tb2RlIG1vZGUsCj4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBpZiAoIXNldF9jaGlwKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
Z290byBjb21taXQ7Cj4KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC8qIFByZXNlcnZlIHNsZWVw
IGR1cmF0aW9uICovCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkYXRhID0gYXRoNWtfaHdfcmVn
X3JlYWQoYWgsIEFSNUtfU0xFRVBfQ1RMKTsKPiArCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCAv
KiBJZiBjYXJkIGlzIGRvd24gd2UgJ2xsIGdldCAweGZmZmYuLi4gc28gd2UKPiArIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgKiBuZWVkIHRvIGNsZWFuIHRoaXMgdXAgYmVmb3JlIHdlIHdyaXRlIHRo
ZSByZWdpc3Rlcgo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqLwo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgaWYgKGRhdGEgJiAweGZmYzAwMDAwKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgZGF0YSA9IDA7Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBlbHNlCj4gLSDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkYXRhID0gZGF0YSAmIDB4ZmZmY2ZmZmY7
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAvKiBQcmVzZXJ2ZSBzbGVlcCBk
dXJhdGlvbiBldGMgKi8KPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRhdGEg
PSBkYXRhICYgfkFSNUtfU0xFRVBfQ1RMX1NMRTsKPgo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
YXRoNWtfaHdfcmVnX3dyaXRlKGFoLCBkYXRhLCBBUjVLX1NMRUVQX0NUTCk7Cj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCBhdGg1a19od19yZWdfd3JpdGUoYWgsIGRhdGEgfCBBUjVLX1NMRUVQX0NU
TF9TTEVfV0FLRSwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFSNUtfU0xFRVBfQ1RMKTsK
PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVkZWxheSgxNSk7Cj4KPiAtIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGZvciAoaSA9IDUwOyBpID4gMDsgaS0tKSB7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBmb3IgKGkgPSAyMDA7IGkgPiAwOyBpLS0pIHsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoC8qIENoZWNrIGlmIHRoZSBjaGlwIGRpZCB3YWtlIHVwICovCj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpZiAoKGF0aDVrX2h3X3JlZ19yZWFkKGFoLCBBUjVL
X1BDSUNGRykgJgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgQVI1S19QQ0lDRkdfU1BXUl9ETikgPT0gMCkKPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJyZWFrOwo+Cj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAvKiBXYWl0IGEgYml0IGFuZCByZXRyeSAqLwo+IC0gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWRlbGF5KDIwMCk7Cj4gLSDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhdGg1a19od19yZWdfd3JpdGUoYWgsIGRhdGEsIEFSNUtf
U0xFRVBfQ1RMKTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVkZWxheSg1
MCk7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhdGg1a19od19yZWdfd3Jp
dGUoYWgsIGRhdGEgfCBBUjVLX1NMRUVQX0NUTF9TTEVfV0FLRSwKPiArIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIEFSNUtfU0xFRVBfQ1RMKTsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoH0KPgo+
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLyogRmFpbCBpZiB0aGUgY2hpcCBkaWRuJ3Qgd2FrZSB1
cCAqLwo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWYgKGkgPD0gMCkKPiArIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIGlmIChpID09IDApCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqByZXR1cm4gLUVJTzsKPgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnJlYWs7Cj4gQEAgLTI5
Niw2ICszMDIsNjQgQEAgY29tbWl0Ogo+IMKgfQo+Cj4gwqAvKgo+ICsgKiBQdXQgZGV2aWNlIG9u
IGhvbGQKPiArICoKPiArICogUHV0IE1BQyBhbmQgQmFzZWJhbmQgb24gd2FybSByZXNldCBhbmQK
PiArICoga2VlcCB0aGF0IHN0YXRlIChkb24ndCBjbGVhbiBzbGVlcCBjb250cm9sCj4gKyAqIHJl
Z2lzdGVyKS4gQWZ0ZXIgdGhpcyBNQUMgYW5kIEJhc2ViYW5kIGFyZQo+ICsgKiBkaXNhYmxlZCBh
bmQgYSBmdWxsIHJlc2V0IGlzIG5lZWRlZCB0byBjb21lCj4gKyAqIGJhY2suIFRoaXMgd2F5IHdl
IHNhdmUgYXMgbXVjaCBwb3dlciBhcyBwb3NzaWJsZQo+ICsgKiB3aXRob3V0IHB1dGluZyB0aGUg
Y2FyZCBvbiBmdWxsIHNsZWVwLgo+ICsgKi8KPiAraW50IGF0aDVrX2h3X29uX2hvbGQoc3RydWN0
IGF0aDVrX2h3ICphaCkKPiArewo+ICsgwqAgwqAgwqAgc3RydWN0IHBjaV9kZXYgKnBkZXYgPSBh
aC0+YWhfc2MtPnBkZXY7Cj4gKyDCoCDCoCDCoCB1MzIgYnVzX2ZsYWdzOwo+ICsgwqAgwqAgwqAg
aW50IHJldDsKPiArCj4gKyDCoCDCoCDCoCAvKiBNYWtlIHN1cmUgZGV2aWNlIGlzIGF3YWtlICov
Cj4gKyDCoCDCoCDCoCByZXQgPSBhdGg1a19od19zZXRfcG93ZXIoYWgsIEFSNUtfUE1fQVdBS0Us
IHRydWUsIDApOwo+ICsgwqAgwqAgwqAgaWYgKHJldCkgewo+ICsgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgQVRINUtfRVJSKGFoLT5haF9zYywgImZhaWxlZCB0byB3YWtldXAgdGhlIE1BQyBDaGlwXG4i
KTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJldHVybiByZXQ7Cj4gKyDCoCDCoCDCoCB9Cj4g
Kwo+ICsgwqAgwqAgwqAgLyoKPiArIMKgIMKgIMKgIMKgKiBQdXQgY2hpcHNldCBvbiB3YXJtIHJl
c2V0Li4uCj4gKyDCoCDCoCDCoCDCoCoKPiArIMKgIMKgIMKgIMKgKiBOb3RlOiBwdXRpbmcgUENJ
IGNvcmUgb24gd2FybSByZXNldCBvbiBQQ0ktRSBjYXJkcwo+ICsgwqAgwqAgwqAgwqAqIHJlc3Vs
dHMgY2FyZCB0byBoYW5nIGFuZCBhbHdheXMgcmV0dXJuIDB4ZmZmZi4uLiBzbwo+ICsgwqAgwqAg
wqAgwqAqIHdlIGluZ29yZSB0aGF0IGZsYWcgZm9yIFBDSS1FIGNhcmRzLiBPbiBQQ0kgY2FyZHMK
PiArIMKgIMKgIMKgIMKgKiB0aGlzIGZsYWcgZ2V0cyBjbGVhcmVkIGFmdGVyIDY0IFBDSSBjbG9j
a3MuCj4gKyDCoCDCoCDCoCDCoCovCj4gKyDCoCDCoCDCoCBidXNfZmxhZ3MgPSAocGRldi0+aXNf
cGNpZSkgPyAwIDogQVI1S19SRVNFVF9DVExfUENJOwo+ICsKPiArIMKgIMKgIMKgIGlmIChhaC0+
YWhfdmVyc2lvbiA9PSBBUjVLX0FSNTIxMCkgewo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0
ID0gYXRoNWtfaHdfbmljX3Jlc2V0KGFoLCBBUjVLX1JFU0VUX0NUTF9QQ1UgfAo+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQVI1S19SRVNFVF9DVExfTUFDIHwgQVI1S19SRVNF
VF9DVExfRE1BIHwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFSNUtfUkVT
RVRfQ1RMX1BIWSB8IEFSNUtfUkVTRVRfQ1RMX1BDSSk7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCBtZGVsYXkoMik7Cj4gKyDCoCDCoCDCoCB9IGVsc2Ugewo+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgcmV0ID0gYXRoNWtfaHdfbmljX3Jlc2V0KGFoLCBBUjVLX1JFU0VUX0NU
TF9QQ1UgfAo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQVI1S19SRVNFVF9D
VExfQkFTRUJBTkQgfCBidXNfZmxhZ3MpOwo+ICsgwqAgwqAgwqAgfQo+ICsKPiArIMKgIMKgIMKg
IGlmIChyZXQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFUSDVLX0VSUihhaC0+YWhfc2Ms
ICJmYWlsZWQgdG8gcHV0IGRldmljZSBvbiB3YXJtIHJlc2V0XG4iKTsKPiArIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIHJldHVybiAtRUlPOwo+ICsgwqAgwqAgwqAgfQo+ICsKPiArIMKgIMKgIMKgIC8q
IC4uLndha2V1cCBhZ2FpbiEqLwo+ICsgwqAgwqAgwqAgcmV0ID0gYXRoNWtfaHdfc2V0X3Bvd2Vy
KGFoLCBBUjVLX1BNX0FXQUtFLCB0cnVlLCAwKTsKPiArIMKgIMKgIMKgIGlmIChyZXQpIHsKPiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFUSDVLX0VSUihhaC0+YWhfc2MsICJmYWlsZWQgdG8gcHV0
IGRldmljZSBvbiBob2xkXG4iKTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJldHVybiByZXQ7
Cj4gKyDCoCDCoCDCoCB9Cj4gKwo+ICsgwqAgwqAgwqAgcmV0dXJuIHJldDsKPiArfQo+ICsKPiAr
LyoKPiDCoCogQnJpbmcgdXAgTUFDICsgUEhZIENoaXBzIGFuZCBwcm9ncmFtIFBMTAo+IMKgKiBU
T0RPOiBIYWxmL1F1YXJ0ZXIgcmF0ZSBzdXBwb3J0Cj4gwqAqLwo+IEBAIC0zMTgsNiArMzgyLDUw
IEBAIGludCBhdGg1a19od19uaWNfd2FrZXVwKHN0cnVjdCBhdGg1a19odyAqYWgsIGludCBmbGFn
cywgYm9vbCBpbml0aWFsKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmV0dXJuIHJldDsKPiDC
oCDCoCDCoCDCoH0KPgo+ICsgwqAgwqAgwqAgLyoKPiArIMKgIMKgIMKgIMKgKiBQdXQgY2hpcHNl
dCBvbiB3YXJtIHJlc2V0Li4uCj4gKyDCoCDCoCDCoCDCoCoKPiArIMKgIMKgIMKgIMKgKiBOb3Rl
OiBwdXRpbmcgUENJIGNvcmUgb24gd2FybSByZXNldCBvbiBQQ0ktRSBjYXJkcwo+ICsgwqAgwqAg
wqAgwqAqIHJlc3VsdHMgY2FyZCB0byBoYW5nIGFuZCBhbHdheXMgcmV0dXJuIDB4ZmZmZi4uLiBz
bwo+ICsgwqAgwqAgwqAgwqAqIHdlIGluZ29yZSB0aGF0IGZsYWcgZm9yIFBDSS1FIGNhcmRzLiBP
biBQQ0kgY2FyZHMKPiArIMKgIMKgIMKgIMKgKiB0aGlzIGZsYWcgZ2V0cyBjbGVhcmVkIGFmdGVy
IDY0IFBDSSBjbG9ja3MuCj4gKyDCoCDCoCDCoCDCoCovCj4gKyDCoCDCoCDCoCBidXNfZmxhZ3Mg
PSAocGRldi0+aXNfcGNpZSkgPyAwIDogQVI1S19SRVNFVF9DVExfUENJOwo+ICsKPiArIMKgIMKg
IMKgIGlmIChhaC0+YWhfdmVyc2lvbiA9PSBBUjVLX0FSNTIxMCkgewo+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgcmV0ID0gYXRoNWtfaHdfbmljX3Jlc2V0KGFoLCBBUjVLX1JFU0VUX0NUTF9QQ1Ug
fAo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQVI1S19SRVNFVF9DVExfTUFD
IHwgQVI1S19SRVNFVF9DVExfRE1BIHwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIEFSNUtfUkVTRVRfQ1RMX1BIWSB8IEFSNUtfUkVTRVRfQ1RMX1BDSSk7Cj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtZGVsYXkoMik7Cj4gKyDCoCDCoCDCoCB9IGVsc2Ug
ewo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0ID0gYXRoNWtfaHdfbmljX3Jlc2V0KGFoLCBB
UjVLX1JFU0VUX0NUTF9QQ1UgfAo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
QVI1S19SRVNFVF9DVExfQkFTRUJBTkQgfCBidXNfZmxhZ3MpOwo+ICsgwqAgwqAgwqAgfQo+ICsK
PiArIMKgIMKgIMKgIGlmIChyZXQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFUSDVLX0VS
UihhaC0+YWhfc2MsICJmYWlsZWQgdG8gcmVzZXQgdGhlIE1BQyBDaGlwXG4iKTsKPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIHJldHVybiAtRUlPOwo+ICsgwqAgwqAgwqAgfQo+ICsKPiArIMKgIMKg
IMKgIC8qIC4uLndha2V1cCBhZ2FpbiEuLi4qLwo+ICsgwqAgwqAgwqAgcmV0ID0gYXRoNWtfaHdf
c2V0X3Bvd2VyKGFoLCBBUjVLX1BNX0FXQUtFLCB0cnVlLCAwKTsKPiArIMKgIMKgIMKgIGlmIChy
ZXQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFUSDVLX0VSUihhaC0+YWhfc2MsICJmYWls
ZWQgdG8gcmVzdW1lIHRoZSBNQUMgQ2hpcFxuIik7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBy
ZXR1cm4gcmV0Owo+ICsgwqAgwqAgwqAgfQo+ICsKPiArIMKgIMKgIMKgIC8qIC4uLmNsZWFyIHJl
c2V0IGNvbnRyb2wgcmVnaXN0ZXIgYW5kIHB1bGwgZGV2aWNlIG91dCBvZgo+ICsgwqAgwqAgwqAg
wqAqIHdhcm0gcmVzZXQgKi8KPiArIMKgIMKgIMKgIGlmIChhdGg1a19od19uaWNfcmVzZXQoYWgs
IDApKSB7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBVEg1S19FUlIoYWgtPmFoX3NjLCAiZmFp
bGVkIHRvIHdhcm0gcmVzZXQgdGhlIE1BQyBDaGlwXG4iKTsKPiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIHJldHVybiAtRUlPOwo+ICsgwqAgwqAgwqAgfQo+ICsKPiArIMKgIMKgIMKgIC8qIE9uIGlu
aXRpYWxpemF0aW9uIHNraXAgUExMIHByb2dyYW1taW5nIHNpbmNlIHdlIGRvbid0IGhhdmUKPiAr
IMKgIMKgIMKgIMKgKiBhIGNoYW5uZWwgLyBtb2RlIHNldCB5ZXQgKi8KPiArIMKgIMKgIMKgIGlm
IChpbml0aWFsKQo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0dXJuIDA7Cj4gKwo+IMKgIMKg
IMKgIMKgaWYgKGFoLT5haF92ZXJzaW9uICE9IEFSNUtfQVI1MjEwKSB7Cj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAvKgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogR2V0IGNoYW5uZWwgbW9k
ZSBmbGFncwo+IEBAIC0zODMsMzkgKzQ5MSw2IEBAIGludCBhdGg1a19od19uaWNfd2FrZXVwKHN0
cnVjdCBhdGg1a19odyAqYWgsIGludCBmbGFncywgYm9vbCBpbml0aWFsKQo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQVI1S19QSFlf
VFVSQk8pOwo+IMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCAvKiByZXNldGluZyBQQ0kgb24g
UENJLUUgY2FyZHMgcmVzdWx0cyBjYXJkIHRvIGhhbmcKPiAtIMKgIMKgIMKgIMKgKiBhbmQgYWx3
YXlzIHJldHVybiAweGZmZmYuLi4gc28gd2UgaW5nb3JlIHRoYXQgZmxhZwo+IC0gwqAgwqAgwqAg
wqAqIGZvciBQQ0ktRSBjYXJkcyAqLwo+IC0gwqAgwqAgwqAgYnVzX2ZsYWdzID0gKHBkZXYtPmlz
X3BjaWUpID8gMCA6IEFSNUtfUkVTRVRfQ1RMX1BDSTsKPiAtCj4gLSDCoCDCoCDCoCAvKiBSZXNl
dCBjaGlwc2V0ICovCj4gLSDCoCDCoCDCoCBpZiAoYWgtPmFoX3ZlcnNpb24gPT0gQVI1S19BUjUy
MTApIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJldCA9IGF0aDVrX2h3X25pY19yZXNldChh
aCwgQVI1S19SRVNFVF9DVExfUENVIHwKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIEFSNUtfUkVTRVRfQ1RMX01BQyB8IEFSNUtfUkVTRVRfQ1RMX0RNQSB8Cj4gLSDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBUjVLX1JFU0VUX0NUTF9QSFkgfCBBUjVLX1JFU0VU
X0NUTF9QQ0kpOwo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbWRlbGF5KDIp
Owo+IC0gwqAgwqAgwqAgfSBlbHNlIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJldCA9IGF0
aDVrX2h3X25pY19yZXNldChhaCwgQVI1S19SRVNFVF9DVExfUENVIHwKPiAtIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFSNUtfUkVTRVRfQ1RMX0JBU0VCQU5EIHwgYnVzX2ZsYWdz
KTsKPiAtIMKgIMKgIMKgIH0KPiAtIMKgIMKgIMKgIGlmIChyZXQpIHsKPiAtIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIEFUSDVLX0VSUihhaC0+YWhfc2MsICJmYWlsZWQgdG8gcmVzZXQgdGhlIE1BQyBD
aGlwXG4iKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJldHVybiAtRUlPOwo+IC0gwqAgwqAg
wqAgfQo+IC0KPiAtIMKgIMKgIMKgIC8qIC4uLndha2V1cCBhZ2FpbiEqLwo+IC0gwqAgwqAgwqAg
cmV0ID0gYXRoNWtfaHdfc2V0X3Bvd2VyKGFoLCBBUjVLX1BNX0FXQUtFLCB0cnVlLCAwKTsKPiAt
IMKgIMKgIMKgIGlmIChyZXQpIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFUSDVLX0VSUihh
aC0+YWhfc2MsICJmYWlsZWQgdG8gcmVzdW1lIHRoZSBNQUMgQ2hpcFxuIik7Cj4gLSDCoCDCoCDC
oCDCoCDCoCDCoCDCoCByZXR1cm4gcmV0Owo+IC0gwqAgwqAgwqAgfQo+IC0KPiAtIMKgIMKgIMKg
IC8qIC4uLmZpbmFsIHdhcm0gcmVzZXQgKi8KPiAtIMKgIMKgIMKgIGlmIChhdGg1a19od19uaWNf
cmVzZXQoYWgsIDApKSB7Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBVEg1S19FUlIoYWgtPmFo
X3NjLCAiZmFpbGVkIHRvIHdhcm0gcmVzZXQgdGhlIE1BQyBDaGlwXG4iKTsKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIHJldHVybiAtRUlPOwo+IC0gwqAgwqAgwqAgfQo+IC0KPiDCoCDCoCDCoCDC
oGlmIChhaC0+YWhfdmVyc2lvbiAhPSBBUjVLX0FSNTIxMCkgewo+Cj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAvKiAuLi51cGRhdGUgUExMIGlmIG5lZWRlZCAqLwo+Cg==
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 2/4] ath5k: Linear PCDAC code fixes
From: Nick Kossifidis @ 2009-07-31 18:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: ath5k-devel, linux-wireless, linville, jirislaby, me, nbd
In-Reply-To: <43e72e890907311107h56add3d9i9d7e825f55c8c40d@mail.gmail.com>
2009/7/31 Luis R. Rodriguez <mcgrof@gmail.com>:
> On Fri, Jul 31, 2009 at 11:05 AM, Nick
> Kossifidis<mick@madwifi-project.org> wrote:
>> * Set correct xpd curve indices for high/low gain curves during
>> rfbuffer setup on RF5112B with both calibration curves available.
>>
>> * Don't return zero min power when we have the same pcdac value
>> twice because it breaks interpolation. Instead return the right
>> x barrier as we do when we have equal power levels for 2 different
>> pcdac values.
>> ---
>> drivers/net/wireless/ath/ath5k/phy.c | 24 +++++++++++++++++-------
>> 1 files changed, 17 insertions(+), 7 deletions(-)
>
> Missing SOB
>
> Luis
Grrr, sorry ppl, resending...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 1/4]: Check EEPROM before tweaking SERDES
From: Luis R. Rodriguez @ 2009-07-31 18:11 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731180238.GA7963@makis>
On Fri, Jul 31, 2009 at 11:02 AM, Nick
Kossifidis<mick@madwifi-project.org> wrote:
> * Read PCI-E infos offset from EEPROM and if it points to
> serdes section (0x40), enable serdes programming (further
> tweaking of serdes values during attach). This follows
> Legacy and Sam's HAL sources.
>
> ---
> drivers/net/wireless/ath/ath5k/attach.c | 56 +++++++++++++++++++------------
> drivers/net/wireless/ath/ath5k/eeprom.c | 10 +++++
> drivers/net/wireless/ath/ath5k/eeprom.h | 4 ++
> 3 files changed, 48 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
> index 9a84d94..6263065 100644
> --- a/drivers/net/wireless/ath/ath5k/attach.c
> +++ b/drivers/net/wireless/ath/ath5k/attach.c
> @@ -253,28 +253,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> }
>
> /*
> - * Write PCI-E power save settings
> - */
> - if ((ah->ah_version == AR5K_AR5212) && (pdev->is_pcie)) {
> - ath5k_hw_reg_write(ah, 0x9248fc00, AR5K_PCIE_SERDES);
> - ath5k_hw_reg_write(ah, 0x24924924, AR5K_PCIE_SERDES);
> - /* Shut off RX when elecidle is asserted */
> - ath5k_hw_reg_write(ah, 0x28000039, AR5K_PCIE_SERDES);
> - ath5k_hw_reg_write(ah, 0x53160824, AR5K_PCIE_SERDES);
> - /* TODO: EEPROM work */
> - ath5k_hw_reg_write(ah, 0xe5980579, AR5K_PCIE_SERDES);
> - /* Shut off PLL and CLKREQ active in L1 */
> - ath5k_hw_reg_write(ah, 0x001defff, AR5K_PCIE_SERDES);
> - /* Preserce other settings */
> - ath5k_hw_reg_write(ah, 0x1aaabe40, AR5K_PCIE_SERDES);
> - ath5k_hw_reg_write(ah, 0xbe105554, AR5K_PCIE_SERDES);
> - ath5k_hw_reg_write(ah, 0x000e3007, AR5K_PCIE_SERDES);
> - /* Reset SERDES to load new settings */
> - ath5k_hw_reg_write(ah, 0x00000000, AR5K_PCIE_SERDES_RESET);
> - mdelay(1);
> - }
> -
> - /*
> * POST
> */
> ret = ath5k_hw_post(ah);
Can the changes for the code be done before the move, or after so that
way the actual code changes to the section can be easily readable?
> @@ -295,6 +273,40 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> goto err_free;
> }
>
> + /*
> + * Write PCI-E power save settings
> + */
> + if ((ah->ah_version == AR5K_AR5212) && (pdev->is_pcie)) {
> + struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
> +
> + ath5k_hw_reg_write(ah, 0x9248fc00, AR5K_PCIE_SERDES);
> + ath5k_hw_reg_write(ah, 0x24924924, AR5K_PCIE_SERDES);
> +
> + /* Shut off RX when elecidle is asserted */
> + ath5k_hw_reg_write(ah, 0x28000039, AR5K_PCIE_SERDES);
> + ath5k_hw_reg_write(ah, 0x53160824, AR5K_PCIE_SERDES);
> +
> + /* If serdes programing is enabled, increase PCI-E
> + * tx power for systems with long trace from host
> + * to minicard connector. */
This is just comment-picky mind using this style for comments for > 1 lines?
/*
* foo bleh buh
* bar
* qwerty
*/
Luis
^ permalink raw reply
* [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Nick Kossifidis @ 2009-07-31 18:10 UTC (permalink / raw)
To: ath5k-devel, linux-wireless; +Cc: linville, jirislaby, me, mcgrof, nbd
* Get rid of calibration timer, instead use a software interrupt
to schedule the calibration tasklet.
---
drivers/net/wireless/ath/ath5k/ath5k.h | 16 ++++++++++++++++
drivers/net/wireless/ath/ath5k/base.c | 28 ++++++++++++++++++----------
drivers/net/wireless/ath/ath5k/base.h | 3 ++-
drivers/net/wireless/ath/ath5k/phy.c | 20 ++++++++++++++++++++
4 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 1047a6c..76cf5b2 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -919,6 +919,12 @@ enum ath5k_int {
AR5K_INT_NOCARD = 0xffffffff
};
+/* Software interrupts used for calibration */
+enum ath5k_software_interrupt {
+ AR5K_SWI_FULL_CALIBRATION = 0x01,
+ AR5K_SWI_SHORT_CALIBRATION = 0x02,
+};
+
/*
* Power management
*/
@@ -1123,6 +1129,15 @@ struct ath5k_hw {
/* noise floor from last periodic calibration */
s32 ah_noise_floor;
+ /* Calibration timestamp */
+ u32 ah_cal_tstamp;
+
+ /* Calibration interval (secs) */
+ u8 ah_cal_intval;
+
+ /* Software interrupt mask */
+ u8 ah_swi_mask;
+
/*
* Function pointers
*/
@@ -1276,6 +1291,7 @@ extern int ath5k_hw_channel(struct ath5k_hw *ah, struct ieee80211_channel *chann
/* PHY calibration */
extern int ath5k_hw_phy_calibrate(struct ath5k_hw *ah, struct ieee80211_channel *channel);
extern int ath5k_hw_noise_floor_calibration(struct ath5k_hw *ah, short freq);
+extern void ath5k_hw_calibration_poll(struct ath5k_hw *ah);
/* Spur mitigation */
bool ath5k_hw_chan_has_spur_noise(struct ath5k_hw *ah,
struct ieee80211_channel *channel);
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index b64731b..02fa71a 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -59,7 +59,7 @@
#include "reg.h"
#include "debug.h"
-static int ath5k_calinterval = 10; /* Calibrate PHY every 10 secs (TODO: Fixme) */
+static u8 ath5k_calinterval = 10; /* Calibrate PHY every 10 secs (TODO: Fixme) */
static int modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
@@ -376,7 +376,7 @@ static int ath5k_stop_hw(struct ath5k_softc *sc);
static irqreturn_t ath5k_intr(int irq, void *dev_id);
static void ath5k_tasklet_reset(unsigned long data);
-static void ath5k_calibrate(unsigned long data);
+static void ath5k_tasklet_calibrate(unsigned long data);
/*
* Module init/exit functions
@@ -799,8 +799,8 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
tasklet_init(&sc->rxtq, ath5k_tasklet_rx, (unsigned long)sc);
tasklet_init(&sc->txtq, ath5k_tasklet_tx, (unsigned long)sc);
tasklet_init(&sc->restq, ath5k_tasklet_reset, (unsigned long)sc);
+ tasklet_init(&sc->calib, ath5k_tasklet_calibrate, (unsigned long)sc);
tasklet_init(&sc->beacontq, ath5k_tasklet_beacon, (unsigned long)sc);
- setup_timer(&sc->calib_tim, ath5k_calibrate, (unsigned long)sc);
ret = ath5k_eeprom_read_mac(ah, mac);
if (ret) {
@@ -2366,7 +2366,7 @@ ath5k_init(struct ath5k_softc *sc)
sc->curband = &sc->sbands[sc->curchan->band];
sc->imask = AR5K_INT_RXOK | AR5K_INT_RXERR | AR5K_INT_RXEOL |
AR5K_INT_RXORN | AR5K_INT_TXDESC | AR5K_INT_TXEOL |
- AR5K_INT_FATAL | AR5K_INT_GLOBAL;
+ AR5K_INT_FATAL | AR5K_INT_GLOBAL | AR5K_INT_SWI;
ret = ath5k_reset(sc, NULL);
if (ret)
goto done;
@@ -2383,8 +2383,8 @@ ath5k_init(struct ath5k_softc *sc)
/* Set ack to be sent at low bit-rates */
ath5k_hw_set_ack_bitrate_high(ah, false);
- mod_timer(&sc->calib_tim, round_jiffies(jiffies +
- msecs_to_jiffies(ath5k_calinterval * 1000)));
+ /* Set PHY calibration timestamp and inteval */
+ ah->ah_cal_intval = ath5k_calinterval;
ret = 0;
done:
@@ -2477,7 +2477,6 @@ ath5k_stop_hw(struct ath5k_softc *sc)
mmiowb();
mutex_unlock(&sc->lock);
- del_timer_sync(&sc->calib_tim);
tasklet_kill(&sc->rxtq);
tasklet_kill(&sc->txtq);
tasklet_kill(&sc->restq);
@@ -2536,6 +2535,9 @@ ath5k_intr(int irq, void *dev_id)
if (status & AR5K_INT_BMISS) {
/* TODO */
}
+ if (status & AR5K_INT_SWI) {
+ tasklet_schedule(&sc->calib);
+ }
if (status & AR5K_INT_MIB) {
/*
* These stats are also used for ANI i think
@@ -2552,6 +2554,8 @@ ath5k_intr(int irq, void *dev_id)
if (unlikely(!counter))
ATH5K_WARN(sc, "too many interrupts, giving up for now\n");
+ ath5k_hw_calibration_poll(ah);
+
return IRQ_HANDLED;
}
@@ -2568,11 +2572,15 @@ ath5k_tasklet_reset(unsigned long data)
* for temperature/environment changes.
*/
static void
-ath5k_calibrate(unsigned long data)
+ath5k_tasklet_calibrate(unsigned long data)
{
struct ath5k_softc *sc = (void *)data;
struct ath5k_hw *ah = sc->ah;
+ /* Only full calibration for now */
+ if (ah->ah_swi_mask != AR5K_SWI_FULL_CALIBRATION)
+ return;
+
ATH5K_DBG(sc, ATH5K_DEBUG_CALIBRATE, "channel %u/%x\n",
ieee80211_frequency_to_channel(sc->curchan->center_freq),
sc->curchan->hw_value);
@@ -2590,8 +2598,8 @@ ath5k_calibrate(unsigned long data)
ieee80211_frequency_to_channel(
sc->curchan->center_freq));
- mod_timer(&sc->calib_tim, round_jiffies(jiffies +
- msecs_to_jiffies(ath5k_calinterval * 1000)));
+ ah->ah_swi_mask = 0;
+
}
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 778e422..667bd9d 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -177,6 +177,8 @@ struct ath5k_softc {
struct ath5k_rfkill rf_kill;
+ struct tasklet_struct calib; /* calibration tasklet */
+
spinlock_t block; /* protects beacon */
struct tasklet_struct beacontq; /* beacon intr tasklet */
struct ath5k_buf *bbuf; /* beacon buffer */
@@ -187,7 +189,6 @@ struct ath5k_softc {
unsigned int nexttbtt; /* next beacon time in TU */
struct ath5k_txq *cabq; /* content after beacon */
- struct timer_list calib_tim; /* calibration timer */
int power_level; /* Requested tx power in dbm */
bool assoc; /* assocate state */
bool enable_beacon; /* true if beacons are on */
diff --git a/drivers/net/wireless/ath/ath5k/phy.c b/drivers/net/wireless/ath/ath5k/phy.c
index 6afba98..d30bc3b 100644
--- a/drivers/net/wireless/ath/ath5k/phy.c
+++ b/drivers/net/wireless/ath/ath5k/phy.c
@@ -1104,6 +1104,26 @@ int ath5k_hw_channel(struct ath5k_hw *ah, struct ieee80211_channel *channel)
PHY calibration
\*****************/
+void
+ath5k_hw_calibration_poll(struct ath5k_hw *ah)
+{
+ u32 current_time = (jiffies / HZ);
+ u32 cal_intval = ah->ah_cal_intval;
+
+ if (!ah->ah_cal_tstamp)
+ ah->ah_cal_tstamp = current_time;
+
+ /* For now we always do full calibration
+ * Mark software interrupt mask and fire software
+ * interrupt (bit gets auto-cleared) */
+ if ((current_time - ah->ah_cal_tstamp) >= cal_intval) {
+ ah->ah_cal_tstamp = current_time;
+ ah->ah_swi_mask = AR5K_SWI_FULL_CALIBRATION;
+ AR5K_REG_ENABLE_BITS(ah, AR5K_CR, AR5K_CR_SWI);
+ }
+
+}
+
/**
* ath5k_hw_noise_floor_calibration - perform PHY noise floor calibration
*
^ permalink raw reply related
* [PATCH 3/4] ath5k: Wakeup fixes
From: Nick Kossifidis @ 2009-07-31 18:08 UTC (permalink / raw)
To: ath5k-devel, linux-wireless; +Cc: linville, jirislaby, me, mcgrof, nbd
* Don't put chip to full sleep because there are problems during
wakeup. Instead hold MAC/Baseband on warm reset state via a new
function ath5k_hw_on_hold.
* Durring attach preserve pcicfg bits when enabling pci core
sw retry fix.
* Minor cleanups
---
drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
drivers/net/wireless/ath/ath5k/attach.c | 4 +-
drivers/net/wireless/ath/ath5k/base.c | 44 +++++----
drivers/net/wireless/ath/ath5k/reset.c | 155 +++++++++++++++++++++++--------
4 files changed, 141 insertions(+), 63 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 9137511..1047a6c 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1157,6 +1157,7 @@ extern void ath5k_unregister_leds(struct ath5k_softc *sc);
/* Reset Functions */
extern int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial);
+extern int ath5k_hw_on_hold(struct ath5k_hw *ah);
extern int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode, struct ieee80211_channel *channel, bool change_channel);
/* Power management functions */
extern int ath5k_hw_set_power(struct ath5k_hw *ah, enum ath5k_power_mode mode, bool set_chip, u16 sleep_duration);
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index 6263065..65d438b 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -145,7 +145,7 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
goto err_free;
/* Bring device out of sleep and reset it's units */
- ret = ath5k_hw_nic_wakeup(ah, CHANNEL_B, true);
+ ret = ath5k_hw_nic_wakeup(ah, 0, true);
if (ret)
goto err_free;
@@ -261,7 +261,7 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
/* Enable pci core retry fix on Hainan (5213A) and later chips */
if (srev >= AR5K_SREV_AR5213A)
- ath5k_hw_reg_write(ah, AR5K_PCICFG_RETRY_FIX, AR5K_PCICFG);
+ AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, AR5K_PCICFG_RETRY_FIX);
/*
* Get card capabilities, calibration values etc
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 7db32ce..b64731b 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2448,27 +2448,29 @@ ath5k_stop_hw(struct ath5k_softc *sc)
ret = ath5k_stop_locked(sc);
if (ret == 0 && !test_bit(ATH_STAT_INVALID, sc->status)) {
/*
- * Set the chip in full sleep mode. Note that we are
- * careful to do this only when bringing the interface
- * completely to a stop. When the chip is in this state
- * it must be carefully woken up or references to
- * registers in the PCI clock domain may freeze the bus
- * (and system). This varies by chip and is mostly an
- * issue with newer parts that go to sleep more quickly.
- */
- if (sc->ah->ah_mac_srev >= 0x78) {
- /*
- * XXX
- * don't put newer MAC revisions > 7.8 to sleep because
- * of the above mentioned problems
- */
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "mac version > 7.8, "
- "not putting device to sleep\n");
- } else {
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
- "putting device to full sleep\n");
- ath5k_hw_set_power(sc->ah, AR5K_PM_FULL_SLEEP, true, 0);
- }
+ * Don't set the card in full sleep mode!
+ *
+ * a) When the device is in this state it must be carefully
+ * woken up or references to registers in the PCI clock
+ * domain may freeze the bus (and system). This varies
+ * by chip and is mostly an issue with newer parts
+ * (madwifi sources mentioned srev >= 0x78) that go to
+ * sleep more quickly.
+ *
+ * b) On older chips full sleep results a weird behaviour
+ * during wakeup. I tested various cards with srev < 0x78
+ * and they don't wake up after module reload, a second
+ * module reload is needed to bring the card up again.
+ *
+ * Until we figure out what's going on don't enable
+ * full chip reset on any chip (this is what Legacy HAL
+ * and Sam's HAL do anyway). Instead Perform a full reset
+ * on the device (same as initial state after attach) and
+ * leave it idle (keep MAC/BB on warm reset) */
+ ret = ath5k_hw_on_hold(sc->ah);
+
+ ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
+ "putting device to sleep\n");
}
ath5k_txbuf_free(sc, sc->bbuf);
diff --git a/drivers/net/wireless/ath/ath5k/reset.c b/drivers/net/wireless/ath/ath5k/reset.c
index 86733fd..34e13c7 100644
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -258,29 +258,35 @@ int ath5k_hw_set_power(struct ath5k_hw *ah, enum ath5k_power_mode mode,
if (!set_chip)
goto commit;
- /* Preserve sleep duration */
data = ath5k_hw_reg_read(ah, AR5K_SLEEP_CTL);
+
+ /* If card is down we 'll get 0xffff... so we
+ * need to clean this up before we write the register
+ */
if (data & 0xffc00000)
data = 0;
else
- data = data & 0xfffcffff;
+ /* Preserve sleep duration etc */
+ data = data & ~AR5K_SLEEP_CTL_SLE;
- ath5k_hw_reg_write(ah, data, AR5K_SLEEP_CTL);
+ ath5k_hw_reg_write(ah, data | AR5K_SLEEP_CTL_SLE_WAKE,
+ AR5K_SLEEP_CTL);
udelay(15);
- for (i = 50; i > 0; i--) {
+ for (i = 200; i > 0; i--) {
/* Check if the chip did wake up */
if ((ath5k_hw_reg_read(ah, AR5K_PCICFG) &
AR5K_PCICFG_SPWR_DN) == 0)
break;
/* Wait a bit and retry */
- udelay(200);
- ath5k_hw_reg_write(ah, data, AR5K_SLEEP_CTL);
+ udelay(50);
+ ath5k_hw_reg_write(ah, data | AR5K_SLEEP_CTL_SLE_WAKE,
+ AR5K_SLEEP_CTL);
}
/* Fail if the chip didn't wake up */
- if (i <= 0)
+ if (i == 0)
return -EIO;
break;
@@ -296,6 +302,64 @@ commit:
}
/*
+ * Put device on hold
+ *
+ * Put MAC and Baseband on warm reset and
+ * keep that state (don't clean sleep control
+ * register). After this MAC and Baseband are
+ * disabled and a full reset is needed to come
+ * back. This way we save as much power as possible
+ * without puting the card on full sleep.
+ */
+int ath5k_hw_on_hold(struct ath5k_hw *ah)
+{
+ struct pci_dev *pdev = ah->ah_sc->pdev;
+ u32 bus_flags;
+ int ret;
+
+ /* Make sure device is awake */
+ ret = ath5k_hw_set_power(ah, AR5K_PM_AWAKE, true, 0);
+ if (ret) {
+ ATH5K_ERR(ah->ah_sc, "failed to wakeup the MAC Chip\n");
+ return ret;
+ }
+
+ /*
+ * Put chipset on warm reset...
+ *
+ * Note: puting PCI core on warm reset on PCI-E cards
+ * results card to hang and always return 0xffff... so
+ * we ingore that flag for PCI-E cards. On PCI cards
+ * this flag gets cleared after 64 PCI clocks.
+ */
+ bus_flags = (pdev->is_pcie) ? 0 : AR5K_RESET_CTL_PCI;
+
+ if (ah->ah_version == AR5K_AR5210) {
+ ret = ath5k_hw_nic_reset(ah, AR5K_RESET_CTL_PCU |
+ AR5K_RESET_CTL_MAC | AR5K_RESET_CTL_DMA |
+ AR5K_RESET_CTL_PHY | AR5K_RESET_CTL_PCI);
+ mdelay(2);
+ } else {
+ ret = ath5k_hw_nic_reset(ah, AR5K_RESET_CTL_PCU |
+ AR5K_RESET_CTL_BASEBAND | bus_flags);
+ }
+
+ if (ret) {
+ ATH5K_ERR(ah->ah_sc, "failed to put device on warm reset\n");
+ return -EIO;
+ }
+
+ /* ...wakeup again!*/
+ ret = ath5k_hw_set_power(ah, AR5K_PM_AWAKE, true, 0);
+ if (ret) {
+ ATH5K_ERR(ah->ah_sc, "failed to put device on hold\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+/*
* Bring up MAC + PHY Chips and program PLL
* TODO: Half/Quarter rate support
*/
@@ -318,6 +382,50 @@ int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
return ret;
}
+ /*
+ * Put chipset on warm reset...
+ *
+ * Note: puting PCI core on warm reset on PCI-E cards
+ * results card to hang and always return 0xffff... so
+ * we ingore that flag for PCI-E cards. On PCI cards
+ * this flag gets cleared after 64 PCI clocks.
+ */
+ bus_flags = (pdev->is_pcie) ? 0 : AR5K_RESET_CTL_PCI;
+
+ if (ah->ah_version == AR5K_AR5210) {
+ ret = ath5k_hw_nic_reset(ah, AR5K_RESET_CTL_PCU |
+ AR5K_RESET_CTL_MAC | AR5K_RESET_CTL_DMA |
+ AR5K_RESET_CTL_PHY | AR5K_RESET_CTL_PCI);
+ mdelay(2);
+ } else {
+ ret = ath5k_hw_nic_reset(ah, AR5K_RESET_CTL_PCU |
+ AR5K_RESET_CTL_BASEBAND | bus_flags);
+ }
+
+ if (ret) {
+ ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip\n");
+ return -EIO;
+ }
+
+ /* ...wakeup again!...*/
+ ret = ath5k_hw_set_power(ah, AR5K_PM_AWAKE, true, 0);
+ if (ret) {
+ ATH5K_ERR(ah->ah_sc, "failed to resume the MAC Chip\n");
+ return ret;
+ }
+
+ /* ...clear reset control register and pull device out of
+ * warm reset */
+ if (ath5k_hw_nic_reset(ah, 0)) {
+ ATH5K_ERR(ah->ah_sc, "failed to warm reset the MAC Chip\n");
+ return -EIO;
+ }
+
+ /* On initialization skip PLL programming since we don't have
+ * a channel / mode set yet */
+ if (initial)
+ return 0;
+
if (ah->ah_version != AR5K_AR5210) {
/*
* Get channel mode flags
@@ -383,39 +491,6 @@ int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
AR5K_PHY_TURBO);
}
- /* reseting PCI on PCI-E cards results card to hang
- * and always return 0xffff... so we ingore that flag
- * for PCI-E cards */
- bus_flags = (pdev->is_pcie) ? 0 : AR5K_RESET_CTL_PCI;
-
- /* Reset chipset */
- if (ah->ah_version == AR5K_AR5210) {
- ret = ath5k_hw_nic_reset(ah, AR5K_RESET_CTL_PCU |
- AR5K_RESET_CTL_MAC | AR5K_RESET_CTL_DMA |
- AR5K_RESET_CTL_PHY | AR5K_RESET_CTL_PCI);
- mdelay(2);
- } else {
- ret = ath5k_hw_nic_reset(ah, AR5K_RESET_CTL_PCU |
- AR5K_RESET_CTL_BASEBAND | bus_flags);
- }
- if (ret) {
- ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip\n");
- return -EIO;
- }
-
- /* ...wakeup again!*/
- ret = ath5k_hw_set_power(ah, AR5K_PM_AWAKE, true, 0);
- if (ret) {
- ATH5K_ERR(ah->ah_sc, "failed to resume the MAC Chip\n");
- return ret;
- }
-
- /* ...final warm reset */
- if (ath5k_hw_nic_reset(ah, 0)) {
- ATH5K_ERR(ah->ah_sc, "failed to warm reset the MAC Chip\n");
- return -EIO;
- }
-
if (ah->ah_version != AR5K_AR5210) {
/* ...update PLL if needed */
^ permalink raw reply related
* Re: [PATCH 2/4] ath5k: Linear PCDAC code fixes
From: Luis R. Rodriguez @ 2009-07-31 18:07 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731180556.GC7963@makis>
On Fri, Jul 31, 2009 at 11:05 AM, Nick
Kossifidis<mick@madwifi-project.org> wrote:
> * Set correct xpd curve indices for high/low gain curves during
> rfbuffer setup on RF5112B with both calibration curves available.
>
> * Don't return zero min power when we have the same pcdac value
> twice because it breaks interpolation. Instead return the right
> x barrier as we do when we have equal power levels for 2 different
> pcdac values.
> ---
> drivers/net/wireless/ath/ath5k/phy.c | 24 +++++++++++++++++-------
> 1 files changed, 17 insertions(+), 7 deletions(-)
Missing SOB
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 17:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249062751.14242.2.camel@johannes.local>
On Fri, Jul 31, 2009 at 10:52 AM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-30 at 17:43 -0700, Luis R. Rodriguez wrote:
>> A regression was added through patch a4ed90d6:
>>
>> "cfg80211: respect API on orig_flags on channel for beacon hint"
>>
>> We did indeed respect _orig flags but the intention was not clearly
>> stated in the commit log. This patch fixes firmware issues picked
>> up by iwlwifi when we lift passive scan of beaconing restrictions
>> on channels its EEPROM has been configured to always enable.
>>
>> By doing so though we also disallowed beacon hints on devices
>> registering their wiphy with custom world regulatory domains
>> enabled, this happens to be currently ath5k, ath9k and ar9170.
>> The passive scan and beacon restrictions on those devices would
>> never be lifted even if we did find a beacon and the hardware did
>> support such enhancements when world roaming.
>>
>> Since Johannes indicates iwlwifi firmware cannot be changed to
>> allow beacon hinting we set up a flag now to specifically allow
>> drivers to disable beacon hints for devices which cannot use them.
>>
>> We enable the flag on iwlwifi to disable beacon hints and by default
>> enable it for all other drivers. It should be noted beacon hints lift
>> passive scan flags and beacon restrictions when we receive a beacon from
>> an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
>> band. We don't bother with channels 1-11 as those channels are allowed
>> world wide.
>>
>> This should fix world roaming for ath5k, ath9k and ar9170, thereby
>> improving scan time when we receive the first beacon from any AP,
>> and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
>> would otherwise not be allowed to do so. Drivers not using custom
>> regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
>> by this as the orig_flags for the channels would have been cleared
>> upon wiphy registration.
>
> Ok, so after all the discussion this seems like the best option after
> all.
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Thanks for the review.
> except I'm not sure about this bit:
>
>> chan->beacon_found = true;
>>
>> + if (wiphy->disable_beacon_hints)
>> + return;
>
> seems like the if might need to be before beacon_found=true?
Nope, we need to ensure chan->beacon_found is set so that we don't
bother processing a beacon on this channel anymore. It saves iwlwifi
from triggering beacon hints onto the workqueue.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Johannes Berg @ 2009-07-31 17:52 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249001028-15110-1-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]
On Thu, 2009-07-30 at 17:43 -0700, Luis R. Rodriguez wrote:
> A regression was added through patch a4ed90d6:
>
> "cfg80211: respect API on orig_flags on channel for beacon hint"
>
> We did indeed respect _orig flags but the intention was not clearly
> stated in the commit log. This patch fixes firmware issues picked
> up by iwlwifi when we lift passive scan of beaconing restrictions
> on channels its EEPROM has been configured to always enable.
>
> By doing so though we also disallowed beacon hints on devices
> registering their wiphy with custom world regulatory domains
> enabled, this happens to be currently ath5k, ath9k and ar9170.
> The passive scan and beacon restrictions on those devices would
> never be lifted even if we did find a beacon and the hardware did
> support such enhancements when world roaming.
>
> Since Johannes indicates iwlwifi firmware cannot be changed to
> allow beacon hinting we set up a flag now to specifically allow
> drivers to disable beacon hints for devices which cannot use them.
>
> We enable the flag on iwlwifi to disable beacon hints and by default
> enable it for all other drivers. It should be noted beacon hints lift
> passive scan flags and beacon restrictions when we receive a beacon from
> an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
> band. We don't bother with channels 1-11 as those channels are allowed
> world wide.
>
> This should fix world roaming for ath5k, ath9k and ar9170, thereby
> improving scan time when we receive the first beacon from any AP,
> and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
> would otherwise not be allowed to do so. Drivers not using custom
> regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
> by this as the orig_flags for the channels would have been cleared
> upon wiphy registration.
Ok, so after all the discussion this seems like the best option after
all.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
except I'm not sure about this bit:
> chan->beacon_found = true;
>
> + if (wiphy->disable_beacon_hints)
> + return;
seems like the if might need to be before beacon_found=true?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 17:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <43e72e890907311028t5087b8bj9b685795e0528151@mail.gmail.com>
On Fri, Jul 31, 2009 at 10:28 AM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> On Fri, Jul 31, 2009 at 9:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Fri, 2009-07-31 at 09:32 -0700, Luis R. Rodriguez wrote:
>>
>>> Its not that simple. Consider the fact we build our own custom
>>> regulatory domain and stuff what is intended for each one of them. The
>>> _orig stuff is set upon channel registration so it is correct that
>>> we'd have to avoid setting the channel flags prior to wiphy
>>> registration. How you do that is left up to implementation. Since
>>> cfg80211 will set the channel *_orig params based on
>>> wiphy_registration() you're only option is to either prevent your
>>> wiphy being registered with the flags set or to reset the channel
>>> flags on the reg_notifier(). The later seems like the way to go but we
>>> currently do not call the reg_notifier() upon beacon hints -- we
>>> currently only call the reg_notifier() upon regulatory domain changes
>>> and upon wiphy registration. My point is both of these options require
>>> considerable changes for 2.6.31.
>>
>> Aha. So the problem really is that we don't have a reg notifier on
>> updates due to beacons.
>
> Yeah, seems that's the core issue from the original implementation. We
> should have added that.
>
>>> > and set them in ath_reg_apply_beaconing_flags and
>>> > ath_reg_apply_active_scan_flags, changing the polarity?
>>> >
>>> > I mean, right now you tell cfg80211 you don't support it,
>>> > and then try
>>> > to support it anyhow.
>>>
>>> Not sure I follow, support what? The reg_notifier() is there for
>>> regulatory domain changes, we didn't call it upon beacon hints. We
>>> can, and I agree its the right approach, but not for 2.6.31.
>>
>> I'm thinking more in terms of iwlwifi here, for all intents and purposes
>> it doesn't support beaconing on channel N, so it only supports NO_IBSS
>> on that channel. Which is what it puts into flags before registration.
>
> Ah I see, well but remember also that devices may have custom world
> regulatory domains for which they can set the no-ibss/passive scan
> flags and then allow for it due to a beacon hint.
>
>>> > Instead, you could tell cfg80211 you _do_ support
>>> > it, and then not support them depending on the notifier? It seems like
>>> > that should work and not break cfg80211's assumption that you can never
>>> > ever support _more_ than registration flags (orig_flags).
>>>
>>> I'm not following at all, orig_flags do not tell cfg80211 the channel
>>> flags the device supports. Most devices set flag to 0 upon wiphy
>>> registration and therefore cfg80211 sets orig_flags to 0 as well
>>> during wiphy registration.
>>
>> Well ok, "supports" is a bad word since we're talking about
>> restrictions. But for iwlwifi the orig_flags _do_ tell cfg80211 the
>> channel restrictions that the device _requires_.
>
> Oh ok, got it, yeah agreed, but its important to note we never
> documented nor was I aware we wanted to treat flags set prior to wiphy
> registration as capabilities. Truth is the device is actually capable
> of active scanning and beaconing on those channels but the design of
> the firmware doesn't allow for it.
>
>> Your devices, however, do not _strictly_ _require_ those channel flags,
>> they just require them for compliance. Unlike iwlwifi which crashes when
>> you don't do it right :)
>>
>> So I think we're in agreement -- the proper solution would be to call
>> the reg notifier on beacon hints too.
>
> Yeah, unless we want to just document an exception to the rules, but I
> do agree that seems like a slippery slope.
>
>> What we do for .31 I can't say I
>> really care,
>
> OK, I do, please consider this patch for 2.6.31 and also on
> wireless-testing for now.
>
>> how much work do you think this would be? It doesn't seem
>> all _that_ bad, at least for core changes?
>
> After some thinking the reg_notifier() does not seem to be the
> appropriate place for this. The reg_notifier() was designed to account
> for regulatory domain changes, not enhancements such as beacon hints.
> Consider the regulatory_request structure passed as the second
> argument to reg_notifier() and the currently supported types of
> regulatory domain changes, %REGDOM_SET_BY_*.
>
> What seems cleaner is to add a beacon_hint() notifier and use that at
> the end of handle_reg_beacon() so that we already give the driver the
> channel on which a beacon was received.
And this in itself would be a no-op if we use the patch I posted, and
we treat iwlwifi on this matter as an exception. So I'm now more happy
to support this patch as-is.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 17:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249058611.6549.3.camel@johannes.local>
On Fri, Jul 31, 2009 at 9:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-31 at 09:32 -0700, Luis R. Rodriguez wrote:
>
>> Its not that simple. Consider the fact we build our own custom
>> regulatory domain and stuff what is intended for each one of them. The
>> _orig stuff is set upon channel registration so it is correct that
>> we'd have to avoid setting the channel flags prior to wiphy
>> registration. How you do that is left up to implementation. Since
>> cfg80211 will set the channel *_orig params based on
>> wiphy_registration() you're only option is to either prevent your
>> wiphy being registered with the flags set or to reset the channel
>> flags on the reg_notifier(). The later seems like the way to go but we
>> currently do not call the reg_notifier() upon beacon hints -- we
>> currently only call the reg_notifier() upon regulatory domain changes
>> and upon wiphy registration. My point is both of these options require
>> considerable changes for 2.6.31.
>
> Aha. So the problem really is that we don't have a reg notifier on
> updates due to beacons.
Yeah, seems that's the core issue from the original implementation. We
should have added that.
>> > and set them in ath_reg_apply_beaconing_flags and
>> > ath_reg_apply_active_scan_flags, changing the polarity?
>> >
>> > I mean, right now you tell cfg80211 you don't support it,
>> > and then try
>> > to support it anyhow.
>>
>> Not sure I follow, support what? The reg_notifier() is there for
>> regulatory domain changes, we didn't call it upon beacon hints. We
>> can, and I agree its the right approach, but not for 2.6.31.
>
> I'm thinking more in terms of iwlwifi here, for all intents and purposes
> it doesn't support beaconing on channel N, so it only supports NO_IBSS
> on that channel. Which is what it puts into flags before registration.
Ah I see, well but remember also that devices may have custom world
regulatory domains for which they can set the no-ibss/passive scan
flags and then allow for it due to a beacon hint.
>> > Instead, you could tell cfg80211 you _do_ support
>> > it, and then not support them depending on the notifier? It seems like
>> > that should work and not break cfg80211's assumption that you can never
>> > ever support _more_ than registration flags (orig_flags).
>>
>> I'm not following at all, orig_flags do not tell cfg80211 the channel
>> flags the device supports. Most devices set flag to 0 upon wiphy
>> registration and therefore cfg80211 sets orig_flags to 0 as well
>> during wiphy registration.
>
> Well ok, "supports" is a bad word since we're talking about
> restrictions. But for iwlwifi the orig_flags _do_ tell cfg80211 the
> channel restrictions that the device _requires_.
Oh ok, got it, yeah agreed, but its important to note we never
documented nor was I aware we wanted to treat flags set prior to wiphy
registration as capabilities. Truth is the device is actually capable
of active scanning and beaconing on those channels but the design of
the firmware doesn't allow for it.
> Your devices, however, do not _strictly_ _require_ those channel flags,
> they just require them for compliance. Unlike iwlwifi which crashes when
> you don't do it right :)
>
> So I think we're in agreement -- the proper solution would be to call
> the reg notifier on beacon hints too.
Yeah, unless we want to just document an exception to the rules, but I
do agree that seems like a slippery slope.
> What we do for .31 I can't say I
> really care,
OK, I do, please consider this patch for 2.6.31 and also on
wireless-testing for now.
> how much work do you think this would be? It doesn't seem
> all _that_ bad, at least for core changes?
After some thinking the reg_notifier() does not seem to be the
appropriate place for this. The reg_notifier() was designed to account
for regulatory domain changes, not enhancements such as beacon hints.
Consider the regulatory_request structure passed as the second
argument to reg_notifier() and the currently supported types of
regulatory domain changes, %REGDOM_SET_BY_*.
What seems cleaner is to add a beacon_hint() notifier and use that at
the end of handle_reg_beacon() so that we already give the driver the
channel on which a beacon was received.
If we really want to stick to using the reg_notifier() on ath.ko we'd
need to make some changes to reg_notifier API, maybe consider a new
struct for the beacon hint event, and then have ath.ko iterate over
all channels and when a channel has chan->beacon_found lift the
flags.. A beacon_hint() callback seems cleaner and to the point.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Johannes Berg @ 2009-07-31 16:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <43e72e890907310932u4510fc6fwc0c3dab598036041@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]
On Fri, 2009-07-31 at 09:32 -0700, Luis R. Rodriguez wrote:
> Its not that simple. Consider the fact we build our own custom
> regulatory domain and stuff what is intended for each one of them. The
> _orig stuff is set upon channel registration so it is correct that
> we'd have to avoid setting the channel flags prior to wiphy
> registration. How you do that is left up to implementation. Since
> cfg80211 will set the channel *_orig params based on
> wiphy_registration() you're only option is to either prevent your
> wiphy being registered with the flags set or to reset the channel
> flags on the reg_notifier(). The later seems like the way to go but we
> currently do not call the reg_notifier() upon beacon hints -- we
> currently only call the reg_notifier() upon regulatory domain changes
> and upon wiphy registration. My point is both of these options require
> considerable changes for 2.6.31.
Aha. So the problem really is that we don't have a reg notifier on
updates due to beacons.
> > and set them in ath_reg_apply_beaconing_flags and
> > ath_reg_apply_active_scan_flags, changing the polarity?
> >
> > I mean, right now you tell cfg80211 you don't support it,
> > and then try
> > to support it anyhow.
>
> Not sure I follow, support what? The reg_notifier() is there for
> regulatory domain changes, we didn't call it upon beacon hints. We
> can, and I agree its the right approach, but not for 2.6.31.
I'm thinking more in terms of iwlwifi here, for all intents and purposes
it doesn't support beaconing on channel N, so it only supports NO_IBSS
on that channel. Which is what it puts into flags before registration.
> > Instead, you could tell cfg80211 you _do_ support
> > it, and then not support them depending on the notifier? It seems like
> > that should work and not break cfg80211's assumption that you can never
> > ever support _more_ than registration flags (orig_flags).
>
> I'm not following at all, orig_flags do not tell cfg80211 the channel
> flags the device supports. Most devices set flag to 0 upon wiphy
> registration and therefore cfg80211 sets orig_flags to 0 as well
> during wiphy registration.
Well ok, "supports" is a bad word since we're talking about
restrictions. But for iwlwifi the orig_flags _do_ tell cfg80211 the
channel restrictions that the device _requires_.
Your devices, however, do not _strictly_ _require_ those channel flags,
they just require them for compliance. Unlike iwlwifi which crashes when
you don't do it right :)
So I think we're in agreement -- the proper solution would be to call
the reg notifier on beacon hints too. What we do for .31 I can't say I
really care, how much work do you think this would be? It doesn't seem
all _that_ bad, at least for core changes?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 16:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249056713.25587.6.camel@johannes.local>
On Fri, Jul 31, 2009 at 9:11 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-31 at 09:03 -0700, Luis R. Rodriguez wrote:
>
>> > I did mean those devices. Adding a reg notifier hook for iwlwifi seems a
>> > little odd, given that cfg80211 is supposed to always honour the flags
>> > (which it copies to orig_flags for that purpose).
>> >
>> > But I don't see why ath couldn't do this:
>> >
>> > * do _not_ set the passive/no-ibss flags in flags (orig_flags)
>>
>> That's up to cfg80211 through the custom regdomain, so yes, and in
>> fact we can WARN if these are set.
>
> Ah, that seems a little heavy-handed :)
>
>> > * in the reg notifier, always set the passive/no-ibss flag into 'flags'
>> > unless a beacon was noticed on that channel.
>>
>> That's fine too, we still need a fix for 2.6.31. Do you have any
>> thoughts on that?
>
> Not really, tbh. Seems like all you'd have to do is remove the
> IEEE80211_CHAN_PASSIVE_SCAN/IEEE80211_CHAN_NO_IBSS flags from your
> channel registration,
Its not that simple. Consider the fact we build our own custom
regulatory domain and stuff what is intended for each one of them. The
_orig stuff is set upon channel registration so it is correct that
we'd have to avoid setting the channel flags prior to wiphy
registration. How you do that is left up to implementation. Since
cfg80211 will set the channel *_orig params based on
wiphy_registration() you're only option is to either prevent your
wiphy being registered with the flags set or to reset the channel
flags on the reg_notifier(). The later seems like the way to go but we
currently do not call the reg_notifier() upon beacon hints -- we
currently only call the reg_notifier() upon regulatory domain changes
and upon wiphy registration. My point is both of these options require
considerable changes for 2.6.31.
> and set them in ath_reg_apply_beaconing_flags and
> ath_reg_apply_active_scan_flags, changing the polarity?
>
> I mean, right now you tell cfg80211 you don't support it,
> and then try
> to support it anyhow.
Not sure I follow, support what? The reg_notifier() is there for
regulatory domain changes, we didn't call it upon beacon hints. We
can, and I agree its the right approach, but not for 2.6.31.
> Instead, you could tell cfg80211 you _do_ support
> it, and then not support them depending on the notifier? It seems like
> that should work and not break cfg80211's assumption that you can never
> ever support _more_ than registration flags (orig_flags).
I'm not following at all, orig_flags do not tell cfg80211 the channel
flags the device supports. Most devices set flag to 0 upon wiphy
registration and therefore cfg80211 sets orig_flags to 0 as well
during wiphy registration.
Luis
^ permalink raw reply
* Re: [PATCH 002/002] [MAC80211] Increase timeouts for station polling
From: Johannes Berg @ 2009-07-31 16:21 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, linville, Reinette Chatre
In-Reply-To: <1249057021.20593.5.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
On Fri, 2009-07-31 at 19:17 +0300, Maxim Levitsky wrote:
> >From 04976d22d45f26aa4b4dece5dd520e3347ac32d7 Mon Sep 17 00:00:00 2001
> From: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Fri, 31 Jul 2009 18:54:23 +0300
> Subject: [PATCH] [MAC80211] Increase timeouts for station polling
>
> Do a probe request every 30 seconds, and wait for probe response, half a second
> This should lower the traffic that card sends, thus save power
Indeed. We just tested that :)
Acked-by: Johannes Berg <johannes@sipsolutions.net>
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> ---
> net/mac80211/mlme.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 1d8640a..e4bb590 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -42,13 +42,13 @@
> * Time the connection can be idle before we probe
> * it to see if we can still talk to the AP.
> */
> -#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
> +#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
> /*
> * Time we wait for a probe response after sending
> * a probe request because of beacon loss or for
> * checking the connection still works.
> */
> -#define IEEE80211_PROBE_WAIT (HZ / 5)
> +#define IEEE80211_PROBE_WAIT (HZ / 2)
>
> #define TMR_RUNNING_TIMER 0
> #define TMR_RUNNING_CHANSW 1
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Johannes Berg @ 2009-07-31 16:21 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, linville, Reinette Chatre
In-Reply-To: <1249056896.20593.3.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]
On Fri, 2009-07-31 at 19:14 +0300, Maxim Levitsky wrote:
> >From 0bf5749f2878f9245b8fb1b64456386374205225 Mon Sep 17 00:00:00 2001
> From: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Fri, 31 Jul 2009 18:54:12 +0300
> Subject: [PATCH] [MAC80211] Retry probe request few times
>
> Retry 5 times (chosen arbitary ), before assuming
> that station is out of range.
>
> Fixes frequent disassociations while connected to weak,
> and sometimes even strong access points.
Looks good, thanks.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
> ---
> net/mac80211/ieee80211_i.h | 1 +
> net/mac80211/mlme.c | 42 ++++++++++++++++++++++++++++++------------
> 2 files changed, 31 insertions(+), 12 deletions(-)
>
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index aec6853..bca7b60 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -280,6 +280,7 @@ struct ieee80211_if_managed {
> struct work_struct beacon_loss_work;
>
> unsigned long probe_timeout;
> + int probe_send_count;
>
> struct mutex mtx;
> struct ieee80211_bss *associated;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index ee83125..1d8640a 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -31,6 +31,7 @@
> #define IEEE80211_AUTH_MAX_TRIES 3
> #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
> #define IEEE80211_ASSOC_MAX_TRIES 3
> +#define IEEE80211_MAX_PROBE_TRIES 5
>
> /*
> * beacon loss detection timeout
> @@ -1156,11 +1157,24 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
> round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
> }
>
> +static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
> +{
> + struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> + const u8 *ssid;
> +
> + ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> + ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> + ssid + 2, ssid[1], NULL, 0);
> +
> + ifmgd->probe_send_count++;
> + ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> + run_again(ifmgd, ifmgd->probe_timeout);
> +}
> +
> static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
> bool beacon)
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> - const u8 *ssid;
> bool already = false;
>
> if (!netif_running(sdata->dev))
> @@ -1203,18 +1217,12 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
> if (already)
> goto out;
>
> - ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> -
> mutex_lock(&sdata->local->iflist_mtx);
> ieee80211_recalc_ps(sdata->local, -1);
> mutex_unlock(&sdata->local->iflist_mtx);
>
> - ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> - ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> - ssid + 2, ssid[1], NULL, 0);
> -
> - run_again(ifmgd, ifmgd->probe_timeout);
> -
> + ifmgd->probe_send_count = 0;
> + ieee80211_mgd_probe_ap_send(sdata);
> out:
> mutex_unlock(&ifmgd->mtx);
> }
> @@ -2072,17 +2080,27 @@ static void ieee80211_sta_work(struct work_struct *work)
> if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
> IEEE80211_STA_CONNECTION_POLL) &&
> ifmgd->associated) {
> + u8 bssid[ETH_ALEN];
> +
> + memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
> if (time_is_after_jiffies(ifmgd->probe_timeout))
> run_again(ifmgd, ifmgd->probe_timeout);
> - else {
> - u8 bssid[ETH_ALEN];
> +
> + else if (ifmgd->probe_send_count < IEEE80211_MAX_PROBE_TRIES) {
> +#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
> + printk(KERN_DEBUG "No probe response from AP %pM"
> + " after %dms, try %d\n", bssid,
> + (1000 * IEEE80211_PROBE_WAIT)/HZ,
> + ifmgd->probe_send_count);
> +#endif
> + ieee80211_mgd_probe_ap_send(sdata);
> + } else {
> /*
> * We actually lost the connection ... or did we?
> * Let's make sure!
> */
> ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
> IEEE80211_STA_BEACON_POLL);
> - memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
> printk(KERN_DEBUG "No probe response from AP %pM"
> " after %dms, disconnecting.\n",
> bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 002/002] [MAC80211] Increase timeouts for station polling
From: Maxim Levitsky @ 2009-07-31 16:17 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, Reinette Chatre, Johannes Berg
In-Reply-To: <1249056817.20593.1.camel@maxim-laptop>
>From 04976d22d45f26aa4b4dece5dd520e3347ac32d7 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri, 31 Jul 2009 18:54:23 +0300
Subject: [PATCH] [MAC80211] Increase timeouts for station polling
Do a probe request every 30 seconds, and wait for probe response, half a second
This should lower the traffic that card sends, thus save power
Wainting longer for response makes probe more robust against 'slow' access points
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
net/mac80211/mlme.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 1d8640a..e4bb590 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -42,13 +42,13 @@
* Time the connection can be idle before we probe
* it to see if we can still talk to the AP.
*/
-#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
+#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
/*
* Time we wait for a probe response after sending
* a probe request because of beacon loss or for
* checking the connection still works.
*/
-#define IEEE80211_PROBE_WAIT (HZ / 5)
+#define IEEE80211_PROBE_WAIT (HZ / 2)
#define TMR_RUNNING_TIMER 0
#define TMR_RUNNING_CHANSW 1
--
1.6.0.4
^ permalink raw reply related
* Re: A station can't reconnect after it wakes up
From: Artur Skawina @ 2009-07-31 16:16 UTC (permalink / raw)
To: Igor Perminov; +Cc: hostap, linux-wireless@vger.kernel.org
In-Reply-To: <1248969930.29068.224.camel@sunlight>
[linux-wireless added to cc list]
Igor Perminov wrote:
> I have an issue related to handling power-saving stations by hostapd
> and/or mac80211 stack. A station can't reconnect after it wakes up.
>
> The problems looks similar to another one having been reported to this
> list earlier (STA can connect, but fails to reconnect within
> ap_max_inactivity):
> http://lists.shmoo.com/pipermail/hostap/2009-February/019192.html
>
> AP: Linux box with D-Link DWA-110 USB Wi-Fi stick (rt73usb kernel
> driver), kernel 2.6.30 with some patches, hostapd 0.6.9.
> Station: Toshiba G900 PDA under Windows Mobile 6.0.
>
> The environment is described in details here:
> http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10
>
> Consider the following step-by-step:
> 1. A station authenticates and associates with the AP and exchanges
> traffic.
> 2. The station indicates to the AP that it is going to sleep.
> 3. The station device goes to the stand-by mode (not only its wi-fi
> card, but the device itself).
> 4. The station device wakes up and begins authentication with an
> Authentication management frame.
>
> This is the behavior of my PDA.
>
> The problem is the mac80211 stack at the point 4 "remembers" that the
> station has gone to sleep. So, the response frames from hostapd are
> buffered by mac80211.
> The station indicates in the Authentication frame that it isn't sleeping
> anymore. But the mac80211 stack analyzes sleep/wake transitions in
> _data_ frames only, but not in management ones. See
> ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes:
> "Ignore doze->wake transitions that are indicated by non-data frames,
> the standard is unclear here".
> As the result, the station never receives the authentication response
> from the AP.
>
> One solution against this problem could be implemented in hostapd: to
> force the mac80211 stack to "forget" the station just after receiving an
> authentication frame (the patch is below). After this change the station
> can reconnect successfully.
i just did a quick test and your hostapd patch does indeed fix my problem
too (p54+hostapd with a winmobile device that couldn't reconnect after
turning the wifi module off and on).
> Another solution (in theory) would be to improve the mac80211
> implementation: to analyze not only data frames, but also
> management ones (or may be just some kinds of them) in
> ieee80211_rx_h_sta_process.
would seem to make sense, but having not read the spec i have no idea
if that's the right answer; hence the linux-wireless cc...
> I've asked this question to the linux-wireless mailing list few days
> ago, but nobody has answered still:
> http://marc.info/?l=linux-wireless&m=124879549212741&w=2
>
> And what is your opinion, what is a better way: should this problem be
> fixed in hostapd or in mac80211?
>
> === Begin diff ===
> --- a/hostapd/ieee802_11.c 2009-06-29 14:21:59.000000000 +0400
> +++ b/hostapd/ieee802_11.c 2009-07-21 16:28:17.000000000 +0400
> @@ -583,6 +583,13 @@
> goto fail;
> }
>
> + res = hostapd_sta_remove(hapd, mgmt->sa);
> + if (res) {
> + wpa_printf(MSG_DEBUG, "authentication: STA=" MACSTR
> + ", hostapd_sta_remove returned %d\n",
> + MAC2STR(mgmt->sa), res);
> + }
> +
> if (vlan_id > 0) {
> if (hostapd_get_vlan_id_ifname(hapd->conf->vlan,
> sta->vlan_id) == NULL) {
> === End diff ===
Thanks for the cc, added this to my local hostapd patch set, until the
issue gets resolved one way or another.
artur
^ permalink raw reply
* [PATCH 001/002] [MAC80211] Retry probe request few times
From: Maxim Levitsky @ 2009-07-31 16:14 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, Reinette Chatre, Johannes Berg
In-Reply-To: <1249056817.20593.1.camel@maxim-laptop>
>From 0bf5749f2878f9245b8fb1b64456386374205225 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri, 31 Jul 2009 18:54:12 +0300
Subject: [PATCH] [MAC80211] Retry probe request few times
Retry 5 times (chosen arbitary ), before assuming
that station is out of range.
Fixes frequent disassociations while connected to weak,
and sometimes even strong access points.
Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 42 ++++++++++++++++++++++++++++++------------
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..bca7b60 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -280,6 +280,7 @@ struct ieee80211_if_managed {
struct work_struct beacon_loss_work;
unsigned long probe_timeout;
+ int probe_send_count;
struct mutex mtx;
struct ieee80211_bss *associated;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ee83125..1d8640a 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,6 +31,7 @@
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_MAX_TRIES 3
+#define IEEE80211_MAX_PROBE_TRIES 5
/*
* beacon loss detection timeout
@@ -1156,11 +1157,24 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
}
+static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+ const u8 *ssid;
+
+ ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
+ ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
+ ssid + 2, ssid[1], NULL, 0);
+
+ ifmgd->probe_send_count++;
+ ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
+ run_again(ifmgd, ifmgd->probe_timeout);
+}
+
static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
bool beacon)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- const u8 *ssid;
bool already = false;
if (!netif_running(sdata->dev))
@@ -1203,18 +1217,12 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
if (already)
goto out;
- ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
-
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
- ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
- ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
- ssid + 2, ssid[1], NULL, 0);
-
- run_again(ifmgd, ifmgd->probe_timeout);
-
+ ifmgd->probe_send_count = 0;
+ ieee80211_mgd_probe_ap_send(sdata);
out:
mutex_unlock(&ifmgd->mtx);
}
@@ -2072,17 +2080,27 @@ static void ieee80211_sta_work(struct work_struct *work)
if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
IEEE80211_STA_CONNECTION_POLL) &&
ifmgd->associated) {
+ u8 bssid[ETH_ALEN];
+
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
if (time_is_after_jiffies(ifmgd->probe_timeout))
run_again(ifmgd, ifmgd->probe_timeout);
- else {
- u8 bssid[ETH_ALEN];
+
+ else if (ifmgd->probe_send_count < IEEE80211_MAX_PROBE_TRIES) {
+#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
+ printk(KERN_DEBUG "No probe response from AP %pM"
+ " after %dms, try %d\n", bssid,
+ (1000 * IEEE80211_PROBE_WAIT)/HZ,
+ ifmgd->probe_send_count);
+#endif
+ ieee80211_mgd_probe_ap_send(sdata);
+ } else {
/*
* We actually lost the connection ... or did we?
* Let's make sure!
*/
ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
IEEE80211_STA_BEACON_POLL);
- memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
printk(KERN_DEBUG "No probe response from AP %pM"
" after %dms, disconnecting.\n",
bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 000/002] Fix frequent reconnects caused by new conection monitor
From: Maxim Levitsky @ 2009-07-31 16:13 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, Reinette Chatre, Johannes Berg
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hi, here is the updated version of these two patches that fix the
$SUBJECT issue.
I attach these (in case mailer mangles them), and reply with patches.
Tested both with low quality signal, and beacon loss.
Lack of TX is found, every 30 seconds now, and quite reliable.
Lack of beacons, triggers probe like it did every 2 seconds.
Best regards,
Maxim Levitsky
[-- Attachment #2: 0001--MAC80211-Retry-probe-request-few-times.patch --]
[-- Type: text/x-patch, Size: 3966 bytes --]
>From 0bf5749f2878f9245b8fb1b64456386374205225 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri, 31 Jul 2009 18:54:12 +0300
Subject: [PATCH] [MAC80211] Retry probe request few times
Retry 5 times (chosen arbitary ), before assuming
that station is out of range.
Fixes frequent disassociations while connected to weak,
and sometimes even strong access points.
Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 42 ++++++++++++++++++++++++++++++------------
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..bca7b60 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -280,6 +280,7 @@ struct ieee80211_if_managed {
struct work_struct beacon_loss_work;
unsigned long probe_timeout;
+ int probe_send_count;
struct mutex mtx;
struct ieee80211_bss *associated;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ee83125..1d8640a 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,6 +31,7 @@
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_MAX_TRIES 3
+#define IEEE80211_MAX_PROBE_TRIES 5
/*
* beacon loss detection timeout
@@ -1156,11 +1157,24 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
}
+static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+ const u8 *ssid;
+
+ ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
+ ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
+ ssid + 2, ssid[1], NULL, 0);
+
+ ifmgd->probe_send_count++;
+ ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
+ run_again(ifmgd, ifmgd->probe_timeout);
+}
+
static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
bool beacon)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- const u8 *ssid;
bool already = false;
if (!netif_running(sdata->dev))
@@ -1203,18 +1217,12 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
if (already)
goto out;
- ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
-
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
- ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
- ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
- ssid + 2, ssid[1], NULL, 0);
-
- run_again(ifmgd, ifmgd->probe_timeout);
-
+ ifmgd->probe_send_count = 0;
+ ieee80211_mgd_probe_ap_send(sdata);
out:
mutex_unlock(&ifmgd->mtx);
}
@@ -2072,17 +2080,27 @@ static void ieee80211_sta_work(struct work_struct *work)
if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
IEEE80211_STA_CONNECTION_POLL) &&
ifmgd->associated) {
+ u8 bssid[ETH_ALEN];
+
+ memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
if (time_is_after_jiffies(ifmgd->probe_timeout))
run_again(ifmgd, ifmgd->probe_timeout);
- else {
- u8 bssid[ETH_ALEN];
+
+ else if (ifmgd->probe_send_count < IEEE80211_MAX_PROBE_TRIES) {
+#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
+ printk(KERN_DEBUG "No probe response from AP %pM"
+ " after %dms, try %d\n", bssid,
+ (1000 * IEEE80211_PROBE_WAIT)/HZ,
+ ifmgd->probe_send_count);
+#endif
+ ieee80211_mgd_probe_ap_send(sdata);
+ } else {
/*
* We actually lost the connection ... or did we?
* Let's make sure!
*/
ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
IEEE80211_STA_BEACON_POLL);
- memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
printk(KERN_DEBUG "No probe response from AP %pM"
" after %dms, disconnecting.\n",
bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
--
1.6.0.4
[-- Attachment #3: 0002--MAC80211-Increase-timeouts-for-station-polling.patch --]
[-- Type: text/x-patch, Size: 1259 bytes --]
>From 04976d22d45f26aa4b4dece5dd520e3347ac32d7 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri, 31 Jul 2009 18:54:23 +0300
Subject: [PATCH] [MAC80211] Increase timeouts for station polling
Do a probe request every 30 seconds, and wait for probe response, half a second
This should lower the traffic that card sends, thus save power
Wainting longer for response makes probe more robust against 'slow' access points
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
net/mac80211/mlme.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 1d8640a..e4bb590 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -42,13 +42,13 @@
* Time the connection can be idle before we probe
* it to see if we can still talk to the AP.
*/
-#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ)
+#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ)
/*
* Time we wait for a probe response after sending
* a probe request because of beacon loss or for
* checking the connection still works.
*/
-#define IEEE80211_PROBE_WAIT (HZ / 5)
+#define IEEE80211_PROBE_WAIT (HZ / 2)
#define TMR_RUNNING_TIMER 0
#define TMR_RUNNING_CHANSW 1
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Johannes Berg @ 2009-07-31 16:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <43e72e890907310903k65be4480j3279253281f2935e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Fri, 2009-07-31 at 09:03 -0700, Luis R. Rodriguez wrote:
> > I did mean those devices. Adding a reg notifier hook for iwlwifi seems a
> > little odd, given that cfg80211 is supposed to always honour the flags
> > (which it copies to orig_flags for that purpose).
> >
> > But I don't see why ath couldn't do this:
> >
> > * do _not_ set the passive/no-ibss flags in flags (orig_flags)
>
> That's up to cfg80211 through the custom regdomain, so yes, and in
> fact we can WARN if these are set.
Ah, that seems a little heavy-handed :)
> > * in the reg notifier, always set the passive/no-ibss flag into 'flags'
> > unless a beacon was noticed on that channel.
>
> That's fine too, we still need a fix for 2.6.31. Do you have any
> thoughts on that?
Not really, tbh. Seems like all you'd have to do is remove the
IEEE80211_CHAN_PASSIVE_SCAN/IEEE80211_CHAN_NO_IBSS flags from your
channel registration, and set them in ath_reg_apply_beaconing_flags and
ath_reg_apply_active_scan_flags, changing the polarity?
I mean, right now you tell cfg80211 you don't support it, and then try
to support it anyhow. Instead, you could tell cfg80211 you _do_ support
it, and then not support them depending on the notifier? It seems like
that should work and not break cfg80211's assumption that you can never
ever support _more_ than registration flags (orig_flags).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* regression on mac80211_hswim
From: Luis R. Rodriguez @ 2009-07-31 16:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Jouni Malinen, Johannes Berg
Noticed a regression on mac80211_hwsim when creating two devices using
regtest=4. Here's the doc on regtest=4:
* @HWSIM_REGTEST_WORLD_ROAM: Used for testing the world roaming. We acomplish
* this by using a custom beacon-capable regulatory domain for the first
* radio. All other device world roam.
HWSIM_REGTEST_WORLD_ROAM = 4,
So I used to test world roaming without any hardware by starting
hostapd on wlan0, and then scanning on the wlan1. Today wlan1 never
sees wlan0's AP. Tested with git hostapd, and wireless-testing. I
would have looked further into it but I really have no time to do so.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 16:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249055782.20312.19.camel@johannes.local>
On Fri, Jul 31, 2009 at 8:56 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-31 at 08:49 -0700, Luis R. Rodriguez wrote:
>
>> > just set the _flags_ in their reg
>> > notifier,
>>
>> So if you mean devices that used custom reg stuff, the answer is no
>> because the patch which introduced the regression would prevent the
>> setting of the passive scan flag and beaconing restrictions so the
>> reg_notifier would never notice the difference.
>
> I did mean those devices. Adding a reg notifier hook for iwlwifi seems a
> little odd, given that cfg80211 is supposed to always honour the flags
> (which it copies to orig_flags for that purpose).
>
> But I don't see why ath couldn't do this:
>
> * do _not_ set the passive/no-ibss flags in flags (orig_flags)
That's up to cfg80211 through the custom regdomain, so yes, and in
fact we can WARN if these are set.
> * in the reg notifier, always set the passive/no-ibss flag into 'flags'
> unless a beacon was noticed on that channel.
That's fine too, we still need a fix for 2.6.31. Do you have any
thoughts on that?
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Johannes Berg @ 2009-07-31 15:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <43e72e890907310849l3487b8a2p52302f6662a26f95@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
On Fri, 2009-07-31 at 08:49 -0700, Luis R. Rodriguez wrote:
> > just set the _flags_ in their reg
> > notifier,
>
> So if you mean devices that used custom reg stuff, the answer is no
> because the patch which introduced the regression would prevent the
> setting of the passive scan flag and beaconing restrictions so the
> reg_notifier would never notice the difference.
I did mean those devices. Adding a reg notifier hook for iwlwifi seems a
little odd, given that cfg80211 is supposed to always honour the flags
(which it copies to orig_flags for that purpose).
But I don't see why ath couldn't do this:
* do _not_ set the passive/no-ibss flags in flags (orig_flags)
* in the reg notifier, always set the passive/no-ibss flag into 'flags'
unless a beacon was noticed on that channel.
What am I missing?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 15:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, Jouni Malinen
In-Reply-To: <1249026324.29587.15.camel@johannes.local>
On Fri, Jul 31, 2009 at 12:45 AM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-30 at 17:43 -0700, Luis R. Rodriguez wrote:
>
>> By doing so though we also disallowed beacon hints on devices
>> registering their wiphy with custom world regulatory domains
>> enabled, this happens to be currently ath5k, ath9k and ar9170.
>> The passive scan and beacon restrictions on those devices would
>> never be lifted even if we did find a beacon and the hardware did
>> support such enhancements when world roaming.
>
> I dislike this solution, it just adds proliferation of possible
> behaviours.
Agreed.
> Can't those devices
Which devices?
> just set the _flags_ in their reg
> notifier,
So if you mean devices that used custom reg stuff, the answer is no
because the patch which introduced the regression would prevent the
setting of the passive scan flag and beaconing restrictions so the
reg_notifier would never notice the difference.
If you mean iwlwifi devices then yes, this is possible but it also
means a big change and I'd like to see this regression fixed on
2.6.31.
> and clear the corresponding bit in the orig_flags?
iwlwifi would just have to touch flags, not orig_flags as orig_flags
should not be touched.
How about using the patch as is for now for wireless-testing and
2.6.31, and then have iwlwifi write their own reg_notifier() ?
Luis
^ 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