IF_HANDOFF() does it for us behind the scenes. Remove the extra call
to re_start() otherwise we try to transmit twice.
In re_encap(), fix the code that guards against consuming too many
descriptors in the TX ring so that it actually works. With the
new 8169S chip, I was able to hit a corner case that drained the
free descriptor count all the way to 0. This is not supposed to
be possible.
COM_NOFIFO() and COM_ESP cases are supposed to be a subsets of the
plain 16550A case, but 16650-related changes made the former fall into
the latter and then both fall into general code for printing the tx
fifo size. This mainly caused hard to parse boot messages like:
"sio0: type 16550A fifo disabled lookalike with 1 bytes FIFO".
COM_NOFIFO() on an ESP port gave a larger mess whose extent is not
clear.
Fixed some nearby style bugs.
defined values instead of hard-coded values. Don't repeat the register
access part of the code 4 times times or triple-space statements. This
fixes half of the style bugs in rev.1.172.
Hardware flow control of 16650As is still officially unsupported. I
was mistaken about it being broken. It is broken in 16650s but is
fixed in 16650As except for the maximum trigger level (which is no
longer used). Testing of the 16650's broken hardware flow control
watermarks by programming them on 16950s showed that their effects are
not too bad if the fifo size and trigger level are reasonably large
(16 is much better than 8).
an UART interface could get stuck when a new interrupt condition
arose while servicing a previous interrupt. Since an interrupt was
already pending, no new interrupt would be triggered.
Avoid infinite recursion by flushing the Rx FIFO and marking an
overrun condition when we could not move the data from the Rx
FIFO to the receive buffer in toto. Failure to flush the Rx FIFO
would leave the Rx ready condition pending.
Note that the SAB 82532 already did this due to the nature of the
chip.
precisely where locking would be needed before adding it, but it
seems uart(4) draws slightly too much attention to have it without
locking for too long.
The lock added is a spinlock that protects access to the underlying
hardware. As a first and obvious stab at this, each method of the
hardware interface grabs the lock. Roughly speaking this serializes
the methods. Exceptions are the probe, attach and detach methods.
a problem for command responses since we rarely ever filled the queue.
However, adapter-initiated commands have a much smaller queue and could
tickle this bug. It's possible that this might fix the recently reported
problems with the aac-2120s, though I haven't been able to reproduce the
problem locally.
MFC-After: 1 day
and some of their bits (i.e., fifo trigger levels, frequency multipliers
and divisors, and bits to select the registers for these). This
attempts to completely describe the 16950's complicated register selects
for 16950-specific registers only.
the description of the data latch registers (they were described as
readonly).
Added some better and worse aliases for standard registers, mostly taken
from the 16950 data sheet. Define deprecated aliases in terms of the
preferred one.
Don't define com_efr in terms of com_fifo. It is unrelated (in a
different bank).
Merged comments to match (put them at the right of the #defines instead
of duplicating them).
Sorted the resulting sections on UART type and register bank. Added a
comment for each bank.
to ns16550.h. The organization of these files was sort of backwards.
The bits in the registers have no driver or bus dependencies but they
but the offsets of the registers in bus space are very bus-dependent.
However, it does no harm to keep the definitions of the register offsets
in ns16550.h provided they are thought of as internal ns*50 offsets.
that has been recorded earlier and overwrite it again later by
reading it directly from the EEPROM again.
Read the MAC address from the PAR0/PAR1 registers instead, which
are autoloaded on reboot.
Tested on AN985, AN983B. According to the datasheets, it should
also work for the AL981 (I don't have such a chip on a card at home)
PR: 52988
Submitted by: Andrew Gordon <arg-bsd@arg.me.uk>
MFC after: 2 weeks
calculate smoothed signal quality data for each node.
o add a 16-deep history buffer to each driver-private node storage that
holds rssi and antenna info for received frames
o override the default per-node "get rssi" method to return an average
rssi value based on samples collected over the last second
o enable beacon reception so even idle systems maintain a running history
of signal quality
This data may also be useful for improving the rate control algorithm.
Based on work by Tom Marshall <tommy@home.tig-grr.com> for MADWIFI.
to the 802.11 layer if they are at least IEEE80211_MIN_LEN
o mask off interrupt status bits that we don't care about so we don't do
the wrong thing; this fixes a problem where the beacon miss interrupt status
bit is delivered together with other status bits when operating in monitor
mode (we would post a beacon miss swi and then do the wrong thing)
was added to the fast path to support the COM_IIR_RXRDYBUG() case even
when that case is not configured. This increased the relative overhead
of sio input by almost 25% in the worst case and by 2-3% in the usual
case (usually only about 0.2% absolute per port at 115200 bps). The
quick fix is to significantly pessimize only the COM_IIR_RXRDYBUG()
case.
safe since the 802.11 layer does the right thing for 11a operation)
o select short preamble operation based on the negotiated capabilities; not
just the local state/capability
o fillin the duration field in the 802.11 header as appropriate
o remove detection of 11g support; no longer needed
Obtained from: MADWIFI (with modifications)
we're on a 32-bit/64-bit bus or not. Use this to decide if we should
set the PCI dual-address cycle enable bit in the C+ command register.
(Enabling DAC on a 32-bit bus seems to do bad things.)
Also, initialize the C+ command register early in the re_init() routine.
The documentation says this register should be configured first.
We simply use the detected FIFO size to determine whether we have
a post 16550 UART or not. The support lacks proper serialization of
hardware access for now.
