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
init_MUTEX() is missing on kernels with realtime patches. Besides,
init_MUTEX is a confusing name, since it initializes a semaphore,
whereas newer kernels have real mutexes as well.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4118 0192ed92-7a03-0410-a25b-9323aeb14dbd
The warning is
ld: warning: cannot find entry symbol stext; defaulting to 0000000000000000
LDFLAGS may have been a better choice when HAL was binary, but now
LDOPTS is the right thing for consistency with the makefiles in other
directories.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4104 0192ed92-7a03-0410-a25b-9323aeb14dbd
The contention window is supposed to be a power of two minus one, i.e.
15, 31, 63, 127... Due to a wrong formula, the actual sequence was 15,
32, 66, 134...
Bug reported by Dan Halperin <dhalperi@cs.washington.edu>
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4097 0192ed92-7a03-0410-a25b-9323aeb14dbd
Make srate signed, or checks for it being less than 0 don't work.
Consistently use IEEE80211_FIXED_RATE_NONE. Fix misleading comments.
Survive the case when the fixed rate is not in the rate table. It can
happen e.g. a CCK rate is used with an 802.11a channel, or in the STA
mode when an OFDM rate is used with 802.11b. The driver should catch
it, but it doesn't. In any case, it's not a reason for an oops.
Remove the debugging message if everything is fine. In case of an
error, specify the VAP name.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4095 0192ed92-7a03-0410-a25b-9323aeb14dbd
