1. 13 Dec, 2010 2 commits
    • Johannes Berg's avatar
      cfg80211/nl80211: separate unicast/multicast default TX keys · dbd2fd65
      Johannes Berg authored
      Allow userspace to specify that a given key
      is default only for unicast and/or multicast
      transmissions. Only WEP keys are for both,
      WPA/RSN keys set here are GTKs for multicast
      only. For more future flexibility, allow to
      specify all combiations.
      Wireless extensions can only set both so use
      nl80211; WEP keys (connect keys) must be set
      as default for both (but 802.1X WEP is still
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Bruno Randolf's avatar
      cfg80211: Add antenna availability information · a7ffac95
      Bruno Randolf authored
      Add a field to wiphy for the hardware to report the availble antennas for
      configuration. Only if this is set to something bigger than zero, will the
      anntenna configuration ops be executed.
      Allthough this could be a simple number of antennas, I defined it as a bitmap
      of antennas which are available for configuration, since it's more consistent
      with the rest of the antenna API and there could be cases where the
      hardware allows only configuration of certain antennas. As it does not make
      much of a difference in size or normal usage, I think it's better to be able to
      support this, in case the need arises.
      The antenna configuration is now also checked against the availabe antennas and
      rejected if it does not match.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      v3:	always apply available antenna mask (for "all" antennas case).
      v2:	reject antenna configurations which don't match the available antennas
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  2. 08 Dec, 2010 2 commits
  3. 07 Dec, 2010 1 commit
  4. 06 Dec, 2010 4 commits
  5. 02 Dec, 2010 2 commits
  6. 01 Dec, 2010 5 commits
  7. 30 Nov, 2010 1 commit
  8. 29 Nov, 2010 1 commit
  9. 24 Nov, 2010 4 commits
  10. 22 Nov, 2010 2 commits
    • Luis R. Rodriguez's avatar
      cfg80211: Fix regulatory bug with multiple cards and delays · b2e253cf
      Luis R. Rodriguez authored
      When two cards are connected with the same regulatory domain
      if CRDA had a delayed response then cfg80211's own set regulatory
      domain would still be the world regulatory domain. There was a bug
      on cfg80211's logic such that it assumed that once you pegged a
      request as the last request it was already the currently set
      regulatory domain. This would mean we would race setting a stale
      regulatory domain to secondary cards which had the same regulatory
      domain since the alpha2 would match.
      We fix this by processing each regulatory request atomically,
      and only move on to the next one once we get it fully processed.
      In the case CRDA is not present we will simply world roam.
      This issue is only present when you have a slow system and the
      CRDA processing is delayed. Because of this it is not a known
      Without this fix when a delay is present with CRDA the second card
      would end up with an intersected regulatory domain and not allow it
      to use the channels it really is designed for. When two cards with
      two different regulatory domains were inserted you'd end up
      rejecting the second card's regulatory domain request.
      This fails with mac80211_hswim's regtest=2 (two requests, same alpha2)
      and regtest=3 (two requests, different alpha2) module parameter
      This was reproduced and tested against mac80211_hwsim using this
      CRDA delayer:
             echo $COUNTRY >> /tmp/log
             sleep 2
      And these regulatory tests:
             modprobe mac80211_hwsim regtest=2
             modprobe mac80211_hwsim regtest=3
      Reported-by: default avatarMark Mentovai <mark@moxienet.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Tested-by: default avatarMark Mentovai <mark@moxienet.com>
      Tested-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Daniel Klaffenbach's avatar
      ssb: b43-pci-bridge: Add new vendor for BCM4318 · 1d8638d4
      Daniel Klaffenbach authored
      Add new vendor for Broadcom 4318.
      Signed-off-by: default avatarDaniel Klaffenbach <danielklaffenbach@gmail.com>
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@kernel.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 18 Nov, 2010 2 commits
  12. 17 Nov, 2010 1 commit
  13. 16 Nov, 2010 6 commits
    • Felix Fietkau's avatar
    • Felix Fietkau's avatar
    • Juuso Oikarinen's avatar
      mac80211: Add function to get probe request template for current AP · a619a4c0
      Juuso Oikarinen authored
      Chipsets with hardware based connection monitoring need to autonomically
      send directed probe-request frames to the AP (in the event of beacon loss,
      for example.)
      For the hardware to be able to do this, it requires a template for the frame
      to transmit to the AP, filled in with the BSSID and SSID of the AP, but also
      the supported rate IE's.
      This patch adds a function to mac80211, which allows the hardware driver to
      fetch this template after association, so it can be configured to the hardware.
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Bruno Randolf's avatar
      mac80211: Add antenna configuration · 15d96753
      Bruno Randolf authored
      Allow antenna configuration by calling driver's function for it.
      We disallow antenna configuration if the wiphy is already running, mainly to
      make life easier for 802.11n drivers which need to recalculate HT capabilites.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Bruno Randolf's avatar
      cfg80211: Add nl80211 antenna configuration · afe0cbf8
      Bruno Randolf authored
      Allow setting of TX and RX antennas configuration via nl80211.
      The antenna configuration is defined as a bitmap of allowed antennas to use.
      This API can be used to mask out antennas which are not attached or should not
      be used for other reasons like regulatory concerns or special setups.
      Separate bitmaps are used for RX and TX to allow configuring different antennas
      for receiving and transmitting. Each bitmap is 32 bit long, each bit
      representing one antenna, starting with antenna 1 at the first bit. If an
      antenna bit is set, this means the driver is allowed to use this antenna for RX
      or TX respectively; if the bit is not set the hardware is not allowed to use
      this antenna.
      Using bitmaps has the benefit of allowing for a flexible configuration
      interface which can support many different configurations and which can be used
      for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
      specific assumptions, drivers can use this information to know which antennas
      are actually attached to the system and derive their capabilities based on
      802.11n devices should enable or disable chains, based on which antennas are
      present (If all antennas belonging to a particular chain are disabled, the
      entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
      Antenna selection) should be calculated based on the available chains after
      applying the antenna masks. Should a 802.11n device have diversity antennas
      attached to one of their chains, diversity can be enabled or disabled based on
      the antenna information.
      Non-802.11n drivers can use the antenna masks to select RX and TX antennas and
      to enable or disable antenna diversity.
      While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
      antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
      but useful configurations as follows:
      1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
      have a low gain antenna for TX in order to keep within the regulatory
      constraints and a high gain antenna for RX in order to receive weaker signals
      ("speak softly, but listen harder"). This can be useful for building long-shot
      outdoor links. Another usage of this setup is having a low-noise pre-amplifier
      on antenna 1 and a power amplifier on the other antenna. This way transmit
      noise is mostly kept out of the low noise receive channel.
      (This would be bitmaps: tx 1 rx 2).
      2) Another similar setup is: Use RX diversity on both antennas, but always send
      on antenna 1. Again that would allow us to benefit from a higher gain RX
      antenna, while staying within the legal limits.
      (This would be: tx 0 rx 3).
      3) And finally there can be special experimental setups in research and
      development even with pre 802.11n hardware where more than 2 antennas are
      available. It's good to keep the API simple, yet flexible.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      v7:	Made bitmasks 32 bit wide and rebased to latest wireless-testing.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Arik Nemtsov's avatar
      mac80211: support hardware TX fragmentation offload · f23a4780
      Arik Nemtsov authored
      The lower driver is notified when the fragmentation threshold changes
      and upon a reconfig of the interface.
      If the driver supports hardware TX fragmentation, don't fragment
      packets in the stack.
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  14. 15 Nov, 2010 7 commits
    • Jussi Kivilinna's avatar
      cfg80211: fix WIPHY_FLAG_IBSS_RSN bit · 309075cf
      Jussi Kivilinna authored
      to BIT(8).
      Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Arnd Hannemann's avatar
      b43legacy: Fix compile on ARM architecture · 62370e2b
      Arnd Hannemann authored
      When b43legacy is compiled on the arm platform, the following errors are seen:
        CC [M]  drivers/net/wireless/b43legacy/xmit.o
      In file included from include/net/dst.h:11,
      from drivers/net/wireless/b43legacy/xmit.c:31:
      include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__'
         before '____cacheline_aligned_in_smp'
      include/net/dst_ops.h: In function 'dst_entries_get_fast':
      include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named
      include/net/dst_ops.h: In function 'dst_entries_get_slow':
      include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named
      include/net/dst_ops.h: In function 'dst_entries_add':
      include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named
      include/net/dst_ops.h: In function 'dst_entries_init':
      include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named
      include/net/dst_ops.h: In function 'dst_entries_destroy':
      include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named
      make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
      make[3]: *** [drivers/net/wireless/b43legacy] Error 2
      make[2]: *** [drivers/net/wireless] Error 2
      make[1]: *** [drivers/net] Error 2
      make: *** [drivers] Error 2
      The cause is a missing include of <linux/cache.h>, which is present for
      i386 and x86_64 architectures, but not for arm.
      Signed-off-by: default avatarArnd Hannemann <arnd@arndnet.de>
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@kernel.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Andreas Herrmann's avatar
      bitops: Provide generic sign_extend32 function · 7919a57b
      Andreas Herrmann authored
      This patch moves code out from wireless drivers where two different
      functions are defined in three code locations for the same purpose and
      provides a common function to sign extend a 32-bit value.
      Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Gery Kahn's avatar
      wl1271: ref_clock cosmetic changes · c8aea565
      Gery Kahn authored
      Cosmetic cleanup for ref_clock code while configured by board.
      Signed-off-by: default avatarGery Kahn <geryk@ti.com>
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@nokia.com>
    • Luis R. Rodriguez's avatar
      cfg80211: fix disabling channels based on hints · ca4ffe8f
      Luis R. Rodriguez authored
      After a module loads you will have loaded the world roaming regulatory
      domain or a custom regulatory domain. Further regulatory hints are
      welcomed and should be respected unless the regulatory hint is coming
      from a country IE as the IEEE spec allows for a country IE to be a subset
      of what is allowed by the local regulatory agencies.
      So disable all channels that do not fit a regulatory domain sent
      from a unless the hint is from a country IE and the country IE had
      no information about the band we are currently processing.
      This fixes a few regulatory issues, for example for drivers that depend
      on CRDA and had no 5 GHz freqencies allowed were not properly disabling
      5 GHz at all, furthermore it also allows users to restrict devices
      further as was intended.
      If you recieve a country IE upon association we will also disable the
      channels that are not allowed if the country IE had at least one
      channel on the respective band we are procesing.
      This was the original intention behind this design but it was
      completely overlooked...
      Cc: David Quan <david.quan@atheros.com>
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      cc: Easwar Krishnan <easwar.krishnan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Luis R. Rodriguez's avatar
      cfg80211: fix allowing country IEs for WIPHY_FLAG_STRICT_REGULATORY · 749b527b
      Luis R. Rodriguez authored
      We should be enabling country IE hints for WIPHY_FLAG_STRICT_REGULATORY
      even if we haven't yet recieved regulatory domain hint for the driver
      if it needed one. Without this Country IEs are not passed on to drivers
      that have set WIPHY_FLAG_STRICT_REGULATORY, today this is just all
      Atheros chipset drivers: ath5k, ath9k, ar9170, carl9170.
      This was part of the original design, however it was completely
      Cc: Easwar Krishnan <easwar.krishnan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Stephen Hemminger's avatar
      rfkill: remove dead code · 2e48928d
      Stephen Hemminger authored
      The following code is defined but never used.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>