Pull up following revision(s) (requested by skrll in ticket #990):
	sys/dev/usb/ehci.c: revision 1.221
In ehci_check_qh_intr don't treat a short control transfer as done if the
status phase is still inflight.  Let the hardware complete it.
PR/48358: Repeated low-speed USB control transfers returning short data
	  fail on EHCI
PR/46696: uhub disables port where USB keyboard attached
Pull up following revision(s) (requested by kefren in ticket #992):
	sys/netinet/tcp_usrreq.c: revision 1.170
Update TCP CB with new values on rfc1323 and mssdflt sysctl updates
=46rom yasuoka-cj7TXg5MjN14Eiagz67IpQ@public.gmane.org in kern/44254
Pull up following revision(s) (requested by hauke in ticket #993):
	sys/compat/linux/common/linux_misc.c: revision 1.227
On linux_sys_getdents, insert d_type at the end of each record.
Fixes PR kern/47806.
Pull up following revision(s) (requested by nakayama in ticket #994):
	sys/arch/sparc64/sparc64/locore.s: revision 1.350
Increase an interrupt depth only in the case of hardware interrupts,
and remove the ci_idepth trick in softint_fastintr.
Fixes the following diagnostic panic reported in port-sparc64.
  panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file
  "../../../../kern/subr_xcall.c", line 351
Pull up following revision(s) (requested by spz in ticket #996):
	sys/kern/uipc_syscalls.c: revision 1.163
PR/47591: Michael Plass: If the unix socket is closed before accept,
unp->unp_conn will be NULL in PRU_ACCEPT, as called from
sys_accept->so_accept. This will cause the usrreq to return with
no error, leaving the mbuf gotten from m_get() with an uninitialized
length, containing junk from a previous call. Initialize m_len to
be 0 to handle this case. This is yet another reason why Beverly's
idea of setting m_len = 0 in m_get() makes a lot of sense. Arguably
this could be an error, since the data we return now has 0 family
and length.
tickets 990, 992, 993, 994, 996