Some architectures give problems when reading
RX frame descriptor words when the descriptor
is not aligned on a 4 byte boundrary.

Due to optimalizations for the ieee80211 payload
4 byte alignment, it is no longer guarenteed
that the descriptor is placed on the 4 byte
boundrary (In fact, for rt73usb it is absolutely
never aligned to 4 bytes, for rt2500usb it depends
on the length of the payload).

This will copy the descriptor to a 4 byte aligned
location before it is read for the first time.
This will also move the payload data alignment
in rt2x00usb (instead of inside the driver) where
it has always belonged.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix a typo in the link tuner where accidently the
2GHz band was checked instead of the 5GHz band.
This forced the link tuner to work in an invalid
range for the currently active band.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The MAC address offset defines were incorrect because
the byte offset was used instead of word index. This
bug had no affect on normal operations since these
defines weren't used. (EEPROM_MAC_ADDR_0 was used
to read 6 bytes from).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The supported_bands field of struct hw_mode_spec now represents a bitfield,
so bitfield operators need to be tested with when setting the band data.

The current code generates the following warning:

[176624.986244] WARNING: at /usr/local/src/incoming/compat-wireless-2.6/net/wireless/core.c:269 wiphy_register()
[176624.986249] Pid: 12548, comm: modprobe Tainted: P        2.6.24.2#4
[176624.986251]
[176624.986251] Call Trace:
[176624.986277]  [<ffffffff881c56bf>] :cfg80211:wiphy_register+0x17f/0x1a0
[176624.986282]  [<ffffffff881ddf80>] :rt61pci:rt61pci_eepromregister_write+0x0/0x80
[176624.986302]  [<ffffffff88b7e4bc>] :mac80211:ieee80211_register_hw+0x2c/0x2b0
[176624.986310]  [<ffffffff881cdc80>] :rt2x00lib:rt2x00lib_probe_dev+0x350/0x3f0
[176624.986318]  [<ffffffff881d74b9>] :rt2x00pci:rt2x00pci_probe+0x149/0x200
[176624.986325]  [<ffffffff8030c858>] pci_device_probe+0xf8/0x170
[176624.986331]  [<ffffffff803594fc>] driver_probe_device+0x9c/0x1c0
[176624.986335]  [<ffffffff80359700>] __driver_attach+0x0/0xb0
[176624.986337]  [<ffffffff803597a5>] __driver_attach+0xa5/0xb0
[176624.986341]  [<ffffffff8035877d>] bus_for_each_dev+0x4d/0x80
[176624.986347]  [<ffffffff80358b8c>] bus_add_driver+0xac/0x210
[176624.986351]  [<ffffffff8030cad3>] __pci_register_driver+0x73/0xc0
[176624.986357]  [<ffffffff8025689e>] sys_init_module+0x18e/0x1a20
[176624.986374]  [<ffffffff8020c42e>] system_call+0x7e/0x83
Signed-off-by: NGertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The async vendor requests are a ugly hack which is not working correctly.
The proper fix for the scheduling while atomic issue is finding out why
we can't use led classes for USB drivers and fix that.

Just replace all async calls with the regular ones and print an
error for the disallowed LED configuration attempts. That will
help in determining which led class is causing the problem.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't wildly pass any number for num_rates to rt2x00lib,
instead pass which type of rates are supported (CCK, OFDM).
Same for num_modes but then for the 2GHZ and 5GHZ band.

This makes the interface look much nicer and makes
extending it later easier.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The dscape stack was renamed to mac80211 a long time ago,
we are long overdue with fixing all comments to reflect this.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Specifications indicate the TSF registers are read-only,
so there is no point in writing 0 to those registers.

As far as I know there isn't another way to reset the
TSF registers. So removing these callbacks will notify
mac80211 about the lack of support.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As Adam Baker reported the DMA address for the
descriptor base was incorrectly initialized in
the PCI drivers.

Instead of the DMA base for the descriptor, the
DMA base for the data was passed resulting in a
broken TX/RX state for PCI drivers.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ACK_CTS frame is a control frame, this means
dropping the frame depends on the FIF_CONTROL flag
for filtering.

This also fixes an obvious typo in register definition.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds a new flag for the skb_frame_desc structure which is used to tag
rts/cts frames that are generated by the driver. Through the tag we can
recognize frames we have generated ourselves, so we don't report their tx
status to mac80211.

This patch is based on the original patch by
Mattias Nissler <mattias.nissler@gmx.de>.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 sends the txpower to use during config(),
we already store it in the rt2x00_dev structure.
When writing the descriptor correctly initialize
the txpower field with this value to make sure
all frames are send out with the correct tx power.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the radio is being disabled we should also
kill the guardian urb which could still be pending
in the device.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Simplify the way rt2x00 assigns new objects to the
rt2x00lib module. This saves a few if statements
and overall does this looks much nicer.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As Adam Baker reported the queue->qid was not initialized
correctly. The QID_AC_BE was assigned to the RX ring.

This will move the queue initialization into a seperate function
and makes sure that all queues are initialized directly with the
correct qids.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

