For ARM, MIPS, and PowerPC, default to 32-byte alignment, but allow it
to be as small as 8.
Don't send an ABORT chunk with verification 0.

MFC after: 1 week
Per the comment, we cannot rely on bsd.own.mk
we could be on an old system that knows noting of MK_BMAKE
or on an almost up to date one that is defaulting it to "no"
neither of which will work.
Set errno to ETIMEDOUT if an SCTP association times out during
setup.

MFC after: 1 week
Fix ipfw(8) sets of ipv6 addresses handling.
Conditionally use stack buffer instead of calling strdup().

PR:		bin/104921
MFC after:	2 weeks
Fix issue with "Logitech Webcam C525":

Set a valid alternate interface setting
when enumerating USB audio devices else
the device mentioned will not work like
expected.

PR:		usb/178722
MFC after:	1 week
Fix rte leak introduced in r248070.

MFC after:	2 weeks
Don't clear stall at first time use of USB MIDI endpoints.
Most likely some non-USB compliant devices will choke on it
sooner or later. Clear stall is strictly speaking not needed.
If the first MIDI command sent or transmitted is lost, this
is not a big problem for us.

MFC after:	1 week
Use separate function to update mbuf checksum flags instead of
duplicating the same code in different places.

MFC after:	2 weeks
Label the mmc child after the parent.
Correct the spelling of "okay".
Add pinmux setting for the Reset GPIO pin for MMC1.
Var_Delete: expand name to delete if needed.
Match what is in netbsd.
Fix wildcard srcs for phony targets
Update maintainers with ath/net80211.
Re-add some code to exclude transmitting if we're in reset.

This fixes some "transmitting during reset" bugs that crept in after
I messed around with this part of the transmit path.
Use my @freebsd.org username, rather than ${WORK} username.

Pointy hat provided by:	kib, thankyou!
Have the ipropd-master listen on an IPv6 socket in addition to an IPv4
socket to allow propagation of changes to a Heimdal Kerberos database
from the KDC master to the slave(s) work on IPv6 as well.

Update the stats logging to also handle IPv6 addresses.

Reported by:		peter (found on FreeBSD cluster)
X-to-be-tested-by:	peter
MFC after:		3 weeks
Be (very) careful about how to add more TX DMA work.

The list-based DMA engine has the following behaviour:

* When the DMA engine is in the init state, you can write the first
  descriptor address to the QCU TxDP register and it will work.

* Then when it hits the end of the list (ie, it either hits a NULL
  link pointer, OR it hits a descriptor with VEOL set) the QCU
  stops, and the TxDP points to the last descriptor that was transmitted.

* Then when you want to transmit a new frame, you can then either:
  + write the head of the new list into TxDP, or
  + you write the head of the new list into the link pointer of the
    last completed descriptor (ie, where TxDP points), then kick
    TxE to restart transmission on that QCU>

* The hardware then will re-read the descriptor to pick up the link
  pointer and then jump to that.

Now, the quirks:

* If you write a TxDP when there's been no previous TxDP (ie, it's 0),
  it works.

* If you write a TxDP in any other instance, the TxDP write may actually
  fail.  Thus, when you start transmission, it will re-read the last
  transmitted descriptor to get the link pointer, NOT just start a new
  transmission.

So the correct thing to do here is:

* ALWAYS use the holding descriptor (ie, the last transmitted descriptor
  that we've kept safe) and use the link pointer in _THAT_ to transmit
  the next frame.

* NEVER write to the TxDP after you've done the initial write.

* .. also, don't do this whilst you're also resetting the NIC.

With this in mind, the following patch does basically the above.

* Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA,
  kill the TDMA special case and replace it with the above.

* Add a new TXQ flag - PUTRUNNING - which indicates that we've started
  DMA.

* Clear that flag when DMA has been shutdown.

* Ensure that we're not restarting DMA with PUTRUNNING enabled.

* Fix the link pointer logic during TXQ drain - we should always ensure
  the link pointer does point to something if there's a list of frames.
  Having it be NULL as an indication that DMA has finished or during
  a reset causes trouble.

Now, given all of this, i want to nuke axq_link from orbit.  There's now HAL
methods to get and set the link pointer of a descriptor, so what we
should do instead is to update the right link pointer.

* If there's a holding descriptor and an empty TXQ list, set the
  link pointer of said holding descriptor to the new frame.

* If there's a non-empty TXQ list, set the link pointer of the
  last descriptor in the list to the new frame.

* Nuke axq_link from orbit.

Note:

* The AR9380 doesn't need this.  FIFO TX writes are atomic.  As long as
  we don't append to a list of frames that we've already passed to the
  hardware, all of the above doesn't apply.  The holding descriptor stuff
  is still needed to ensure the hardware can re-read a completed
  descriptor to move onto the next one, but we restart DMA by pushing in
  a new FIFO entry into the TX QCU.  That doesn't require any real
  gymnastics.

Tested:

* AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
Add another obsolete file: nfs fha moved