Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 11月, 2012 2 次提交
    • J
      cfg80211: pass a channel definition struct · 683b6d3b
      由 Johannes Berg 提交于 
      Instead of passing a channel pointer and channel type
to all functions and driver methods, pass a new channel
definition struct. Right now, this struct contains just
the control channel and channel type, but for VHT this
will change.

Also, add a small inline cfg80211_get_chandef_type() so
that drivers don't need to use the _type field of the
new structure all the time, which will change.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      683b6d3b
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      由 Johannes Berg 提交于 
      As mwifiex (and mac80211 in the software case) are the
only drivers actually implementing remain-on-channel
with channel type, userspace can't be relying on it.
This is the case, as it's used only for P2P operations
right now.

Rather than adding a flag to tell userspace whether or
not it can actually rely on it, simplify all the code
by removing the ability to use different channel types.
Leave only the validation of the attribute, so that if
we extend it again later (with the needed capability
flag), it can't break userspace sending invalid data.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  3. 30 10月, 2012 1 次提交
    • J
      cfg80211: allow per interface TX power setting · c8442118
      由 Johannes Berg 提交于 
      The TX power setting is currently per wiphy (hardware
device) but with multi-channel capabilities that doesn't
make much sense any more.

Allow drivers (and mac80211) to advertise support for
per-interface TX power configuration. When the TX power
is configured for the wiphy, the wdev will be NULL and
the driver can still handle that, but when a wdev is
given the TX power can be set only for that wdev now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c8442118
  5. 18 10月, 2012 2 次提交
    • A
      wireless: drivers: make use of WLAN_EID_VENDOR_SPECIFIC · 04b2312a
      由 Arend van Spriel 提交于 
      The include file linux/ieee80211.h contains three definitions for
the same thing in enum ieee80211_eid due to historic changes:

/* Information Element IDs */
enum ieee80211_eid {
    :
    WLAN_EID_WPA = 221,
    WLAN_EID_GENERIC = 221,
    WLAN_EID_VENDOR_SPECIFIC = 221,
    :
};

The standard refers to this as "vendor specific" element so the
other two definitions are better not used. This patch changes the
wireless drivers to use one definition, ie. WLAN_EID_VENDOR_SPECIFIC.

Cc: Jouni Malinen <j@w1.fi>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> [ipw2x00]
Signed-off-by: NArend van Spriel <arend@broadcom.com>
[change libipw as well]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      04b2312a
    • J
      wireless: use OR operation to set wiphy features · b292219f
      由 Johannes Berg 提交于 
      The next patch will introduce a flag that is set
by default in cfg80211 so drivers and mac80211
need to use |= to set features they have so that
they don't clear the already-set feature.

We could set the flag in wiphy_register() instead
of wiphy_new() to avoid this patch, but then the
drivers couldn't *unset* flags they don't want to
use even though the implementation is generic.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b292219f
  7. 19 9月, 2012 1 次提交
  9. 12 7月, 2012 2 次提交
  11. 09 7月, 2012 1 次提交
    • J
      cfg80211: use wdev in mgmt-tx/ROC APIs · 71bbc994
      由 Johannes Berg 提交于 
      The management frame and remain-on-channel APIs will be
needed in the P2P device abstraction, so move them over
to the new wdev-based APIs. Userspace can still use both
the interface index and wdev identifier for them so it's
backward compatible, but for the P2P Device wdev it will
be able to use the wdev identifier only.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      71bbc994
  13. 27 6月, 2012 1 次提交
  15. 11 6月, 2012 2 次提交
  17. 06 6月, 2012 1 次提交
    • J
      cfg80211: provide channel to start_ap function · aa430da4
      由 Johannes Berg 提交于 
      Instead of setting the channel first and then
starting the AP, let cfg80211 store the channel
and provide it as one of the AP settings.

This means that now you have to set the channel
before you can start an AP interface, but since
hostapd/wpa_supplicant always do that we're OK
with this change.

Alternatively, it's now possible to give the
channel as an attribute to the start-ap nl80211
command, overriding any preset channel.

Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aa430da4
  19. 30 5月, 2012 1 次提交
    • K
      ath6kl: separate ht cap for each band · 67b3f129
      由 Kiran Reddy 提交于 
      In virtual interface structure, for each band separate ht cap
is needed. so that one can disable or enable ht capability band
wise.
This will fix the following issue:

1) Disable 11n from supplicant and start a P2P GO.
2) In beacon frames no HT-CAP IE is seen which is expected.
3) Now remove the P2P GO and kill the supplicant.
4) Beacon stops
5) Now using iw  associate to an external AP in 5 GHZ
6) In 5 GHZ no HT IE going in assoc request but
when  associated in 2.4 GHZ can see HT IES over the air
in assoc request.

In the code for del_beacon in cfg80211.c,set_ht_cap is being
called first for 2.4 GHZ and then for 5 GHZ. When  called
for the first time for 2.4 GHZ the enable flag will be set to true
and so when called for the second time for 5 GHZ it just returns
after checking the flag.

Also using this one can have different HT capabilities
per band (for example one may decide not to use 20/40 in 2.4 GHZ
but use it in 5 GHZ). So maintaining a single context is not ok.
it is true for even the enable/disable flag and other HT
capabilities as well
Signed-off-by: NKiran Reddy <c_lreddy@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      67b3f129
  21. 24 5月, 2012 1 次提交
  23. 17 5月, 2012 1 次提交
  25. 16 5月, 2012 2 次提交
    • N
      ath6kl: Include match ssid list in scheduled scan · dd45b759
      由 Naveen Singh 提交于 
      Scheduled scan implementation was only taking probed list into
consideration. The matched list was dropped. This would cause
FW not to report the AP as the list never had that AP's SSID
populated. This was causing long connection time when supplicant
would just issue a wild card SSID in probed list. As a part of
this implementation, ath6kl driver would create a complete list
by taking both probed and matched list and pass it to FW. FW would
probe for the SSID that it needs to and would match against the
relevant SSIDS that is been configured.

kvalo: whitespace changes, less indentation in the for loop, use ++
Signed-off-by: NNaveen Singh <navesing@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      dd45b759
    • T
      ath6kl: enable enhanced bmiss detection · c422d52d
      由 Thomas Pedersen 提交于 
      Enable enhanced bmiss detection if the firmware supports it. This
feature is only enabled on some firmwares since it comes with a power
cost.

Also add a few missing command ids to keep the enums straight.

kvalo: fix a compiler with ath6kl_err(), add few empty lines
Signed-off-by: NThomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c422d52d
  27. 14 5月, 2012 1 次提交
  29. 11 5月, 2012 1 次提交
  31. 27 4月, 2012 1 次提交
  33. 26 4月, 2012 2 次提交
  35. 23 4月, 2012 3 次提交
  37. 18 4月, 2012 4 次提交
  39. 16 4月, 2012 2 次提交
  41. 12 4月, 2012 3 次提交
  43. 11 4月, 2012 1 次提交
  45. 09 4月, 2012 4 次提交