Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 01 3月, 2008 2 次提交
    • L
      ath5k: Port to new bitrate/channel API · d8ee398d
      由 Luis R. Rodriguez 提交于 
      Author: Nick Kossifidis <mickflemm@gmail.com>

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found
on status descriptors, it's still buggy but we are getting
closer (i think it improved stability a little).

Changes to hw.c, initvals.c, phy.c
Changes-licensed-under: ISC

Changes to ath5k.h, base.c, base.h
Changes-licensed-under: 3-Clause-BSD
Acked-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NLuis R. Rodriguez <mcgrof@winlab.rutgers.edu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d8ee398d
    • 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
  3. 01 2月, 2008 1 次提交
  5. 29 1月, 2008 2 次提交
  7. 23 1月, 2008 1 次提交
  9. 20 12月, 2007 1 次提交
  11. 18 12月, 2007 1 次提交
  13. 10 11月, 2007 1 次提交
  15. 18 10月, 2007 1 次提交
  17. 11 10月, 2007 9 次提交
  19. 09 7月, 2007 1 次提交
  21. 12 6月, 2007 2 次提交
  23. 10 5月, 2007 1 次提交
  25. 08 5月, 2007 1 次提交
  27. 03 5月, 2007 1 次提交
  29. 28 4月, 2007 1 次提交
  31. 26 4月, 2007 2 次提交
  33. 04 10月, 2006 1 次提交
  35. 30 8月, 2006 1 次提交
  37. 28 7月, 2006 1 次提交
  39. 06 7月, 2006 1 次提交
    • D
      [PATCH] ZyDAS ZD1211 USB-WLAN driver · e85d0918
      由 Daniel Drake 提交于 
      There are 60+ USB wifi adapters available on the market based on the ZyDAS
ZD1211 chip.

Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
data operations are coordinated by the device driver. The ZD1211 chip sits
alongside an RF transceiver which is also controlled by the driver. Our driver
currently supports 2 RF types, we know of one other available in a few marketed
products which we will be supporting soon.

Our driver also supports the newer revision of ZD1211, called ZD1211B. The
initialization and RF operations are slightly different for the new revision,
but the main difference is 802.11e support. Our driver does not support the
QoS features yet, but we think we know how to use them.

This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
up to them. Additionally, the firmware is redistributable and they have
provided device specs.

This driver has been written primarily by Ulrich Kunitz and myself. Graham
Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
developers of ieee80211 and softmac have made our lives so much easier- thanks!

We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite

If there is enough time for review, we would like to aim for inclusion in
2.6.18. The driver works nicely as a STA, and can connect to both open and
encrypted networks (we are using software-based encryption for now). We will
work towards supporting more advanced features in the future (ad-hoc, master
mode, 802.11a, ...).
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e85d0918
  41. 06 6月, 2006 1 次提交
  43. 25 4月, 2006 3 次提交
    • Z
      [PATCH] wireless Kconfig add IPW2200_RADIOTAP · 34f8ae46
      由 Zhu Yi 提交于 
      Makefile both IPW2200_RADIOTAP and IPW2200_PROMISCUOUS depend on
IPW2200_MONITOR. Let IPW2200_PROMISCUOUS select IPW2200_RADIOTAP.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34f8ae46
    • Z
      [PATCH] ipw2200: rename CONFIG_IPW_QOS to CONFIG_IPW2200_QOS · e43e3c1e
      由 Zhu Yi 提交于 
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e43e3c1e
    • Z
      [PATCH] ipw2200: Enable rtap interface for RF promiscuous mode while associated · d685b8c2
      由 Zhu Yi 提交于 
      With this patch, a new promiscuous mode is enabled. If the module is loaded
with the rtap_iface=1 module parameter, two interfaces will be created
(instead of just one).

The second interface is prefixed 'rtap' and provides received 802.11 frames
on the current channel to user space in a radiotap header format.

Example usage:

        % modprobe ipw2200 rtap_iface=1
        % iwconfig eth1 essid MyNetwork
        % dhcpcd eth1
        % tcpdump -i rtap0

If you do not specify 'rtap_iface=1' then the rtap interface will
not be created and you will need to turn it on via:

        % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface

You can filter out what type of information is passed to user space via
the rtap_filter sysfs entry.  Currently you can tell the driver to
transmit just the headers (which will provide the RADIOTAP and IEEE
802.11 header but not the payload), to filter based on frame control
type (Management, Control, or Data), and whether to report transmitted
frames, received frames, or both.

The transmit frame reporting is based on a patch by Stefan Rompf.

Filters can be get and set via a sysfs interface. For example, set the
filter to only send headers (0x7), don't report Tx'd frames (0x10), and
don't report data frames (0x100):

        % echo 0x117 > /sys/bus/pci/drivers/ipw2200/*/rtap_filter

All your packets are belong to us:

        % tethereal -n -i rtap0
Signed-off-by: NJames Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d685b8c2
  45. 20 4月, 2006 1 次提交
    • J
      [PATCH] Revert NET_RADIO Kconfig title change · c1783454
      由 Jean Tourrilhes 提交于 
      	2.6.17-rc1 changed the title for the entry CONFIG_NET_RADIO. I
personally disagree with this change and want it reverted. Patch for
2.6.17-rc1.
	Rationale : WIRELESS_EXT is an invisible option. Therefore,
the only way for a user to enable it is via NET_RADIO. Some users need
to do that for out-of-tree drivers. Therefore it should be mentionned
in the title of the option.
	Rationale2 : the option just below is called "Wireless
Extension API over RtNetlink". Some users may confuse this option for
the main "Wireless Extension" option. Therefore reverting this change
help disambiguate the relation between those two options.
Signed-off-by: NJean Tourrilhes <jt@hpl.hp.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c1783454
  47. 01 4月, 2006 1 次提交
  49. 28 3月, 2006 2 次提交