When TX aggregation is stopped, there are a few
different cases:
 - connection with the peer was dropped
 - session stop was requested locally
 - session stop was requested by the peer
 - connection was dropped while a session is stopping

The behaviour in these cases should be different, if
the connection is dropped then the driver should drop
all frames, otherwise the frames may continue to be
transmitted, aggregated in the case of a locally
requested session stop or unaggregated in the case of
the peer requesting session stop.

Split these different cases so that the driver can
act accordingly; however, treat local and remote stop
the same way and ask the driver to not send frames as
aggregated packets any more.

In the case of connection drop, the stop callback the
driver is otherwise supposed to call is no longer
required.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In commit 'mac80211: support radiotap vendor namespace RX data'
new fields were added to 'struct ieee80211_rx_status' and those
fileds must be zeroed. However the rt2x00 driver stores driver
specific data in the cb array of the rx skbs, so the fields
might contain garbage and this can cause unexpected behaviour.

The rt2x00 driver from the compat-wireless-2012-12-01
tarball caused the following warning:

  WARNING: at
  /devel/ramips/build_dir/target-mipsel_r2_uClibc-0.9.33.2/linux-ramips_rt305x/
  compat-wireless-2012-12-01/net/mac80211/rx.c:115 ieee80211_rx_irqsafe+0x274/0xbcc
  [mac80211]()
  Modules linked in: dwc_otg ledtrig_usbdev nf_nat_irc
  nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp ipt_MASQUERADE
  iptable_nat nf_nat pppoe xt_conntrack xt_CT xt_NOTRACK iptable_raw
  xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack pppox
  ipt_REJECT xt_TCPMSS xt_comment xt_multiport xt_mac xt_limit
  iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async
  ppp_generic slhc rt2800pci(O) rt2800lib(O) rt2x00soc(O) rt2x00pci(O)
  rt2x00lib(O) mac80211(O) usbcore usb_common nls_base crc_itu_t
  crc_ccitt eeprom_93cx6 cfg80211(O) compat(O) arc4 aes_generic
  crypto_blkcipher cryptomgr aead crypto_hash crypto_algapi leds_gpio
  button_hotplug(O) gpio_keys_polled input_polldev input_core
  Call Trace:
  [<801e96b4>] dump_stack+0x8/0x34
  [<80010a9c>] warn_slowpath_common+0x78/0xa4
  [<80010ae0>] warn_slowpath_null+0x18/0x24
  [<80a9710c>] ieee80211_rx_irqsafe+0x274/0xbcc [mac80211]

The patch ensures that each field gets initialized with
zeroes.

Cc: <users@rt2x00.serialmonkey.com>
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Someone who physically disassembled the device confirms that its
chipset is Ralink RT5370n.

(Fixed-up after having already merged original patch. -- JWL)
Signed-off-by: NMaia Kozheva <sikon@ubuntu.com>
Reviewed-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a
Ralink chipset supported by the rt2800usb driver. Currently, to work
around the problem (it's missing in all present kernel versions,
up to and including 3.7.x), I had to add this to /etc/rc.local:

echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id

After that, the device works without problems. Been using it for over
a week with no bugs in sight.

The attached patch is trivial and simply adds the new USB ID to the
list of devices handled by rt2800usb.
Signed-off-by: NMaia Kozheva <sikon@ubuntu.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

CONFIG_HOTPLUG is going away as an option.  As result the __dev*
markings will be going away.

Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: users@rt2x00.serialmonkey.com (moderated for non-subscribers)
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise rt2500* triggers a warning in cfg80211, from net/wireless/core.c:

	/* Combinations with just one interface aren't real */
	if (WARN_ON(c->max_interfaces < 2))

This was introduced in commit 55d2e9da:
rt2x00: Replace open coded interface checking with interface combinations.
Reported-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Tested-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Cc: stable@vger.kernel.org [3.7+]
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This revert:

commit be03d4a4
Author: Andreas Hartmann <andihartmann@01019freenet.de>
Date:   Tue Apr 17 00:25:28 2012 +0200

    rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

To fix problem workaround by above commit use
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for
"mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch).

Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828Bisected-by: NFrancisco Pina Martins <f.pinamartins@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

On the RF3290,RF5360,RF5370,RF5372,RF5390,RF5392
radio frontends, the VCO calibration can be
controlled via the RFCSR3 register. The current
code uses the RFCSR30_RF_CALIBRATION constant to
enable the calibration, however that belongs to
the RFCSR30 register. Although the values of the
constant is correct, but using that for another
register is confusing.

Add a new definition for the VCO calibration enable
bit of the RFCSR3 register and use that in the
relevant places in order to avoid confusions.

The patch contains no functional changes.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch contains no functional changes.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch contains no functional changes.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Reported-by: NPetr Stetiar <ynezz@true.cz>
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds detection for the Sweex LW323 USB wireless network card
in the rt2x00 driver (just one line in rt2800usb.c).
It applies to linux-3.7-rc3.
Signed-off-by: NJaume Delclòs <jaume@delclos.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During hardware restart, all interfaces are iterated even
though they haven't been re-added to the driver, document
this behaviour. The same also happens during resume, which
is even more confusing since all of the interfaces were
previously removed from the driver. Make this optional so
drivers relying on the current behaviour can still use it,
but to let drivers that don't want this behaviour disable
it.

