| Message ID | 1528974690-31600-1-git-send-email-ilias.apalodimas@linaro.org |
|---|---|
| Headers | show |
| Series | Add switchdev on TI-CPSW | expand |
Hi Ilias Thanks for removing the CPU port. That helps a lot moving forward. > - Multicast testing client-port1(tagged on vlan 100) server-port1 > switch-config is provided by TI (https://git.ti.com/switch-config) > and is used to verify correct switch configuration. > 1. switch-config output > - type: vlan , vid = 100, untag_force = 0x4, reg_mcast = 0x6, > unreg_mcast = 0x0, member_list = 0x6 > Server running on sw0p2: iperf -s -u -B 239.1.1.1 -i 1 > Client running on sw0p1: iperf -c 239.1.1.1 -u -b 990m -f m -i 5 -t 3600 > No IGMP reaches the CPU port to add MDBs(since CPU does not receive > unregistered multicast as programmed). Is this something you can work around? Is there a TCAM you can program to detect IGMP and pass the packets to the CPU? Without receiving IGMP, multicast is pretty broken. If i understand right, a multicast listener running on the CPU should work, since you can add an MDB to receive multicast traffic from the two ports. Multicast traffic sent from the CPU also works. What does not work is IGMP snooping of traffic between the two switch ports. You have no access to the IGMP frames, so cannot snoop. So unless you can work around that with a TCAM, i think you just have to blindly pass all multicast between the two ports. > Setting on/off and IFF_MULTICAST (on eth0/eth1/br0) will affect registered > multicast masks programmed in the switch(for port1, port2, cpu port > respectively). > This muct occur before adding VLANs on the interfaces. If you change the > flag after the VLAN configuration you need to re-issue the VLAN config > commands. This you should fix. You should be able to get the stack to tell you about all the configured VLANs, so you can re-program the switch. > - NFS: > The only way for NFS to work is by chrooting to a minimal environment when > switch configuration that will affect connectivity is needed. You might want to look at the commit history for DSA. Florian added a patch which makes NFS root work with DSA. It might give you clues as to what you need to add to make it just work. Andrew
On Mon, Jun 18, 2018 at 05:04:24PM +0200, Andrew Lunn wrote: > Hi Ilias > > Thanks for removing the CPU port. That helps a lot moving forward. > > > - Multicast testing client-port1(tagged on vlan 100) server-port1 > > switch-config is provided by TI (https://git.ti.com/switch-config) > > and is used to verify correct switch configuration. > > 1. switch-config output > > - type: vlan , vid = 100, untag_force = 0x4, reg_mcast = 0x6, > > unreg_mcast = 0x0, member_list = 0x6 > > Server running on sw0p2: iperf -s -u -B 239.1.1.1 -i 1 > > Client running on sw0p1: iperf -c 239.1.1.1 -u -b 990m -f m -i 5 -t 3600 > > No IGMP reaches the CPU port to add MDBs(since CPU does not receive > > unregistered multicast as programmed). > > Is this something you can work around? Is there a TCAM you can program > to detect IGMP and pass the packets to the CPU? Without receiving > IGMP, multicast is pretty broken. Yes it's described in example 2. (i'll explain in detail further down) > > If i understand right, a multicast listener running on the CPU should > work, since you can add an MDB to receive multicast traffic from the > two ports. Multicast traffic sent from the CPU also works. What does > not work is IGMP snooping of traffic between the two switch ports. You > have no access to the IGMP frames, so cannot snoop. So unless you can > work around that with a TCAM, i think you just have to blindly pass > all multicast between the two ports. Yes, if the CPU port is added on the VLAN then unregistered multicast traffic (and thus IGMP joins) will reach the CPU port and everything will work as expected. I think we should not consider this as a "problem" as long as it's descibed properly in Documentation. This switch is excected to support this. What you describe is essentially what happens on "example 2." Enabling the unregistered multicat traffic to be directed to the CPU will cover all use cases that require no user intervention for everything to work. MDBs will automcatically be added/removed to the hardware and traffic will be offloaded. With the current code the user has that possibility, so it's up to him to decide what mode of configuration he prefers. > > > Setting on/off and IFF_MULTICAST (on eth0/eth1/br0) will affect registered > > multicast masks programmed in the switch(for port1, port2, cpu port > > respectively). > > > This muct occur before adding VLANs on the interfaces. If you change the > > flag after the VLAN configuration you need to re-issue the VLAN config > > commands. > > This you should fix. You should be able to get the stack to tell you > about all the configured VLANs, so you can re-program the switch. I was planning fixing these via bridge link commands which would get propagated to the driver for port1/port2 and CPU port. I just didn't find anything relevant to multicast on bridge commands apart from flooding (which is used properly). I think that the proper way to do this is follow the logic that was introduced by VLANs i.e: bridge vlan add dev br0 vid 100 pvid untagged self <---- destined for CPU port and apply it for multicast/flooding etc. This requires iproute2 changes first though. > > > - NFS: > > The only way for NFS to work is by chrooting to a minimal environment when > > switch configuration that will affect connectivity is needed. > > You might want to look at the commit history for DSA. Florian added a > patch which makes NFS root work with DSA. It might give you clues as > to what you need to add to make it just work. I'll have a look. Chrooting is rarely needed in our case anyway. It's only needed when "loss of connectivity" is bound to take place. > > Andrew Thanks Ilias
> Yes, if the CPU port is added on the VLAN then unregistered multicast traffic > (and thus IGMP joins) will reach the CPU port and everything will work as > expected. I think we should not consider this as a "problem" as long as it's > descibed properly in Documentation. This switch is excected to support this. Back to the two e1000e. What would you expect to happen with them? Either IGMP snooping needs to work, or your don't do snooping at all. > What you describe is essentially what happens on "example 2." > Enabling the unregistered multicat traffic to be directed to the CPU will cover > all use cases that require no user intervention for everything to work. MDBs > will automcatically be added/removed to the hardware and traffic will be > offloaded. > With the current code the user has that possibility, so it's up to him to > decide what mode of configuration he prefers. So by default, it just needs to work. You can give the user the option to shoot themselves in the foot, but they need to actively pull the trigger to blow their own foot off. > > > Setting on/off and IFF_MULTICAST (on eth0/eth1/br0) will affect registered > > > multicast masks programmed in the switch(for port1, port2, cpu port > > > respectively). > > > > > This muct occur before adding VLANs on the interfaces. If you change the > > > flag after the VLAN configuration you need to re-issue the VLAN config > > > commands. > > > > This you should fix. You should be able to get the stack to tell you > > about all the configured VLANs, so you can re-program the switch. > I was planning fixing these via bridge link commands which would get propagated > to the driver for port1/port2 and CPU port. I just didn't find anything > relevant to multicast on bridge commands apart from flooding (which is used > properly). I think that the proper way to do this is follow the logic that was > introduced by VLANs i.e: > bridge vlan add dev br0 vid 100 pvid untagged self <---- destined for CPU port > and apply it for multicast/flooding etc. > This requires iproute2 changes first though. No, i think you can do this in the driver. The driver just needs to ask the stack to tell it about all the VLANs again. Or you walk the VLAN tables in the hardware and do the programming based on that. I don't see why user space should be involved at all. What would you expect with two e1000e's? Andrew
On Mon, Jun 18, 2018 at 06:28:36PM +0200, Andrew Lunn wrote: > > Yes, if the CPU port is added on the VLAN then unregistered multicast traffic > > (and thus IGMP joins) will reach the CPU port and everything will work as > > expected. I think we should not consider this as a "problem" as long as it's > > descibed properly in Documentation. This switch is excected to support this. > > Back to the two e1000e. What would you expect to happen with them? > Either IGMP snooping needs to work, or your don't do snooping at > all. That's a different use case, you don't have a CPU port on e1000 and it "just works". You can't do anything to the card and drop the packet. If you want to have the same example imagine something like "i filter and drop IGMP messages on one of the 2 e1000e's on the bridge but i expect IGMP to work". It's a totally different hardware here were this is an option and for TI usecases a valid option. > > > What you describe is essentially what happens on "example 2." > > Enabling the unregistered multicat traffic to be directed to the CPU will cover > > all use cases that require no user intervention for everything to work. MDBs > > will automcatically be added/removed to the hardware and traffic will be > > offloaded. > > With the current code the user has that possibility, so it's up to him to > > decide what mode of configuration he prefers. > > So by default, it just needs to work. You can give the user the option > to shoot themselves in the foot, but they need to actively pull the > trigger to blow their own foot off. Yes it does by default. I don't consider it "foot shooting" though. If we stop thinking about switches connected to user environments and think of industrial ones, my understanding is that this is a common scenarioa that needs to be supported. > > > > > Setting on/off and IFF_MULTICAST (on eth0/eth1/br0) will affect registered > > > > multicast masks programmed in the switch(for port1, port2, cpu port > > > > respectively). > > > > > > > This muct occur before adding VLANs on the interfaces. If you change the > > > > flag after the VLAN configuration you need to re-issue the VLAN config > > > > commands. > > > > > > This you should fix. You should be able to get the stack to tell you > > > about all the configured VLANs, so you can re-program the switch. > > I was planning fixing these via bridge link commands which would get propagated > > to the driver for port1/port2 and CPU port. I just didn't find anything > > relevant to multicast on bridge commands apart from flooding (which is used > > properly). I think that the proper way to do this is follow the logic that was > > introduced by VLANs i.e: > > bridge vlan add dev br0 vid 100 pvid untagged self <---- destined for CPU port > > and apply it for multicast/flooding etc. > > This requires iproute2 changes first though. > > No, i think you can do this in the driver. The driver just needs to > ask the stack to tell it about all the VLANs again. Or you walk the > VLAN tables in the hardware and do the programming based on that. I > don't see why user space should be involved at all. What would you > expect with two e1000e's? We are pretty much describing the same thing i just thought having a bridge command for it was more appropriate. After the user removes the multicast flag for an interface i'll just walk VLANs and adjust accordingly. It's doable and i'll change it for the patch. Thanks Ilias
On Mon, Jun 18, 2018 at 07:46:02PM +0300, Ilias Apalodimas wrote: > On Mon, Jun 18, 2018 at 06:28:36PM +0200, Andrew Lunn wrote: > > > Yes, if the CPU port is added on the VLAN then unregistered multicast traffic > > > (and thus IGMP joins) will reach the CPU port and everything will work as > > > expected. I think we should not consider this as a "problem" as long as it's > > > descibed properly in Documentation. This switch is excected to support this. > > > > Back to the two e1000e. What would you expect to happen with them? > > Either IGMP snooping needs to work, or your don't do snooping at > > all. > That's a different use case I disagree. That is the exact same use case. I add ports to a bridge and i expect the bridge to either do IGMP snooping, or just forward all multicast. That is the users expectations. That is how the Linux network stack works. If the hardware has limitations you want to try to hide them from the user. > > So by default, it just needs to work. You can give the user the option > > to shoot themselves in the foot, but they need to actively pull the > > trigger to blow their own foot off. > Yes it does by default. I don't consider it "foot shooting" though. > If we stop thinking about switches connected to user environments I never think about switches. I think about a block of acceleration hardware, which i try to offload Linux networking to. And if the hardware cannot accelerate Linux network functions properly, i don't try to offload it. That way it always operates in the same way, and the user expectations are clear. Andrew
On Mon, Jun 18, 2018 at 07:30:25PM +0200, Andrew Lunn wrote: > On Mon, Jun 18, 2018 at 07:46:02PM +0300, Ilias Apalodimas wrote: > > On Mon, Jun 18, 2018 at 06:28:36PM +0200, Andrew Lunn wrote: > > > > Yes, if the CPU port is added on the VLAN then unregistered multicast traffic > > > > (and thus IGMP joins) will reach the CPU port and everything will work as > > > > expected. I think we should not consider this as a "problem" as long as it's > > > > descibed properly in Documentation. This switch is excected to support this. > > > > > > Back to the two e1000e. What would you expect to happen with them? > > > Either IGMP snooping needs to work, or your don't do snooping at > > > all. > > That's a different use case > > I disagree. That is the exact same use case. I add ports to a bridge > and i expect the bridge to either do IGMP snooping, or just forward > all multicast. That is the users expectations. That is how the Linux > network stack works. If the hardware has limitations you want to try > to hide them from the user. Why is this a limitation? Isn't it proper functionality? If you configure the CPU port as "passthrough" (which again is the default) then everything works just like e1000e. The user doesn't have to do anything at all, MDBs are added/deleted based on proper timers/joins etc. If the user chooses to use the cpu port as a kind of internal L-2 filter, that's up to him, but having hardware do the filtering for you isn't something i'd call a limitation. I am not sure what's the case here though. The hardware operates as you want by defaulti. As added functionality the user can, if he chooses to, add the MDBs manually instead of having some piece of code do that for him. This was clearly described in the first RFC since it was the only reason to add a CPU port. Is there a problem with the user controlling these capabilities of the hardware? > > > So by default, it just needs to work. You can give the user the option > > > to shoot themselves in the foot, but they need to actively pull the > > > trigger to blow their own foot off. > > > Yes it does by default. I don't consider it "foot shooting" though. > > If we stop thinking about switches connected to user environments > > I never think about switches. I think about a block of acceleration > hardware, which i try to offload Linux networking to. And if the > hardware cannot accelerate Linux network functions properly, i don't > try to offload it. That way it always operates in the same way, and > the user expectations are clear. > > Andrew The acceleration block is working properly here. The user has the ability to instruct the acceleration block not to accelerate all the traffic but specific cases he chooses to. Isn't that a valid use case since the hardware supports that ? Regards Ilias
On 06/18/2018 12:49 PM, Ilias Apalodimas wrote: > On Mon, Jun 18, 2018 at 07:30:25PM +0200, Andrew Lunn wrote: >> On Mon, Jun 18, 2018 at 07:46:02PM +0300, Ilias Apalodimas wrote: >>> On Mon, Jun 18, 2018 at 06:28:36PM +0200, Andrew Lunn wrote: >>>>> Yes, if the CPU port is added on the VLAN then unregistered multicast traffic >>>>> (and thus IGMP joins) will reach the CPU port and everything will work as >>>>> expected. I think we should not consider this as a "problem" as long as it's >>>>> descibed properly in Documentation. This switch is excected to support this. >>>> >>>> Back to the two e1000e. What would you expect to happen with them? >>>> Either IGMP snooping needs to work, or your don't do snooping at >>>> all. >>> That's a different use case >> >> I disagree. That is the exact same use case. I add ports to a bridge >> and i expect the bridge to either do IGMP snooping, or just forward >> all multicast. That is the users expectations. That is how the Linux >> network stack works. If the hardware has limitations you want to try >> to hide them from the user. > Why is this a limitation? Isn't it proper functionality? > If you configure the CPU port as "passthrough" (which again is > the default) then everything works just like e1000e. The user doesn't have to do > anything at all, MDBs are added/deleted based on proper timers/joins etc. > If the user chooses to use the cpu port as a kind of internal L-2 filter, > that's up to him, but having hardware do the filtering for you isn't something > i'd call a limitation. > > I am not sure what's the case here though. The hardware operates as you want > by defaulti. As added functionality the user can, if he chooses to, add the > MDBs manually instead of having some piece of code do that for him. > This was clearly described in the first RFC since it was the only reason to add > a CPU port. Is there a problem with the user controlling these capabilities of > the hardware? >>>> So by default, it just needs to work. You can give the user the option >>>> to shoot themselves in the foot, but they need to actively pull the >>>> trigger to blow their own foot off. >> >>> Yes it does by default. I don't consider it "foot shooting" though. >>> If we stop thinking about switches connected to user environments >> >> I never think about switches. I think about a block of acceleration >> hardware, which i try to offload Linux networking to. And if the >> hardware cannot accelerate Linux network functions properly, i don't >> try to offload it. That way it always operates in the same way, and >> the user expectations are clear. Yeh. Sry, but the user expectations depends on application area. For the industrial & automotive application It's not only about acceleration only - it's about filtering (hm, hw filtering is acceleration also :), which is the strict requirement. Yes, CPSW will help Linux networking stuck to accelerate packet forwarding, but it's expected to do this only for *allowed* traffic. One of the main points is to prevent DoS attacks when Linux Host will not be able to perform required operations and will stuck processing some network (mcast) traffic. Example, remote control/monitoring stations where one Port connected to the private sensor/control network and another is wan/trunk port. Plus, Linux Host is running industrial application which monitor/control some hw by itself - activity on WAN port should have minimal effect on ability of Linux Host industrial application to perform it target function and prevent packets flooding to the private network. As result, after boot, such systems are expected to work following the rule: "everything is prohibited which is not explicitly allowed". And that's exactly what CPSW allows to achieve by filling manually/statically ALE VLAN/FDB/MDB tables and this way prevent IGMP/.. Flood Attacks. Hope, above will help understand our use-cases and why we "annoyingly" asking about possibility to do manual/static configuration and not rely on IGMP or other great, but not applicable for all use cases, networking technologies. > The acceleration block is working properly here. The user has the ability to > instruct the acceleration block not to accelerate all the traffic but specific > cases he chooses to. Isn't that a valid use case since the hardware supports > that ? -- regards, -grygorii
Hello, This the RFC v2 which does not register the CPU port based on net-next. I didn't manage to rewrite the driver and splitting it to common library-old-new but, i did reorganize the patches a bit based on Andrew's suggestions. Hopefully it's easier to read. patch #1: Prepares headers files and move common code to cpsw_priv.h. patch #2: Adds functions to ALE for modifying VLANs/MDBs. patch #3: Prepares cpsw driver for switchdev mode, without changing any of the funtionality. patch #4: Adds new mode of operation based on switchdev. In order to enable this you need enable CONFIG_NET_SWITCHDEV, CONFIG_BRIDGE_VLAN_FILTERING, CONFIG_TI_CPSW_SWITCHDEV and add this to udev config: SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="0f011900", \ ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}" Since the phys_switch_id is based on cpsw version, users with different version will need to do 'ip -d link show dev sw0p1 | grep switchid' and replace with the correct value. This patch creates 2 ports, sw0p1 and sw0p2 both connected to PHYs. Bridge setup: ip link add name br0 type bridge ip link set dev br0 type bridge ageing_time 1000 ip link set dev br0 type bridge vlan_filtering 1 ip link set dev sw0p1 up ip link set dev sw0p2 up ip link set dev sw0p1 master br0 ip link set dev sw0p2 master br0 ifconfig br0 up - VLAN config: untagged: bridge vlan add dev sw0p1 vid 100 pvid untagged master bridge vlan add dev sw0p2 vid 100 pvid untagged master tagged: bridge vlan add dev sw0p1 vid 100 master bridge vlan add dev sw0p2 vid 100 master IP address on br0: This will add VLAN 100 on the cpu port. bridge vlan add dev br0 vid 100 pvid untagged self udhcpc -i br0 - FDBs: FDBs are automatically added on the appropriate switch port uppon detection Manually adding FDBs: bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100 bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master - MDBs: MDBs are automatically added on the appropriate switch port uppon detection Manually adding MDBs: bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100 - Multicast testing client-port1(tagged on vlan 100) server-port1 switch-config is provided by TI (https://git.ti.com/switch-config) and is used to verify correct switch configuration. 1. switch-config output - type: vlan , vid = 100, untag_force = 0x4, reg_mcast = 0x6, unreg_mcast = 0x0, member_list = 0x6 Server running on sw0p2: iperf -s -u -B 239.1.1.1 -i 1 Client running on sw0p1: iperf -c 239.1.1.1 -u -b 990m -f m -i 5 -t 3600 No IGMP reaches the CPU port to add MDBs(since CPU does not receive unregistered multicast as programmed). If the MDB is added manually via: bridge mdb add dev br0 port sw0p2 grp 239.1.1.1 permanent vid 100 or unregistered flooding is enabled via: bridge link set dev sw0p2 mcast_flood on Multicast traffic is offloaded as expected. 2. switch-config output - type: vlan , vid = 100, untag_force = 0x7, reg_mcast = 0x7, unreg_mcast = 0x1, member_list = 0x7 In this case CPU port receives the IGMP message and programs the switch accordingly. tcpdump on br0 shows no packets. If the MDB entry is removed with "bridge mdb del dev br0 port sw0p1 grp 239.1.1.1 permanent" br0 is flooded with multicast packets correctly(since unreg multicast is set for the CPU port). If the the mdb entry is manually added tcpdump shows no packets and multicast offloading starts working again. root@ti:~# bridge mdb show dev br0 port sw0p1 grp ff02::fb temp offload vid 100 dev br0 port sw0p1 grp 239.1.1.1 temp offload vid 100 root@ti:~# switch-config -d type: mcast, vid = 100, addr = 01:00:5e:01:01:01, mcast_state = f, \ no super, port_mask = 0x2 - Multicast testing server-port0 client-port1 CPU port(port 0) does not show on bridge mdb show Using ti's switch-config to dump the switch status shows that the MDB is installed correctly. root@ti:~# switch-config -d type: mcast, vid = 100, addr = 01:00:5e:01:01:01, mcast_state = f, \ no super, port_mask = 0x1 - registered multicast: Setting on/off and IFF_MULTICAST (on eth0/eth1/br0) will affect registered multicast masks programmed in the switch(for port1, port2, cpu port respectively). This muct occur before adding VLANs on the interfaces. If you change the flag after the VLAN configuration you need to re-issue the VLAN config commands. If CPU port is participating the proper VLANs MDBs/FDBs will be offloaded by the switch as described in switchdev API. This will also be reflected on "bridge vlan/fdb/mdb show" command(in case the host sends the join the mdb entry won't show there, but ALE status confirms that it's added). - NFS: The only way for NFS to work is by chrooting to a minimal environment when switch configuration that will affect connectivity is needed. Assuming you are booting NFS with eth1 interface(the script is hacky and it's just there to prove NFS is doable). setup.sh: #!/bin/sh mkdir proc mount -t proc none /proc ifconfig br0 > /dev/null if [ $? -ne 0 ]; then echo "Setting up bridge" ip link add name br0 type bridge ip link set dev br0 type bridge ageing_time 1000 ip link set dev br0 type bridge vlan_filtering 1 ip link set eth1 down ip link set eth1 name sw0p1 ip link set dev sw0p1 up ip link set dev sw0p2 up ip link set dev sw0p2 master br0 ip link set dev sw0p1 master br0 bridge vlan add dev br0 vid 1 pvid untagged self ifconfig sw0p1 0.0.0.0 udhchc -i br0 fi umount /proc run_nfs.sh: #!/bin/sh mkdir /tmp/root/bin -p mkdir /tmp/root/lib -p cp -r /lib/ /tmp/root/ cp -r /bin/ /tmp/root/ cp /sbin/ip /tmp/root/bin cp /sbin/bridge /tmp/root/bin cp /sbin/ifconfig /tmp/root/bin cp /sbin/udhcpc /tmp/root/bin cp /path/to/setup.sh /tmp/root/bin chroot /tmp/root/ busybox sh /bin/run_nfs.sh run ./run_nfs.sh - Current issues/future work: 1. For this hardware and it's applications it's essential to control the CPU port individually. After removing the CPU port we lost the ability to control unregistered multicast traffic flags. This code unconditionally(if it participates on that VLAN) adds CPU port on the unregistered multicast mask, while for ports 1 and 2 this is configurable via: "bridge link set dev eth1 mcast_flood on/off" Petr Machata introduced a funtionality on VLANs(9c86ce2c1ae337fc10568a12aea812ed03de8319) where the command "bridge vlan add dev br0 vid 100 pvid untagged self" is propagated to the driver and allows us to configure the CPU port. Adding something similar for MDBs i.e "bridge link set dev br0 mcast_flood on self" that reaches the driver is an idea on how to control the CPU port independently and removing the need to add/remove the CPU port on the vlan group for this to happen. 2. VLAN CoS is always set to 0 3. Add support for ageing configuration 4. ALE_P0_UNI_FLOOD can be controlled via: "bridge link set dev br0 flood on self" if this propagates to the driver as well. 5. Add documentation for CPSW configuration on the patch - Changes since RFC v1: - Removed CPU port registration. User can now add CPU port VLANs with "bridge vlan add/del dev br0 vid 100 pvid untagged self". - Removing VLANs will modify registered/unregistered multicast port masks properly. - ALE_P0_UNI_FLOOD is controlled from bridge members. As long as the bridge has members(switch interfaces) this will be enabled. - added management for SWITCHDEV_OBJ_ID_HOST_MDB to control MDBs for the CPU port. - Added STP support. - Added multicast flood support. CPU port is always enabled for now. Ilias Apalodimas (4): net/cpsw: move common headers definitions to cpsw_priv.h net/cpsw_ale: add functions to modify VLANs/MDBs net/cpsw: prepare cpsw for switchdev support net/cpsw_switchdev: add switchdev mode of operation on cpsw driver drivers/net/ethernet/ti/Kconfig | 9 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw.c | 555 ++++++++++++++++++++++--------- drivers/net/ethernet/ti/cpsw_ale.c | 188 ++++++++++- drivers/net/ethernet/ti/cpsw_ale.h | 10 + drivers/net/ethernet/ti/cpsw_priv.h | 148 +++++++++ drivers/net/ethernet/ti/cpsw_switchdev.c | 418 +++++++++++++++++++++++ drivers/net/ethernet/ti/cpsw_switchdev.h | 4 + 8 files changed, 1167 insertions(+), 166 deletions(-) create mode 100644 drivers/net/ethernet/ti/cpsw_priv.h create mode 100644 drivers/net/ethernet/ti/cpsw_switchdev.c create mode 100644 drivers/net/ethernet/ti/cpsw_switchdev.h -- 2.7.4