MFC r227091-227095,227098-227099:

MFC r227091-227095,227098-227099:
r227091:
  Make sure to unload loaded DMA area(descriptor, command, event ring).

r227092:
  Announce IFCAP_LINKSTATE capability and let network stack know link
  state changes.  Hide superfluous link up/down message under
  bootverbose since if_link_state_change(9) shows that information.
  While I'm here, change baudrate with the resolved speed of the
  established link instead of blindly setting it 1G. Unfortunately,
  it seems there is no way to differentiate 10/100Mbps from
  non-gigabit link so just assume we established a 100Mbps link if
  current link is not a gigabit link.

r227093:
  Introduce ti_ifmedia_upd_locked() to use in driver initialization
  and add missing driver lock for both ti_ifmedia_upd() and
  ti_ifmedia_sts().

r227094:
  Don't clear upper 4bits from VLAN tag information.  It's
  responsibility of vlan(4) to extract VLAN id from the tag
  information and vlan(4) correctly handles it.

r227095:
  Don't abuse if_hwassist and make sure enabling corresponding TX/RX
  checksum offloading and VLAN hardware tag insertion/stripping from
  the currently enabled hardware offloading capabilities.
  Previously if_hwassist, which was initialized to TX/RX checksum
  offloading, was blindly used to enable both TX and RX checksum
  offloading such that disabling either TX or RX checksum offloading
  was not possible.

  ti(4) controllers support TX/RX checksum offloading with VLAN
  tagging so announce TX/RX checksum offloading capability over VLAN
  to vlan(4).

  Make VLAN hardware tag insertion/stripping honors currently enabled
  interface capability instead of blindly enabling VLAN hardware
  tagging. This change allows disabling hardware support of VLAN tag.

  Because ti(4) supports VLAN oversized frames, make network stack
  know the capability by setting if_hdrlen.

  While I'm here, rewrite SIOCSIFCAP handler and make sure to
  reinitialize controller whenever TX/RX checksum offloading and VLAN
  hardware tagging option is changed.  The requirement of controller
  reinitialization comes from the limitation of Tigon I/II firmware.
  Tigon I/II firmware requires all related RCBs should be
  reinitialized whenever any of its hardware offloading capabilities
  change.

  vlan(4) is also notified whenever the parent interface's capability
  changes such that it can correctly handle TX/RX checksum offloading
  based on parent interface's enabled offloading capabilities.

  RX checksum offloading handler was changed to make upper stack use
  controller computed partial checksum value.  Previously, ti(4) just
  set the computed value for any frames(IPv4, IPv6) and the value was
  not used in upper stack because driver didn't set CSUM_DATA_VALID
  such that upper network stack had to recompute checksum of TCP/UDP
  packets. I have no idea how this was not noticed for a long time.
  With this change, upper network stack does not have to fully
  recompute the checksum such that calculating pseudo checksum based
  on partial checksum is sufficient to know whether received packet's
  checksum is correct or not. However, I don't know why ti(4) does
  not have controller compute pseudo checksum as controller has
  ability to do it. I'm just guessing enabling that feature could
  trigger a firmware bug or could be slower than computing it on host
  side so just leave it as it was.

  In order not to produce false positives, ti(4) now checks whether
  controller actually computed IP or TCP/UDP checksum by checking
  ti_flags field.

r227098:
  Because ti(4) drops a driver lock in RX handler, check whether
  driver is still running before re-enabling interrupts.

r227099:
  Implement altq(4) support.
  While I'm here fix a logic error in r227098 where it didn't
  re-enable interrupts when TX queue is empty.

git-svn-id: svn://svn.freebsd.org/base/stable/9@229417 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f