Remove a bogus re-assignment.
Add a basic set of data points which count the number of sleep entries
that are being done by the OS.

For now this'll match up with the "wakeups"; although I'll dig deeper into
this to see if we can determine which sleep state the CPU managed to get
into.  Most things I've seen these days only expose up to C2 or C3 via
ACPI even though the CPU goes all the way down to C6 or C7.
Updates to i.MX53:

* Define support for the SDHCI driver, although it doesn't work yet
* Fix the memory mappings for IPU [1]

Reviewed by:	ray [1]
Don't resume a TID on each filtered frame completion - only do it if
we did suspend it.

The whole suspend/resume TID queue thing is supposed to be a matched
reference count - a subsystem (eg addba negotiation, BAR transmission,
filtered frames, etc) is supposed to call pause() once and then resume()
once.

ath_tx_tid_filt_comp_complete() is called upon the completion of any
filtered frame, regardless of whether the driver had aleady seen
a filtered frame and called pause().

So only call resume() if tid->isfiltered = 1, which indicates that
we had called pause() once.

This fixes a seemingly whacked and different problem - traffic hangs.

What was actually going on:

* There'd be some marginal link with crappy behaviour, causing filtered
  frames and BAR TXing to occur;
* A BAR TX would occur, setting the new BAW (block-ack window) to seqno n;
* .. and pause() would be called, blocking further transmission;
* A filtered frame completion would occur from the hardware, but with
  tid->isfiltered = 0 which indiciates we haven't actually marked
  the queue yet as filtered;
* ath_tx_tid_filt_comp_complete() would call resume(), continuing
  transmission;
* Some frames would be queued to the hardware, since the TID is now no
  longer paused;
* .. and if some make it out and ACked successfully, the new BAW
  may be seqno n+1 or more;
* .. then the BAR TX completes and sets the new seqno back to n.

At this point the BAW tracking would be loopy because the BAW
start was modified but the BAW ring buffer wasn't updated in lock
step.

Tested:

* Routerstation Pro + AR9220 AP
Add a comment explaining the obvious.
Correct the actual definition of ath_tx_tid_filt_comp_single() to
match how it's used.

This is another bug that led to aggregate traffic hanging because
the BAW tracking stopped being accurate.  In this instance, a filtered
frame that exceeded retries would return a non-error, which would
mean the caller would never remove it from the BAW.  But it wouldn't
be added to the filtered list, so it would be lost forever.  There'd
thus be a hole in the BAW that would never get transmitted and
this leads to a traffic hang.

Tested:

* Routerstation Pro, AR9220 AP
Don't do continue inside the scheduler loop; we really need to check
if we've hit the end of the list and cycled around to the first
node again.

Obtained from:	DragonflyBSD
Add some debugging and forcing of the BAW to match what the current
tracked BAW actually is.

The net80211 code that completes a BAR will set tid->txa_start (the
BAW start) to whatever value was called when sending the BAR.
Now, in case there's bugs in my driver code that cause the BAW
to slip along, we should make sure that the new BAW we start
at is actually what we currently have it at, not what we've sent.

This totally breaks the specification and so this stays a printf().
If it happens then I need to know and fix it.

Whilst here, add some debugging updates:

* add TID logging to places where it's useful;
* use SEQNO().
Distinguish between the different variants and configurations of Sunix
{MIO,SER}5xxxx chips instead of treating all of them as PUC_PORT_2S.
Among others, this fixes the hang seen when trying to probe the none-
existent second UART on an actually 1-port chip.

Obtained from:	NetBSD (BAR layouts)
MFC after:	3 days
Sponsored by:	Bally Wulff Games & Entertainment GmbH
Fix cursor color in reverse video mode.

PR:		kern/188196
Submitted by:	Claude Buisson <clbuisson@orange.fr> (original version)
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Update to fix at r264244.
o Unmute terminal when done with driver replacement.
o Move init fonts to early point.
o Minor cleanup.

MFC after:	6 days
X-MFC-with:	r264244 r264242
Sponsored by:	The FreeBSD Foundation
Revert r264132, disconnecting sys/boot/amd64 for now

Some 64-bit Ficl warnings broke tinderbox builds.
Correct a variable's type for 64-bit Ficl

FICL_INT is long.
Fix printf args for 64-bit archs

Sponsored by:	The FreeBSD Foundation
Add explicit casts to quiet warnings in libefi

Sponsored by:	The FreeBSD Foundation
Wakeup only one thread of added in r263978i at a time.

This slightly reduces lock congestion between threads.

Submitted by:	trasz
Fix NFS deadlock vulnerability. [SA-14:05]

Fix "Heartbleed" vulnerability and ECDSA Cache Side-channel
Attack in OpenSSL. [SA-14:06]
(Re)connect sys/boot/amd64 to the build

Sponsored by:	The FreeBSD Foundation
Add Stacey Son's binary activation patches that allow remapping of
execution to a emumation program via parsing of ELF header information.

With this kernel module and userland tool, poudriere is able to build
ports packages via the QEMU userland tools (or another emulator program)
in a different architecture chroot, e.g. TARGET=mips TARGET_ARCH=mips

I'm not connecting this to GENERIC for obvious reasons, but this should
allow the kernel module to be built by default and enable the building
of the userland tool (which automatically loads the kernel module).

Submitted by:	sson@
Reviewed by:	jhb@
Put proper ${} around variable expansion.  This fixes the build on 9.2
with fmake (which complained). Not sure why bmake didn't complain though...