skbdesc->data_len was not initialized correctly
in rt2x00pci, rt2x00usb, rt2500usb and rt73usb.

The value was set to queue->data_size which
means that the incorrect frame size was pased
to the upper layers.

Correctly base the value on either the skb->len,
or the rx frame size passed to the driver by the
device.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The second eeprom recovery message is about
the RSSI offset for ieee802.11 A.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rename "frame" folder to "queue" folder,
add extra file to this folder which contains
statistics about all hardware queues. This will
help debugging and spotting problems in the
queue indexing system.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Call rt2x00_config_intf() outside of the spinlock context since
the call will sleep for USB drivers. By using the ieee80211_if_conf
values as arguments we make keep access tp rt2x00_intf thread safe
even without the lock.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The csr_cache and csr_addr pointers are both the same size
and they are never used both by the same driver. This makes
them a nice candidate for an union.
We could merge into 1 pointer, but that would either upset sparse,
or require a lot of __force casts.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Select CONFIG_NEW_LEDS before selecting the other LED config
options. This fixes a link error when NEW_LEDS was disabled.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When calculating the offset to add to the queue entry base to get the
individual entry's private data area the base address must be treated
as a char * not a struct queue_entry so we can do byte oriented
pointer arithmetic with it.
Signed-off-by: NAdam Baker <linux@baker-net.org.uk>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the last remnants of the MGMT ring initialization
from rt61pci.ko
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the debug messages regarding initialization from
EEPROM. The values are vendor specific, and are not really
needed for debug purposes. If they ever become usefull we
still have access to them through debugfs which also
prints the exact same values...
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Be more strict when using the queue_entry_priv_pci_rx
and queue_entry_priv_pci_tx structures. Only use a
particular type that matches the queue type.

When freeing the DMA the priv_tx->data and priv_tx->dma
was used. This is incorrect since the start of the DMA
was in fact the priv_tx->desc pointer. Instead of
recalculating the dma_addr_t for the DMA start this
patch will swap the data and descriptor part of the
allocated memory.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Michael Büker <m.bueker@berlin.de> reports that the RT2x00 drivers
are not indented as they should be, so use proper dependencies to make
them be indented as expected.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Ack-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix typo in rate initialization. This fixes the WARN_ON()
in net/wireless/util.cpp:83
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add kerneldoc for vendor request functions in rt2x00usb.
Add asynchroneous vendor request function in rt2x00usb.

With the availability of the asynchroneuous vendor request
we can now enable LED class support for rt2500usb and rt73usb.
Since LED handling is not important, it doesn't really matter
if a register call fails (This solution is better then no
LED class support at all).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make use of the led triggers provided by mac80211 to control
the led status. This can be enabled through a per-driver
configuration option which will automatically enable the
generic handler in rt2x00lib.

This has been enabled for rt2500usb and rt73usb for the moment
since the led class will call set_brightness in irq context which
will not work correctly with the usb drivers who need to sleep.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

No need to perform the calculation ourselves when
wireless provides a helper function for it.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2500usb initialized the SIFS and EIFS without using the
values coming from rt2x000lib. After this is fixed HWMODE_{A,B,G}
is now unused and can be removed in favour of the ieee80211_band
enumeration which could still be usefull later.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Recent changes to the rate structure registration broke rt2x00,
the hw_value was reduced from 32bits to 16bits while rt2x00 used
the full 32bits. However the way rt2x00 used the value was inflexible
and needed to be changed anyway.

This patch creates a array containing information for each rate,
the hw_value passed to mac80211 is the index value for that array
including a field to indicate if short preamble should be enabled.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch creates new cfg80211 wiphy API for channel and bitrate
registration and converts mac80211 and drivers to the new API. The
old mac80211 API is completely ripped out. All drivers (except ath5k)
are updated to the new API, in many cases I expect that optimisations
can be done.

Along with the regulatory code I've also ripped out the
IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
unnecessary if the hardware simply gives us whatever channels it wants
to support and we then enable/disable them as required, which is pretty
much required for travelling.

Additionally, the patch adds proper "basic" rate handling for STA
mode interface, AP mode interface will have to have new API added
to allow userspace to set the basic rate set, currently it'll be
empty... However, the basic rate handling will need to be moved to
the BSS conf stuff.

I do expect there to be bugs in this, especially wrt. transmit
power handling where I'm basically clueless about how it should work.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When Q_INDEX is increased, the queue->length should be increased,
only when Q_INDEX_DONE is increased should queue_length be descreased.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As Johannes Berg indicated the BEACON and AFTER_BEACON
queue indeces in mac80211 should be removed because they
are too hardware specific. This patch adds the queue index
defines into rt2x00queue.h and removes the dependency of
the defines inside mac80211.h.

Also move rt2x00pci_beacon_update() into rt2400pci and
rt2500pci individually since it is no longer a generic
function since rt61 and rt2800 no longer use that.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The QID_MGMT is assigned to the beacon and atim queue
during initialization. This means we don't need a seperate
check in write_tx_desc()..
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>