This website requires JavaScript.
About
Status
₊˚⊹Discord
Explore
Register
Sign in
Reference in a new issue
Blame
Copy permalink
Reference in a new issue
Copy permalink
kernel
/
linux
Star
0
Fork
You've already forked linux
0
mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced
2026-09-26 18:16:26 +00:00
Code
Issues
Releases
Packages
Activity
af2afd247f
linux
/
net
/
wireless
/
util.c
121 lines
2.7 KiB
Raw
Normal View
History
cfg80211 API for channels/bitrates, mac80211 and driver conversion This patch creates new cfg80211 wiphy API for channel and bitrate registration and converts mac80211 and drivers to the new API. The old mac80211 API is completely ripped out. All drivers (except ath5k) are updated to the new API, in many cases I expect that optimisations can be done. Along with the regulatory code I've also ripped out the IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be unnecessary if the hardware simply gives us whatever channels it wants to support and we then enable/disable them as required, which is pretty much required for travelling. Additionally, the patch adds proper "basic" rate handling for STA mode interface, AP mode interface will have to have new API added to allow userspace to set the basic rate set, currently it'll be empty... However, the basic rate handling will need to be moved to the BSS conf stuff. I do expect there to be bugs in this, especially wrt. transmit power handling where I'm basically clueless about how it should work. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-01-24 19:38:38 +01:00
cfg80211: don't export ieee80211_get_channel This patch makes ieee80211_get_channel a static inline defined in cfg80211's header file which simply calls __ieee80211_get_channel to avoid symbol clashes with the ieee80211 code. The problem was pointed out by David Miller, thanks! Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: David Miller <davem@davemloft.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-26 14:14:55 +01:00
wireless: add wiphy channel freq to channel struct lookup helper Add ieee80211_get_channel() which gets you a channel struct for a specific wiphy if that channel is present in that wiphy. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-16 18:34:33 +01:00
cfg80211: don't export ieee80211_get_channel This patch makes ieee80211_get_channel a static inline defined in cfg80211's header file which simply calls __ieee80211_get_channel to avoid symbol clashes with the ieee80211 code. The problem was pointed out by David Miller, thanks! Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: David Miller <davem@davemloft.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-26 14:14:55 +01:00
wireless: add wiphy channel freq to channel struct lookup helper Add ieee80211_get_channel() which gets you a channel struct for a specific wiphy if that channel is present in that wiphy. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-16 18:34:33 +01:00
cfg80211 API for channels/bitrates, mac80211 and driver conversion This patch creates new cfg80211 wiphy API for channel and bitrate registration and converts mac80211 and drivers to the new API. The old mac80211 API is completely ripped out. All drivers (except ath5k) are updated to the new API, in many cases I expect that optimisations can be done. Along with the regulatory code I've also ripped out the IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be unnecessary if the hardware simply gives us whatever channels it wants to support and we then enable/disable them as required, which is pretty much required for travelling. Additionally, the patch adds proper "basic" rate handling for STA mode interface, AP mode interface will have to have new API added to allow userspace to set the basic rate set, currently it'll be empty... However, the basic rate handling will need to be moved to the BSS conf stuff. I do expect there to be bugs in this, especially wrt. transmit power handling where I'm basically clueless about how it should work. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-01-24 19:38:38 +01:00
wireless: fix ERP rate flags In the rate API patch I accidentally reverted the test for ERP rates, this fixes it. All rates except 1, 2, 5.5 and 11 MBit are ERP rates, not those. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-01-30 17:36:10 +01:00
cfg80211 API for channels/bitrates, mac80211 and driver conversion This patch creates new cfg80211 wiphy API for channel and bitrate registration and converts mac80211 and drivers to the new API. The old mac80211 API is completely ripped out. All drivers (except ath5k) are updated to the new API, in many cases I expect that optimisations can be done. Along with the regulatory code I've also ripped out the IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be unnecessary if the hardware simply gives us whatever channels it wants to support and we then enable/disable them as required, which is pretty much required for travelling. Additionally, the patch adds proper "basic" rate handling for STA mode interface, AP mode interface will have to have new API added to allow userspace to set the basic rate set, currently it'll be empty... However, the basic rate handling will need to be moved to the BSS conf stuff. I do expect there to be bugs in this, especially wrt. transmit power handling where I'm basically clueless about how it should work. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-01-24 19:38:38 +01:00
wireless: Fix WARN_ON() with ieee802.11b When the driver registers a IEEE80211_BAND_2GHZ band, it can either be 802.11b or 802.11g. But when 802.11b rates are registered "want" will be 3 (since 4 rates are being registered, and each of those 4 rates will decrease "want"). Since this is a correct situation, there is no need to trigger a WARN_ON() for this. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-02-02 23:53:10 +01:00
cfg80211 API for channels/bitrates, mac80211 and driver conversion This patch creates new cfg80211 wiphy API for channel and bitrate registration and converts mac80211 and drivers to the new API. The old mac80211 API is completely ripped out. All drivers (except ath5k) are updated to the new API, in many cases I expect that optimisations can be done. Along with the regulatory code I've also ripped out the IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be unnecessary if the hardware simply gives us whatever channels it wants to support and we then enable/disable them as required, which is pretty much required for travelling. Additionally, the patch adds proper "basic" rate handling for STA mode interface, AP mode interface will have to have new API added to allow userspace to set the basic rate set, currently it'll be empty... However, the basic rate handling will need to be moved to the BSS conf stuff. I do expect there to be bugs in this, especially wrt. transmit power handling where I'm basically clueless about how it should work. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-01-24 19:38:38 +01:00
