Replace ctl_min() macro with MIN().

MFC after:	1 week
Cleanup the code.

Reported by:	Coverity
CID:		1232003
Add to sbappendstream_locked() a check against NULL mbuf, like it is done
in sbappend_locked() and sbappendrecord_locked().

This is a quick fix to the panic introduced by r274712.

A proper solution should be to make sosend_generic() avoid calling
pru_send() with NULL mbuf for the protocols that do not understand
control messages. Those protocols that understand control messages,
should be able to receive NULL mbuf, if control is non-NULL.
Report XML parsing errors.

MFC after:	3 days
Report initiator id in portlist XML in more formalized way.

MFC after:	3 days
Increase allowed size of the microcode blob to 32KB.  Some Intel CPU's
updates weight 28KB.

PR:	179523
MFC after:	1 week
Clean up to use the standard style of "options \t" and "device\t\t"
Clean up the style of the CUBIEBOARD2 config file
Driver for CPU frequency/voltage control on the Raspberry Pi.

Differential Revision:	https://reviews.freebsd.org/D1025
Submitted by:	Daisuke Aoyama aoyama@peach.ne.jp
Reviewed by:	ian (earlier version), rpaulo
MFC after:	1 month
Relnotes:	yes
Document where in scan_task the scan state can change, and potentially
deal/log a warning if the scan flags change during one of those race
windows.

It's highly likely that I need to actually sit down and replace this
scan infrastructure at some point.  It has some other side effects too -
the scan task is a blocking task scheduled in the net80211 taskqueue;
so drivers that use this taskqueue have other things not run.  Eek.

If you see this printf happen then please let me know!
Emulate writes to the IA32_MISC_ENABLE MSR.

PR:		196093
Reported by:	db
Tested by:	db
Discussed with:	grehan
MFC after:	1 week
Remove some hard-coded IE assembly over to use net80211 methods.

PR:		kern/196069
Submitted by:	 Andriy Voskoboinyk <s3erios@gmail.com>
Fix and harmonize the validation of PR-SCTP policies.

Reported by:	Coverity
CID:		1232044
MFC after:	3 days
Revert r274494, r274712, r275955 and provide extra comments explaining
why there could appear a zero-sized mbufs in socket buffers.

A proper fix would be to divorce record socket buffers and stream
socket buffers, and divorce pru_send that accepts normal data from
pru_send that accepts control data.
Add some more debugging to the scan cancel methods - I'd like to see
what situations would cause the scan cancel's to not complete.
Add more debugging to try and track down this scan hang nonsense.
Break out the unicast/multicast TIM bit setting into "set something
that indicates we have traffic" bit and a "do something if we have
traffic bit."

I'm going to be fleshing out this stuff more over time and it'll make
more sense to have it broken out into two pieces here.
Update ieee80211_sta_tim_notify() to do double duty - handle STA sleep
to awake transition as well as handle waking up a VAP in STA powersave
mode if it's in bgscan.

This was a reasonably hairy bug to try and figure out and it became
more obvious because of stuff I've done.

Specifically:

* a NIC would go into bgscan mode - either because of a bgscan timer
  or wpa_supplicant asked it to;
* the AP would indicate there's traffic for the STA by setting the TIM
  bitmap bit for it;
* mindwell would be met during scan, so it'd wake up and break out of
  the scan loop in scan_task(), but
* because the scan wasn't completed, it wouldn't bring the VAP out of
  STA mode powersave (so it wouldn't tell the AP about it and it would
  block VAP TX);
* .. but because we kept seeing the TIM bit set, ic->ic_lastdata was
  being constantly updated, and ..
* bgscancont() would thus never say "yes we can continue a bgscan"
  so the bgscan would hang and never make progress.

Now, I do see this particular state occur on iwn(4) - /however/ -
this NIC has the firmware call ieee80211_scan_next() once the firmware
scan for that channel has completed.  This has the effect of moving
the scan along to the next channel.  I do see the debug that I'm adding
where we see a beacon with a TIM bit set whilst we're in bgscan, so
the condition about waking up to receive traffic is triggering.
It just won't cause a hang.

For other NICs - all of the USB ones and at least ath(4) -
ieee80211_scan_next() / ieee80211_scan_done() isn't called.
So it relies upon the mindwell timer, the beacon receive and the
beacon / probe response -> ieee80211_add_scan() to move along
the scan state.

In the above case, mindwell triggered, there's no beacons triggering
the scan_add code to move things along, and we weren't waking things
up when seeing the TIM set for us.  So it just hung until the interface
was dropped.

So, the short-term fix here is to do what the comment in scan_task()
says - if we are in bgscan mode and we see our TIM bit set, just wake
up the VAP.  If it's already awake then it's a nop.  If we're awake
then we transition to awake and handle the traffic.  Once there's no
TX or RX traffic going on, ic->ic_lastdata won't be updated anymore
and bgscancont() will continue.

This was triggered more often after my initial SLEEP state handling
for software sleep states - because now I update ic->ic_lastdata
upon seeing a TIM bit set, not just the RX of the subsequent traffic.
That's needed so the thing doesn't ping-pong up and down between
seeing the TIM bit set, sending the "I'm awake" NULL data frame, and
starting to receive data from the AP.

I'd like to subsequently split ic_lastdata into two - one for TX and
one for RX - so it becomes easier to use the correct one (or both!)
when making decisions like whether to scan, go to sleep, etc.

I'd appreciate this getting some further testing.

Tested:

* rsu(4), STA mode, bgscan on
* iwn(4), STA mode, bgscan on
Where appropriate, use the modern terms for the one true time base
(UTC) rather than the archaic (GMT) in comments. Except where the
comments are making fun of people doing this (and pedants who insist
on the new terms).
Fix various mdoc issues.

Found with:	mandoc -Tlint