Linux 2.6.13 introduced Wireless Extension 18 with WPA support. It was
released in August 2005. People making changes to MadWifi should not be
required to be software archeologistists to test their changes.
Not using netdev_notifier_info_to_dev() gives no compile warnings but
crashes the kernel, so this patch is intentionally applied before Linux
3.10 procfs support is enabled to avoid a revision that compiles and
crashes on new kernels.
It's a dangerous program that should be distributed separately from
MadWifi, with its own README full of serious warnings.
ath_info is not even using MadWifi, it writes to the hardware registers
directly. ath_info is definitely not needed to use MadWifi. It could
help with the development, but so could Wireshark and many other
programs that are not part of MadWifi.
It's impossible to eliminate all warnings with all combinations of
kernels and compilers. Users are punished for using untested
combinations that should be OK. Other projects don't use -Werror and
nothing bad happens.
Future compilers would surely introduce new warnings. MadWifi doesn't
need to break because of that.
There is no way to make -Werror apply to MadWifi code but not to the
kernel headers. Linux kernel doesn't use -Werror, why should MadWifi?
Using -Werror creates a false sense of security. It's easy to assume
that the code is warning-free at least on the developers' systems.
However, broken code was committed in the past that would not compile at
all. Code quality means more that absence of warnings. It cannot be
ensured by -Werror.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4172 0192ed92-7a03-0410-a25b-9323aeb14dbd
Instead, use sc->sc_bdev to find the physical device. sc->sc_bdev is
NULL on AHB and we don't use SET_NETDEV_DEV on AHB anyway, so do it on
PCI only.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4170 0192ed92-7a03-0410-a25b-9323aeb14dbd
It's already defined in CentOS 2.6.18-238.19.1.el5 kernel. Use
parentheses around dev to be safer.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4168 0192ed92-7a03-0410-a25b-9323aeb14dbd
Don't define IEEE80211_VLAN_TAG_USED on Linux 3.1 and newer. Don't use
vlan_hwaccel_rx() if IEEE80211_VLAN_TAG_USED is not 1.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4163 0192ed92-7a03-0410-a25b-9323aeb14dbd
This is more reliable than using head and tail. It also suppresses this
scary message:
error: git-svn died of signal 13
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4148 0192ed92-7a03-0410-a25b-9323aeb14dbd
Change IEEE80211_NODE_SAVEQ_DEQUEUE to a compound statement returning a
value, which may or may not be ignored by the caller.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4137 0192ed92-7a03-0410-a25b-9323aeb14dbd
Use CONFIG_LOCALVERSION as an alternative to check that the
configuration settings have been included.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4134 0192ed92-7a03-0410-a25b-9323aeb14dbd
Write packet numbers in hex notation. This way, it's easier to spot
them in the encrypted packets.
Also, use the ULL suffix, not LL for packet numbers, which are unsigned
48-bit integers. It shouldn't matter, but it's more descriptive.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4127 0192ed92-7a03-0410-a25b-9323aeb14dbd
Only call ath_hal_verify_default_intmit() if interference mitigation is
supported by the chipset.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4124 0192ed92-7a03-0410-a25b-9323aeb14dbd
Allocate all memory at once to simplify error handling. Allocate a
network device and use it both for the master and the VAP. Set a
descriptive name on the network device, as it's used in error and debug
messages.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4122 0192ed92-7a03-0410-a25b-9323aeb14dbd
The kernel AES will only be requested if hardware encryption is not
available and if AES is really needed. At that point, a failure to
allocate the AES cipher would be a real problem, not a minor debug
condition.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4121 0192ed92-7a03-0410-a25b-9323aeb14dbd
Pavel Roskin