- 30 Nov, 2011 7 commits
-
-
Mohammed Shafi Shajakhan authored
Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The on-channel work optimisations have caused a number of issues, and the code is unfortunately very complex and almost impossible to follow. Instead of attempting to put in more workarounds let's just remove those optimisations, we can work on them again later, after we change the whole auth/assoc design. This should fix rate_control_send_low() warnings, see RH bug 731365. Cc: stable@vger.kernel.org Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Luis R. Rodriguez authored
mBm is passed but dBm was assumed... Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
-
Luis R. Rodriguez authored
Both cases are doing the same so treat the switch cases for both as an "or". Signed-off-by:
-
Luis R. Rodriguez authored
mBm is passed but dBm was assumed... Signed-off-by:
-
Luis R. Rodriguez authored
Tons of drivers missed that we use mBm and not dBm... Signed-off-by:
-
Axel Lin authored
This patch converts the drivers in net/rfkill/* to use the module_platform_driver() macro which makes the code smaller and a bit simpler. Cc: "David S. Miller" <davem@davemloft.net> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Antonio Ospite <ospite@studenti.unina.it> Cc: Rhyland Klein <rklein@nvidia.com> Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Rhyland Klein <rklein@nvidia.com> Signed-off-by:
-
- 28 Nov, 2011 33 commits
-
-
Emmanuel Grumbach authored
Add more data when inconsistencies occur in the AGG state machine. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
Not sure it is the best way to do it, but many times we want to know what the configuration options were enabled for the compiled driver. Let's just log the options during load time; so there were be no confusion. Signed-off-by:
-
Wey-Yi Guy authored
missing the string, add it Signed-off-by:
-
Johannes Berg authored
Since the uCode hasn't been released (yet?), warn only if using older than API 4, but load anything up to API 6. Signed-off-by:
-
Johannes Berg authored
This makes handling the calibration data more generic and no longer requires updating IWL_CALIB_MAX when a new uCode comes with more calibration packets. Since we just copy the data back, there's also no need for understanding which calibration we received -- we can just reflect it back to the runtime uCode. Signed-off-by:
-
Johannes Berg authored
The init microcode knows very well which calibrations are required and sends us results for those that are. Consequently, we can just send all of those to the RT uCode again. The problem with having the driver know about this is that it is a uCode feature, not a hardware feature so the config is completely unsuitable. The only thing we need to check is whether the device needs crystal calibration or not, add a new parameter to the configuration for that. This makes new uCode work on 6000 series devices. Signed-off-by:
-
Hsu, Kenny authored
Create new testmode commands to suppot indirect access of peripheral register. - IWL_TM_CMD_APP2DEV_INDIRECT_REG_READ32 - IWL_TM_CMD_APP2DEV_INDIRECT_REG_WRITE32 Meanwhile, add affix "DIRECT" into original register access commands for better discrimination with new commands. - IWL_TM_CMD_APP2DEV_DIRECT_REG_READ32 - IWL_TM_CMD_APP2DEV_DIRECT_REG_WRITE32 - IWL_TM_CMD_APP2DEV_DIRECT_REG_WRITE8 Signed-off-by:
Kenny Hsu <kenny.hsu@intel.com> Signed-off-by:
-
Nick Kossifidis authored
Optimize ath5k_cw_validate by using the classic (X & (X - 1)) == 0 check to see if a number is power of 2. v2: Use functions from log2.h instead Signed-off-by:
Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
-
Nick Kossifidis authored
According to documentation higher DCUs have higher priority and should be used for beacons and CAB traffic. More specifically DCU 9 should be used for beacons and DCU 8 for CAB traffic, I assumed DCU 7 should be OK for UAPSD traffic. Note that DCU 8 and 9 are special because they can only be mapped to a single QCU each but since we use a 1:1 mapping between QCUs and DCUs anyway we don't have to change much. P.S. I also did a few related cleanups on qcu.c and ath5k.h Signed-off-by:
-
Nick Kossifidis authored
No need to take ath5k_hw as an argument. Signed-off-by:
-
Nick Kossifidis authored
MRR support and 2GHz radio override belong in ah_capabilities and we should use them (e.g. so far we used to set mrr descriptor without checking if MRR support is enabled + we checked for MRR support 2 times, one by trying to set up an MRR descriptor and another one based on MAC version). Signed-off-by:
-
Nick Kossifidis authored
Add a module parameter to disable hw rf kill switch (GPIO interrupt) because in some cases when the card doesn't come with the laptop, EEPROM configuration doesn't match laptop's configuration and rf kill interrupt always fires up and disables hw. I thought of moving this to debugfs and make it per-card but this way it's easier for users and distros to handle. Signed-off-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
-
Nick Kossifidis authored
There is no short calibration on AR5210, make sure we treat it always as full calibration. Signed-off-by:
-
Nick Kossifidis authored
No functional changes Add kernel doc for all ath5k_hw_* functions and strcucts. Also do some cleanup, rename ath5k_hw_init_beacon to ath5k_hw_init_beacon_timers, remove an unused variable from ath5k_hw_pcu_init and a few obsolete macros, mostly related to XR. Signed-off-by:
-
Nick Kossifidis authored
Use usleep_range where possible to reduce busy waits Signed-off-by:
-
Nick Kossifidis authored
Noise floor calibration does not interfere with traffic and should run more often as part of our "short calibration". The full calibration is not the noise floor calibration but the AGC + Gain_F (on RF5111 and RF5112) calibration and should run less often because it does interfere with traffic. So Short calibration -> I/Q & NF Calibration Long calibration -> Short + AGC + Gain_F This patch was for some time on my pub/ dir on www.kernel.org and has been tested by a few people and me. I think it's O.K. to go in. I also changed ah_calibration to ah_iq_cal_needed to make more sense. v2 Use a workqueue instead of a tasklet for calibration Signed-off-by:
-
Nick Kossifidis authored
No functional changes, just a few comments/documentation/cleanup Signed-off-by:
-
Nick Kossifidis authored
Add TXNOFRM to INT_TX_ALL since it's a TX interrupt too. Signed-off-by:
-
Nick Kossifidis authored
Since card has 12 tx queues and we want to keep track of the interrupts per queue we can't fit all these interrupt bits on a single register. So we have 5 registers, the primary interrupt status register (PISR) and the 4 secondary interupt status registers (SISRs). In order to be able to read them all at once (atomic operation) Atheros introduced the Read-And-Clear registers to make things easier. So when reading RAC_PISR register, hw does a read on PISR and all SISRs, returns the value of PISR, copies all SISR values to their shadow copies (RAC_SISRx) and clears PISR and SISRs. This saves us from reading PISR/SISRs in a sequence. So far we 've used this approach and MadWiFi/Windows driver etc also used it for years. It turns out this operation is not atomic after all (at least not on all cards) That means it's possible to loose some interrupts because they came after the copy step and hw cleared them on the clean step ! That's probably the reason we got missed beacons, got stuck queues etc and couldn't figure out what was going on. With this patch we switch from RaC operation to an alternative method (that makes more sense IMHO anyway, I just chose to be on the safe side so far). Instead of reading RAC registers, we read the normal PISR/SISR registers and clear any bits we got by writing them back on the register. This will clear only the bits we got on our read step and leave any new bits unaffected (at least that's what docs say). So if any new interrupts come up we won't miss it. I've tested this with an AR5213 and an AR2425 and it seems O.K. Many thanks to Adrian Chadd for debuging this and reviewing the patch ! v2: Make sure we don't clear PISR bits that map to SISR generated interrupts (added a comment on the code for this) Signed-off-by:
-
Johannes Berg authored
There's little point in this config symbol, if tracing is disabled the overhead is negligible and if you think it's too bad you can always turn off tracing completely. Also remove the part where we don't have sparse check the tracing code -- it seems that it can now deal with it (or the code changed). Signed-off-by:
-
Thomas Pedersen authored
Lose about two levels of unnecessary indentation. Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Thomas Pedersen authored
We used to initiate a path discovery when receiving a frame for which there is no forwarding information. To cut down on PREQ spam, just send a (gated) PERR in response. Also separate path discovery logic from nexthop querying. This patch means we no longer queue frames when forwarding, so kill the PERR TX stuff in discard_frame(). Signed-off-by:
-
Thomas Pedersen authored
As per 802.11mb 13.9.11.3 Signed-off-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
-
Thomas Pedersen authored
We can't rely on ieee80211_select_queue() to do its job at this point since the skb->protocol is not yet known. Instead, factor out and reuse the queue mapping logic for injected frames. Also, to mitigate congestion, forwarded frames should be dropped if the outgoing queue was stopped. This was not correctly implemented as we were not checking the right queue. Furthermore, we were dropping frames that had arrived to their destination if that queue was stopped. Signed-off-by:
-
Thomas Pedersen authored
HWMP originator and target addresses were switched on the air but also on reception, which is why path selection still worked. Signed-off-by:
-
Thomas Pedersen authored
Don't write the TA until next hop is actually known, since we might need the original TA for sending a PERR. Previously we would send a PERR to ourself if path resolution for a forwarded frame failed. Signed-off-by:
-
Chun-Yeow Yeoh authored
Signed-off-by:
Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by:
-
Veli-Pekka Peltola authored
Signed-off-by:
Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com> Signed-off-by:
-
Ben Greear authored
Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Lars-Peter Clausen authored
In ancient times it was necessary to manually initialize the bus field of an spi_driver to spi_bus_type. These days this is done in spi_driver_register(), so we can drop the manual assignment. The patch was generated using the following coccinelle semantic patch: // <smpl> @@ identifier _driver; @@ struct spi_driver _driver = { .driver = { - .bus = &spi_bus_type, }, }; // </smpl> Signed-off-by:Lars-Peter Clausen <lars@metafoo.de> Cc: Dan Williams <dcbw@redhat.com> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Luciano Coelho <coelho@ti.com> Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Acked-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Eliad Peller authored
It doesn't have any actual effect here, but we should skb_put() *before* copying the data. Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
-
Johannes Berg authored
Emmanuel reported that my previous patches to enable handing all fragments to drivers at once triggered the warning that the SKB queue wasn't empty. This is happening when we actually queue up some frames and don't hand them to the driver (queues are stopped). The reason for it is that my code that splices the frame(s) over to the pending queue didn't re-init the local queue, so skb_queue_empty() was false. Fix this by using the _init versions of the splicing. Also, convert the warning to WARN_ON_ONCE. Reported-by:
-
Helmut Schaa authored
Previously BlockAcks were always dropped by the rt2800 hardware while BlockAckReqs were always accepted. However, both are only useful on monitor interfaces at the moment and both are control frames. So pass them up when mac80211 sets FIF_CONTROL. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
