Age | Commit message (Collapse) | Author |
|
ok jmatthew@
|
|
sc_link.openings is greater than 34.
Encountered by Sigi Rudzio on his Blade 2500, who kindly did some
testing to discover that the answer is 34, not 42.
Nuke some whitespace on the way by.
|
|
Original work by Neil Ashford and dlg@
ok kettenis@
|
|
When this error occurs, it tends to occur multiple times in a row. Affected
frames are lost and never get transmitted, and traffic stalls for a while.
I don't understand what is causing this. I have found that it only occurs if
we ask the firmware to use its multi-rate retry table. If we send frames at
a fixed rate, it does not happen. So this can be used as a workaround until
the real problem is understood.
Since this error is particularly problematic with block ack, use a fixed Tx
rate for aggregation queues for now. All subframes contained in an aggregate
are always sent together at the same rate anyway.
ok mpi@
|
|
ok jmatthew@ mpi@
|
|
ok patrick@
|
|
high 8 bits of the value we extract, in case the firmware leaves junk there.
Hrvoje Popovski has seen this with newer firmware on a ConnectX 5 card,
which now works properly.
ok dlg@
|
|
|
|
|
|
|
|
From Greg Jones <gjones5555 (at) netscape (dot) net>
|
|
with a mainline Linux device tree.
|
|
unlikely circumstances - lots of single-fragment packets being sent, a
significant number of packets being received, while the interrupt handler
was unable to process the completion queue - the completion queue could
overflow, which would result in the interface locking up.
ok dlg@
|
|
the end of it, rather than after. Now we can actually allocate queues
big enough to need multiple mailboxes.
ok dlg@
|
|
development that I forgot about, but turns out to be a potential race with
the actual interrupt handler.
ok dlg@
|
|
Not used yet but may become useful later.
|
|
ok jmc@ deraadt@ kettenis@
"thanks and don't wait for me" patrick@
|
|
|
|
only supports 32-bit access (hello Raspberry Pi).
ok tobhe@
|
|
give us uSD card or WiFi support (but not both) depending on the firmware
configuration.
ok tobhe@
|
|
only supports 32-bit access (hello Raspberry Pi).
ok tobhe@
|
|
the Raspberry Pi 4.
ok deraadt@
|
|
into wsdisplay(4). This code is now exposed through
wsdisplay_brightness_{step,zero,cycle} functions that can be called by
any driver that handles brightnes "hotkeys". These functions take
a wsdisplay(4) device pointer as their first argument, which should be
provided if a clear association between events and a particular display
exist. This is used in wskbd(4). Otherwise NULL can be passed and
the code will direct the request at the first wsdisplay(4) that
implements brightness adjustment.
Tested by many. Fixes brightness keys on x395 and other thinkpads with
AMD graphics.
ok patrick@
|
|
Original work by Neil Ashford and dlg@
Feedback from jsg@
ok kettenis@, dlg@
|
|
Original work by Neil Ashford and dlg@
Feedback from jsg@
ok kettenis@, dlg@
|
|
In its current state the driver relies on the firmware for initializing
the controller. Therefore it only really works when using the EDK2-based
UEFI firmware.
ok jsg@
|
|
from Hemno Sapients <calomalus at airmail.cc>, thanks
|
|
ok deraadt
|
|
|
|
ok jsg@
|
|
From Lyude Paul
a0522bbd37d80507d118d3616e46bccde2c395a9 in linux 4.19.y/4.19.116
8732fe46b20c951493bfc4dba0ad08efdf41de81 in mainline linux
|
|
From Sasha Levin
9a61fe235c0a653457c741d6140c6a8f8d8bfb48 in linux 4.19.y/4.19.116
a86675968e2300fb567994459da3dbc4cd1b322a in mainline linux
|
|
Patch from and commited on behalf of Jonathan Gray (jsg@)
ok kettenis@
|
|
ok patrick@
|
|
From Hans Verkuil
329ef07f7fb83d4de62c239e376a6a0e04ff4b3c in linux 4.19.y/4.19.115
a4c30a4861c54af78c4eb8b7855524c1a96d9f80 in mainline linux
|
|
From James Zhu
7b9d4492808eb3c3ba43f6391b138101a7e9e42e in linux 4.19.y/4.19.115
acfc62dc68770aa665cc606891f6df7d6d1e52c0 in mainline linux
|
|
From Mario Kleiner
a9049fd69bc4fdcc48ec3a638f1f470938354984 in linux 4.19.y/4.19.115
dec9de2ada523b344eb2428abfedf9d6cd0a0029 in mainline linux
|
|
|
|
Use a monotonic clock for timestamping LUNs to avoid problems when the
UTC clock jumps.
ok krw@
|
|
the Raspberry Pi4.
ok patrick@
|
|
ok patrick@
|
|
ok patrick@
|
|
|
|
ok patrick@
|
|
ok patrick@
|
|
Spotted with clang -Wno-error=uninitialized. ok jsg@
|
|
Harmless since free(9) first checks that the pointer is not NULL.
ok krw@
|
|
every CCMP encrypted frame is discarded by the AP as a replay.
This happened because of CCMP frames with out of range PNs sent by hardware.
It seems iwn firmware doesn't like it if we reset the Tx scheduler slot for
a frame which is still within the firmware's block ack window, even if the
frame has already been ACKed. So frames now get cleared off the Tx queue
only when the block ack window has moved past them, which is good enough and
seems to prevent the problem.
Problem reproduced and fix tested by both myself and jca@
|
|
They're macros on Linux because they save state in their flags
parameter. Turning them to static inline functions creates a lot
of -Wuninitialized warnings, so just use macros which set their flags
argument.
ok kettenis@
|
|
cache-coherent or not. To implement this, acpi(4) gets two bus_dma tags
and passes the appropriate one when attaching devices based on _CCA.
On i386/amd64, where for all practical purpose DMA is always cache-coherent,
the two tags are the same. But on arm64 they are distinct.
ok patrick@
|