device drivers for bus system with other endinesses than the CPU (using
interfaces compatible to NetBSD):
- bwap16() and bswap32(). These have optimized implementations on some
architectures; for those that don't, there exist generic implementations.
- macros to convert from a certain byte order to host byte order and vice
versa, using a naming scheme like le16toh(), htole16().
These are implemented using the bswap functions.
- stream bus space access functions, which do not perform a byte order
conversion (while the normal access functions would if the bus endianess
differs from the CPU endianess).
htons(), htonl(), ntohs() and ntohl() are implemented using the new
functions above for kernel usage. None of the above interfaces is currently
exported to user land.
Make use of the new functions in a few places where local implementations
of the same functionality existed.
Reviewed by: mike, bde
Tested on alpha by: mike
prism2 flag in pccard.conf, but I'm leaving it place for the moment in
case the small sample of PrismII cards that I've tried is not
representative.
MFC After: 30 days
Obtained from: NetBSD
pccard layer and rename them PCMCIA_CARD and PCMCIA_CARD2 respectively
(note, this is being done with an eye towards NetBSD integreation so
it is easier to keep lists of cards between us and them in sync).
Use this in the an and wi drivers.
trying something new with the macros here and will likely try to get
them adopted by NetBSD as well as moving them to other drivers. They
make the list more compact and easier to read, the price of rigid to a
schema for generating them (of course there are those that would argue
this isn't bad).
Obtained from: NetBSD's if_wi_pcmcia.c 1.9
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
go into the PLX 9052's interrupt control register and turn on the magic
interrupt enable bit.
Partial thanks are due to OpenBSD for pointing out that the chip is a
PLX 9052 and pointing me to the datasheet PDF.
It appears that a number of PrismII card vendors seem to be doing the
same thing (that is, using the same PCI bridge chip) to support PCI,
but each with their own vendor/product ID. So rather than cut-n-paste
another if statement into the probe routine, it's probably better to
provide support for a table. Adding new devices will be a lot easier
that way.
despite the fact that most people want to set exactly the same settings
regardless of which card they have. It has been repeatidly suggested
that this configuration should be done via ifconfig. This patch
implements the required functionality in ifconfig and add support to the
wi and an drivers. It also provides partial, untested support for the
awi driver.
PR: 25577
Submitted by: Brooks Davis <brooks@one-eyed-alien.net>
a LinkSys card here in the office where reading the station address
fails the first time, but works find afterwards. Without this, the
probe fails. I don't think this will negatively impact any existing
cards, but I want to confirm this before MFC'ing.
s/1518/ETHER_MAX_LEN
Some style changes, add some braces, mostly residual from having
a lot of debug hooks added while working on this driver.
Bring in a plethora of changes from NetBSD:
revision 1.58
date: 2001/03/08 11:07:08; author: ichiro; state: Exp; lines: +17 -1
it wait until busy flag disappears.
it was able to prevent some cards with late initializing faling in wi_reset().
revision 1.41
date: 2000/10/13 19:15:08; author: jonathan; state: Exp; lines: +4 -2
Fix wi_intr() to avoid touching card registers during insert/remove events,
when sharing an interrupt with other devices:
check sc->sc_enabled, and drop the interrupt if its' off.
revision 1.30
date: 2000/08/18 04:11:48; author: jhawk; state: Exp; lines: +4 -4
Copy wi_{dst,src}_addr from struct wi_frame into faked-up ether_header
instead of addr1 and addr2. THis means that tcpdump -e will show the
correct MAC address for communications with access points instead of showing
the BSSID.
In the future there should be 802.11 support for bpf/libpcap/tcpdump,
but that is aways down the road.
o Change the number of init tries from 5 to a #define.
o Allow up to 5s rather than 2s for commands to complete. This
is still much less than 51 minutes, but makes my intel card init
with more reliability than before.
Don't leak iospace when irq allocation fails. (call wi_free())
Call bus_release_resource() with the correct "rid" obtained from
bus_alloc_resource() that's saved in the softc instead of a hardcoded
0.
It appears that some of the new PRISM2 cards need it.
Fail the probe if we fail to read the MAC address.
Fix a comment.
Delete the unload printf. The bus system now prints this message.
a #defined constant, wrap a few long lines, etc... Also remove stupid
'all your base are belong to us' joke from comment that I don't really
care to see immortalized in the source tree.
mtx_enter(lock, type) becomes:
mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks)
mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized)
similarily, for releasing a lock, we now have:
mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN.
We change the caller interface for the two different types of locks
because the semantics are entirely different for each case, and this
makes it explicitly clear and, at the same time, it rids us of the
extra `type' argument.
The enter->lock and exit->unlock change has been made with the idea
that we're "locking data" and not "entering locked code" in mind.
Further, remove all additional "flags" previously passed to the
lock acquire/release routines with the exception of two:
MTX_QUIET and MTX_NOSWITCH
The functionality of these flags is preserved and they can be passed
to the lock/unlock routines by calling the corresponding wrappers:
mtx_{lock, unlock}_flags(lock, flag(s)) and
mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN
locks, respectively.
Re-inline some lock acq/rel code; in the sleep lock case, we only
inline the _obtain_lock()s in order to ensure that the inlined code
fits into a cache line. In the spin lock case, we inline recursion and
actually only perform a function call if we need to spin. This change
has been made with the idea that we generally tend to avoid spin locks
and that also the spin locks that we do have and are heavily used
(i.e. sched_lock) do recurse, and therefore in an effort to reduce
function call overhead for some architectures (such as alpha), we
inline recursion for this case.
Create a new malloc type for the witness code and retire from using
the M_DEV type. The new type is called M_WITNESS and is only declared
if WITNESS is enabled.
Begin cleaning up some machdep/mutex.h code - specifically updated the
"optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN
and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently
need those.
Finally, caught up to the interface changes in all sys code.
Contributors: jake, jhb, jasone (in no particular order)
All calls to mtx_init() for mutexes that recurse must now include
the MTX_RECURSE bit in the flag argument variable. This change is in
preparation for an upcoming (further) mutex API cleanup.
The witness code will call panic() if a lock is found to recurse but
the MTX_RECURSE bit was not set during the lock's initialization.
The old MTX_RECURSE "state" bit (in mtx_lock) has been renamed to
MTX_RECURSED, which is more appropriate given its meaning.
The following locks have been made "recursive," thus far:
eventhandler, Giant, callout, sched_lock, possibly some others declared
in the architecture-specific code, all of the network card driver locks
in pci/, as well as some other locks in dev/ stuff that I've found to
be recursive.
Reviewed by: jhb
<sys/proc.h> to <sys/systm.h>.
Correctly document the #includes needed in the manpage.
Add one now needed #include of <sys/systm.h>.
Remove the consequent 48 unused #includes of <sys/proc.h>.
ether_ifdetach().
The former consolidates the operations of if_attach(), ng_ether_attach(),
and bpfattach(). The latter consolidates the corresponding detach operations.
Reviewed by: julian, freebsd-net
of the individual drivers and into the common routine ether_input().
Also, remove the (incomplete) hack for matching ethernet headers
in the ip_fw code.
The good news: net result of 1016 lines removed, and this should make
bridging now work with *all* Ethernet drivers.
The bad news: it's nearly impossible to test every driver, especially
for bridging, and I was unable to get much testing help on the mailing
lists.
Reviewed by: freebsd-net
source address when receiving frames (and keep using address 2 when in
pseudo-IBSS mode). This is apparently necessary in order to obtain the
true MAC address of the sending station which is needed for PPPoE.
Patch supplied by: Blaz Zupan <blaz@amis.net>
prevent a page fault if the card is ejected while BPF is in use. This
could happen if DHCP or tcpdump was in use on that interface during
ejection. Other drivers may also require this modification.
Reviewed by: wes
Also update wicontrol to enable/disable encryption, set WEP keys and set the
TX key index. Silver cards only have 40-bit keys. This is something of a quick
hack, but it works well enough for me to commit this from the LinuxWorld
exhibit floor.
The WEP support only shows up if you have a card that supports it.
Would have been approved by: jkh, if he hadn't wandered off somewhere
Approved in his place by: msmith, who's standing right here
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
- Convert to new bus attachment scheme. Thanks to Blaz Zupan for doing
the initial work here. One thing I changed was to have the attach
and detach routines work like the PCI drivers, which means that in
theory you should be able to load and unload the driver like the PCI
NIC drivers, however the pccard support for this hasn't settled down
yet so it doesn't quite work. Once the pccard work is done, I'll have
to revisit this.
- Add device wi0 to PCCARD. If we're lucky, people should be able to
install via their WaveLAN cards now.
- Add support for signal strength caching. The wicontrol utility has
also been updated to allow zeroing and displaying the signal strength
cache.
- Add a /sys/modules/wi directory and fix a Makefile to builf if_wi.ko.
Currently this module is only built for the i386 platform, though once
the pccard stuff is done it should be able to work on the alpha too.
(Theoretically you should be able to plug one of the WaveLAN/IEEE ISA
cards into an alpha with an ISA slot, but we'll see how that turns out.
- Update LINT to use only device wi0. There is no true ISA version of
the WaveLAN/IEEE so we'll never use an ISA attachment.
- Update files.i386 so that if_wi is dependent on card.
there are stubs compiled into the kernel if BPF support is not enabled,
there aren't any problems with unresolved symbols. The modules in /modules
are compiled with BPF support enabled anyway, so the most this will do is
bloat GENERIC a little.
events, in order to pave the way for removing a number of the ad-hoc
implementations currently in use.
Retire the at_shutdown family of functions and replace them with
new event handler lists.
Rework kern_shutdown.c to take greater advantage of the use of event
handlers.
Reviewed by: green
The structure is the right length, but some of the members (notably
wi_q_info) were off a bit. This causes the received signal strength
values to appear bogus.
frames (or just insane received packet lengths generated due to errors
reading from the NIC's internal buffers). Anything too large to fit
safely into an mbuf cluster buffer is discarded and an error logged.
I have not observed this problem with my own cards, but on user has
reported it and adding the sanity test seems reasonable in any case.
Problem noted and patch provided by: Per Andersson <per@cdg.chalmers.se>
- Mention that the 6Mbps turbo adapters are supported in HARDWARE.TXT
and RELNOTES.TXT and the wi.4 man page
- Mention turbo adapters in the wicontrol.8 man page and provide a
complete table of available transmit speed settings
power management. This will only work on newer firmware revisions; older
firmware will silently ignore the attempts to turn power management on.
Patches supplied by: Brad Karp <karp@eecs.harvard.edu>
WaveLAN's radio modem. The default is whatever the NIC uses since NICs
sold in different countries may default to different frequencies. (The
Lose95/LoseNT software doesn't let you select the channel so it's probably
not really meant to be changed.)
adapter (and some workalikes). Also add man pages and a wicontrol
utility to manipulate some of the card parameters.
This driver was written using information gleaned from the Lucent HCF Light
library, though it does not use any of the HCF Light code itself, mainly
because it's contaminated by the GPL (but also because it's pretty gross).
The HCF Light lacks certain featurs from the full (but proprietary) HCF
library, including 802.11 frame encapsulation support, however it has
just enough register information about the Hermes chip to allow someone
with enough spare time and energy to implement a proper driver. (I would
have prefered getting my hands on the Hermes manual, but that's proprietary
too. For those who are wondering, the Linux driver uses the proprietary
HCF library, but it's provided in object code form only.)
Note that I do not have access to a WavePOINT access point, so I have
only been able to test ad-hoc mode. The wicontrol utility can turn on
BSS mode, but I don't know for certain that the NIC will associate with
an access point correctly. Testers are encouraged to send their results
to me so that I can find out if I screwed up or not.
network adapters. These are all PCMCIA devices (the ISA version is a
PCMCIA to ISA bridge with a PCMCIA card plugged into it). Also add a
wicontrol utility to read and write some of the card's parameters.
Note: I do not have access to a WavePOINT access point, so I have only
been able to test this driver in ad-hoc (point to point) mode. The
wicontrol utility allows programming the desired service set name (SSID)
and enabling BSS mode, but I can't tell for sure if it works (I know the
card switches modes, but I can't verify that it joins a service set
correctly).
This driver was written using information gleaned from the Lucent HCF Light
library, which is an API library designed to simplify driver development
for devices based on the Lucent Hermes chip. Unfortunately, the HCF Light
is missing certain features (like 802.11 frame encapsulation!) which are
available only in the proprietary complete HCF code, which is not available
to the public. This driver uses none of the HCF Light code: it's very ugly
and contaminated by the GPL. IP and ARP packets are encapsulated as 802.11
frames, everything else is encapsulated as 802.3.
(It would be easier to just get the Hermes programming manual, but that's
not publically available either. For those who are wondering, the Linux
WaveLAN/IEEE driver uses the proprietary HCF code, which is provided in
object code form only. So much for supporting open source sofware.)
Multicast filter support is implemented, however it appears that the
filter doesn't work: programming in one IP mutlicast group enables them
all.
