significant clean up and optimizations:
- don't call bioq_disksort() on every command, the hardware will do that for
us.
- remove all of the complicated bio deferral code. bio's that can't be
serviced immediately can just wait on the bioq.
- Only reserve one command object for doing control commands to the card.
This simplifies a lot of code and significantly reduces the size of the
command struct.
- Allocate commands out of a slab instead of embedding them into the softc.
- Call the command action method directly instead of having ips_get_free_cmd()
call it indirectly.
MFC After: 1 week
null-modem tty device emulate the speed settings faithfully.
The speed is emulated independently for the two directions, using
the slower of the local sides ispeed and the remote sides ospeed.
The emulated speed takes settings of bits/char, parity and stopbit
into account.
Inspired by: The BSD-DK Editor Celebrity Deathmatch Contest
the interface when going to toggle VLAN support for
internal reasons. If the IFCAP_VLAN_HWTAGGING bit is
cleared, we should rely on the (re)init routine to turn
VLAN support off and never touch the relevant hardware bits.
This applies to other capability bits, too. The user
obviously has a reason for clearing a capability bit,
e.g., if his particular NIC is buggy and hangs if a
certain hardware capability is turned on even for a
fraction of a second.
The flag adapter->em_insert_vlan_header still is set or
reset irrespective of the IFCAP_VLAN_HWTAGGING setting,
as before, in order to handle the case when a user sets
promiscuous mode on an interface first and later turns
its IFCAP_VLAN_HWTAGGING bit on.
This change might look orthogonal to rev#1.85, but in fact
it is not. It introduces bugfixes that hopefully will make
implementing the general scheme mentioned in the commit
message of rev#1.85 easier.
configuration: it appears to work properly in the non-promiscuous case, but
we've not yet implemented a more general solution that maintains full
functionality with promiscuous mode enabled. While my hope is that we can
get one implemented soon, this will improve functionality substantially in
the mean time.
MFC after: 3 days
AX88190 ones, but that one only minorly):
o don't set flags in the match routine. They appear to be cleared
when probe/attach is called. Before this change, they were
always treated as a simple ne2000, which would fail to get the
right NIC address.
o Lookup device again in the probe routine and probe based on the
cards that you see.
o Detect and report the DL10022 seprately from the DL10019 cards.
While I'm here:
o remove a bad printf
o change another bad printf to device_printf.
o minor style(9) formatting tweaks.
# note: a lot of OEM entries are in the ed_pccard_products such that we can
# likely remove, or collapse, many of them.
This makes all of my DL100xx cards at least probe the ethernet address
correctly, which it wasn't doing before. I can't seem to locate my
AX88xxx based cards, so those haven't been tested, but they were
busted before the change so they can't be any worse now...
address, and additional information. Then the printing of the
ethernet address was moved into ether_attach, and so we were printing
orphaned information about the card. Now the probe message is
prefixed by edX:. Prepare for it to move under bootverbose, but don't
move it there yet (the || 1 trick).
versions of the Racore PC Card Ethernet card. Rearrange to reflect
this reality. This ejects IODATA from 0x1bf, which belongs to Racore.
Thanks to Wilko for providing me with a dumpcis for the DEPCM card.
Also, added Nextcom Nexthawk card from NetBSD
o mark rx frames including FCS in the payload with the
IEEE80211_RADIOTAP_F_FCS flag
o remove hack to copy 802.11 headers with padding out of line; instead mark
the frames with IEEE80211_RADIOTAP_F_DATAPAD and require applications to
do the work
o split precalculated radiotap flags into tx+rx now that they can be different
Note the full usefulness of these changes depends on updates to applications
that process radiotap data.
o don't reclaim any previous beacon state in ath_beacon_alloc; do it
explicitly in ath_newstate
o reference count the node held in the beacon frame state block
o process ibss merge more intelligently; let the state machine do the
right thing instead of explicitly setting the new bssi id
o explicitly stop tx dma before doing beacon setup to handle the ibss
merge case
USB device support):
- Convert all of my locally chosen function names to their actual
Windows equivalents, where applicable. This is a big no-op change
since it doesn't affect functionality, but it helps avoid a bit
of confusion (it's now a lot easier to see which functions are
emulated Windows API routines and which are just locally defined).
- Turn ndis_buffer into an mdl, like it should have been. The structure
is the same, but now it belongs to the subr_ntoskrnl module.
- Implement a bunch of MDL handling macros from Windows and use them where
applicable.
- Correct the implementation of IoFreeMdl().
- Properly implement IoAllocateMdl() and MmBuildMdlForNonPagedPool().
- Add the definitions for struct irp and struct driver_object.
- Add IMPORT_FUNC() and IMPORT_FUNC_MAP() macros to make formatting
the module function tables a little cleaner. (Should also help
with AMD64 support later on.)
- Fix if_ndis.c to use KeRaiseIrql() and KeLowerIrql() instead of
the previous calls to hal_raise_irql() and hal_lower_irql() which
have been renamed.
The function renaming generated a lot of churn here, but there should
be very little operational effect.
NetBSD went this route a while ago. FreeBSD originally tried this to
cope with multifunction cards. However, it turns out that we're
better off not worrying about the function number, and instead worry
about the function type for the function. This has worked well in
NetBSD, and all FreeBSD's relevant drivers have been converted.
# I'll rework the macros that specify them shortly, as soon as I can
# come up with a good, compatible way to deal...
Use the correct number of handles for multihandle returns.
Very, very, rarely on some SMP systems we've seen an 'unstable' type
in the response queue. I dunno whether or not it's a bug in our
handling, or whether there's a cache incoherency issue, but
try to guard against it.
MFC after: 2 weeks
