cast the result of the ternary ops in __swapXX to the relevant types.
it appears clang and guenther@ have a different way of interpreting
the c standards around type promotion and ternary operators compared
to gcc and me.
"no you do it" guenther@
backout, because it breaks builds in dev/microcode.
Always build the parts of the tree that use a file.
Fix DRM_DEBUG builds.
Show uvm_fault and trace when typing show panic on a page fault'd kernel
Currently there is only support for amd64, if this change settles
I will add support for the rest of the architectures.
Remove unnecessary delays. There is no reason to wait after each and every
read or write to aregister. There is also no reason to wait after
transmitting a STOP since the controller will wait until the bus is free
when transmitting the next START. Based on a diff by Stephen Graf.
Also remove the interrupt code; it doesn't work on the newer variants of
the device. The functionality will be put back in a future commit.
Make arm64 use the MI mplock implementation. Avoid
pulled in for assembly files by bringing
those files is included.
Sync with the code in libc
OK millert; original commit message by tedu@:
memcpy from the right place. at this point, the used variable is not
relevant. from Mark Karpilovskij.
When we receive an AUTH or ASSOC event even though we have already
reached the RUN state, this probably means that we have roamed to
a different AP. In that case throw us back into SCAN mode and let
the stack look for a new AP to connect to. In the future it might
be worthwhile to use the ROAM event information to read the new AP
information to adjust our stack, but that is further down the road.
|message||Add support for AXP221/223.|
|message||Implement R40/V40 SATA clock.|
|message||Handle resets; needed on Allwinner R40/V40.|
Drop incoming network packets as long as we are not in RUN state. This
happens when we successfully associate and the AP tries to initiate the
WPA2 handshake but we haven't received the asynchronous ASSOC event yet.
Dropping the packet will make the AP retry, and at that point we should
have successfully associated. While there, don't feed the event packets
to our network stack. It's been helpful for debugging but now it's time
to let go.
To send out packets we need to create a flowring. Acting as station,
we typically have about four flowrings per priority. As access point
we apparently need one, or four considering the priorities, flowrings
per client. For now let's start with a single TX flowring. To setup
a flowring we need to send a create request and can only start sending
packets as soon as we are told that the ring is created. With this we
can now do actual network traffic.