There were some changes in the values we have to use for these settings.  This
patches updates them.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In revision 6.1.0.0.288 the general parameters structure has changed.  This
patch updates the driver code accordingly.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In revision 6.1.0.0.288 the radio parameters structure has changed.  This
patch updates the driver code accordingly.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If userencounter the "Fatal DMA Problem" with a BCM43XX device, and
still wish to use b43 as the driver, their only option is to rebuild
the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and
allows PIO mode to be selected with a load-time parameter for the module.
Note that the configuration variable CONFIG_B43_PIO is also removed.

Once the DMA problem with the BCM4312 devices is solved, this patch will
likely be reverted.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NJohn Daiker <daikerjohn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The receive descriptor ops that are currently marked as being for
8687 only are actually used for all STA firmware images, whereas the
receive descriptor ops marked as 8366 are only used on 8366 when an
AP firmware image is in use.

Rename the receive descriptor ops to reflect this, use the STA ops
unconditionally if the firmware image loaded reported the STA ready
code, and rename the mwl8k_device_info::rxd_ops member to ap_rxd_ops
to indicate that it should only be used if we are running on AP
firmware.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whether the firmware we have loaded is AP or STA firmware decides
which receive descriptor format we have to use.  Therefore, move
rx/tx ring initialisation to be after firmware loading.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Sort firmware commands by command code, get rid of the 802_11 substring
in all command names, and make sure that the command functions match the
firmware command names.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Disable the TX hang monitoring routine when doing a scan.
Monitoring for a hung situation is not really necessary during
a scan run.

Cc: stable@kernel.org
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cancel/restart the ANI timer directly.
With this patch, the ANI lock can be removed.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k currently supports only RX interrupt
mitigation.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NEmese Revfy <re.emese@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of hard-coding the SM PS mode per hardware,
this makes iwlwifi support the new mac80211 API for
controlling the SM PS mode.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The zd1211rw always assumed that the storage device is at endpoint 1,
but there are devices (Spairon Homelink 1202) that are at endpoint 0.
Try both, starting with 1 to make sure to not break existing setups.
Signed-off-by: NStefan Seyfried <seife@sphairon.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStefan Seyfried <seife@sphairon.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

IEEE-802.11n spec says the RX highest data rate field does
not specify the highest supported RX data rate if its not set.
Ignore it if not set then. Refer to section 7.3.56.4

Cc: johannes@sipsolutions.net
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When debugging you want to be lazy and not have to parse
bits yourself so let mac80211 debugfs do the parsing for you.

This is what I get against my WRT610N:

root@tux:~# cat /sys/kernel/debug/ieee80211/phy0/stations/00\:22\:6b\:aa\:bb\:01/ht_capa
ht supported
cap: 0x000e
	HT20/HT40
	SM Power Save disabled
	No RX STBC
	Max AMSDU length: 7935 bytes
	No DSSS/CCK HT40
ampdu factor/density: 2/6
MCS mask: ff ff 00 00 00 00 00 00 00 00
MCS rx highest: 0
MCS tx params: 0

Cc: johannes@sipsolutions.net
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The MCS set is 16 bits so when debugging ensure the full 16 bits
are represented. Current reading would make you think its only
8 bits.

Cc: johannes@sipsolutions.net
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Speaking of 802.11n rates in terms of Mbps doesn't really developers
and is just useful for users. To aid debugging add the MCS index back
and an HT20/HT40 mode.

New screenshot:

    HT    MCS   Rate    Success    Retries   XRetries        PER
                6.0:          0          0          0          0
                9.0:          0          0          0          0
               12.0:         26        260          0         49
               18.0:         80        804          2         58
               24.0:          0          0          0          0
               36.0:          0          0          0          0
               48.0:          0          0          0          0
               54.0:          0          0          0          0
  HT20      0   6.5:       1368      13660          0         48
  HT20      1  13.0:          0          0          0          0
  HT20      2  19.5:          0          0          0          0
  HT20      3  26.0:          0          0          0          0
  HT20      4  39.0:          0          0          0          0
  HT20      5  52.0:         55        578         14         43
  HT20      6  58.5:         29        306          8         69
  HT20      7  65.0:         21        210          0         67
  HT20      8  13.0:         21        210          0         56
  HT20      9  26.0:          0          0          0          0
  HT20     10  39.0:          0          0          0          0
  HT20     11  52.0:          0          0          0          0
  HT20     12  78.0:          0          0          0          0
  HT20     13 104.0:          0          0          0          0
  HT20     14 117.0:          0          0          0          0
  HT20     15 130.0:         27        290         10         55
  HT40      0  13.5:         79        687         16         17
  HT40      1  27.5:         60        409         10         17
  HT40      2  40.5:         56        381         21         25
  HT40      3  54.0:         44        302         21         18
  HT40      4  81.5:         19        171          2         14
  HT40      5 108.0:          0          0          0          0
  HT40      6 121.5:          0          0          0          0
  HT40      7 135.0:          0          0          0          0
  HT40      7 150.0:          0          0          0          0
  HT40      8  27.0:          0          0          0          0
  HT40      9  54.0:          0          0          0          0
  HT40     10  81.0:          0          0          0          0
  HT40     11 108.0:         11        100          0         18
  HT40     12 162.0:         23        200          0         22
  HT40     13 216.0:         61        580          0         35
  HT40     14 243.0:         37        271          0         66
  HT40     15 270.0:         65        217          2         73
  HT40     15 300.0:          0          0          0          0
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since mac80211_hwsim supports multiple virtual interfaces, we need to
iterate through all active interfaces when figuring out whether there
is a match during TX Ack status checking. This fixes TX status
reporting for cases where secondary interfaces are used.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When hw rate control is used, these parameters have
no meaning because the hardware cannot get at them
right now, so disallow setting them. Also clean up
the function a bit.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Determine the offset at compile time.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Used to be a write-only-variable :-)
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This variable was once set to WLAN_CAPABILITY_SHORT_PREAMBLE and
there's no code that could change the variable to something else.
Therefore it seems this is not necessary :-)
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mostly for the embedded people that know beforehand that they don't need
MESH at all and want to save some bytes, but also helpful for the upcoming
cfg80211 transition.

   text    data     bss     dec     hex filename
 114264    2308     140  116712   1c7e8 libertas.ko   with mesh
 105026    2000     140  107166   1a29e libertas.ko   without mesh
 --------------------------------------------------
  -9238    -308           -9546
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While it's might be technically true that only MESH-enabled firmwares
are also RTAP-enabled, I like to have this decoupled.
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mesh_autostart_enabled was nowhere set. Rumor is that this is used in the
OLPC tree, but they never did submit their code upstream.

After removing this code, it turned out that the sync_channel stuff is now
also unused, so get rid of that as well.
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Both variables contained the same information (no mesh, old mesh, new mesh).
So we can get rid of one variable.

Also move the mesh-version test from cmd.c into mesh.c.
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Clean out some cruft that could use an already existing
sta_info struct -- that case cannot happen. Also, there's
a bug there -- if allocation/insertion fails then it is
possible that we are left in a lingering state where
mac80211 waits for the AP, cfg80211 waits for mac80211,
but the AP has already replied. Since there's no way to
indicate an internal error, pretend there was a timeout,
i.e. that the AP never responded.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>