2019-05-19 15:07:45 +03:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2012-11-26 13:16:10 +04:00
|
|
|
config HAVE_NET_DSA
|
|
|
|
|
def_bool y
|
2017-01-10 00:49:26 +03:00
|
|
|
depends on INET && NETDEVICES && !S390
|
2012-11-26 13:16:10 +04:00
|
|
|
|
|
|
|
|
# Drivers must select NET_DSA and the appropriate tagging format
|
|
|
|
|
|
2019-04-28 20:37:23 +03:00
|
|
|
menuconfig NET_DSA
|
2015-03-21 04:31:03 +03:00
|
|
|
tristate "Distributed Switch Architecture"
|
2019-02-26 06:34:02 +03:00
|
|
|
depends on HAVE_NET_DSA
|
2017-11-11 18:29:41 +03:00
|
|
|
depends on BRIDGE || BRIDGE=n
|
2020-04-21 16:41:08 +03:00
|
|
|
select GRO_CELLS
|
2017-01-10 00:49:26 +03:00
|
|
|
select NET_SWITCHDEV
|
2018-05-10 23:17:32 +03:00
|
|
|
select PHYLINK
|
2019-03-24 13:14:38 +03:00
|
|
|
select NET_DEVLINK
|
2020-06-13 19:50:22 +03:00
|
|
|
help
|
2015-03-21 04:31:03 +03:00
|
|
|
Say Y if you want to enable support for the hardware switches supported
|
|
|
|
|
by the Distributed Switch Architecture.
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 17:44:02 +04:00
|
|
|
|
2012-11-26 13:16:10 +04:00
|
|
|
if NET_DSA
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 17:44:02 +04:00
|
|
|
|
net: dsa: Optional VLAN-based port separation for switches without tagging
This patch provides generic DSA code for using VLAN (802.1Q) tags for
the same purpose as a dedicated switch tag for injection/extraction.
It is based on the discussions and interest that has been so far
expressed in https://www.spinics.net/lists/netdev/msg556125.html.
Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q
does not offer a complete solution for drivers (nor can it). Instead, it
provides generic code that driver can opt into calling:
- dsa_8021q_xmit: Inserts a VLAN header with the specified contents.
Can be called from another tagging protocol's xmit function.
Currently the LAN9303 driver is inserting headers that are simply
802.1Q with custom fields, so this is an opportunity for code reuse.
- dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb.
Removing the VLAN header is left as a decision for the caller to make.
- dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID
and a Tx VID, for proper untagged traffic identification on ingress
and steering on egress. Also sets up the VLAN trunk on the upstream
(CPU or DSA) port. Drivers are intentionally left to call this
function explicitly, depending on the context and hardware support.
The expected switch behavior and VLAN semantics should not be violated
under any conditions. That is, after calling
dsa_port_setup_8021q_tagging, the hardware should still pass all
ingress traffic, be it tagged or untagged.
For uniformity with the other tagging protocols, a module for the
dsa_8021q_netdev_ops structure is registered, but the typical usage is
to set up another tagging protocol which selects CONFIG_NET_DSA_TAG_8021Q,
and calls the API from tag_8021q.h. Null function definitions are also
provided so that a "depends on" is not forced in the Kconfig.
This tagging protocol only works when switch ports are standalone, or
when they are added to a VLAN-unaware bridge. It will probably remain
this way for the reasons below.
When added to a bridge that has vlan_filtering 1, the bridge core will
install its own VLANs and reset the pvids through switchdev. For the
bridge core, switchdev is a write-only pipe. All VLAN-related state is
kept in the bridge core and nothing is read from DSA/switchdev or from
the driver. So the bridge core will break this port separation because
it will install the vlan_default_pvid into all switchdev ports.
Even if we could teach the bridge driver about switchdev preference of a
certain vlan_default_pvid (task difficult in itself since the current
setting is per-bridge but we would need it per-port), there would still
exist many other challenges.
Firstly, in the DSA rcv callback, a driver would have to perform an
iterative reverse lookup to find the correct switch port. That is
because the port is a bridge slave, so its Rx VID (port PVID) is subject
to user configuration. How would we ensure that the user doesn't reset
the pvid to a different value (which would make an O(1) translation
impossible), or to a non-unique value within this DSA switch tree (which
would make any translation impossible)?
Finally, not all switch ports are equal in DSA, and that makes it
difficult for the bridge to be completely aware of this anyway.
The CPU port needs to transmit tagged packets (VLAN trunk) in order for
the DSA rcv code to be able to decode source information.
But the bridge code has absolutely no idea which switch port is the CPU
port, if nothing else then just because there is no netdevice registered
by DSA for the CPU port.
Also DSA does not currently allow the user to specify that they want the
CPU port to do VLAN trunking anyway. VLANs are added to the CPU port
using the same flags as they were added on the user port.
So the VLANs installed by dsa_port_setup_8021q_tagging per driver
request should remain private from the bridge's and user's perspective,
and should not alter the VLAN semantics observed by the user.
In the current implementation a VLAN range ending at 4095 (VLAN_N_VID)
is reserved for this purpose. Each port receives a unique Rx VLAN and a
unique Tx VLAN. Separate VLANs are needed for Rx and Tx because they
serve different purposes: on Rx the switch must process traffic as
untagged and process it with a port-based VLAN, but with care not to
hinder bridging. On the other hand, the Tx VLAN is where the
reachability restrictions are imposed, since by tagging frames in the
xmit callback we are telling the switch onto which port to steer the
frame.
Some general guidance on how this support might be employed for
real-life hardware (some comments made by Florian Fainelli):
- If the hardware supports VLAN tag stacking, it should somehow back
up its private VLAN settings when the bridge tries to override them.
Then the driver could re-apply them as outer tags. Dedicating an outer
tag per bridge device would allow identical inner tag VID numbers to
co-exist, yet preserve broadcast domain isolation.
- If the switch cannot handle VLAN tag stacking, it should disable this
port separation when added as slave to a vlan_filtering bridge, in
that case having reduced functionality.
- Drivers for old switches that don't support the entire VLAN_N_VID
range will need to rework the current range selection mechanism.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-05 13:19:22 +03:00
|
|
|
# tagging formats
|
|
|
|
|
config NET_DSA_TAG_8021Q
|
2019-11-12 07:38:46 +03:00
|
|
|
tristate
|
net: dsa: Optional VLAN-based port separation for switches without tagging
This patch provides generic DSA code for using VLAN (802.1Q) tags for
the same purpose as a dedicated switch tag for injection/extraction.
It is based on the discussions and interest that has been so far
expressed in https://www.spinics.net/lists/netdev/msg556125.html.
Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q
does not offer a complete solution for drivers (nor can it). Instead, it
provides generic code that driver can opt into calling:
- dsa_8021q_xmit: Inserts a VLAN header with the specified contents.
Can be called from another tagging protocol's xmit function.
Currently the LAN9303 driver is inserting headers that are simply
802.1Q with custom fields, so this is an opportunity for code reuse.
- dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb.
Removing the VLAN header is left as a decision for the caller to make.
- dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID
and a Tx VID, for proper untagged traffic identification on ingress
and steering on egress. Also sets up the VLAN trunk on the upstream
(CPU or DSA) port. Drivers are intentionally left to call this
function explicitly, depending on the context and hardware support.
The expected switch behavior and VLAN semantics should not be violated
under any conditions. That is, after calling
dsa_port_setup_8021q_tagging, the hardware should still pass all
ingress traffic, be it tagged or untagged.
For uniformity with the other tagging protocols, a module for the
dsa_8021q_netdev_ops structure is registered, but the typical usage is
to set up another tagging protocol which selects CONFIG_NET_DSA_TAG_8021Q,
and calls the API from tag_8021q.h. Null function definitions are also
provided so that a "depends on" is not forced in the Kconfig.
This tagging protocol only works when switch ports are standalone, or
when they are added to a VLAN-unaware bridge. It will probably remain
this way for the reasons below.
When added to a bridge that has vlan_filtering 1, the bridge core will
install its own VLANs and reset the pvids through switchdev. For the
bridge core, switchdev is a write-only pipe. All VLAN-related state is
kept in the bridge core and nothing is read from DSA/switchdev or from
the driver. So the bridge core will break this port separation because
it will install the vlan_default_pvid into all switchdev ports.
Even if we could teach the bridge driver about switchdev preference of a
certain vlan_default_pvid (task difficult in itself since the current
setting is per-bridge but we would need it per-port), there would still
exist many other challenges.
Firstly, in the DSA rcv callback, a driver would have to perform an
iterative reverse lookup to find the correct switch port. That is
because the port is a bridge slave, so its Rx VID (port PVID) is subject
to user configuration. How would we ensure that the user doesn't reset
the pvid to a different value (which would make an O(1) translation
impossible), or to a non-unique value within this DSA switch tree (which
would make any translation impossible)?
Finally, not all switch ports are equal in DSA, and that makes it
difficult for the bridge to be completely aware of this anyway.
The CPU port needs to transmit tagged packets (VLAN trunk) in order for
the DSA rcv code to be able to decode source information.
But the bridge code has absolutely no idea which switch port is the CPU
port, if nothing else then just because there is no netdevice registered
by DSA for the CPU port.
Also DSA does not currently allow the user to specify that they want the
CPU port to do VLAN trunking anyway. VLANs are added to the CPU port
using the same flags as they were added on the user port.
So the VLANs installed by dsa_port_setup_8021q_tagging per driver
request should remain private from the bridge's and user's perspective,
and should not alter the VLAN semantics observed by the user.
In the current implementation a VLAN range ending at 4095 (VLAN_N_VID)
is reserved for this purpose. Each port receives a unique Rx VLAN and a
unique Tx VLAN. Separate VLANs are needed for Rx and Tx because they
serve different purposes: on Rx the switch must process traffic as
untagged and process it with a port-based VLAN, but with care not to
hinder bridging. On the other hand, the Tx VLAN is where the
reachability restrictions are imposed, since by tagging frames in the
xmit callback we are telling the switch onto which port to steer the
frame.
Some general guidance on how this support might be employed for
real-life hardware (some comments made by Florian Fainelli):
- If the hardware supports VLAN tag stacking, it should somehow back
up its private VLAN settings when the bridge tries to override them.
Then the driver could re-apply them as outer tags. Dedicating an outer
tag per bridge device would allow identical inner tag VID numbers to
co-exist, yet preserve broadcast domain isolation.
- If the switch cannot handle VLAN tag stacking, it should disable this
port separation when added as slave to a vlan_filtering bridge, in
that case having reduced functionality.
- Drivers for old switches that don't support the entire VLAN_N_VID
range will need to rework the current range selection mechanism.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-05 13:19:22 +03:00
|
|
|
select VLAN_8021Q
|
|
|
|
|
help
|
|
|
|
|
Unlike the other tagging protocols, the 802.1Q config option simply
|
|
|
|
|
provides helpers for other tagging implementations that might rely on
|
|
|
|
|
VLAN in one way or another. It is not a complete solution.
|
|
|
|
|
|
|
|
|
|
Drivers which use these helpers should select this as dependency.
|
|
|
|
|
|
2019-12-18 11:02:14 +03:00
|
|
|
config NET_DSA_TAG_AR9331
|
|
|
|
|
tristate "Tag driver for Atheros AR9331 SoC with built-in switch"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for
|
|
|
|
|
the Atheros AR9331 SoC with built-in switch.
|
|
|
|
|
|
2019-04-28 20:37:23 +03:00
|
|
|
config NET_DSA_TAG_BRCM_COMMON
|
|
|
|
|
tristate
|
|
|
|
|
default n
|
|
|
|
|
|
2014-08-28 04:04:55 +04:00
|
|
|
config NET_DSA_TAG_BRCM
|
2019-04-28 20:37:23 +03:00
|
|
|
tristate "Tag driver for Broadcom switches using in-frame headers"
|
|
|
|
|
select NET_DSA_TAG_BRCM_COMMON
|
|
|
|
|
help
|
|
|
|
|
Say Y if you want to enable support for tagging frames for the
|
|
|
|
|
Broadcom switches which place the tag after the MAC source address.
|
|
|
|
|
|
2014-08-28 04:04:55 +04:00
|
|
|
|
2017-11-11 02:22:54 +03:00
|
|
|
config NET_DSA_TAG_BRCM_PREPEND
|
2019-04-28 20:37:23 +03:00
|
|
|
tristate "Tag driver for Broadcom switches using prepended headers"
|
|
|
|
|
select NET_DSA_TAG_BRCM_COMMON
|
|
|
|
|
help
|
|
|
|
|
Say Y if you want to enable support for tagging frames for the
|
|
|
|
|
Broadcom switches which places the tag before the Ethernet header
|
|
|
|
|
(prepended).
|
|
|
|
|
|
|
|
|
|
config NET_DSA_TAG_GSWIP
|
|
|
|
|
tristate "Tag driver for Lantiq / Intel GSWIP switches"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for the
|
|
|
|
|
Lantiq / Intel GSWIP switches.
|
2017-11-11 02:22:54 +03:00
|
|
|
|
2008-10-07 17:45:02 +04:00
|
|
|
config NET_DSA_TAG_DSA
|
2019-04-28 20:37:23 +03:00
|
|
|
tristate "Tag driver for Marvell switches using DSA headers"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for the
|
|
|
|
|
Marvell switches which use DSA headers.
|
2008-10-07 17:45:02 +04:00
|
|
|
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 17:44:02 +04:00
|
|
|
config NET_DSA_TAG_EDSA
|
2019-04-28 20:37:23 +03:00
|
|
|
tristate "Tag driver for Marvell switches using EtherType DSA headers"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for the
|
|
|
|
|
Marvell switches which use EtherType DSA headers.
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 17:44:02 +04:00
|
|
|
|
2019-04-28 20:37:23 +03:00
|
|
|
config NET_DSA_TAG_MTK
|
|
|
|
|
tristate "Tag driver for Mediatek switches"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for
|
|
|
|
|
Mediatek switches.
|
|
|
|
|
|
2017-05-31 23:19:06 +03:00
|
|
|
config NET_DSA_TAG_KSZ
|
2019-09-10 16:18:36 +03:00
|
|
|
tristate "Tag driver for Microchip 8795/9477/9893 families of switches"
|
2019-04-28 20:37:23 +03:00
|
|
|
help
|
|
|
|
|
Say Y if you want to enable support for tagging frames for the
|
2019-09-10 16:18:36 +03:00
|
|
|
Microchip 8795/9477/9893 families of switches.
|
2018-12-15 03:58:04 +03:00
|
|
|
|
2020-07-08 15:25:36 +03:00
|
|
|
config NET_DSA_TAG_RTL4_A
|
|
|
|
|
tristate "Tag driver for Realtek 4 byte protocol A tags"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for the
|
|
|
|
|
Realtek switches with 4 byte protocol A tags, sich as found in
|
|
|
|
|
the Realtek RTL8366RB.
|
|
|
|
|
|
2019-11-14 18:03:29 +03:00
|
|
|
config NET_DSA_TAG_OCELOT
|
|
|
|
|
tristate "Tag driver for Ocelot family of switches"
|
|
|
|
|
select PACKING
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for the
|
|
|
|
|
Ocelot switches (VSC7511, VSC7512, VSC7513, VSC7514, VSC9959).
|
|
|
|
|
|
2019-04-28 20:37:23 +03:00
|
|
|
config NET_DSA_TAG_QCA
|
|
|
|
|
tristate "Tag driver for Qualcomm Atheros QCA8K switches"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for
|
|
|
|
|
the Qualcomm Atheros QCA8K switches.
|
2012-11-26 13:16:10 +04:00
|
|
|
|
2019-04-28 20:37:23 +03:00
|
|
|
config NET_DSA_TAG_LAN9303
|
|
|
|
|
tristate "Tag driver for SMSC/Microchip LAN9303 family of switches"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames for the
|
|
|
|
|
SMSC/Microchip LAN9303 family of switches.
|
2016-09-15 17:26:40 +03:00
|
|
|
|
2019-05-05 13:19:27 +03:00
|
|
|
config NET_DSA_TAG_SJA1105
|
|
|
|
|
tristate "Tag driver for NXP SJA1105 switches"
|
|
|
|
|
select NET_DSA_TAG_8021Q
|
2019-06-11 21:47:45 +03:00
|
|
|
select PACKING
|
2019-05-05 13:19:27 +03:00
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames with the
|
|
|
|
|
NXP SJA1105 switch family. Both the native tagging protocol (which
|
|
|
|
|
is only for link-local traffic) as well as non-native tagging (based
|
|
|
|
|
on a custom 802.1Q VLAN header) are available.
|
|
|
|
|
|
2017-05-16 23:40:07 +03:00
|
|
|
config NET_DSA_TAG_TRAILER
|
2019-04-28 20:37:23 +03:00
|
|
|
tristate "Tag driver for switches using a trailer tag"
|
|
|
|
|
help
|
|
|
|
|
Say Y or M if you want to enable support for tagging frames at
|
|
|
|
|
with a trailed. e.g. Marvell 88E6060.
|
2017-04-18 11:48:24 +03:00
|
|
|
|
2012-11-26 13:16:10 +04:00
|
|
|
endif
|
