Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
o add back rx monitor support
o make WI_RID_SCAN_RES DTRT
o fix a bug handling zero-length RID requests (used by dstumbler to set
a zero-length SSID)
o make RID_SCAN_REQ DTRT
o add back WI_RID_OWN_SSID
o fix wi_scan_ap to take a channel mask and txrate (for prism cards)
These changes fix dstumbler -o (monitor mode). A minor change to dstumbler
is needed to get normal AP scanning mode to work right; this is preferred to
modifying the driver.
PR: kern/53187
Reviewed by: Bruce M Simpson <bms@spc.org>
than once. This appears to work around the hanging issues, at the
expense of warnings about bad RID allocations. I'm not sure this is a
permanant workaround, but does appear to help in the tests that I've
done here.
that one cannot generally hold a lock and call bus_teardown_intr.
This is race free with wi_intr because bus_teardown_intr won't allow
wi_intr to be called after it returns.
# jeff hsu points out that there might be a race between this unlock
# and wi_start. While that may be true also, it won't impact this commit.
Submitted by: jhb
firmware 1.50.12, but 2.20.1 and 3.10.4 work. The 1.50.12 card gets
past doing dhclient, but hangs on transmit a little after the ip
address is set. The 1.50.12 card has always been 'cranky' and Bill
Paul's tearing it apart at FreeBSD '99 hasn't helped.
sc_reset and sc_enable are subtlely different things. sc_reset means
exactly "WI_CMD_INI has happened." sc_enabled means "WI_CMD_ENABLE
has been sent to the card without a WI_CMD_DISABLE following." This
is a little different than what they mean on NetBSD (where both of
these concepts are comingled). NetBSD will try to only enable symbol
cards once, while FreeBSD only sends the WI_CMD_INI once.
Also, only try once to reset the card on a symbol.
This makes the lucent cards no worse than before, but apparently not
much better either. I got fewer hangs in my testing than I have in
the past, but I don't know if it is statistically significant or not.
network layer (ether).
- Don't abuse module names to facilitate ifconfig module loading;
such abuse isn't really needed. (And if we do need type information
associated with a module then we should make it explicit and not
use hacks.)
of the entries have a description, we'll use that to override the
description that the pccard layer generates for us.
This saves about 930 bytes in the module, so I feel it won't hurt the
crowded boot disks....
# other modules to follow
Change 27224 by imp@imp_hammer on 2003/03/22 00:16:22
Put what I think are the correct TX RATE translation tables
in place for LUCENT firmware. This is based on the 4.x driver.
Maybe it should be table driven?
ifconfig wi0 media DS/11Mbps still fails, but it fails before
we even get to the txrate stuff, so other things are wrong.
Change 27225 by imp@imp_hammer on 2003/03/22 00:45:11
Default ic_fixed_rate to -1. This is the same thing as autoselect.
There really should be a #define for this...
one tx buffer for these cards. The old driver only used one. We use
1 for symbol, and 3 for prism cards.
o Don't do the maximum loops thing in the ISR. In fact, revert to the
old interrupt handler. Lucent cards don't seem to work too well if
you don't disable/enable interrupts from the card in the ISR.
Between these two changes, Lucent cards suck less. They work in
autoselect mode only. And seem to get 1Mbps or 2Mbps only. Setting a
specific media speed doesn't work, and I've had a few issues even with
these patches. They turn a former brick into a nearly useful card.
These patches work on the prism 2 and 2.5 PC Card cards that I have.
I've not tested this on PCI cards. I suspect, but couldn't find
proof, that they were the reason that the ISR was changed so radically
from its FreeBSD roots in NetBSD. We might need to have a variant ISR
if so.
code both seem to call wi_start (directly or via the if_start pointer)
without checking to see if OACTIVE is 0. In addition, I think that
with the use of 3 transmit buffers this routine can be called with
OACTIVE set, but I might be mistaken about that (and it doesn't
matter).
Reviewed by: sam
Noticed by: imp, alfred, ambrisko
attach routine, calling WIUNLOCK in the error case of one of the ifs
for that routine is now bogus. This should have been removed when the
WILOCK() was removed, but wasn't.
Submitted by: "Harti Brandt" <brandt@fokus.fraunhofer.de>
at which tx errors are printed (default to 0); hw.wi.debug control the debug
msgs and is only present when WI_DEBUG is defined at compile time (the default
for the moment)
Requested by: imp
