Age | Commit message (Collapse) | Author |
|
ok millert@ tom@
|
|
No functional change.
The previous name was chosen at a time when I could not yet anticipate
what this function would really end up doing.
The new name should make this function's purpose more obvious, especially
where it appears at strategic places in driver code.
|
|
The heavy lifting was done by damien@ years ago. I didn't even have
to figure out what the hardware expects, the code was already there.
This driver now supports MCS 0-15 in client and hostap mode.
No Tx aggregation and no 40 MHz channels yet.
tested by vgross@, bmercer@, tb@, jmc@, Vadim Vygonets, Peter Kay
ok bmercer@ tb@ phessler@
|
|
For now this only affects RTL8188EU chips, perhaps because the author of this
patch does not own any devices containing any of the other chips (hint hint).
Patch by misha aka Mikhail / mp39590 at gmail
ok mpi@
|
|
currently re appears to end up spinning on landisk. the most obvious
cause of this would be an inability to add entries on the rx ring
when we run out of mbufs. cope with this by calling rxeof from the
isr when the FIFO_OVERFLOW status bit is set. rxeof in turn
unconditionally tries to fill the rx ring, even if it doesnt dequeue
any packets off the ring.
while here limit the number of entries that can go on the rx ring
to 1 less than the size of the ring. a full ring looks the same as
an empty ring (cos the producer and consumer are the same in both
cases), so avoid letting this happen.
ok deraadt@ who hit problems on his landisk and tested this diff
|
|
|
|
about an implicit enum conversion.
ok stsp@
|
|
ok millert@
|
|
NULL tests.
ok mpi@
|
|
the important change is to no longer account for packets and
descriptors separately, instead we just deal with available descriptors
on the ring.
this allows us to guarantee that oactive will only be set after
re_start has queued at least one packet, which in turn guarantees
that the chip will interrupt in the future and run re_txeof to clear
oactive.
without this change it was possible for a call of re_start to almost
fill the descriptor ring, followed by a second call that could fail
to post a packet because it had run out of descriptors and would
then set oactive. if re_txeof ran concurrently it could complete
all the previously posted packets without noticing that oactive had
been set and therefore needed to be cleared. in that situation
oactive would be set, but nothing would be set up to clear it
in the immediate future.
this fixes a lockup reported by haesbaert.
|
|
previously there was a limit of 64 packets on the tx ring. soon we
will use as many descriptors as we want to fill the ring.
|
|
|
|
previously you could have 64 packets on a ring with up to 1024
descriptors. this mismatch makes the accounting for free space
complicated and allows for a data race with OACTIVE being set.
it will also let us push more packets.
|
|
without this it is possible for re_txeof to let the chip look at
and complete tx descriptors that re_start has written to the ring
but not accounted for in the software producer index. in this
situation no future interrupts may be generated for packets on the
ring, and tx will stall.
the serialisation is implemented by only doing the writes from tasks
via ifq_serialize.
this is part of a bigger diff that fixes lockups reported by haesbaert.
|
|
some (broken) controllers require ordered split transfers.
From linux a310acd7a7ea53533886c11bb7edd11ffd61a036
Tested by gonzalo@, ok dlg@
|
|
Makes gonzalo@'s Macbookair7,1 NVMe report the correct version.
ok dlg@
|
|
it seems devices using levelled intx interrupts need to explicitely ack
interrupts by masking and unmasking the source around the completion
ring handling. without this completions can be lost, which in turn
causes long (permanent?) stalls in the block layer under heavy write
load.
ive experienced this problem with an intel nvme part that only has
intx and msix support. because we dont support msix yet we only
use intx on it. it appeared to lock up before this fix.
this has been tested on both that intel board and a samsung with msi.
this fix was based on work found in code by nonaka
|
|
ok kettenis
|
|
From Brad Smith.
|
|
On these chips RTS causes bad performance in hostap mode for unknown reasons.
Convert some debug printfs to DPRINTF.
Add a comment which explains why 2 free slots are needed on the Tx queue.
ok phessler@ sthen@
|
|
gets set. Therefore, ahci_port_softreset() restores the sate of the
former register once the device detection sequence is finished. The
device detection code in ahci_pmp_port_portreset() does not restore
AHCI_PREG_CMD afterwards, so let it catch up. Apparently, this part
was an oversight as ahci_pmp_port_portreset() did not otherwise use
"cmd".
From Marius Strobl
tested by awolk (amd64), bluhm (amd64, i386), myself (amd64, armv7)
ok jmatthew@
|
|
slot. Thus, extend the check whether NCQ actually should be enabled
accordingly.
From Marius Strobl
tested by awolk (amd64), bluhm (amd64, i386), myself (amd64, armv7)
ok jmatthew@
|
|
recovery from the CCB pool sized based on the NCS capability, i. e.
number of command slots reported by the controller, it is necessary
to pretend at least 2 slots in sc->sc_ncmds for devices without NCQ
support. That way, also at least 1 available slot is made available
for atascsi(4). Otherwise, controllers having only a single command
slot will trigger "no free xfers on a new port" in atascsi(4).
Note that pretending 2 command slots is also fine with the abuse of
the NCQ error recovery CCB in ahci_port_softreset().
From Marius Strobl
tested by awolk (amd64), bluhm (amd64, i386), myself (amd64, armv7)
ok jmatthew@
|
|
does not say anything about which type (snoopable/uncached etc.) of
bus transactions are issued by HBAs on accesses to the descriptors.
Thus, the right assumption would be "classical" concurrent accesses
by both CPU/driver as well as hardware to the descriptors and their
DMA memory backings respectively, which is also confirmed by actual
testing. Consequently, switch to BUS_DMA_COHERENT mappings for said
DMA memory as otherwise corruption of descriptors is seen.
From Marius Strobl
tested by awolk (amd64), bluhm (amd64, i386), myself (amd64, armv7)
ok jmatthew@
|
|
|
|
|
|
|
|
the ioff argument to pool_init() is unused and has been for many
years, so this replaces it with an ipl argument. because the ipl
will be set on init we no longer need pool_setipl.
most of these changes have been done with coccinelle using the spatch
below. cocci sucks at formatting code though, so i fixed that by hand.
the manpage and subr_pool.c bits i did myself.
ok tedu@ jmatthew@
@ipl@
expression pp;
expression ipl;
expression s, a, o, f, m, p;
@@
-pool_init(pp, s, a, o, f, m, p);
-pool_setipl(pp, ipl);
+pool_init(pp, s, a, ipl, f, m, p);
|
|
methods from all audio drivers and from the audio_if structure as they
are never called.
|
|
|
|
deleted aha.h header. therefore bha must be dragged into the attic too.
|
|
"looks correct" deraadt@ guenther@ on an earlier rev
|
|
we're only going to set it again 10 lines later.
ok mpi@
|
|
|
|
discovered by the ever alert mlarkin
|
|
|
|
ok natano@ krw@
|
|
Tested by procter@ on RT2860 and by me on RT2790 and RT3090.
Ported from FreeBSD by James Hastings.
|
|
everybody gets to test!
|
|
everybody gets to test!
|
|
value.
Specs from mikeb@, ok dlg@
|
|
This allows glue drivers to set the type based on other information (such as
Oopen Firmware or device tree properties) without going through to risky
code paths.
ok deraadt@, visa@
|
|
and 1. As a result rgephy(4) attaches twice. Prevent this from happening
by passing the PHY address, which is part of the device tree, down from the
bus-specific glue to the generic driver code.
|
|
drivers that fill that field in too.
quad types are going away.
|
|
guenther is proposing the removal of u_quad_t. uint64_t is more portable.
tested on a perc5 and perc6, no functional change.
|
|
GMAC core which is used on the Allwinner A20 SoCs and later SoCs in the
Allwinner family. Since this core is very likely to show up the base of
other devices, it gets to live here in dev/ic.
Ported from NetBSD (where it is named awge(4)) by patrick@. Some further
fixes by me.
ok deraadt@
|
|
workarounds. Some of them will soon stand in the way of armv7.
Off to the attic you go.
|
|
Repairs urtwn(4) on macppc. Problem reported by juanfra@.
ok millert@ deraadt@
|
|
from tom
|
|
in the file sys/dev/ic/rtwn.c. This reduces kernel bloat and will make it
easier to have both drivers benefit from future enhancements.
ok mpi@
|