Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 6月, 2008 1 次提交
  3. 10 6月, 2008 1 次提交
  5. 22 5月, 2008 4 次提交
  7. 15 5月, 2008 2 次提交
    • B
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      由 Bruno Randolf 提交于 
      trying to clean up the signal/noise code. the previous code in mac80211 had
confusing names for the related variables, did not have much definition of
what units of signal and noise were provided and used implicit mechanisms from
the wireless extensions.

this patch introduces hardware capability flags to let the hardware specify
clearly if it can provide signal and noise level values and which units it can
provide. this also anticipates possible new units like RCPI in the future.

for signal:

  IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
  IEEE80211_HW_SIGNAL_DB     - dB difference to unspecified reference point
  IEEE80211_HW_SIGNAL_DBM    - dBm, difference to 1mW

for noise we currently only have dBm:

  IEEE80211_HW_NOISE_DBM     - dBm, difference to 1mW

if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
to provide the maximum value (max_signal) it reports in order for applications
to make sense of the signal values.

i tried my best to find out for each driver what it can provide and update it
but i'm not sure (?) for some of them and used the more conservative guess in
doubt. this can be fixed easily after this patch has been merged by changing
the hardware flags of the driver.

DRIVER          SIGNAL    MAX	NOISE   QUAL
-----------------------------------------------------------------
adm8211         unspec(?) 100   n/a     missing
at76_usb        unspec(?) (?)   unused  missing
ath5k           dBm             dBm     percent rssi
b43legacy       dBm             dBm     percent jssi(?)
b43             dBm             dBm     percent jssi(?)
iwl-3945        dBm             dBm     percent snr+more
iwl-4965        dBm             dBm     percent snr+more
p54             unspec    127   n/a     missing
rt2x00          dBm	        n/a     percent rssi+tx/rx frame success
  rt2400        dBm             n/a
  rt2500pci     dBm             n/a
  rt2500usb     dBm             n/a
  rt61pci       dBm             n/a
  rt73usb       dBm             n/a
rtl8180         unspec(?) 65    n/a     (?)
rtl8187         unspec(?) 65    (?)     noise(?)
zd1211          dB(?)     100   n/a     percent

drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      566bfe5a
    • B
      zd1211rw: initial IBSS support · 84e6dc9a
      由 Bruno Randolf 提交于 
      this adds initial IBSS support for the zydas zd1211rw:
convince driver that it can do IBSS mode. add mac80211 beacon_update callback.

IBSS merge and TSF updates don't work yet, but it makes the driver usable in
ad-hoc networks.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      84e6dc9a
  9. 07 3月, 2008 1 次提交
  11. 01 3月, 2008 2 次提交
    • M
      zd1211rw: Fix beacon filter flags thinko · 2c1a1b12
      由 Michael Buesch 提交于 
      We must not clear the FIF_BCN_PRBRESP_PROMISC bit in the
new_flags. The zd-driver does support sending beacons and
probe responses to the host. What the flag does is say "Send me
all beacons and probe responses". And we actually do that. We always
do that, so we ignore the case when the bit is disabled. But that is
fine. But we must not clear the flag, as that tells mac80211 that
we do not support passing beacons and probe responses to the stack.
And that's not true.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2c1a1b12
    • J
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      由 Johannes Berg 提交于 
      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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  13. 21 2月, 2008 1 次提交
  15. 29 1月, 2008 5 次提交
  17. 18 12月, 2007 1 次提交
    • U
      zd1211rw: Fix alignment problems · 93137943
      由 Ulrich Kunitz 提交于 
      Shaddy Baddah found an alignment problem with zd1211rw driver at
2007-11-19. This patch fixes it, it is based on the patch proposed by
Herbert Xu. The alignment 4 has been the agreed value on the
linux-wireless mailing list.

Notify that the problem does only affect the old zd1211rw softmac
driver and not the zd1211rw-mac80211 driver. Daniel Drake has
already provided a patch for the replacement of the softmac
driver, which this patch will break.
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      93137943
  19. 11 10月, 2007 4 次提交
  21. 07 8月, 2007 1 次提交
  23. 11 7月, 2007 2 次提交
    • D
      [PATCH] zd1211rw: Defer firmware load until first ifup · 74553aed
      由 Daniel Drake 提交于 
      While playing with the firmware a while back, I discovered a way to
access the device's entire address space before the firmware has been
loaded.

Previously we were loading the firmware early on (during probe) so that
we could read the MAC address from the EEPROM and register a netdevice.
Now that we can read the EEPROM without having firmware, we can defer
firmware loading until later while still reading the MAC address early
on.

This has the advantage that zd1211rw can now be built into the kernel --
previously if this was the case, zd1211rw would be loaded before the
filesystem is available and firmware loading would fail.

Firmware load and other device initialization operations now happen the
first time the interface is brought up.

Some architectural changes were needed: handling of the is_zd1211b flag
was moved into the zd_usb structure, MAC address handling was obviously
changed, and a preinit_hw stage was added (the order is now: init,
preinit_hw, init_hw).
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      74553aed
    • D
      [PATCH] zd1211rw: Allow channels 1-11 for unrecognised regulatory domains · 86d95c21
      由 Daniel Drake 提交于 
      Zen Kato's device has a regulatory domain value of 0x49, which is not an
IEEE 802.11 code and is not even identified in the vendor driver.

Recent versions of the vendor driver don't even look at the regdomain
value any more, and just allow channels 1-11 everywhere. This patch
brings us more in line with that behaviour, by allowing channels 1-11
for regdomains which we don't know about.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      86d95c21
  25. 28 4月, 2007 2 次提交
  27. 08 2月, 2007 3 次提交
  29. 20 12月, 2006 1 次提交
  31. 07 12月, 2006 1 次提交
  33. 06 12月, 2006 4 次提交
  35. 02 12月, 2006 4 次提交