- 26 May, 2017 40 commits
-
-
Ido Schimmel authored
The mlxsw driver currently implements three types of RIFs. VLAN and FID RIFs for L3 interfaces on top of VLAN-aware and VLAN-unaware bridges (respectively) and Subport RIFs for all other L3 interfaces. All the RIF types follow a common configuration procedure, which only differs in the type-specific bits. The patch exploits this fact and consolidates the common code paths, thereby simplifying the code and making it more extensible. This work also prepares the driver for use with future ASICs, where the range of the Subport RIFs will be extended and their configuration modified accordingly. By merely implementing a new RIF operations and selecting it during initialization, the same driver could be re-used. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The device supports three types of FIDs. 802.1Q and 802.1D FIDs for VLAN-aware and VLAN-unaware bridges (respectively) and rFIDs to transport packets to the router block. The different users (e.g., bridge, router, ACLs) of the FIDs infrastructure need not know about the internal FIDs implementation and can therefore interact with it using a restricted set of exported functions. By encapsulating the entire FID logic and hiding it from the rest of the driver we get a code base that it much simpler and easier to work with and extend. For example, in the current Spectrum ASIC only 802.1D FIDs can be assigned a VNI, but future ASICs will also support 802.1Q FIDs. With this patch in place, support for future ASICs can be easily added by implementing a new FID operations according to their capabilities. Signed-off-by:
-
Ido Schimmel authored
All RIF types are associated with a virtual router (VR), so determine VR first when creating a RIF. That way, we can more easily integrate the common RIF core in the following patches. Signed-off-by:
-
Ido Schimmel authored
If a packet ingress the router but can't be assigned an ingress RIF, it's dropped. Therefore, in the case of RIF configured on top of a bridge, it makes sense to start flooding broadcast packets to the router only after the RIF was created. Signed-off-by:
-
Ido Schimmel authored
Now that all the information to create a RIF is contained within the RIF struct itself, we can also simplify the destruction logic. Signed-off-by:
-
Ido Schimmel authored
All the information necessary for the configuration of RIFs can now be found in the RIF struct itself, so reduce the arguments list. This gets us one step closer to the common RIF core. Signed-off-by:
-
Ido Schimmel authored
Currently, when a Subport RIF is configured, the LAG status and VLAN of the underlying port are read from the port itself. This is problematic, as we would like to have common code to configure all types of RIFs, which aren't necessarily bound to a port. Instead, embed the RIF in a struct specific to the Subport type, which contains all the necessary information. Signed-off-by:
-
Ido Schimmel authored
In the following patches the RIF's configuration function is going to expect a RIF struct with all the necessary information. Therefore, allocate the RIF just before it's configured to the device. Signed-off-by:
-
Ido Schimmel authored
The following patches are going to re-arrange the FID and RIF code, so that when the RIF is configured to the device based on the information present in the RIF struct (which points to a FID). For this reason, move the FID allocation to just before the RIF configuration. Signed-off-by:
-
Ido Schimmel authored
As explained in the cover letter, since the introduction of the bridge offload in the mlxsw driver, information related to the offloaded bridge and bridge ports was stored in the individual port struct, mlxsw_sp_port. This lead to a bloated struct storing both physical properties of the port (e.g., autoneg status) as well as logical properties of an upper bridge port (e.g., learning, mrouter indication). While this might work well for simple devices, it proved to be hard to extend when stacked devices were taken into account and more advanced use-cases (e.g., IGMP snooping) considered. This patch removes the excess information from the above struct and instead stores it in more appropriate structs that represent the bridge port, the bridge itself and a VLAN configured on the bridge port. The membership of a port in a bridge is denoted using the Port-VLAN struct, which points to the bridge port and also member in the bridge VLAN group of the VLAN it represents. This allows us to completely remove the vPort abstraction and consolidate many of the code paths relating to VLAN-aware and unaware bridges. Note that the FID / vFID code is currently duplicated, but this will soon go away when the common FID core will be introduced. Signed-off-by:
-
Ido Schimmel authored
Up until now we used to create FIDs upon the creation of VLAN uppers on top of the VLAN-aware bridge. This was done so that in case a router interface (RIF) was configured on top of the bridge, the FID would already be there. Instead, simplify the code and only create the FID upon RIF creation. This is an intermediary step towards the introduction of the common FID core, in which this code would be completely removed. Signed-off-by:
-
Ido Schimmel authored
Currently, when port netdevs (or their uppers) are enslaved to a bridge, we simply propagate the CHANGEUPPER event all the way down and lose the context of the actual netdevice used as the bridge port. This leads to a lot of information hanging off the ports (and vPorts), which doesn't logically belong there, such as mrouter indication and unknown unicast flood state. Following patches are going to put the mlxsw_sp_port struct on diet and instead introduce a bridge port struct, where the above mentioned information belongs. But in order to do that, we need to be able to determine the bridge port netdevice, so propagate it down. Signed-off-by:
-
Ido Schimmel authored
We're going to get rid of vPorts completely later in the patchset, but the router code is self-contained, so it's a good candidate to start the transition with. Convert all the functions that expects to operate on a vPort to operate on a Port-VLAN instead. Signed-off-by:
-
Ido Schimmel authored
When a vPort is destroyed, it leaves the FID it's currently mapped to (if any) and drops the reference. The FID's leave function expects to get the vPort as its argument, but this will have to change when the vPort model is retired. Change the function signature to expect a Port-VLAN struct instead and patch the call sites accordingly. The code introduced in this patch will be removed later in the patchset, but this intermediary step is required in order to ease the code review. Signed-off-by:
-
Ido Schimmel authored
This is the first step in the transition from the vPort model to a unified Port-VLAN structure. The new structure is defined and created / destroyed upon invocation of the 8021q ndos, but it's not actually used throughout the code. Subsequent patches will initialize it correctly and also create / destroy it upon switchdev's VLAN object. Signed-off-by:
-
Ido Schimmel authored
We currently transition the port to "Virtual mode" upon the creation of its first VLAN upper, as we need to classify incoming packets to a FID using {Port, VID} and not only the VID. However, it's more appropriate to transition the port to this mode when the {Port, VID} are actually mapped to a FID. Either during the enslavement of the VLAN upper to a VLAN-unaware bridge or the configuration of a router port. Do this change now in preparation for the introduction of the FID core, where this operation will be encapsulated. To prevent regressions, this patch also explicitly configures an OVS slave to "Virtual mode". Otherwise, a packet that didn't hit an ACL rule could be classified to an existing FID based on a global VID-to-FID mapping, thus not incurring a FID mis-classification, which would otherwise trap the packet to the CPU to be processed by the OVS daemon. Signed-off-by: -
Ido Schimmel authored
During enslavement to a bridge, after the CHANGEUPPER is sent, the multicast enabled state of the bridge isn't propagated down to the offloading driver unless it's changed. This patch allows such drivers to query the multicast enabled state from the bridge, so that they'll be able to correctly configure their flood tables during port enslavement. In case multicast is disabled, unregistered multicast packets can be treated as broadcast and be flooded through all the bridge ports. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Ido Schimmel authored
It's useful for drivers supporting bridge offload to be able to query the bridge's VLAN filtering state. Currently, upon enslavement to a bridge master, the offloading driver will only learn about the bridge's VLAN filtering state after the bridge device was already linked with its slave. Being able to query the bridge's VLAN filtering state allows such drivers to forbid enslavement in case resource couldn't be allocated for a VLAN-aware bridge and also choose the correct initialization routine for the enslaved port, which is dependent on the bridge type. Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== net: dsa: mv88e6xxx: Add basic SERDES support Some of the Marvell switches are SERDES interface, which must be powered up before packets can be passed. This is particularly true on the 6390, where the SERDES defaults to down, probably to save power. This series refactors the existing SERDES support for the 6352, and adds 6390 support. v2: Split phy functions out into phy.[ch] Don't add MV88E6XXX_FLAG_G1_ATU_FID back again Move the serdes op up in mv88e6xxx_ops Move some #defines into serdes.h Add a mv88e6xxx_serdes_power() Don't keep moving calls to this helper around in the code v3: Move more phy functions into phy.[ch] Make mv88e6xxx_phy_page_get() and mv88e6xxx_phy_page_put static Use the mv88e6xxx_serdes_power() helper everywhere dev_err(...) when mv88e6xxx_serdes_power() fails Add reviewed-by's ==================== Signed-off-by: -
Andrew Lunn authored
Implement the port enable/disable callbacks, which enable/disable the SERDES interfaces, if applicable. This should save a bit of power/heat. We also need to enable SERDES on CPU and DSA ports, so keep the existing call to the op, but make it conditional. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
The mv88e6390X family has 8 SERDES lanes. These can be used for 2 10Gbps ports, ports 9 or 10. If these ports are used at slower speeds, the SERDES lanes become available for other ports for 1000Base-X. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Andrew Lunn authored
Now that we use an op for SERDES operations, we don't need a flag for it. Remove it. Signed-off-by:
-
Andrew Lunn authored
The mv88e6390 family has a different SERDES implementation. Refactor the mv88e6352 code into an ops function, so we can later add the mv88e6390 code. Signed-off-by:
-
Andrew Lunn authored
The upcoming SERDES support will need to make use of PHY functions. Move them out into a file of there own. No code changes. Signed-off-by:
-
Uwe Kleine-König authored
Instead of falling back to 00:00:00:00:00:00 generate a random address if none is provided via platform data or from the device's register space. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
David S. Miller authored
Andrew Lunn says: ==================== More marvell phy cleanups This patchset continues the cleanup of the Marvell PHY driver. These phys use pages to allow more than the 32 registers that fit into the MDIO address space. Cleanup the code used for changing pages. v2 Reverse christmas tree ==================== Signed-off-by: -
Andrew Lunn authored
Bring all the page names together, remove the repeats, and make them uniform. Signed-off-by:
-
Andrew Lunn authored
There is a common pattern of first reading the currently selected page and then changing to another page. Add a helper to do this. Signed-off-by:
-
Andrew Lunn authored
EXT_ADDR_PAGE is the same meaning as MII_MARVELL_PHY_PAGE, i.e. change page. Replace it will calls to the helpers. Signed-off-by:
-
Andrew Lunn authored
Replace magic numbers for PHY pages with symbolic names. Signed-off-by:
-
Prasad Kanneganti authored
lio_enable_irq (called by napi poll) is reporting to Octeon an inaccurate count of processed rx packets causing Octeon to eventually stop forwarding packets to the host. Fix it by using this formula for an accurate count: processed rx packets = droq->pkt_count - droq->pkts_pending Also increase SOFT_COMMAND_BUFFER_SIZE to match what the firmware expects. Signed-off-by:Prasad Kanneganti <prasad.kanneganti@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
Prasad Kanneganti authored
There's a rare pci_driver.probe failure of the VF driver that's caused by PF/VF handshake going out of sync. The culprit is octeon_mbox_write() who ignores an ack timeout condition; it just keeps unconditionally writing all elements of mbox_cmd->data[] even when the other side is not ready for them. Fix it by making each write of mbox_cmd->data[i] conditional to having previously received an ack. Also fix the octeon_mbox_state enum such that each state gets a unique value. Also add ULL suffix to numeric literals in macro definitions. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: Create sysfs reciprocal links for attached_dev/phydev This patch series addresses a device topology shortcoming where a program scanning /sys would not be able to establish a mapping between the network device and the PHY device. In the process it turned out that no PHY device documentation existed for sysfs attributes. Changes in v2: - document possible phy_interface values in sysfs-class-net-phydev ==================== Reviewed-by:
-
Florian Fainelli authored
Document the different sysfs attributes that exist for PHY devices: attached_dev, phy_has_fixups, phy_id and phy_interface. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Now that we link the network device to its PHY device, document this sysfs symbolic link. Signed-off-by:
-
Florian Fainelli authored
There is currently no way for a program scanning /sys to know whether a network device is attached to a particular PHY device, just like the PHY device is not pointed back to its attached network device. Create a symbolic link in the network device's namespace named "phydev" which points to the PHY device and create a symbolic link in the PHY device's namespace named "attached_dev" that points back to the network device. These links are set up during phy_attach_direct() and removed during phy_detach() for symetry. Signed-off-by:
-
David S. Miller authored
Roopa Prabhu says: ==================== net: extend RTM_GETROUTE to return fib result This series adds a new RTM_F_FIB_MATCH flag to return matched fib result with RTM_GETROUTE. This is useful for applications and protocols in userspace wanting to query the selected route. examples (with patched iproute2): ipv4: ---- $ip route show default via 192.168.0.2 dev eth0 10.0.14.0/24 nexthop via 172.16.0.3 dev dummy0 weight 1 nexthop via 172.16.1.3 dev dummy1 weight 1 $ip route get 10.0.14.2 10.0.14.2 via 172.16.1.3 dev dummy1 src 172.16.1.1 cache $ip route get fibmatch 10.0.14.2 10.0.14.0/24 nexthop via 172.16.0.3 dev dummy0 weight 1 nexthop via 172.16.1.3 dev dummy1 weight 1 ipv6: ---- $ip -6 route show 2001:db9:100::/120 metric 1024 nexthop via 2001:db8:2::2 dev dummy0 weight 1 nexthop via 2001:db8:12::2 dev dummy1 weight 1 $ip -6 route get 2001:db9:100::1 2001:db9:100::1 from :: via 2001:db8:12::2 dev dummy1 src 2001:db8:12::1 metric 1024 pref medium $ip -6 route get fibmatch 2001:db9:100::1 2001:db9:100::/120 metric 1024 nexthop via 2001:db8:12::2 dev dummy1 weight 1 nexthop via 2001:db8:2::2 dev dummy0 weight 1 v2: - pick up new forward port of patch-01 from david - inet6_rtm_getroute: use container_of for rt6_info to dst conversion ==================== Signed-off-by: -
Roopa Prabhu authored
This patch adds support to return matched fib result when RTM_F_FIB_MATCH flag is specified in RTM_GETROUTE request. This is useful for user-space applications/controllers wanting to query a matching route. Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Roopa Prabhu authored
This patch adds support to return matched fib result when RTM_F_FIB_MATCH flag is specified in RTM_GETROUTE request. This is useful for user-space applications/controllers wanting to query a matching route. Signed-off-by:
-
Roopa Prabhu authored
This flag when specified will return matched fib result in response to a RTM_GETROUTE query. Signed-off-by:
-
