Linux 2.6.30 doesn't define IRQ_NONE as a macro. Assume irqreturn_t,
IRQ_NONE and IRQ_HANDLED to be present on Linux 2.6.29 and newer.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3985 0192ed92-7a03-0410-a25b-9323aeb14dbd
If $(KERNELPATH)/arch/ppc is missing, ARCH should be "powerpc", not
"ppc". CONFIG_PPC_MERGE disappeared in Linux 2.6.28.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3935 0192ed92-7a03-0410-a25b-9323aeb14dbd
Use netdev_priv() for Linux 2.4.27 and newer. Provide compatibility
wrapper for older kernels.
Imply CONFIG_KMOD for Linux 2.6.27 and newer.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3902 0192ed92-7a03-0410-a25b-9323aeb14dbd
due to unlucky timing of beacon timer configuration (which we try to avoid) and
due to unlucky timing of local TSF updates (triggered by the reception of a
beacon with the same BSSID - something we can't avoid) the beacon timers (we
have 4) can be updated seperately, leaving one of them in the past, not beeing
updated until the timers wrap around. due to the fact that the beacon interval
does not fit into the timer period (16 bit) a whole number of times the size of
the ATIM window can get bigger than desired (we don't use ATIM right now so the
window size should always be 1).
this results in a phaenome described as "ramping" (ticket #1154) which is
actually a transmission delay, since the hardware is not allowed to transmit
data in the ATIM period.
the problem is described and discussed in length at
http://thread.gmane.org/gmane.linux.drivers.madwifi.devel/6066
since we don't know of a way to disable ATIM alltogether, the following adds
some workarounds to this problem:
1.) disable interrupts in timing critical function ath_beacon_config
2.) stop beacons before reconfiguring them
3.) check ATIM window after critical code which might have changed the timers
3a.) beacon configuration
3b.) reception of a beacon with the same BSSID. the hardware will have updated
the local TSF and this might have left one of the beacon timers in the past.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3867 0192ed92-7a03-0410-a25b-9323aeb14dbd
av_beacon_alloc should be unsigned long, not unsigned int to match
signatures of bitmask manupulation functions on i386.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3856 0192ed92-7a03-0410-a25b-9323aeb14dbd
Just because GFP_KERNEL is defined, it doesn't mean that gfp_t is
available. Define gfp_t as a macro instead.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3855 0192ed92-7a03-0410-a25b-9323aeb14dbd
Add targets for both HAL binaries without $(obj), which is needed for
Linux 2.4 build system. Keep targets with $(obj) for Linux 2.6.
Use $(HALBIN) for non-unmangled HAL and $(HALOBJ) for unmangled HAL.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3836 0192ed92-7a03-0410-a25b-9323aeb14dbd
gets pulled in by Subversion as external dependency. This adds some
more lines to the output of "svn status", which caused the check for
not yet committed changes in the local working copy to fail. These
lines are now filtered out to fix this issue.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3831 0192ed92-7a03-0410-a25b-9323aeb14dbd
AR2424 and AR2425 share the same PCI ID. Probing AR2425 with HAL that
doesn't support it is problematic. It causes an unhandled NMI and puts
the device to a non-functional state. After that, even HAL that
supports AR2425 won't be able to use the device until the system is
rebooted.
Reject AR2425 devices if HAL doesn't positively indicate support for
them.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3825 0192ed92-7a03-0410-a25b-9323aeb14dbd
Conversions in place should be avoided in the build system because make
doesn't know if the conversion has taken place. Use a different name
for HAL before unmangling. Respect the build quietness settings.
Simplify Linux 2.4 rules so that the commands for decoding and
unmangling are written only once.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3815 0192ed92-7a03-0410-a25b-9323aeb14dbd
The trunk and the madwifi-dfs branch fixed jiffy rollover differently,
but the madwifi-dfs fix is closer to the original code.
Reference: madwifi-dfs@3676
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3788 0192ed92-7a03-0410-a25b-9323aeb14dbd
Instead of simply alternating antenna, send multicast frames out each antenna
based on the proportion of sucessfully transmitted unicast frames. This helps
in situations where one antenna is significantly better than another.
Signed-off-by: Perry Lorier <perry@cs.waikato.ac.nz>
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3776 0192ed92-7a03-0410-a25b-9323aeb14dbd
