[Prism54-devel] [PATCH] islpci_close() should shut down the radio

Jens Maurer Jens.Maurer@gmx.net
Mon, 05 Jan 2004 00:35:21 +0100


This is a multi-part message in MIME format.
--------------080609030304090008040002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello!

It has bothered me that after a "ifconfig eth1 down" my card was
not totally inert, but still had the green light ("link to AP established")
turned on, i.e. the radio and the firmware was still active.

The attached patch makes prism54_close() give the card a
hard reset into non-RAMBOOT mode, thus the radio is off.

This is mostly cut&paste from the firmware loading code, so
it could do with some unification.

Note that I'm disabling the device's interrupts here and I
actually wait until the interrupts potentially executing on
other CPUs are dealt with.  Also, the "mdelay(50)" was turned
into a schedule_timeout() to be nice to others on the system.

This also appears to fix some random hangs that I saw when
rmmod + insmod in relatively quick succession.  (The hang
could sometimes be resolved by manually ejecting the card
from its slot.)

CAVEAT: When I do a "ifconfig eth1 down; ifconfig eth1 up"
I get the message "reclaimed rx frame count not correct (26  != 24)!"
in the system log file.  I can't see what I'm doing in
my patch to cause this behaviour.  I've tried debugging this
by manually counting the number of elements in the mgmt_rx_freeq
list and comparing that with ->qsize, but that hanged my
system hard (no Alt-SysRq, nothing).  I presume someone is
destroying the mgmt_rx_freeq.

The whole mgmt* handling appears to be really complicated,
we demultiplex responses from the card into various
queues, etc.  It looks like we always send one request and
wait for its answer, except for traps that happen out of
thin air.  If the simple request-response mechanism is
really the only way we do it, we could design for it and
remove large parts of islpci_mgt.c .  All transmit queues
except for the hardware mgmt transmit queue would be gone
(we can queue at most one request, possibly fragmented,
but we can't handle more fragments than are slots in
the hardware queue, anyway).  For receive, allocate the
data for schedule_work() dynamically and attach a
dynamically allocated buffer that contains the trap
info.  The schedule_work() callback will free the data
when done.  This way, schedule_work() will implement
the trap receive queue for us.  The responses to mgmt
requests can be collected out of the hardware receive
queue, which won't overflow, because there is at most
one answer outstanding.

I assume the mgmt and trap stuff is not speed-critical
(so multiple outstanding requests are not necessary)
and is called from process context (modprobe, ifconfig,
or ioctl) only, so we can nicely protect the whole
exchange including the mib structure with a semaphore.

Btw, the recent changes to isl_ioctl.c are good, except
that it's now time to get rid of the MGT_* macros,
because they don't really save lines of code any more
and sometimes contain "return" statements that
obfuscate the program flow when used (hopefully no
user holds any locks when using these).

Jens Maurer

--------------080609030304090008040002
Content-Type: text/plain;
 name="islpci_close.patch"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="islpci_close.patch"

