summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/p54
AgeCommit message (Collapse)Author
2008-10-31p54: integrate parts of lmac_longbow.h and other parts of stlc45xxJohn W. Linville
This patch removes most/all? of the "magic" numbers and unknown structure variables inside the code and replaces them with meaningful prototypes. (Plus a one line warning fix from Larry Finger <Larry.Finger@lwfinger.net>.) Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: borrow some setup code from stlc45xxChristian Lamparter
This patch initialize all remaining values which are necessary for SPI firmwares. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: fix memory managementChristian Lamparter
We have to be careful if multiple "control frames" are passed in a very short intervals to the device's firmware. As p54_assign_address always put them into same memory location. To guarantee that this won't happen anymore, we have to treat control frames like normal data frames in the devices own memory management. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: p54: refactor p54_rx_frame_sentChristian Lamparter
the long names and the nesting in p54_rx_frame_sent really became a "line longer than 80 characters" problem. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: refactor statistic timer codeChristian Lamparter
Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: broken out edcf changesChristian Lamparter
This patch series hopefully increases p54's "longterm" stability. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: implement MRRJohannes Berg
This implements multi-rate retry in p54. With lots of help and testing from Christian and the limiting idea from nbd. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31mac80211/drivers: rewrite the rate control APIJohannes Berg
So after the previous changes we were still unhappy with how convoluted the API is and decided to make things simpler for everybody. This completely changes the rate control API, now taking into account 802.11n with MCS rates and more control, most drivers don't support that though. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54/rtl8187: fix up the seqno patchJohannes Berg
Sorry about that, for some reason I didn't notice that I'd left some unused variables in there. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31mac80211: provide sequence numbersJohannes Berg
I've come to think that not providing sequence numbers for the normal STA mode case was a mistake, at least two drivers now had to implement code they wouldn't otherwise need, and I believe at76_usb and adm8211 might be broken. This patch makes mac80211 assign a sequence number to all those frames that need one except beacons. That means that if a driver only implements modes that do not do beaconing it need not worry about the sequence number. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: Move rx_mtu to struct bootrec_descLarry Finger
The patch entitled "[PATCH] p54: Fix sparse warnings" added the __le16 variable rx_mtu to struct bootrec, but it could equally well be placed in the struct bootrec_desc, which overlays the 'data' section of bootrec. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31mac80211: introduce hw config change flagsJohannes Berg
This makes mac80211 notify the driver which configuration actually changed, e.g. channel etc. No driver changes, this is just plumbing, driver authors are expected to act on this if they want to. Also remove the HW CONFIG debug printk, it's incorrect, often we configure something else. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31mac80211: kill hw.conf.antenna_sel_{rx,tx}Johannes Berg
Never actually used. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31p54: honour bss_info_changed's short slot time settingsChristian Lamparter
This patch was made on behalf of Johannes request. "mac80211 and IEEE80211_CONF_SHORT_SLOT_TIME" Of course, bss_info_changed provides some more useful data. e.g.: basic_rates, dtim_period, beacon_int and maybe even more. Everything can be hooked up if it's necessary. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/p54/p54common.c
2008-10-27net: convert print_mac to %pMJohannes Berg
This converts pretty much everything to print_mac. There were a few things that had conflicts which I have just dropped for now, no harm done. I've built an allyesconfig with this and looked at the files that weren't built very carefully, but it's a huge patch. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-27p54: fix build warningsChristian Lamparter
On Saturday 25 October 2008 10:24:10 Johannes Berg wrote: > just FYI in case you haven't seen them. the p54 one looks like a genuine > problem. > > drivers/net/wireless/p54/p54common.c: In function ‘p54_parse_eeprom’: > drivers/net/wireless/p54/p54common.c:325: warning: ‘synth’ may be used uninitialized in this function There you go. Yes, it is a genuine problem, if the device's eeprom is screwed really up. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-27p54: fix misbehavings when firmware can't be foundChristian Lamparter
This patch fixes a double-free error in p54pci ( http://bugzilla.kernel.org/show_bug.cgi?id=11782 ) Trying to free already-free IRQ 10 Pid: 108, comm: pccardd Not tainted 2.6.27-05577-g0cfd810-dirty #1 Call Trace:  [<c01265dc>] free_irq+0xad/0xb9  [<c01050dd>] dma_generic_alloc_coherent+0x0/0xd7  [<c01ba8e6>] p54p_stop+0x4a/0x1fa  [<c01050dd>] dma_generic_alloc_coherent+0x0/0xd7  [<c02348c5>] p54p_probe+0x23e/0x302 Tested-by: Sean Young Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-22p54: enable 2.4/5GHz spectrum by eeprom bits.Christian Lamparter
Badness at /home/proski/src/linux-2.6/net/mac80211/rx.c:2200 NIP: c02bc850 LR: c02ab268 CTR: 00000000 REGS: ef01fcc0 TRAP: 0700 Tainted: G W (2.6.27-wl) MSR: 00029032 <EE,ME,IR,DR> CR: 22004084 XER: 20000000 TASK = c1a58800[1778] 'p54pci' THREAD: ef01e000 [...] NIP [c02bc850] __ieee80211_rx+0x17c/0x638 LR [c02ab268] ieee80211_tasklet_handler+0x104/0x120 Call Trace: [ef01fd70] [c1a0c020] 0xc1a0c020 (unreliable) [ef01fdb0] [c02ab268] ieee80211_tasklet_handler+0x104/0x120 [...] the problem was that some older cards are mis-identified and didn't support 5GHz rates, while they have the right MAC & Synth chip. This patch changes the way how p54 decides if it should enable 11a channels or not. Reported-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-14p54usb: Device ID updatesChristian Lamparter
This patch updates p54usb's device list. It adds the ID for SMC 2862W-G v2 and marks the "Spinnaker Proto board" as a first generation device. Reported-by: <jafg666@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-14p54: Fix compilation problem on PPCLarry Finger
The commit entitled "p54: Fix sparse warnings" introduced a compile error on PPC architecture. Thanks to Johannes Berg <johannes@sipsolutions.net> for reporting this problem. Signed-off-by: <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-06p54: report appropriate rate and band values for 802.11aChristian Lamparter
This patch adds the a few lines that went missing in "p54: 802.11a 5GHz phy support" Essentially: the rx-code wasn't updated and therefore reported the wrong band, but more importantly the rate index was off as well, since 802.11a doesn't allow the "four" 802.11b rates... Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-30p54: Fix sparse warningsLarry Finger
The command make C=2 CF="-D__CHECK_ENDIAN__" drivers/net/wireless/p54/ generates the following warnings: .../p54common.c:152:38: warning: incorrect type in argument 1 (different base types) .../p54common.c:152:38: expected restricted __be32 const [usertype] *p .../p54common.c:152:38: got unsigned int *<noident> .../p54common.c:184:15: warning: restricted __le32 degrades to integer .../p54common.c:185:29: warning: cast to restricted __le16 .../p54common.c:309:11: warning: symbol 'p54_rf_chips' was not declared. Should it be static? .../p54common.c:313:5: warning: symbol 'p54_parse_eeprom' was not declared. Should it be static? .../p54common.c:620:43: warning: incorrect type in argument 3 (different base types) .../p54common.c:620:43: expected unsigned long [unsigned] [usertype] len .../p54common.c:620:43: got restricted __le16 [usertype] len .../p54common.c:780:41: warning: restricted __le16 degrades to integer .../p54common.c:781:32: warning: restricted __le16 degrades to integer .../p54common.c:1250:28: warning: incorrect type in argument 2 (different base types) .../p54common.c:1250:28: expected unsigned short [unsigned] [usertype] filter_type .../p54common.c:1250:28: got restricted __le16 [usertype] filter_type .../p54common.c:1252:28: warning: incorrect type in argument 2 (different base types) .../p54common.c:1252:28: expected unsigned short [unsigned] [usertype] filter_type .../p54common.c:1252:28: got restricted __le16 [usertype] filter_type .../p54common.c:1257:42: warning: incorrect type in argument 2 (different base types) .../p54common.c:1257:42: expected unsigned short [unsigned] [usertype] filter_type .../p54common.c:1257:42: got restricted __le16 .../p54common.c:1260:42: warning: incorrect type in argument 2 (different base types) .../p54common.c:1260:42: expected unsigned short [unsigned] [usertype] filter_type .../p54common.c:1260:42: got restricted __le16 .../p54usb.c:228:10: warning: restricted __le32 degrades to integer .../p54usb.c:228:23: warning: restricted __le32 degrades to integer .../p54usb.c:228:7: warning: incorrect type in assignment (different base types) .../p54usb.c:228:7: expected restricted __le32 [assigned] [usertype] chk .../p54usb.c:228:7: got unsigned int .../p54usb.c:221:8: warning: symbol 'p54u_lm87_chksum' was not declared. Should it be static? All of the above have been fixed. One question, however, remains: In struct bootrec, the array "data" is treated in many places as native CPU order, but it may be little-endian everywhere. As far as I can tell, this driver has only been used with little-endian hardware. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-15mac80211: use nl80211 interface typesJohannes Berg
There's really no reason for mac80211 to be using its own interface type defines. Use the nl80211 types and simplify the configuration code a bit: there's no need to translate them any more now. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-11p54: 802.11a 5GHz phy supportChristian Lamparter
This patch brings the 5GHz Phy in any prism54 devices (of course, only those who have one) to life. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-11p54: control output power levelsChristian Lamparter
I hope this patch is enough to cover at least the basic requirements of IEEE 802.11h's TPC. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-11p54: add lots of useful rx/tx statisticsChristian Lamparter
The firmware can provide lots of useful statistics about noise floor, mac time and lots of numbers about successful transfers and dropped frames. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-11p54: add more rx filtersChristian Lamparter
This patch adds new filters settings to make the card more useful in monitor mode. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-11p54: 32-bit tsf timestampsChristian Lamparter
tcpdump: 02:15:42.874518 61112184us tsft 48.0 Mb/s 2437 MHz (0x0480) antenna 1 [0x0000000e] CF +QoS Data IV 02:15:42.874557 >>>4356079526us<<< tsft 24.0 Mb/s 2437 MHz (0x0480) antenna 1 [0x0000000e] Acknowledgment 02:15:42.976844 61214513us tsft 1.0 Mb/s 2437 MHz (0x0480) antenna 0 [0x0000000e] Beacon as one can see on the huge jump, it's very plausible that firmware does not report the full 64-bit mac time, just the lower 32bit and some kinds of flags... Therefore if we want a useful timestamp we have to emulate the high bits. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-08p54: better firmware supportChristian Lamparter
This patch hopefully contains all necessary changes to support firmwares for all devices up to atleast 2.13.3.0. (or: LowerMAC Protocol Rev: 5.5 ) And this is a big win, since: * newer firmwares are more stable and reliable than the old ones. * no problems anymore with packages > 1399 octets (without lowering the MTU). * monitor mode finally works on USB for more than just a few seconds. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-08p54: set_filter refactoringChristian Lamparter
p54_set_filter has a way too many unnecessary "magic" parameters and values. This patch axes all superfluous parameters and gives most of the magic values appropriate names. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-05p54usb: support LM87 firmwaresChristian Lamparter
This patch adds the necessary changes to support LM87 firmwares. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-05p54: move eeprom code into common libraryChristian Lamparter
Both p54pci and p54usb uses a good chunk of device specific code to get the data from the device's eeprom into the drivers memory. So, this patch reduces the code size and will it make life easier if someone wants to implement ethtool eeprom dumping features. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-05p54: enhance firmware parser to reduce memory wasteChristian Lamparter
This patch greatly reduces one of biggest memory waste in the driver. The firmware headers provides the right values for extra head-/tailroom and mtu size which are usually much lower than the old hardcoded ones. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-05p54pci: increase ring buffer index counter when skippingChristian Lamparter
I'm afraid, I forgot to add the following lines to 7262d59366 ("p54pci: rx tasklet refactoring"). These changes are necessary to ensure loop termination. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-05cfg80211: keep track of supported interface modesLuis R. Rodriguez
It is obviously good for userspace to know up front which interface modes a given piece of hardware might support (even if adding such an interface might fail later because of concurrency issues), so let's make cfg80211 aware of that. For good measure, disallow adding interfaces in all other modes so drivers don't forget to announce support for one mode when they add it. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Stephen Blackheath <tramp.enshrine.stephen@blacksapphire.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-29p54pci: rx tasklet refactoringChristian Lamparter
This patch moves the all of p54pci's receiver code out of the bloated interrupt handler routine and into a less critical tasklet. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-29p54: redo queue numberingChr
The firmware supports 8 different queues and not only 4. So, let's make some room for further tasks (ap/adhoc support) in this area. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-29p54: take tx_queue's lock in rx_frame_sentChr
p54_rx_frame_sent will alter the tx_queue. Therefore we should hold the lock to protect against concurrent p54_assign_address calls. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-29p54: fix rssi auto calibrationChristian Lamparter
Ever wondered why the signal was so bad with p54 compared to madwifi, or intel? Well, if you have revision 1 rssi calibration curve points in your EEPROM, then wonder no more. The firmware wants a extra 1 byte padding for every curve point. But someone forgot to put them into the EEPROM's data structure... So now, big question: what happens when we blindly "memcpy" these data points? Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-22p54: rename prism54xyz -> p54xyzChristian Lamparter
It's been a long time, but fullmac prism54 driver is still around... I think we should rename every prism54* in order to avoid some confusion about "what is actually what" in the future ;-). Thanks-to: Maxi <maxi@daemonizer.de> Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-18p54u: reset skb's data/tail pointer on requeueChristian Lamparter
(Only important for USB V1 Adaptors) If an incoming frame wasn't accepted by p54_rx function the skb will be reused for new frames... But, we must not forget to set the skb's data pointers into the same state in which it was initialized by p54u_init_urbs. Otherwise we either end up with 16 bytes less on every requeue, or if a new frame is worthy enough to be accepted, the data is in the wrong place (urb->transfer_buffer wasn't updated!) and mac80211 has a hard time to recognize it... Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-18p54: move p54_vdcf_init to the right place.Christian Lamparter
priv->tx_hdr_len is set by the driver _after_ it called p54_init_common. While this isn't much a problem for any PCI or ISL3887 cards/sticks, because they don't need any extra header and therefore tx_hdr_len is zero for them... Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-18p54: Fix regression due to "net: Delete NETDEVICES_MULTIQUEUE kconfig option"Christian Lamparter
Commit b19fa1f, entitled "net: Delete NETDEVICES_MULTIQUEUE kconfig option" breaks p54pci and p54usb. Additionally, the old logic always tx'ed cts frames (if enabled) with a short preamble when [rate > 3]. (i.e. with any 802.11g rate). Of course this isn't that bad, but it's still wrong! (This patch also clarifies the meanings of some of the fields in the tx header for the hardware. -- JWL) Signed-off-by: Christian Lamparter <chunkeey@web.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x] Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-07p54: swap short slot time dcf valuesChristian Lamparter
these "magic" values must to be the other way round... Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-07p54: Fix for TX sequence number problemLarry Finger
Following "mac80211: fix TX sequence numbers", if a packet has the IEEE80211_TX_CTL_ASSIGN_SEQ assigned, a sequence number must be supplied, either by hardware or software. AFAIK, no such hardware exists for the p54, thus it must be done in software. With this patch, a connection qith p54usb is stable, whereas the interface went off-line in 2-3 hours without this change. Note that this code will have to be reworked for proper sequence numbers on beacons. In addition, the sequence number has been placed in the hardware state, not the vif state. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-04p54: Fix potential concurrent access to private dataLarry Finger
Experience with the rtl8187 driver has shown that mac80211 can make calls to the config callback routine in rapid succession. This patch creates a mutex that protects the private data in several of the routines called by mac80211. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-18Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 Conflicts: Documentation/powerpc/booting-without-of.txt drivers/atm/Makefile drivers/net/fs_enet/fs_enet-main.c drivers/pci/pci-acpi.c net/8021q/vlan.c net/iucv/iucv.c
2008-07-10p54: treat firmware data as constDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-07-02p54: Add quality output to iwlist and iwconfigLarry.Finger@lwfinger.net
The p54 driver family reports a quality of 0 in iwconfig and iwlist output. This patch calculates a quality number as a percentage of the rssi to the maximum signal of 127 reported as the maximum signal. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-10-27 08:35:23 +0000