1. 12 5月, 2009 18 次提交
    • R
      iwlwifi: more descriptive unsupported hardware message · 9906a07e
      Reinette Chatre 提交于
      Somehow these pre-production cards are showing up in the community.
      With this message we hope that it will be clear that the hardware is not
      supported.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9906a07e
    • M
      iwlagn: improve rate scale table search · d6e93399
      Mohamed Abbas 提交于
      iwlagn rate scaling will periodically search other rate scale
      tables to switch to the best table regarding performance. In the past
      the number of search tables were 3. Every time the rate scale algorithm
      goes through these available tables in will stay in current table for
      some time before start searching again. Recent driver support more
      feature and antenna, so we have more tables to search. This patch make
      sure we go through all available tables.
      Signed-off-by: NMohamed Abbas <mohamed.abbas@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d6e93399
    • J
      iwlwifi: clean up PS code · 7af2c460
      Johannes Berg 提交于
      This removes all the dead code that tries to adjust the power
      saving level based on the system AC state (inacceptable policy
      in the kernel) or based on overtemp conditions (unused).
      
      Also, pass _all_ policy wrt. enabling PS to mac80211, since
      we do not use the power_disabled internally I now use that to
      mirror the mac80211 CONF_PS setting. When mac80211 turns off
      CONF_PS we follow suit. This means that the user power level
      (which can currently only be set from sysfs) is not touched
      for mac80211 powersave changes.
      
      This means no "association status" checks are necessary since
      mac80211 will not allow power save to be enabled when not
      associated.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMohamed Abbas <mohamed.abbas@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7af2c460
    • J
      iwlwifi: fix PS disable status race · f0f74a0e
      Johannes Berg 提交于
      iwlwifi internally needs to keep track of whether PS
      is enabled in the firmware or not. To do this, it keeps
      a bit in the status flags, called STATUS_POWER_PMI.
      
      The code to set this bit looks as follows:
      
      static int iwl_set_power(struct iwl_priv *priv, void *cmd)
      {
      	return iwl_send_cmd_pdu_async(priv, POWER_TABLE_CMD,
      				      sizeof(struct iwl_powertable_cmd),
      				      cmd, NULL);
      }
      
      int iwl_power_update_mode(...)
      {
      	[...]
      	if (final_mode != IWL_POWER_MODE_CAM)
      		set_bit(STATUS_POWER_PMI, &priv->status);
      
      	iwl_update_power_cmd(priv, &cmd, final_mode);
      	cmd.keep_alive_beacons = 0;
      
      	if (final_mode == IWL_POWER_INDEX_5)
      		cmd.flags |= IWL_POWER_FAST_PD;
      
      	ret = iwl_set_power(priv, &cmd);
      
      	if (final_mode == IWL_POWER_MODE_CAM)
      		clear_bit(STATUS_POWER_PMI, &priv->status);
      	else
      		set_bit(STATUS_POWER_PMI, &priv->status);
      
      	if (priv->cfg->ops->lib->update_chain_flags && update_chains)
      		priv->cfg->ops->lib->update_chain_flags(priv);
      	[...]
      }
      
      Now, this bit really needs to track what the _firmware_
      thinks, not what the driver thinks. Therefore, there is
      a race condition here -- the driver sets the bit before
      it knows that the async command sent to the card in the
      iwl_set_power function has been processed. As a result,
      the call to update_chain_flags() may think that the card
      has been woken up (PMI bit cleared) while in reality it
      hasn't processed the async POWER_TABLE_CMD yet.
      
      This leads to bugs -- any commands the update_chain_flags
      function sends can get stuck and subsequent commands also
      fail.
      
      The fix is almost trivial: since there's no reason to send
      an async command here (in fact, there almost never should
      be since many mac80211 callbacks can sleep) just make the
      function wait for the card to process the command and then
      return and clear the PMI bit.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMohamed Abbas <mohamed.abbas@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f0f74a0e
    • J
      iwlwifi: do proper hw restart · 19cc1087
      Johannes Berg 提交于
      When the microcode fails for any reason, ask mac80211 to
      recover instead of trying ourselves and failing at it.
      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>
      19cc1087
    • J
      mac80211: remove ieee80211_ht_bss_info · 44033f80
      Johannes Berg 提交于
      This struct is no longer used (and hasn't been for a while).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      44033f80
    • J
      mac80211: properly track HT operation_mode · 413ad50a
      Johannes Berg 提交于
      When we disassociate, we set the channel to non-HT which
      obviously invalidates any ht_operation_mode setting. But
      when we then associate with the next AP again, we might
      still have the ht_operation_mode from the previous AP
      cached and fail to configure the hardware with the new
      (but unchanged) operation mode. This patch fixes it by
      separately tracking whether our cache is valid.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      413ad50a
    • J
      mac80211: move HT operation mode BSS info · 9ed6bcce
      Johannes Berg 提交于
      There really is no need to have a separate struct for a
      single variable. The fact that it exists is due to the
      code legacy, but we can remove that now. Very simple.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9ed6bcce
    • I
      rt2x00: Fix chipset detection for rt73usb · 5a994011
      Ivo van Doorn 提交于
      The lower 4 bytes of the chipset revision must contain
      a non-zero value. This bug was introduced by
      "rt2x00: Simplify rt2x00_check_rev".
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5a994011
    • J
      mac80211: improve scan timing · 99c84cb0
      Johannes Berg 提交于
      The call to ieee80211_hw_config() is supposed to apply changes
      synchronously, so once it returns the parameters are applied to
      the hardware. Thus, there really is no need to delay the probing
      by the channel switch time again since the channel switch has
      already happened once we get to this code.
      
      Additionally, there is no need to wait for a NAV update (probe
      delay) when the channel is passively scanned. Remove that extra
      time too.
      
      This cuts scanning time from over 7 seconds to under 4 on ar9170,
      which is due to the number of channels scanned and ar9170's switch
      time being advertised as 135ms (my test now indicates it is about
      77ms with the current driver, but the difference might also be due
      to using a different machine with different USB controllers).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      99c84cb0
    • J
      mac80211: MFP - Drop unprotected Action frames prior key setup · f2ca3ea4
      Jouni Malinen 提交于
      When management frame protection (IEEE 802.11w) is used, unprotected
      Robust Action frames are not allowed prior to key configuration.
      However, unprotected Deauthentication and Disassociation frames are
      allowed at that point, but not after key configuration.
      
      Make ieee80211_drop_unencrypted() handle the special cases for MFP by
      separating the basic Data frame case from Management frame processing
      and handle the Management frames only if MFP has been negotiated. In
      addition, do not use sdata->drop_unencrypted for Management frames
      since the decision on whether to accept the frame depends on the key
      being configured.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f2ca3ea4
    • J
      mac80211: Drop unencrypted frames based on key setup · 0c7c10c7
      Jouni Malinen 提交于
      When using nl80211, we do not have a mechanism to set
      sdata->drop_unencrypted. Currently, this breaks code that is supposed
      to drop unencrypted frames when protection is expected since
      ieee80211_rx_h_decrypt() is optimized to not set rx->key when the
      frame is not protected.
      
      This patch modifies ieee80211_rx_h_decrypt() to set rx->key for all
      frames and only skip decryption if the frame is not protected. This
      allows ieee80211_drop_unencrypted() to correctly drop frames even if
      drop_unencrypted is not set.
      
      The changes here are not enough to handle all cases, though. Additional
      patches will be needed to implement proper IEEE 802.1X PAE for station
      mode (currently, this is only used for AP mode) and some additional
      rules are needed for MFP to drop unprotected Robust Action frames prior
      to having PTK and IGTK configured.
      
      In theory, the unprotected frames could and should be dropped in
      ieee80211_rx_h_decrypt(). However, due to the special case with EAPOL
      frames that have to be allowed to be received unprotected even when
      keys are set, it is simpler to only set rx->key and allow the
      ieee80211_frame_allowed() function to handle the actual dropping of
      data frames after 802.11->802.3 header conversion. In addition,
      unprotected robust management frames are dropped before they are
      processed.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0c7c10c7
    • J
      iwlwifi: make iwl_set_rate static · 782571f4
      Johannes Berg 提交于
      It's not needed outside iwl-core.c
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      782571f4
    • J
      cfg80211: fix wext iw_freq parsing · 0b258582
      Johannes Berg 提交于
      The function to parse a struct iw_freq has a stupid bug,
      it returns NULL when the channel cannot be found at all,
      but NULL is supposed to mean "auto". Fix this by checking
      the return value of ieee80211_get_channel() and returning
      ERR_PTR(-EINVAL) if it returned NULL (channel not found).
      
      This fixes an issue where you could say (in IBSS mode)
      	iwconfig wlan0 channel 21
      and it would use channel 1 instead because that's the
      first available channel with IBSS allowed (which is what
      the "auto" setting uses).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b258582
    • J
      mac80211: set default QoS values according to spec · aa837e1d
      Johannes Berg 提交于
      We've never really cared about the default QoS (WMM) values, but
      we really should if the AP doesn't send any. This patch makes
      mac80211 use the default values according to 802.11-2007, and
      additionally syncs the default values when we disassociate so
      whatever the last AP said gets "unconfigured".
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aa837e1d
    • J
      mac80211: fix scan channel race · 58905ca5
      Johannes Berg 提交于
      When a software scan starts, it first sets sw_scanning, but
      leaves the scan_channel "unset" (it currently actually gets
      initialised to a default). Now, when something else tries
      to (re)configure the hardware in the window between these two
      events (after sw_scanning = true, but before scan_channel is
      set), the current code switches to the (unset!) scan_channel.
      This causes trouble, especially when switching bands and
      sending frames on the wrong channel.
      
      To work around this, leave scan_channel initialised to NULL
      and use it to determine whether or not a switch to a different
      channel should occur (and also use the same condition to check
      whether to adjust power for scan or not).
      
      Additionally, avoid reconfiguring the hardware completely when
      recalculating idle resulted in no changes, this was the problem
      that originally led us to discover the race condition in the
      first place, which was helpfully bisected by Pavel. This part
      of the patch should not be necessary with the other fixes, but
      not calling the ieee80211_hw_config function when we know it to
      be unnecessary is certainly a correct thing to do.
      
      Unfortunately, this patch cannot and does not fix the race
      condition completely, but due to the way the scan code is
      structured it makes the particular problem Pavel discovered
      (race while changing channel at the same time as transmitting
      frames) go away. To fix it completely, more work especially
      with locking configuration is needed.
      Bisected-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      58905ca5
    • G
      wireless: WL12XX should depend on GENERIC_HARDIRQS · 02018b39
      Geert Uytterhoeven 提交于
      m68k allmodconfig:
      | drivers/net/wireless/wl12xx/main.c: In function 'wl12xx_probe':
      | drivers/net/wireless/wl12xx/main.c:1273: error: implicit declaration of function 'set_irq_type'
      | make[1]: *** [drivers/net/wireless/wl12xx/main.o] Error 1
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      02018b39
    • J
      nl80211 : Add support for configuring MFP · dc6382ce
      Jouni Malinen 提交于
      NL80211_CMD_ASSOCIATE request must be able to indicate whether
      management frame protection (IEEE 802.11w) is being used. mac80211 was
      able to use MFP in client mode only with WEXT, but the new
      NL80211_ATTR_USE_MFP attribute will allow this to be done with
      nl80211, too.
      
      Since we are currently using nl80211 for MFP only with drivers that
      use user space SME, only MFP disabled and required values are
      used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
      be extended with MFP optional in the future, if that is needed with
      some drivers (e.g., if the RSN IE is generated by the driver).
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dc6382ce
  2. 10 5月, 2009 7 次提交
  3. 09 5月, 2009 4 次提交
  4. 08 5月, 2009 11 次提交