Commit Graph

5 Commits

Author SHA1 Message Date
adrian
d57c6dcdab [etherswitch] add in an initial API for controlling per-port LED behaviour.
This is just implemented for the AR8327 for now.

Submitted by:	Dan Nelson <dnelson_1901@yahoo.com>
2016-08-04 17:45:35 +00:00
loos
e4f13850f7 Add a new flag (ETHERSWITCH_VID_VALID) to say what vlangroups are in use.
This fix the case when etherswitch is printing the information of port 0
vlan group (in port based vlan mode) with no member ports.

Add the ETHERSWITCH_VID_VALID support to ip17x driver.

Add the ETHERSWITCH_VID_VALID support to rt8366 driver.

arswitch doesn't need to be updated as it doesn't support vlans management
yet.

Approved by:	adrian (mentor)
2013-07-23 13:56:38 +00:00
adrian
2284dfb917 Add the ability to change the vlan operation mode.
This adds a vlan capability field to etherswitch_info structure and some
definitions of ports flags.

It adds the support to global config parameters which right now is used
only to switch between the vlan modes, but it is intended to be extended
to support the setup of others parameters (STP, mirror, etc.).

Submitted by:	Luiz Otavio O Souza <loos.br@gmail.com>
Reviewed by:	ray
2013-05-08 20:46:54 +00:00
adrian
38a1025029 Convert over the etherswitch framework to use VLAN IDs per port, rather
than VLAN groups.

Some chips (eg this rtl8366rb) has a VLAN group per port - you first
define a set of VLANs in a vlan group, then you assign a VLAN group
to a port.

Other chips (eg the AR8xxx switch chips) have a VLAN ID array per
port - there's no group per se, just a list of vlans that can be
configured.

So for now, the switch API will use the latter and rely on drivers
doing the heavy lifting if one wishes to use the VLAN group method.
Maybe later on both can be supported.

PR:		kern/177878
PR:		kern/177873
Submitted by:	Luiz Otavio O Souza <loos.br@gmail.com>
Reviewed by:	ray
2013-04-22 05:52:18 +00:00
adrian
98304d063a Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:

* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
  for the atheros switches.

This also includes initial support for:

* rtl8366rb support - which is a 10/100/1000 switch which supports
  vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
  which supports an alternate vlan configuration (so the vlan group
  methods are stubbed.)

The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:

* If applicable, one or more MDIO busses which ethernet interfaces can
  then attach PHYs to via miiproxy/mdioproxy;

* exposes miibusses, one for each port at the moment, so ..

* .. a PHY can be exposed on each miibus, for each switch port, with all
  of the existing MII/ifnet framework.

However:

* The ifnet is manually created for now, and it isn't linked into the
  interface list, nor can you (currently) send/receive frames on this ifnet.
  At some point in the future there may be _some_ support for this, for
  switches with a multi-port, isolated mode.

* I'm still in the process of sorting out correct(er) locking.

TODO:

* ray's switch code in zrouter (zrouter.org) includes a much more developed
  newbus API that covers the various switch methods, as well as a
  capability API so drivers, the switch layer and the userland utility
  can properly control the subset of supported features.

  The plan is to sort that out later, once the rest of ray's switch drivers
  are brought over and extended to export MII busses and PHYs.

Submitted by:	Stefan Bethke <stb@lassitu.de>
Reviewed by:	ray
2012-05-11 20:53:20 +00:00