Also convert all API users, keeping the old semantics
except in hwsim, where the new normal ones are desired.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the
EEPROM, but step is equal to 0xff. This results on ridiculous delta
calculations and completely broke TX power settings.
Reported-and-tested-by: NPavel Lucik <pavel.lucik@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch fixes warnings like below happened on resume:

WARNING: at net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x32/0x34()

Problem is that in __ieee80211_susped() we remove sdata (i.e wlan0
interface) and then during resume we call usb_unbind_interface() ->
ieee80211_unregister_hw() with sdata removed.

Patch fixes problem by adding .reset_resume calback, hence we do not
unbind usb device on resume. This callback can be the same as normal
.resume callback, sice we do all needed initalization during interface
start, which is performed on resume [ ieee80211_resume() ->
ieee80211_reconfig() -> rt2x00mac_start() -> rt2x00lib_start ].

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=48041Reported-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Reported-and-tested-by: NStephen Boyd <bebarino@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some rt2800 devices don't have their calibrated max eirp tx power in
their calibration data. For those devices reduce tx power according to
difference between regulatory max channel power and requested tx power.

This patch is based on Helmut Schaa work.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Preparation for use regulatory max channel power in TX power delta
calculations.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don use TX_PWR_CFG_0 register value of OFDM 6M tx power as criterion
since it can be changed. The same do vendor driver (see
AsicAdjustSingleSkuTxPower and AsicGetTxPowerOffset functions from
2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO).
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We skip compensate calculation for non 11b rates on 2.4GHz band. I do
not see that on vendor driver
(2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO).
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Based on AsicAdjustTxPower function from vendor driver
(2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO)
limit per rate TX power values we program into TX_PWR_CFG_ registers.

Note that on some configurations (devices/rates) is allowed to use
bigger values than 0xc, but we use safe maximum value for now. Further
work need to be done to allow use bigger values than 0xc.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TX power delta can be negative. TX_PWR_CFG_ registers allow to set delta
only in range between 0 dBm and 15 dBm (4 bits for each rate). Se we
need to use BBP_R1 to configure negative deltas.

Not utilize +6 dBm increasing BBP_R1 option for safety reason. For now,
this can be used for devices, which export maximum allowed TX power
value.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This should be register 66 instead of 62.
(probably happened by copy&past'ing from the lines below)
Signed-off-by: NDaniel Golle <dgolle@allnet.de>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mac80211 has formal infrastructure to specify which interface combinations
are supported. Make use of this facility in favor of open coding it
ourselves.
So far we only have to specify we can support multiple AP interfaces,
no other combinations are supported.

Inspired by an earlier patch from Paul Fertser.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All drivers set this value to 1, so there is no need (currently) to let
drivers set this.
Therefor, remove the field; we can always add it back when it is needed.

Inspired by an earlier patch from Paul Fertser.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Setting of the individual fields of the RF register can be simplified.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

Move RT3290 BBP initialization sequence (part) to the right place in the code.

This is just a code style change, no functional changes.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Align with the values used by the RT3572 Ralink vendor driver v2.5.0.0.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make the code in rt2800_get_default_vgc more understandable and
readable, especially for the 5GHz band values.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support for the RT3352 WiSoC was developed for and tested with the ALL5002
devboard running OpenWrt. For now, this supports only devices with internal
TXALC. Corrections were made according to the remarks of Stanislaw Gruszka and
Gertjan van Wingerde, thank you guys for reviewing!
Signed-off-by: NDaniel Golle <dgolle@allnet.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Refactor the probe_hw code so that more code can be shared between
rt2800pci and rt2800usb.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The various rt2x00 drivers use different methods to name the different
GPIO register fields indicating the GPIO pin value and the fields
indicating the direction.
Start using a unified naming scheme for the GPIO register fields:
	- <csr>_VAL<x> for fields indicating the GPIO pin value.
	- <csr>_DIR<x> for fields indicating the GPIO pin direction.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Ensure that all active GPIO pins are included in the GPIO register
definitions, nothing more and nothing less.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.

The fix was tested on the latest compat-wireless-3.5.1-1-snpc.

Cc: stable@vger.kernel.org
Signed-off-by: NSergei Poselenov <sposelenov@emcraft.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to program the rfkill switch GPIO pin direction to input at
device initialization time, not only when the interface is brought up.
Doing this only when the interface is brought up could lead to rfkill
detecting the switch is turned on erroneously and inability to create
the interface and bringing it up.
Reported-and-tested-by: NAndreas Messer <andi@bastelmap.de>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The register is 16 bits wide, not 32.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is an RT3572 based device.
Signed-off-by: NMaximilian Engelhardt <maxi@daemonizer.de>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to the vendor driver v2.6.0.1, during the rf register init the SRAM
voltage should be increased to 1.35V and after 1ms decreased back to 1.2V. This
patch adds the field setting of LDO_CFG0_LDO_CORE_VLEVEL accordingly.

Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@blackshift.org>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>