These drivers are not compiled by default, so were missed in the
conversion.

Sponsored by:	Juniper Networks, Inc.

Reviewed by:	imp, jhb
Approved by:	imp (mentor)
Differential Revision:	https://reviews.freebsd.org/D50913

Switch to using sys/stdarg.h for va_list type and va_* builtins.

Make an attempt to insert the include in a sensible place.  Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.

Reviewed by:	imp
Exp-run by:	antoine (PR 286274)
Pull Request:	https://github.com/freebsd/freebsd-src/pull/1595

Unloading the e6000sw driver with a "fixed" ixgbe (which is doing
MDIO transfers faster than 8ms per) has exposed another fun race
condition - the MII busses were being torn down before the etherswitch
device.

* Modify e6000sw_miiforphy() to return NULL if the mii bus device
  isn't setup, which stops the panic

* Change the module order so the e6000sw module is detached first,
  before the miibus entries and attached PHYs are destroyed.
  This ensures that the miibus entries aren't destroyed outside
  of the driver lock, and e6000sw_tick() doesn't try dereferencing
  dead miibus device_t's.

Differential Revision: https://reviews.freebsd.org/D50294
Reviewed by:	jhb

This adds the minimum support required to probe/attach the 88E6190X.

I've tested this against an AT&T ATT-150 OCP device (Silicom i3000)
with local changes to export MDIO via ixge(4).

Hints are required to probe/attach/configure the switch on amd64,
but with the mentioned diffs, it does work.

Thanks to Stas Alekseev <stas@alekseev.us> for the pull request
and Stas / Jason Hensler <omegadraconis@gmail.com> for chasing
down information about the chipset, linux stuff and AT&T OCP
hardware information.

PR:		kern/281211
Pull Request:	https://github.com/freebsd/freebsd-src/pull/1408
Differential Revision:	https://reviews.freebsd.org/D50044
Reviewed by:	imp

Although all the machinery is present, the tick routine only ran once.
It was never rescheduled.  So, reschedule it.

However in practice I've discovered that the tick routine is running
whilst a bunch of phys are actually being probe/attached on each per-port
MII bus being created and probed off of the switch itself.

Until that's debugged (and likely the whole PHY management stuff is
cleaned up here), just add a NULL check and thus don't panic.

Differential Revision:	https://reviews.freebsd.org/D50031
Reviewed by:	imp

Although the tick isn't running every hz right now, when it /is/
running at hz, the shutdown path will race with an existing running
tick routine, causing unpredictable panics.

* Introduce a shutdown flag which will abort doing the tick work if set
* set the shutdown flag and start cancel/draining the taskqueue during
  detach.

Differential Revision:	https://reviews.freebsd.org/D50030

The driver sleep lock was being held during most of the error paths,
and not unlocking it will panic the kernel during detach.  So, fix it.

Differential Revision:	https://reviews.freebsd.org/D50029
Reviewed by:	imp

This fixes the driver to load correctly as a module when etherswitch
is also a module.

Differential Revision:	https://reviews.freebsd.org/D50027
Reviewed by:	imp

This is required for it to be a module

Differential Revision:	https://reviews.freebsd.org/D50024
Reviewed by:	imp