1. 08 5月, 2010 6 次提交
    • S
      ath9k_htc: Fix beaconing in IBSS mode · 9c6dda4e
      Sujith 提交于
      The current way of managing beaconing in ad-hoc
      mode has a subtle race - the beacon obtained from mac80211
      is freed in the SWBA handler rather than the TX
      completion routine. But transmission of beacons goes
      through the normal SKB queue maintained in hif_usb,
      leading to a situation where __skb_dequeue() in the TX
      completion handler goes kaput.
      
      Fix this by simply getting a beacon from mac80211 for
      every SWBA and free it in its completion routine.
      Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9c6dda4e
    • J
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg 提交于
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
    • J
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg 提交于
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
      
       * different HT/no-HT modes
      
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
      
       * CSA
      
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f444de05
    • D
      orinoco: refactor xmit path · bac6fafd
      David Kilroy 提交于
      ... so orinoco_usb can share some common functionality.
      
      Handle 802.2 encapsulation and MIC calculation in that function.
      The 802.3 header is prepended to the SKB. The calculated MIC is written
      to a specified buffer. Also modify the transmit control word that will
      be passed onto the hardware to specify whether the MIC is present, and
      the key used.
      Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bac6fafd
    • F
      ath9k: fix another source of corrupt frames · 3ef83d74
      Felix Fietkau 提交于
      Atheros hardware supports receiving frames that span multiple
      descriptors and buffers. In this case, the rx status of every
      descriptor except for the last one is invalid and may contain random
      data. Because the driver does not support this, it needs to drop such
      frames.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ef83d74
    • C
      ar9170usb: remove deprecated aggregation code · f3926b49
      Christian Lamparter 提交于
      This patch removes the incomplete AMPDU implementation in ar9170usb.
      
      The code in question is:
       * too big and complex (more than 550 SLOC.)
         This is enough to qualify for a new separate code file!
      
       * unbalanced quantity & quality
      	over-engineered areas like:
      		* xmit scheduling and queuing frames for multiple HT peers
      		* redundant frame sorting
      	are confronted by gaping holes:
      		* accurate transmission feedback
      		* firmware error-handling and device reset
      		* HT rate control algorithm
      
       * error-prone
      	Since its inclusion, hardly anything was done to fix
      	any of the outlined flaws from the initial commit message.
      
         => This also indicates poor maintainability.
      
       * relies heavily on several spinlocks.
      
      As a result of this shortcomings, the code is slow and does not
      even support the most basic 11n requirement: HT station mode.
      
      Therefore, I request to purge my heap of **** from the kernel:
      "ar9170: implement transmit aggregation".
      
      The next item on the agenda is: (re-)start from scratch with
      an adequate design to accommodate the special requirements
      and features of the available frameworks and tools.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f3926b49
  2. 06 5月, 2010 1 次提交
  3. 05 5月, 2010 6 次提交
  4. 04 5月, 2010 14 次提交
  5. 01 5月, 2010 12 次提交
  6. 29 4月, 2010 1 次提交
    • D
      iwl: cleanup: remove unneeded error handling · f7f7cc47
      Dan Carpenter 提交于
      This is just a cleanup and doesn't change how the code works.
      
      debugfs_create_dir() and debugfs_create_file() return an error pointer
      (-ENODEV) if CONFIG_DEBUG_FS is not enabled, otherwise if an error occurs
      they return NULL.  This is how they are implemented and what it says in
      the DebugFS documentation.  DebugFS can not be compiled as a module.
      
      As a result, we only need to check for error pointers and particularly
      -ENODEV one time to know that DebugFS is enabled.  This patch keeps the
      first check for error pointers and removes the rest.
      
      The other reason for this patch, is that it silences some Smatch warnings.
      Smatch sees the condition "(result != -ENODEV)" and assumes that it's
      possible for "result" to equal -ENODEV.  If it were possible it would lead
      to an error pointer dereference.  But since it's not, we can just remove
      the check.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f7f7cc47