SW5kZXg6IGlzbHBjaV9kZXYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdmFyL2xpYi9j
dnMvcHJpc201NC1uZy9rc3JjL2lzbHBjaV9kZXYuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24g
MS40MwpkaWZmIC11IC1yMS40MyBpc2xwY2lfZGV2LmMKLS0tIGlzbHBjaV9kZXYuYwkxNyBE
ZWMgMjAwMyAwNjoxNjozOSAtMDAwMAkxLjQzCisrKyBpc2xwY2lfZGV2LmMJNCBKYW4gMjAw
NCAyMzowMzoyMyAtMDAwMApAQCAtNDAsNiArNDAsMTIgQEAKICMgaW5jbHVkZSAiaXNsX3dk
cy5oIgogI2VuZGlmCiAKKyNpZiBMSU5VWF9WRVJTSU9OX0NPREUgPD0gS0VSTkVMX1ZFUlNJ
T04oMiw1LDApCisjZGVmaW5lIHByaXNtNTRfc3luY2hyb25pemVfaXJxKGlycSkgc3luY2hy
b25pemVfaXJxKCkKKyNlbHNlCisjZGVmaW5lIHByaXNtNTRfc3luY2hyb25pemVfaXJxKGly
cSkgc3luY2hyb25pemVfaXJxKGlycSkKKyNlbmRpZgorCiAjZGVmaW5lIElTTDM4NzdfSU1B
R0VfRklMRQkiaXNsMzg3NyIKICNkZWZpbmUgSVNMMzg5MF9JTUFHRV9GSUxFCSJpc2wzODkw
IgogCkBAIC0yNDYsMTcgKzI2OCw0MiBAQAogc3RhdGljIGludAogaXNscGNpX2Nsb3NlKHN0
cnVjdCBuZXRfZGV2aWNlICpuZGV2KQogewotI2lmZGVmIENPTkZJR19QUklTTTU0X1dEUwog
CWlzbHBjaV9wcml2YXRlICpwcml2ID0gbmRldi0+cHJpdjsKLSNlbmRpZgorCXZvaWQgKmRl
dmljZV9iYXNlID0gcHJpdi0+ZGV2aWNlX2Jhc2U7CisJdTMyIHJlZzsKIAogCXByaW50ayhL
RVJOX0RFQlVHICIlczogaXNscGNpX2Nsb3NlICgpXG4iLCBuZGV2LT5uYW1lKTsKIAorCW5l
dGlmX3N0b3BfcXVldWUobmRldik7CisKICNpZmRlZiBDT05GSUdfUFJJU001NF9XRFMKIAlj
bG9zZV93ZHNfbGlua3MoJnByaXYtPndkc3ApOwogI2VuZGlmCi0JbmV0aWZfc3RvcF9xdWV1
ZShuZGV2KTsKLS8qICAgICAgbmV0aWZfbWFya19kb3duKCBuZGV2ICk7ICovCisKKwkvKiBk
aXNhYmxlIGFsbCBkZXZpY2UgaW50ZXJydXB0cyBpbiBjYXNlIHRoZXkgd2VyZW4ndCAqLwor
CWlzbDM4eHhfZGlzYWJsZV9pbnRlcnJ1cHRzKHByaXYtPmRldmljZV9iYXNlKTsgIAorICAg
ICAgICAvKiB3YWl0IHVudGlsIGludGVycnVwdHMgaGF2ZSBmaW5pc2hlZCBleGVjdXRpbmcg
b24gb3RoZXIgQ1BVcyAqLworICAgICAgICBwcmlzbTU0X3N5bmNocm9uaXplX2lycShwcml2
LT5wZGV2LT5pcnEpOworCisJcmVnID0gcmVhZGwoZGV2aWNlX2Jhc2UgKyBJU0wzOFhYX0NU
UkxfU1RBVF9SRUcpOworICAgICAgICByZWcgJj0gfihJU0wzOFhYX0NUUkxfU1RBVF9SRVNF
VCB8IElTTDM4WFhfQ1RSTF9TVEFUX1JBTUJPT1QpOworICAgICAgICB3cml0ZWwocmVnLCBk
ZXZpY2VfYmFzZSArIElTTDM4WFhfQ1RSTF9TVEFUX1JFRyk7CisgICAgICAgIHdtYigpOwor
ICAgICAgICB1ZGVsYXkoSVNMMzhYWF9XUklURUlPX0RFTEFZKTsKKworCXJlZyB8PSBJU0wz
OFhYX0NUUkxfU1RBVF9SRVNFVDsKKyAgICAgICAgd3JpdGVsKHJlZywgZGV2aWNlX2Jhc2Ug
KyBJU0wzOFhYX0NUUkxfU1RBVF9SRUcpOworICAgICAgICB3bWIoKTsKKyAgICAgICAgdWRl
bGF5KElTTDM4WFhfV1JJVEVJT19ERUxBWSk7CisKKwkvKiBjbGVhciB0aGUgUmVzZXQgYml0
ICovCisgICAgICAgIHJlZyAmPSB+SVNMMzhYWF9DVFJMX1NUQVRfUkVTRVQ7CisgICAgICAg
IHdyaXRlbChyZWcsIGRldmljZV9iYXNlICsgSVNMMzhYWF9DVFJMX1NUQVRfUkVHKTsKKyAg
ICAgICAgd21iKCk7CisKKyAgICAgICAgLyogd2FpdCBhIHdoaWxlIGZvciB0aGUgZGV2aWNl
IHRvIHJlc2V0ICovCisJc2V0X2N1cnJlbnRfc3RhdGUoVEFTS19VTklOVEVSUlVQVElCTEUp
OworCXNjaGVkdWxlX3RpbWVvdXQoNTAqSFovMTAwMCk7CiAKIAlyZXR1cm4gMDsKIH0KIAo=
--------------080609030304090008040002--