summaryrefslogtreecommitdiffstats
path: root/sys/dev/if_ndis
Commit message (Collapse)AuthorAgeFilesLines
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-064-4/+4
|
* record the bssid for an associationsam2004-12-121-0/+1
| | | | Tested by: Daniel O'Connor
* Fix compilation and correct mapping from struct ifnet tosam2004-12-101-7/+9
| | | | | | struct ieee80211com after net80211 import. Submitted by: Tor Egge
* Update for net80211 changes.sam2004-12-082-17/+17
|
* Drop the NDIS lock before returning from ndis_start().le2004-10-181-1/+3
| | | | | | PR: i386/72795 Submitted by: Frank Mayhar <frank@exit.com> MFC in: 3 days
* Fix sis, bfe and ndis in the same way dc was fixed:mlaier2004-10-081-0/+3
| | | | | | | Do not tell the hardware to send when there were no packets enqueued. Found and reviewed by: green MFC after: 1 days
* Make the Texas Instruments 802.11g chipset work with the NDISulator.wpaul2004-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was tested with a Netgear WG311v2 802.11b/g PCI card. Things that were fixed: - This chip has two memory mapped regions, one at PCIR_BAR(0) and the other at PCIR_BAR(1). This is a little different from the other chips I've seen with two PCI shared memory regions, since they tend to have the second BAR ad PCIR_BAR(2). if_ndis_pci.c tests explicitly for PCIR_BAR(2). This has been changed to simply fill in ndis_res_mem first and ndis_res_altmem second, if a second shared memory range exists. Given that NDIS drivers seem to scan for BARs in ascending order, I think this should be ok. - Fixed the code that tries to process firmware images that have been loaded as .ko files. To save a step, I was setting up the address mapping in ndis_open_file(), but ndis_map_file() flags pre-existing mappings as an error (to avoid duplicate mappings). Changed this so that the mapping is now donw in ndis_map_file() as expected. - Made the typedef for 'driver_entry' explicitly include __stdcall to silence gcc warning in ndis_load_driver(). NOTE: the Texas Instruments ACX111 driver needs firmware. With my card, there were 3 .bin files shipped with the driver. You must either put these files in /compat/ndis or convert them with ndiscvt -f and kldload them so the driver can use them. Without the firmware image, the NIC won't work.
* Minor cleanups:wpaul2004-08-031-2/+8
| | | | | | - Fix typo in comment - Remember to free() sc->ndis_txarray on detach - Remember to do an ifmedia_removeall() for ethernet devices
* Second part of ALTQ driver modifications, covering:mlaier2004-08-011-0/+19
| | | | | | | | | | an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
* The watchdog callout executes with the (non-sleepable) ifnet lock heldwpaul2004-08-011-1/+1
| | | | | | | now, but it's possible for ndis_reset_nic() to sleep (sometimes the MiniportReset() method returns NDIS_STATUS_PENDING and we have to wait for completion). To get around this, execute the ndis_reset_nic() routine in the NDIS_TASKQUEUE thread.
* Add some minor changes related to PCMCIA attribute memory mappingwpaul2004-08-011-2/+18
| | | | | | (which I apparently forgot to commit earlier). Acquire NDIS_LOCK() in ndis_linksts_done().
* Make NdisReadPcmciaAttributeMemory() and NdisWritePcmciaAttributeMemory()wpaul2004-07-113-22/+75
| | | | | | | | | | | | | | | | | | | | | | | actually work. Make the PCI and PCCARD attachments provide a bus_get_resource_list() method so that resource listing for PCCARD works. PCCARD does not have a bus_get_resource_list() method (yet), so I faked up the resource list management in if_ndis_pccard.c, and added bus_get_resource_list() methods to both if_ndis_pccard.c and if_ndis_pci.c. The one in the PCI attechment just hands off to the PCI bus code. The difference is transparent to the NDIS resource handler code. Fixed ndis_open_file() so that opening files which live on NFS filesystems work: pass an actual ucred structure to VOP_GETATTR() (NFS explodes if the ucred structure is NOCRED). Make NdisMMapIoSpace() handle mapping of PCMCIA attribute memory resources correctly. Turn subr_ndis.c:my_strcasecmp() into ndis_strcasecmp() and export it so that if_ndis_pccard.c can use it, and junk the other copy of my_strcasecmp() from if_ndis_pccard.c.
* Fix two problems:wpaul2004-07-072-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
* Take advantage of the dev sysctl tree.des2004-06-042-0/+8
| | | | Approved by: wpaul
* Unbreak the Intel 2100 Centrino wireless driver (and probably others):wpaul2004-06-041-7/+12
| | | | | | | | | | | | | | | | | | | | | - In subr_ndis.c, my_strcasecmp() actually behaved like my_strncasecmp(): we really need it to behave like the former, not the latter. (It was falsely matching "RadioEnable", which defaults to 1 with "RadioEnableHW" which the driver creates itself and to 0, because we were using strlen("RadioEnable") as the length to test. This caused the radio to always be turned off. :( ) - In if_ndis.c, only set IEEE80211_CHAN_A for channels if we actually set any IEEE80211_MODE_11A rates. (ieee80211_attach() will "helpfully" add IEEE80211_MODE_11A to ic_modecaps for you if you initialize any 802.11a channels. This caused "ndis0: 11a rates:" to erroneously be displayed during driver load.) - Also in if_ndis.c, when using TESTSETRATE() to add in any missing 802.11b rates, remember to OR the rates with IEEE80211_RATE_BASIC, otherwise comparing against existing basic rates won't match. (1, 2, 5.5 and 11Mbps are basic rates, according to the 802.11b spec.) This erroneously cause 11Mbps to be added to the 11b rate list twice.
* Explicitly #include <sys/module.h> in these files too (they usewpaul2004-06-012-0/+2
| | | | MODULE_DEPEND()).
* In subr_ndis.c, when searching for keys in our make-pretend registry,wpaul2004-05-291-3/+50
| | | | | | | | | | | | | | | | | | | | | make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
* Restore source code compatibility with 5.2-RELEASE.wpaul2004-05-121-0/+4
|
* Link state change notification of ethernet media to the routing socket.andre2004-05-061-0/+5
| | | | | | | o The ndis_ticktask() function updates the ifi_link_state field and calls rt_ifmsg() to notify listeners on the routing socket. Approved by: wpaul
* Small timer cleanups:wpaul2004-04-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | - Use the dh_inserted member of the dispatch header in the Windows timer structure to indicate that the timer has been "inserted into the timer queue" (i.e. armed via timeout()). Use this as the value to return to the caller in KeCancelTimer(). Previously, I was using callout_pending(), but you can't use that with timeout()/untimeout() without creating a potential race condition. - Make ntoskrnl_init_timer() just a wrapper around ntoskrnl_init_timer_ex() (reduces some code duplication). - Drop Giant when entering if_ndis.c:ndis_tick() and subr_ntorkrnl.c:ntoskrnl_timercall(). At the moment, I'm forced to use system callwheel via timeout()/untimeout() to handle timers rather than the callout API (struct callout is too big to fit inside the Windows struct KTIMER, so I'm kind of hosed). Unfortunately, all the callouts in the callwhere are not marked as MPSAFE, so when one of them fires, it implicitly acquires Giant before invoking the callback routine (and releases it when it returns). I don't need to hold Giant, but there's no way to stop the callout code from acquiring it as long as I'm using timeout()/untimeout(), so for now we cheat by just dropping Giant right away (and re-acquiring it right before the routine returns so keep the callout code happy). At some point, I will need to solve this better, but for now this should be a suitable workaround.
* Remove code that fiddles with Giant in ndis_ticktask() that snuck inwpaul2004-04-281-4/+0
| | | | during previous commit.
* Correct KASSERT()s that check for initialization of mutexes in ndis_detach(),wpaul2004-04-231-2/+6
| | | | | | which are different now that I'm not using mutex pools anymore. Noticed by: des
* Set the INTR_MPSAFE flag.wpaul2004-04-221-1/+1
|
* Ok, _really_ fix the Intel 2100B Centrino deadlock problems this time.wpaul2004-04-221-29/+3
| | | | | | | | | | | | | | | | (I hope.) My original instinct to make ndis_return_packet() asynchronous was correct. Making ndis_rxeof() submit packets to the stack asynchronously fixes one recursive spinlock acquisition, but it's also possible for it to happen via the ndis_txeof() path too. So: - In if_ndis.c, revert ndis_rxeof() to its old behavior (and don't bother putting ndis_rxeof_serial() back since we don't need it anymore). - In kern_ndis.c, make ndis_return_packet() submit the call to the MiniportReturnPacket() function to the "ndis swi" thread so that it always happens in another context no matter who calls it.
* Fix the problems people have been having with the Intel 2100B Centrinowpaul2004-04-211-107/+19
| | | | | | | | | | | | | | | | | | | | | wireless ever since I added the new spinlock code. Previously, I added a special ndis_rxeof_serial() function to insure that when we receive a packet, we never end up calling the MiniportReturnPacket() routine until after the receive handler has finished. I set things up so that ndis_rxeof_serial() would only be used for serialized miniports since they depend on this property. Well, it turns out deserialized miniports depend on a similar property: you can't let MiniportReturnPacket() be called from the same context as the receive handler at all. The 2100B driver happens to use a single spinlock for all of its synchronization, and it tries to acquire it both while in MiniportHandleInterrupt() and in MiniportReturnPacket(), so if we call MiniportReturnPacket() from the MiniportHandleInterrupt() context, we will end up trying to acquire the spinlock recursively, which you can't do. To fix this, I made the ndis_rxeof_serial() handler the default. An alternate solution would be to make ndis_return_packet() submit the call to MiniportReturnPacket() to the NDIS task queue thread. I may do that in the future, after I've tested things a bit more.
* Continue my efforts to imitate Windows as closely as possible bywpaul2004-04-142-50/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
* - The MiniportReset() function can return NDIS_STATUS_PENDING, in whichwpaul2004-04-051-36/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
* Add missing cprd_flags member to partial resource structure inwpaul2004-03-291-0/+2
| | | | | | | | | | | | | resource_var.h. In kern_ndis.c:ndis_convert_res(), fill in the cprd_flags and cprd_sharedisp fields as best we can. In if_ndis.c:ndis_setmulti(), don't bother updating the multicast filter if our multicast address list is empty. Add some missing updates to ndis_var.h and ntoskrnl_var.h that I forgot to check in when I added the KeDpc stuff.
* The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() iswpaul2004-03-241-5/+11
| | | | | | | | | | variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
* Recently I realized that the ADMtek 8211 driver wasn't working correctlywpaul2004-03-231-3/+4
| | | | | | | | | | (NIC would claim to establish a link with an ad-hoc net but it couldn't send/receive packets). It turns out that every time the checkforhang handler was called by ndis_ticktask(), the driver would generate a new media connect event. The NDIS spec says the checkforhang handler is called "approximately every 2 seconds" but using exactly 2 seconds seems too fast. Using 3 seconds makes it happy again, so we'll go with that for now.
* Make if_ndis_pci.c and if_ndis_pccard.c use bus_alloc_resource() againwpaul2004-03-212-12/+12
| | | | | | | | instead of bus_alloc_resource_any() to restore source compatibility with 5.2-REL and 5.2.1-REL systems. bus_alloc_resource_any() doesn't really do anything besides hide some of bus_alloc_resource()'s arguments from us, and in my opinion this isn't worth breaking backwards compatibility for people who want to use the NDISulator code on 5.2.x.
* Fix another Intel 2200BG bug: don't schedule ndis_ticktask() on mediawpaul2004-03-211-1/+2
| | | | disconnect events if the link wasn't even up yet.
* - Rewrite the timer and event API routines in subr_ndis.c so that theywpaul2004-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are actually layered on top of the KeTimer API in subr_ntoskrnl.c, just as it is in Windows. This reduces code duplication and more closely imitates the way things are done in Windows. - Modify ndis_encode_parm() to deal with the case where we have a registry key expressed as a hex value ("0x1") which is being read via NdisReadConfiguration() as an int. Previously, we tried to decode things like "0x1" with strtol() using a base of 10, which would always yield 0. This is what was causing problems with the Intel 2200BG Centrino 802.11g driver: the .inf file that comes with it has a key called RadioEnable with a value of 0x1. We incorrectly decoded this value to '0' when it was queried, hence the driver thought we wanted the radio turned off. - In if_ndis.c, most drivers don't accept NDIS_80211_AUTHMODE_AUTO, but NDIS_80211_AUTHMODE_SHARED may not be right in some cases, so for now always use NDIS_80211_AUTHMODE_OPEN. NOTE: There is still one problem with the Intel 2200BG driver: it happens that the kernel stack in Windows is larger than the kernel stack in FreeBSD. The 2200BG driver sometimes eats up more than 2 pages of stack space, which can lead to a double fault panic. For the moment, I got things to work by adding the following to my kernel config file: options KSTACK_PAGES=8 I'm pretty sure 8 is too big; I just picked this value out of a hat as a test, and it happened to work, so I left it. 4 pages might be enough. Unfortunately, I don't think you can dynamically give a thread a larger stack, so I'm not sure how to handle this short of putting a note in the man page about it and dealing with the flood of mail from people who never read man pages.
* Don't announce MAC addresses twice.mdodd2004-03-201-6/+0
| | | | (ieee80211_ifattach() calls ether_ifattach().)
* Convert callers to the new bus_alloc_resource_any(9) API.njl2004-03-172-12/+12
| | | | | Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
* Don't set ifp->if_output to ether_output(), since ether_ifattach()mux2004-03-121-1/+0
| | | | | | | will do it for us (we either call ether_ifattach() directly, or it gets called within ieee80211_ifattach()). Approved by: wpaul
* Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer driverswpaul2004-03-111-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster.
* Trim unneeded includes from if_ndis_pccard.c and if_ndis_pci.c. Also removedwpaul2004-03-092-26/+0
| | | | unused variables from if_ndis_pccard.c
* If the resource listing obtained from BUS_GET_RESOURCE_LIST() inwpaul2004-03-091-0/+20
| | | | | | | | ndis_probe_pci() doesn't contain an entry for an IRQ resource, try to force one to be routed to us anyway by adding an extra call to bus_alloc_resource(). If this fails, then we have to abort the attach. Patch provided by jhb, tweaked by me.
* Add preliminary support for PCMCIA devices in addition to PCI/cardbus.wpaul2004-03-074-222/+648
| | | | | | | | | | | | if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
* Add yet more bulletproofing. This is to guard against the case thatwpaul2004-02-111-2/+3
| | | | | ndis_init_nic() works one during attach, but fails later. Many things will blow up if ndis_init_nic() fails and we aren't careful.
* Don't hold NDIS_LOCK() around call to ndis_getstate_80211() since itwpaul2004-02-071-0/+2
| | | | may block on ndis_get_info().
* Implement support for single packet sends. The Intel Centrino driverwpaul2004-02-031-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
* Use the OID_802_11_CONFIGURATION OID when deciding if the underlying driverwpaul2004-02-011-2/+4
| | | | | | | | | | | | | | | is for an 802.11 device or not. At least one driver I have does not support the OID_802_11_NETWORK_TYPES_SUPPORTED OID. Also, for now, don't do anything special in the ndis_suspend() method. I originally wanted to shut down the NIC but leave the IFF_UP flag alone since technically the interface is meant to remain up, but an interrupt may be delivered to the ISR on suspend, and if this happens while the NIC is halted, we will crash, since none of the miniport driver methods will function. This needs to be dealt with properly later, but for now this prevents a panic, and the resume method properly re-inits the NIC.
* Go back to using AUTHMODE_AUTO if WEP is on. In some cases, the Centrinowpaul2004-01-291-1/+3
| | | | | | won't associate in BSS mode if you use AUTHMODE_SHARED. I probably don't understand enough to know when SHARED should be used vs. OPEN or WPA. For now, go back to what works.
* This should have been checked in as part of the last update to if_ndis.c:wpaul2004-01-271-0/+1
| | | | | add yet another member to the ndis_softc as part of the workaround for the net80211 dain bramage.
* Add a kludge to avoid having ndis_init() called needlessly by dhclientwpaul2004-01-271-10/+22
| | | | | | | | on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
* Use the M_BZERO flag with malloc() in a couple of places.wpaul2004-01-271-8/+6
|
* Correct KASSERT() in ndis_destroy(): ndis_mtx is a pointer now.wpaul2004-01-251-1/+4
| | | | Also add KASSERT() for ndis_intrmtx().
* Add missing newlines to some device_printf()s.wpaul2004-01-241-3/+6
| | | | | Don't do anything in ndis_get_assoc() if the link isn't up (avoids spurrious "couldn't get bssid" messages on the console).
OpenPOWER on IntegriCloud