- 21 Jun, 2020 16 commits
-
-
Vladimir Oltean authored
Access Control Lists (and their respective Access Control Entries) are specifically entries in the VCAP IS2, the security enforcement block, according to the documentation. Let's rename the files that deal with generic operations on the VCAP TCAM, so that VCAP IS1 and ES0 can reuse the same code without confusion. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The ocelot hardware library shouldn't contain too much net_device specific code, since it is shared with DSA which abstracts that structure away. So much as much of this code as possible into the mscc_ocelot driver and outside of the common library. We're making an exception for MDB and LAG code. That is not yet exported to DSA, but when it will, most of the code that's already in ocelot.c will remain there. So, there's no point in moving code to ocelot_net.c just to move it back later. We could have moved all net_device code to ocelot_vsc7514.c directly, but let's operate under the assumption that if a new switchdev ocelot driver gets added, it'll define its SoC-specific stuff in a new ocelot_vsc*.c file and it'll reuse the rest of the code. Signed-off-by:
-
Vladimir Oltean authored
ocelot_regs.c actually shouldn't be part of the common library. It describes the register map of the VSC7514 switch. The way ocelot switches work, they'll have highly optimized register maps, so another SoC will likely have the same registers but laid out completely different in memory (so there's little room for reusing this structure). So move it to ocelot_vsc7514.c instead. Signed-off-by:
-
Vladimir Oltean authored
Putting 'ocelot' in the config's name twice just to say that 'it's the ocelot driver running on the ocelot SoC' is a bit confusing. Instead, it's just the ocelot driver. Now that we've renamed the previous symbol that was holding the MSCC_OCELOT_SWITCH_OCELOT into *_LIB (because that's what it is), we're free to use this name for the driver. Signed-off-by:
-
Vladimir Oltean authored
Hide the CONFIG_MSCC_OCELOT_SWITCH option from users. It is meant to be only a hardware library which is selected by the drivers that use it (ocelot, felix). Since it is "selected" from Kconfig, all its dependencies are manually transferred to the driver that selects it. This is because "select" in Kconfig language is a bit of a mess, and doesn't handle dependencies of selected options quite right. Signed-off-by:
-
Vladimir Oltean authored
mscc_ocelot is a slightly better name for a module than ocelot_board or ocelot_vsc7514 is, so let's use that. Signed-off-by:
-
Vladimir Oltean authored
To follow the model of felix and seville where we have one platform-specific file, rename this file to the actual SoC it serves. Signed-off-by:
-
Vladimir Oltean authored
Get rid of sparse "cast to restricted __be16" warnings. Signed-off-by:
-
Vladimir Oltean authored
sparse is rightfully complaining about the fact that: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 26 | __builtin_constant_p((l) > (h)), (l) > (h), 0))) | ^ note: in expansion of macro ‘GENMASK_INPUT_CHECK’ 39 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) | ^~~~~~~~~~~~~~~~~~~ note: in expansion of macro ‘GENMASK’ 127 | mask = GENMASK(width, 0); | ^~~~~~~ So replace the variables that go into GENMASK with plain, signed integer types. Signed-off-by: -
Vladimir Oltean authored
Get rid of some sparse warnings. Signed-off-by:
-
David S. Miller authored
Andrea Mayer says: ==================== Strict mode for VRF This patch set adds the new "strict mode" functionality to the Virtual Routing and Forwarding infrastructure (VRF). Hereafter we discuss the requirements and the main features of the "strict mode" for VRF. On VRF creation, it is necessary to specify the associated routing table used during the lookup operations. Currently, there is no mechanism that avoids creating multiple VRFs sharing the same routing table. In other words, it is not possible to force a one-to-one relationship between a specific VRF and the table associated with it. The "strict mode" imposes that each VRF can be associated to a routing table only if such routing table is not already in use by any other VRF. In particular, the strict mode ensures that: 1) given a specific routing table, the VRF (if exists) is uniquely identified; 2) given a specific VRF, the related table is not shared with any other VRF. Constraints (1) and (2) force a one-to-one relationship between each VRF and the corresponding routing table. The strict mode feature is designed to be network-namespace aware and it can be directly enabled/disabled acting on the "strict_mode" parameter. Read and write operations are carried out through the classic sysctl command on net.vrf.strict_mode path, i.e: sysctl -w net.vrf.strict_mode=1. Only two distinct values {0,1} are accepted by the strict_mode parameter: - with strict_mode=0, multiple VRFs can be associated with the same table. This is the (legacy) default kernel behavior, the same that we experience when the strict mode patch set is not applied; - with strict_mode=1, the one-to-one relationship between the VRFs and the associated tables is guaranteed. In this configuration, the creation of a VRF which refers to a routing table already associated with another VRF fails and the error is returned to the user. The kernel keeps track of the associations between a VRF and the routing table during the VRF setup, in the "management" plane. Therefore, the strict mode does not impact the performance or the intrinsic functionality of the data plane in any way. When the strict mode is active it is always possible to disable the strict mode, while the reverse operation is not always allowed. Setting the strict_mode parameter to 0 is equivalent to removing the one-to-one constraint between any single VRF and its associated routing table. Conversely, if the strict mode is disabled and there are multiple VRFs that refer to the same routing table, then it is prohibited to set the strict_mode parameter to 1. In this configuration, any attempt to perform the operation will lead to an error and it will be reported to the user. To enable strict mode once again (by setting the strict_mode parameter to 1), you must first remove all the VRFs that share common tables. There are several use cases which can take advantage from the introduction of the strict mode feature. In particular, the strict mode allows us to: i) guarantee the proper functioning of some applications which deal with routing protocols; ii) perform some tunneling decap operations which require to use specific routing tables for segregating and forwarding the traffic. Considering (i), the creation of different VRFs that point to the same table leads to the situation where two different routing entities believe they have exclusive access to the same table. This leads to the situation where different routing daemons can conflict for gaining routes control due to overlapping tables. By enabling strict mode it is possible to prevent this situation which often occurs due to incorrect configurations done by the users. The ability to enable/disable the strict mode functionality does not depend on the tool used for configuring the networking. In essence, the strict mode patch solves, at the kernel level, what some other patches [1] had tried to solve at the userspace level (using only iproute2) with all the related problems. Considering (ii), the introduction of the strict mode functionality allows us implementing the SRv6 End.DT4 behavior. Such behavior terminates a SR tunnel and it forwards the IPv4 traffic according to the routes present in the routing table supplied during the configuration. The SRv6 End.DT4 can be realized exploiting the routing capabilities made available by the VRF infrastructure. This behavior could leverage a specific VRF for forcing the traffic to be forwarded in accordance with the routes available in the VRF table. Anyway, in order to make the End.DT4 properly work, it must be guaranteed that the table used for the route lookup operations is bound to one and only one VRF. In this way, it is possible to use the table for uniquely retrieving the associated VRF and for routing packets. I would like to thank David Ahern for his constant and valuable support during the design and development phases of this patch set. Comments, suggestions and improvements are very welcome! ==================== Acked-by:David Ahern <dsahern@gmail.com> Signed-off-by:
-
Andrea Mayer authored
The new strict mode functionality is tested in different configurations and on different network namespaces. Signed-off-by:
Andrea Mayer <andrea.mayer@uniroma2.it> Signed-off-by:
-
Andrea Mayer authored
During the initialization phase of the VRF module, the callback for table to VRF device lookup is registered in l3mdev. Signed-off-by:
-
Andrea Mayer authored
Add net.vrf.strict_mode sysctl parameter. When net.vrf.strict_mode=0 (default) it is possible to associate multiple VRF devices to the same table. Conversely, when net.vrf.strict_mode=1 a table can be associated to a single VRF device. When switching from net.vrf.strict_mode=0 to net.vrf.strict_mode=1, a check is performed to verify that all tables have at most one VRF associated, otherwise the switch is not allowed. The net.vrf.strict_mode parameter is per network namespace. Signed-off-by:
-
Andrea Mayer authored
Add the data structures and the processing logic to keep track of the associations between VRF devices and routing tables. When a VRF is instantiated, it needs to refer to a given routing table. For each table, we explicitly keep track of the existing VRFs that refer to the table. Signed-off-by:
-
Andrea Mayer authored
Add infrastructure to l3mdev (the core code for Layer 3 master devices) in order to find out the corresponding VRF device for a given table id. Therefore, the l3mdev implementations: - can register a callback that returns the device index of the l3mdev associated with a given table id; - can offer the lookup function (table to VRF device). Signed-off-by:
-
- 20 Jun, 2020 13 commits
-
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. Also, remove unnecessary variable _size_. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== Clause 45 PHY probing improvements Last time this series was posted back in May, Florian reviewed the patches, which was the only feedback I received. I'm now posting them without the RFC tag. This series aims to improve the probing for Clause 45 PHYs. The first four patches clean up get_phy_device() and called functions, updating the kernel doc, adding information about the various error return values. We then provide better kerneldoc for get_phy_device(), describing what is going on, and more importantly what the various return codes mean. Patch 6 adds support for probing MMDs >= 8 to check for their presence. Patch 7 changes get_phy_c45_ids() to only set the returned devices_in_package if we successfully find a PHY. Patch 8 splits the use of "devices in package" from the "mmds present". Patch 9 expands our ID reading to cover the other MMDs. ==================== Signed-off-by: -
Russell King authored
Expand the device_ids[] array to allow all MMD IDs to be read rather than just the first 8 MMDs, but only read the ID if the MDIO_STAT2 register reports that a device really is present here for these new devices to maintain compatibility with our current behaviour. Note that only a limited number of devices have MDIO_STAT2. 88X3310 PHY vendor MMDs do are marked as present in the devices_in_package, but do not contain IEE 802.3 compatible register sets in their lower space. This avoids reading incorrect values as MMD identifiers. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King authored
We have two competing requirements for the devices_in_package field. We want to use it as a bit array indicating which MMDs are present, but we also want to know if the Clause 22 registers are present. Since "devices in package" is a term used in the 802.3 specification, keep this as the as-specified values read from the PHY, and introduce a new member "mmds_present" to indicate which MMDs are actually present in the PHY, derived from the "devices in package" value. Reviewed-by:
-
Russell King authored
Only set the devices_in_package to a non-zero value if we find a valid value for this field, so we avoid leaving it set to e.g. 0x1fffffff. Reviewed-by:
-
Russell King authored
Add support for probing MMDs above 7 for a valid devices-in-package specifier, but only probe the vendor MMDs for this if they also report that there the device is present in status register 2. This avoids issues where the MMD is implemented, but does not provide IEEE 802.3 compliant registers (such as the MV88X3310 PHY.) Reviewed-by:
-
Russell King authored
Reword the get_phy_device() kerneldoc to be more explicit about how we probe for the PHY, and what the various return conditions signify. Reviewed-by:
-
Russell King authored
Move the ID check from get_phy_device() into get_phy_c22_id(), which simplifies get_phy_device(). The ID reading functions are now responsible for indicating whether they found a PHY or not via their return code - they must return -ENODEV when a PHY is not present. Reviewed-by:
-
Russell King authored
When we decide that a PHY is not present, we do not need to go through the hoops of setting *phy_id to 0xffffffff, and then return zero to make get_phy_device() fail - we can return -ENODEV which will have the same effect. Doing so means we no longer have to pass a pointer to phy_id in, and we can then clean up the clause 22 path in a similar way. Reviewed-by:
-
Russell King authored
Rearrange the code to read the PHY IDs, so we don't call get_phy_id() only to immediately call get_phy_c45_ids(). Move that logic into get_phy_device(), which results in better readability. Reviewed-by:
-
Russell King authored
Move the Cortina PHY workaround out of the "devices in package" loop; it doesn't need to be in there as the control flow will terminate the loop once we enter the workaround irrespective of the workaround's outcome. The workaround is triggered by the ID being mostly 1's, which will in any case terminate the loop. Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by:
-
- 19 Jun, 2020 11 commits
-
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. Also, remove unnecessary variable _size_. This code was detected with the help of Coccinelle and, audited and fixed manually. Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83Signed-off-by:
-
Eric Dumazet authored
If IPv6 is builtin, we do not need an expensive indirect call to reach icmp6_send(). v2: put inline keyword before the type to avoid sparse warnings. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David S. Miller authored
Vishal Kulkarni says: ==================== cxgb4: add support for ethtool n-tuple filters Patch 1: Adds data structure to maintain list of filters and handles init/dinit of the same. Patch 2: Handles addition of filters via ETHTOOL_SRXCLSRLINS. Patch 3: Handles deletion of filtes via ETHTOOL_SRXCLSRLDEL. Patch 4: Handles viewing of added filters. Patch 5: Adds FLOW_ACTION_QUEUE support. ==================== Signed-off-by: -
Vishal Kulkarni authored
Add support for queue action to steer Rx traffic hitting the flows to specified Rxq. Signed-off-by:
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by:
Vishal Kulkarni <vishal@chelsio.com> Signed-off-by:
-
Vishal Kulkarni authored
Add support to fetch the requested ethtool n-tuple filters by translating them from hardware spec to ethtool n-tuple spec. Signed-off-by:
-
Vishal Kulkarni authored
Add support to delete ethtool n-tuple filter. Fetch the appropriate filter region (HPFILTER, HASH, NORMAL) in which the filter exists, and delete it from the respective region, accordingly. Signed-off-by:
-
Vishal Kulkarni authored
Add support to parse and insert ethtool n-tuple filters. Translate n-tuple spec to flow spec and use the existing tc-flower offload infra to insert ethtool n-tuple filters. Signed-off-by:
-
Vishal Kulkarni authored
Allocate and manage resources required for ethtool n-tuple filters. Also fetch the HASH filter region size and calculate nhash entries. Signed-off-by:
-
Po Liu authored
This patch adds a drop frames counter to tc flower offloading. Reporting h/w dropped frames is necessary for some actions. Some actions like police action and the coming introduced stream gate action would produce dropped frames which is necessary for user. Status update shows how many filtered packets increasing and how many dropped in those packets. v2: Changes - Update commit comments suggest by Jiri Pirko. Signed-off-by:
Po Liu <Po.Liu@nxp.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Reviewed-by:
Vlad Buslov <vladbu@mellanox.com> Signed-off-by:
-
