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: NPavel Roskin <proski@gnu.org>
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch brings the 5GHz Phy in any prism54 devices (of course, only those who have one) to life.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I hope this patch is enough to cover at least the basic requirements of IEEE 802.11h's TPC.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds new filters settings to make the card more useful in monitor mode.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds the necessary changes to support LM87 firmwares.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NStephen Blackheath <tramp.enshrine.stephen@blacksapphire.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit b19fa1fa, 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: NChristian Lamparter <chunkeey@web.de>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

these "magic" values must to be the other way round...
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When I moved the TX info into skb->cb apparently I forgot to change a
few places to put the p54-internal data into info->driver_data rather
than skb->cb. This should fix it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch updates mac80211 and drivers to be multi-queue aware and
use that instead of the internal queue mapping. Also does a number
of cleanups in various pieces of the code that fall out and reduces
internal mac80211 state size.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch converts mac80211 and all drivers to have transmit
information and status in skb->cb rather than allocating extra
memory for it and copying all the data around. To make it fit,
a union is used where only data that is necessary for all steps
is kept outside of the union.

A number of fixes were done by Ivo, as well as the rt2x00 part
of this patch.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch modifies struct ieee80211_tx_control to give band
info and the rate index (instead of rate pointers) to drivers.
This mostly serves to reduce the TX control structure size to
make it fit into skb->cb so that the fragmentation code can
put it there and we can think about passing it to drivers that
way in the future.

The rt2x00 driver update was done by Ivo, thanks.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Having drivers start queues is just confusing, their ->start()
callback can block and do whatever is necessary, so let mac80211
start queues and have drivers wake queues when necessary (to get
packets flowing again right away.)
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

trying to clean up the signal/noise code. the previous code in mac80211 had
confusing names for the related variables, did not have much definition of
what units of signal and noise were provided and used implicit mechanisms from
the wireless extensions.

this patch introduces hardware capability flags to let the hardware specify
clearly if it can provide signal and noise level values and which units it can
provide. this also anticipates possible new units like RCPI in the future.

for signal:

  IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
  IEEE80211_HW_SIGNAL_DB     - dB difference to unspecified reference point
  IEEE80211_HW_SIGNAL_DBM    - dBm, difference to 1mW

for noise we currently only have dBm:

  IEEE80211_HW_NOISE_DBM     - dBm, difference to 1mW

if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
to provide the maximum value (max_signal) it reports in order for applications
to make sense of the signal values.

i tried my best to find out for each driver what it can provide and update it
but i'm not sure (?) for some of them and used the more conservative guess in
doubt. this can be fixed easily after this patch has been merged by changing
the hardware flags of the driver.

DRIVER          SIGNAL    MAX	NOISE   QUAL
-----------------------------------------------------------------
adm8211         unspec(?) 100   n/a     missing
at76_usb        unspec(?) (?)   unused  missing
ath5k           dBm             dBm     percent rssi
b43legacy       dBm             dBm     percent jssi(?)
b43             dBm             dBm     percent jssi(?)
iwl-3945        dBm             dBm     percent snr+more
iwl-4965        dBm             dBm     percent snr+more
p54             unspec    127   n/a     missing
rt2x00          dBm	        n/a     percent rssi+tx/rx frame success
  rt2400        dBm             n/a
  rt2500pci     dBm             n/a
  rt2500usb     dBm             n/a
  rt61pci       dBm             n/a
  rt73usb       dBm             n/a
rtl8180         unspec(?) 65    n/a     (?)
rtl8187         unspec(?) 65    (?)     noise(?)
zd1211          dB(?)     100   n/a     percent

drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

net/mac80211/wme.c: In function ‘wme_qdiscop_enqueue’:
net/mac80211/wme.c:219: warning: comparison is always false due to limited range of data type

drivers/net/wireless/p54/p54common.c: In function ‘p54_conf_tx’:
drivers/net/wireless/p54/p54common.c:947: warning: comparison is always false due to limited range of data type
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This
 * makes the queue number passed to drivers a u16
   (as it will be with skb_get_queue_mapping)
 * removes the useless queue number defines
 * splits hw->queues into hw->queues/ampdu_queues
 * removes the debugfs files for per-queue counters
 * removes some dead QoS code
 * removes the beacon queue configuration for IBSS
   so that the drivers now never get a queue number
   bigger than (hw->queues + hw->ampdu_queues - 1)
   for tx and only in the range 0..hw->queues-1 for
   conf_tx.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The callback takes a ieee80211_tx_queue_stats with a contained
array of ieee80211_tx_queue_stats_data, remove the former, rename
the latter to ieee80211_tx_queue_stats and make tx_stats() take
the array directly.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When I called p54_parse_eeprom() on a hand-coded structure
I managed to make a small mistake with wrap->len which caused
a segfault a few lines down when trying to read entry->len.
This patch changes the validation code to avoid such problems.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Tested-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since the EEPROM structure is read from hardware, it is
always little endian, annotate that in the struct and
make sure to convert where applicable.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: Michael Wu <flamingice@sourmilk.net>
Tested-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch allows p54common to print the
uknown EEPROM fields, which can help
when debugging/testing devices.
Signed-off-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes a few sparse warnings in p54.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This trival one-liner changes the QoS initialization values to match IEEE
802.11e defaults.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>