1. 10 9月, 2014 6 次提交
    • S
      ath9k: Add CTWindow support · fdcf1bd4
      Sujith Manoharan 提交于
      Since CTWindow can be used for improving discoverability,
      fill this field in the NoA Attribute properly.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fdcf1bd4
    • S
      ath9k: Fix offchannel duration calculation · bb628eb9
      Sujith Manoharan 提交于
      Currently, different units are used for handling
      sc->offchannel.duration. In scan mode, it contains jiffies and in RoC
      mode, milliseconds is used. This causes confusion since in
      ath_chanctx_switch(), TU_TO_USEC is used to determine the offchannel
      duration, resulting in incorrect values. Fix this by using jiffies in
      both modes.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bb628eb9
    • S
      ath9k: Fix NoA start time calculation · bd81533d
      Sujith Manoharan 提交于
      The start time field in the NoA attribute needs to be
      updated based on the TSF timer when an absence notification
      is sent by the P2P GO. When two channel contexts are active,
      continuous, cyclic NoA is announced by setting the count value to 255,
      but the start time is updated only once, for one beacon and
      the same value is sent in all subsequent beacons, even
      though the timestamp keeps moving.
      
      Fix this by removing the check for 'periodic_noa_duration'
      and assign the interface's start_time/duration values directly
      when there is more than one active context.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bd81533d
    • S
      ath9k: Fix panic when adding an AP interface · 9bf30ff9
      Sujith Manoharan 提交于
      If a station interface is already assigned to a context
      and is active and a second interface of type AP is added,
      then beaconing on the new interface has to be begin only
      after the BSS_CHANGED_BEACON_ENABLED flag is sent by mac80211
      to the driver.
      
      But, since we issue ATH_CHANCTX_EVENT_ENABLE_MULTICHANNEL as soon
      as a new channel context is added, a switch occurs almost immediately
      before BSS_CHANGED_BEACON_ENABLED is received. When a HW reset
      is done for the new context, beacons are enabled for the
      interface since "enable_beacon" in the BSS config maintained
      in mac80211 is true - but the driver hasn't been notified yet.
      This causes a panic, since the beacon interval is zero for this
      interface and ath9k_cmn_beacon_config_ap() doesn't have a safety check.
      
      Fix this panic by checking if the beacon params has been cached
      for this context and use the "enable_beacon" flag maintained
      locally in the driver. Also, recalculate the summary data
      after the beacon params have been cached when BSS_CHANGED_BEACON_ENABLED
      is received.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9bf30ff9
    • S
      ath9k: Fix beacons for managed mode · 602607b6
      Sujith Manoharan 提交于
      If the current opmode is managed, the ATH_OP_BEACONS flag
      needs to be set only when there is a primary station interface
      and it is associated/active.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      602607b6
    • S
      ath9k: Fix beacon configuration for channel contexts · 12a1b3d4
      Sujith Manoharan 提交于
      In channel context mode, when a new context is added,
      mac80211 issues a bss_info_changed() notfication when
      preparing the connection for the new interface/context.
      
      But, this is done prior to the mgd_prepare_tx() call which
      is where we switch to the new context. Since the current
      context will be different when the earlier bss_info_changed()
      is handled, the beacon information for the VIF is not
      updated, but discarded since the rules for the current context
      disallows it.
      
      In the subsequent association process for the new context/vif,
      this becomes a problem because the beacon parameters are invalid.
      This causes problems with the TSF timer, causing large jumps.
      
      To fix this, check if the beacon info is being updated for a
      different context and if so, allow it without any checks since
      we limit the max. interfaces to two anyway.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      12a1b3d4
  2. 05 9月, 2014 1 次提交
  3. 29 8月, 2014 33 次提交