1. 24 4月, 2012 8 次提交
  2. 17 4月, 2012 6 次提交
  3. 14 4月, 2012 6 次提交
  4. 13 4月, 2012 15 次提交
  5. 12 4月, 2012 5 次提交
    • T
      cfg80211: add channel switch notify event · 5314526b
      Thomas Pedersen 提交于
      The firmware may decide to switch channels while already beaconing, e.g.
      in response to a cfg80211 connect request on a different vif. Add this
      event to notify userspace when an AP or GO interface has successfully
      migrated to a new channel, so it can update its configuration
      accordingly.
      Signed-off-by: NThomas Pedersen <c_tpeder@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5314526b
    • J
      cfg80211/mac80211: enable proper device_set_wakeup_enable handling · 6d52563f
      Johannes Berg 提交于
      In WoWLAN, we only get the triggers when we actually get
      to suspend. As a consequence, drivers currently don't
      know that the device should enable wakeup. However, the
      device_set_wakeup_enable() API is intended to be called
      when the wakeup is enabled, not later when needed.
      
      Add a new set_wakeup() call to cfg80211 and mac80211 to
      allow drivers to properly call device_set_wakeup_enable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6d52563f
    • J
      mac80211: clean up an ieee80211_do_open error path · 4d6c36fa
      Johannes Berg 提交于
      Eliad's comment prompted me to look closer at
      the error paths in ieee80211_do_open() and I
      found one that should use the error labels.
      
      Also add a comment about the clear_bit since
      in many error cases the bit hasn't been set.
      
      Cc: Eliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4d6c36fa
    • J
      mac80211: add improved HW queue control · 3a25a8c8
      Johannes Berg 提交于
      mac80211 currently only supports one hardware queue
      per AC. This is already problematic for off-channel
      uses since if we go off channel while the BE queue
      is full and then try to send an off-channel frame
      the frame will never go out. This will become worse
      when we support multi-channel since then a queue on
      one channel might be full, but we have to stop the
      software queue for all channels. That is obviously
      not desirable.
      
      To address this problem allow drivers to register
      more hardware queues, and allow them to map them to
      virtual interfaces. When they stop a hardware queue
      the corresponding AC software queues on the correct
      interfaces will be stopped as well. Additionally,
      there's an off-channel queue to solve that problem
      and a per-interface after-DTIM beacon queue. This
      allows drivers to manage software queues closer to
      how the hardware works.
      
      Currently, there's a limit of 16 hardware queues.
      This may or may not be sufficient, we can adjust it
      as needed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3a25a8c8
    • J
      mac80211: add explicit monitor interface if needed · 4b6f1dd6
      Johannes Berg 提交于
      The queue mapping redesign that I'm planning to do
      will break pure injection unless we handle monitor
      interfaces explicitly. One possible option would
      be to have the driver tell mac80211 about monitor
      mode queues etc., but that would duplicate the API
      since we already need to have queue assignments
      handled per virtual interface.
      
      So in order to solve this, have a virtual monitor
      interface that is added whenever all active vifs
      are monitors. We could also use the state of one
      of the monitor interfaces, but managing that would
      be complicated, so allocate separate state.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b6f1dd6