- 05 Mar, 2020 1 commit
-
-
Taehee Yoo authored
In the current rmnet code, there is no module alias. So, RTNL couldn't load rmnet module automatically. Test commands: ip link add dummy0 type dummy modprobe -rv rmnet ip link add rmnet0 link dummy0 type rmnet mux_id 1 Signed-off-by:Taehee Yoo <ap420073@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 04 Mar, 2020 39 commits
-
-
David S. Miller authored
Russell King says: ==================== marvell10g tunable and power saving support This patch series adds support for: - mdix configuration (auto, mdi, mdix) - energy detect power down (edpd) - placing in edpd mode at probe for both the 88x3310 and 88x2110 PHYs. Antione, could you test this for the 88x2110 PHY please? v3: fix return code in get_tunable/set_tunable v2: fix comments from Antione. ==================== Tested-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Russell King authored
Place the 88x3310 into powersaving mode when probing, which saves 600mW per PHY. For both PHYs on the Macchiatobin double-shot, this saves about 10% of the board idle power. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King authored
Add support for the energy detect power down tunable, which saves around 600mW when the link is down. The 88x3310 supports off, rx-only and NLP every second. Enable EDPD by default for 88x3310. Signed-off-by:
-
Russell King authored
Add support for controlling the MDI-X state of the PHY. Signed-off-by:
-
David S. Miller authored
Merge branch 'PCI-Add-and-use-constant-PCI_STATUS_ERROR_BITS-and-helper-pci_status_get_and_clear_errors' Heiner Kallweit says: ==================== PCI: Add and use constant PCI_STATUS_ERROR_BITS and helper pci_status_get_and_clear_errors Several drivers have own definitions for this constant, so move it to the PCI core. In addition in multiple places the following code sequence is used: 1. Read PCI_STATUS 2. Mask out non-error bits 3. Action based on set error bits 4. Write back set error bits to clear them As this is a repeated pattern, add a helper to the PCI core. Most affected drivers are network drivers. But as it's about core PCI functionality, I suppose the series should go through the PCI tree. v2: - fix formal issue with cover letter v3: - fix dumb typo in patch 7 v4: - add patches 1-3 - move new constant PCI_STATUS_ERROR_BITS to include/linux/pci.h - small improvements in commit messages ==================== Signed-off-by: -
Heiner Kallweit authored
Use new helper pci_status_get_and_clear_errors() to simplify the code. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Use new constant PCI_STATUS_ERROR_BITS to simplify the code. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Heiner Kallweit authored
Use new PCI core constant PCI_STATUS_ERROR_BITS to simplify the code. Signed-off-by:
-
Heiner Kallweit authored
Use new helper pci_status_get_and_clear_errors() to simplify the code. Signed-off-by:
-
Heiner Kallweit authored
Use new helper pci_status_get_and_clear_errors() to simplify the code. Signed-off-by:
-
Heiner Kallweit authored
Several drivers use the following code sequence: 1. Read PCI_STATUS 2. Mask out non-error bits 3. Action based on error bits set 4. Write back set error bits to clear them As this is a repeated pattern, add a helper to the PCI core. Signed-off-by:
-
Heiner Kallweit authored
This collection of PCI error bits is used in more than one driver, so move it to the PCI core. Signed-off-by:
-
Heiner Kallweit authored
In preparation of factoring out PCI_STATUS error bit handling let drivers use the same collection of error bits. To facilitate bisecting we do this in a separate patch per affected driver. For the r8169 driver we have to add PCI_STATUS_PARITY to the error bits. Signed-off-by:
-
Heiner Kallweit authored
In preparation of factoring out PCI_STATUS error bit handling let drivers use the same collection of error bits. To facilitate bisecting we do this in a separate patch per affected driver. For the skfp driver we have to add PCI_STATUS_REC_TARGET_ABORT to the error bits. Signed-off-by:
-
Heiner Kallweit authored
In preparation of factoring out PCI_STATUS error bit handling let drivers use the same collection of error bits. To facilitate bisecting we do this in a separate patch per affected driver. For the Marvell drivers we have to add PCI_STATUS_SIG_TARGET_ABORT to the error bits. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Allow unknown unicast traffic to CPU for Felix DSA This is the continuation of the previous "[PATCH net-next] net: mscc: ocelot: Workaround to allow traffic to CPU in standalone mode": https://www.spinics.net/lists/netdev/msg631067.html Following the feedback received from Allan Nielsen, the Ocelot and Felix drivers were made to use the CPU port module in the same way (patch 1), and Felix was made to additionally allow unknown unicast frames towards the CPU port module (patch 2). ==================== Signed-off-by:
-
Vladimir Oltean authored
Compared to other DSA switches, in the Ocelot cores, the RX filtering is a much more important concern. Firstly, the primary use case for Ocelot is non-DSA, so there isn't any secondary Ethernet MAC [the DSA master's one] to implicitly drop frames having a DMAC we are not interested in. So the switch driver itself needs to install FDB entries towards the CPU port module (PGID_CPU) for the MAC address of each switch port, in each VLAN installed on the port. Every address that is not whitelisted is implicitly dropped. This is in order to achieve a behavior similar to N standalone net devices. Secondly, even in the secondary use case of DSA, such as illustrated by Felix with the NPI port mode, that secondary Ethernet MAC is present, but its RX filter is bypassed. This is because the DSA tags themselves are placed before Ethernet, so the DMAC that the switch ports see is not seen by the DSA master too (since it's shifter to the right). So RX filtering is pretty important. A good RX filter won't bother the CPU in case the switch port receives a frame that it's not interested in, and there exists no other line of defense. Ocelot is pretty strict when it comes to RX filtering: non-IP multicast and broadcast traffic is allowed to go to the CPU port module, but unknown unicast isn't. This means that traffic reception for any other MAC addresses than the ones configured on each switch port net device won't work. This includes use cases such as macvlan or bridging with a non-Ocelot (so-called "foreign") interface. But this seems to be fine for the scenarios that the Linux system embedded inside an Ocelot switch is intended for - it is simply not interested in unknown unicast traffic, as explained in Allan Nielsen's presentation [0]. On the other hand, the Felix DSA switch is integrated in more general-purpose Linux systems, so it can't afford to drop that sort of traffic in hardware, even if it will end up doing so later, in software. Actually, unknown unicast means more for Felix than it does for Ocelot. Felix doesn't attempt to perform the whitelisting of switch port MAC addresses towards PGID_CPU at all, mainly because it is too complicated to be feasible: while the MAC addresses are unique in Ocelot, by default in DSA all ports are equal and inherited from the DSA master. This adds into account the question of reference counting MAC addresses (delayed ocelot_mact_forget), not to mention reference counting for the VLAN IDs that those MAC addresses are installed in. This reference counting should be done in the DSA core, and the fact that it wasn't needed so far is due to the fact that the other DSA switches don't have the DSA tag placed before Ethernet, so the DSA master is able to whitelist the MAC addresses in hardware. So this means that even regular traffic termination on a Felix switch port happens through flooding (because neither Felix nor Ocelot learn source MAC addresses from CPU-injected frames). So far we've explained that whitelisting towards PGID_CPU: - helps to reduce the likelihood of spamming the CPU with frames it won't process very far anyway - is implemented in the ocelot driver - is sufficient for the ocelot use cases - is not feasible in DSA - breaks use cases in DSA, in the current status (whitelisting enabled but no MAC address whitelisted) So the proposed patch allows unknown unicast frames to be sent to the CPU port module. This is done for the Felix DSA driver only, as Ocelot seems to be happy without it. [0]: https://www.youtube.com/watch?v=B1HhxEcU7JgSuggested-by:
Allan W. Nielsen <allan.nielsen@microchip.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
Vladimir Oltean authored
Ocelot has the concept of a CPU port. The CPU port is represented in the forwarding and the queueing system, but it is not a physical device. The CPU port can either be accessed via register-based injection/extraction (which is the case of Ocelot), via Frame-DMA (similar to the first one), or "connected" to a physical Ethernet port (called NPI in the datasheet) which is the case of the Felix DSA switch. In Ocelot the CPU port is at index 11. In Felix the CPU port is at index 6. The CPU bit is treated special in the forwarding, as it is never cleared from the forwarding port mask (once added to it). Other than that, it is treated the same as a normal front port. Both Felix and Ocelot should use the CPU port in the same way. This means that Felix should not use the NPI port directly when forwarding to the CPU, but instead use the CPU port. This patch is fixing this such that Felix will use port 6 as its CPU port, and just use the NPI port to carry the traffic. Therefore, eliminate the "ocelot->cpu" variable which was holding the index of the NPI port for Felix, and the index of the CPU port module for Ocelot, so the variable was actually configuring different things for different drivers and causing at least part of the confusion. Also remove the "ocelot->num_cpu_ports" variable, which is the result of another confusion. The 2 CPU ports mentioned in the datasheet are because there are two frame extraction channels (register based or DMA based). This is of no relevance to the driver at the moment, and invisible to the analyzer module. Signed-off-by:
-
David S. Miller authored
Leslie Monis says: ==================== pie: minor improvements This patch series includes the following minor changes with respect to the PIE/FQ-PIE qdiscs: - Patch 1 removes some ambiguity by using the term "backlog" instead of "qlen" when referring to the queue length in bytes. - Patch 2 removes redundant type casting on two expressions. - Patch 3 removes the pie_vars->accu_prob_overflows variable without affecting the precision in calculations and makes the size of the pie_vars structure exactly 64 bytes. - Patch 4 realigns a comment affected by a change in patch 3. Changes from v1 to v2: - Kept 8 as the argument to prandom_bytes() instead of changing it to 7 as suggested by David Miller. ==================== Reviewed-by:Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Leslie Monis authored
Realign a comment after the change introduced by the previous patch. Signed-off-by:
Leslie Monis <lesliemonis@gmail.com> Signed-off-by:
-
Leslie Monis authored
The variable pie_vars->accu_prob is used as an accumulator for probability values. Since probabilty values are scaled using the MAX_PROB macro denoting (2^64 - 1), pie_vars->accu_prob is likely to overflow as it is of type u64. The variable pie_vars->accu_prob_overflows counts the number of times the variable pie_vars->accu_prob overflows. The MAX_PROB macro needs to be equal to at least (2^39 - 1) in order to do precise calculations without any underflow. Thus MAX_PROB can be reduced to (2^56 - 1) without affecting the precision in calculations drastically. Doing so will eliminate the need for the variable pie_vars->accu_prob_overflows as the variable pie_vars->accu_prob will never overflow. Removing the variable pie_vars->accu_prob_overflows also reduces the size of the structure pie_vars to exactly 64 bytes. Signed-off-by:
Mohit P. Tahiliani <tahiliani@nitk.edu.in> Signed-off-by:
Gautam Ramakrishnan <gautamramk@gmail.com> Signed-off-by:
-
Leslie Monis authored
In function pie_calculate_probability(), the variables alpha and beta are of type u64. The variables qdelay, qdelay_old and params->target are of type psched_time_t (which is also u64). The explicit type casting done when calculating the value for the variable delta is redundant and not required. Signed-off-by:
-
Leslie Monis authored
Remove ambiguity by using the term backlog instead of qlen when representing the queue length in bytes. Signed-off-by:
-
David S. Miller authored
Paul Blakey says: ==================== Fixes for tc act_ct software offload of established flows (diff v4->v6) v4 of the original patchset was accidentally merged while we moved ahead with v6 review. This two patches are the diff between v4 that was merged and v6 that was the final revision, which was acked by the community. ==================== Signed-off-by: -
Paul Blakey authored
To make the filler functions more generic, use network relative skb pulling. Signed-off-by:
Paul Blakey <paulb@mellanox.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Paul Blakey authored
When checking the protocol number tcf_ct_flow_table_lookup() handles the flow as if it's always ipv4, while it can be ipv6. Instead, refactor the code to fetch the tcp header, if available, in the relevant family (ipv4/ipv6) filler function, and do the check on the returned tcp header. Fixes: 46475bb2 ("net/sched: act_ct: Software offload of established flows") Signed-off-by:
-
Jakub Kicinski authored
Core already zeroes out the struct ethtool_coalesce structure, drivers don't have to set every field to 0 individually. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Wire up Ocelot tc-flower to Felix DSA This series is a proposal on how to wire up the tc-flower callbacks into DSA. The example taken is the Microchip Felix switch, whose core implementation is actually located in drivers/net/ethernet/mscc/. The proposal is largely a compromise solution. The DSA middle layer handles just enough to get to the interesting stuff (FLOW_CLS_REPLACE, FLOW_CLS_DESTROY, FLOW_CLS_STATS), but also thin enough to let drivers decide what filter keys and actions they support without worrying that the DSA middle layer will grow exponentially. I am far from being an expert, so I am asking reviewers to please voice your opinion if you think it can be done differently, with better results. The bulk of the work was actually refactoring the ocelot driver enough to allow the VCAP (Versatile Content-Aware Processor) code for vsc7514 and the vsc9959 switch cores to live together. Flow block offloads have not been tested yet, only filters attached to a single port. It might be as simple as replacing ocelot_ace_rule_create with something smarter, it might be more complicated, I haven't tried yet. I should point out that the tc-matchall filter offload is not implemented in the same manner in current mainline. Florian has already went all the way down into exposing actual per-action callbacks, starting with port mirroring. Because currently only mirred is supported by this DSA mid layer, everything else will return -EOPNOTSUPP. So even though ocelot supports matchall (aka port-based) policers, we don't have a call path to call into them. Personally I think that this is not going to scale for tc-matchall (there may be policers, traps, drops, VLAN retagging, etc etc), and that we should consider whether further matchall filter/action combinations should be just passed on to drivers with no interpretation instead. As for the existing mirroring callbacks in DSA, they can either be kept as-is, or replaced with simple accessors to TC_CLSMATCHALL_REPLACE and TC_CLSMATCHALL_DESTROY, just like for flower, and drivers which currently implement the port mirroring callbacks will need to have some extra "if" conditions now, in order for them to call their port mirroring implementations. ==================== Signed-off-by: -
Vladimir Oltean authored
Export the cls_flower methods from the ocelot driver and hook them up to the DSA passthrough layer. Tables for the VCAP IS2 parameters, as well as half key packing (field offsets and lengths) need to be defined for the VSC9959 core, as they are different from Ocelot, mainly due to the different port count. Signed-off-by:
-
Vladimir Oltean authored
Due to the immense variety of classification keys and actions available for tc-flower, as well as due to potentially very different DSA switch capabilities, it doesn't make a lot of sense for the DSA mid layer to even attempt to interpret these. So just pass them on to the underlying switch driver. DSA implements just the standard boilerplate for binding and unbinding flow blocks to ports, since nobody wants to deal with that. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Remove the definitions for the VCAP IS2 table from ocelot_ace.c, since it is specific to VSC7514. The VSC9959 VCAP IS2 table supports more rules (1024 instead of 64) and has a different width for the action (89 bits instead of 99). Signed-off-by:
-
Vladimir Oltean authored
The Felix driver is now using its own PHYLINK instance, not calling into ocelot_adjust_link. So the port_pcs_init function pointer is an unnecessary indirection. Remove it. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
-
Vladimir Oltean authored
The IGR_PORT_MASK key width is different between the 11-port VSC7514 and the 6-port VSC9959 switches. And since IGR_PORT_MASK is one of the first fields of a VCAP key entry, it means that all further field offset/length pairs are shifted between the 2. The ocelot driver performs packing of VCAP half keys with the help of some preprocessor macros: - A set of macros for defining the HKO (Half Key Offset) and HKL (Half Key Length) of each possible key field. The offset of each field is defined as the sum between the offset and the sum of the previous field. - A set of accessors on top of vcap_key_set for shorter (aka less typing) access to the HKO and HKL of each key field. Since the field offsets and lengths are different between switches, defining them through the preprocessor isn't going to fly. So introduce a structure holding (offset, length) pairs and instantiate it in ocelot_board.c for VSC7514. In a future patch, a similar structure will be instantiated in felix_vsc9959.c for NXP LS1028A. The accessors also need to go. They are based on macro name concatenation, which is horrible to understand and follow. Signed-off-by:
-
Vladimir Oltean authored
This is a cosmetic patch that makes the name of the driver private variable be used uniformly in ocelot_ace.c as in the rest of the driver. Signed-off-by:
-
Vladimir Oltean authored
There is no need to check the "ret" variable, one can just return the function result back to the caller. Signed-off-by:
-
Vladimir Oltean authored
The "ocelot_rule" variable name is both annoyingly long trying to distinguish itself from struct flow_rule *rule = flow_cls_offload_flow_rule(f), as well as actually different from the "ace" variable name which is used all over the place in ocelot_ace.c and is referring to the same structure. And the "rule" variable name is, confusingly, different from f->rule, but sometimes one has to look up to the beginning of the function to get an understanding of what structure type is actually being handled. So let's use the "ace" name wherever possible ("Access Control Entry"). Signed-off-by: -
Vladimir Oltean authored
The ocelot tc-flower offload binds a second flow block callback (apart from the one for matchall) just because it uses a different block private structure (ocelot_port_private for matchall, ocelot_port_block for flower). But ocelot_port_block just appears to be boilerplate, and doesn't help with anything in particular at all, it's just useless glue between the (global!) struct ocelot_acl_block *block pointer, and a per-netdevice struct ocelot_port_private *priv. So let's just simplify that, and make struct ocelot_port_private be the private structure for the block offload. This makes us able to use the same flow callback as in the case of matchall. This also reveals that the struct ocelot_acl_block *block is used rather strangely, as mentioned above: it is defined globally, allocated at probe time, and freed at unbind time. So just move the structure to the main ocelot structure, which gives further opportunity for simplification. Also get rid of backpointers from struct ocelot_acl_block and struct ocelot_ace_rule back to struct ocelot, by reworking the function prototypes, where necessary, to use a more DSA-friendly "struct ocelot *ocelot, int port" format. And finally, remove the debugging prints that were added during development, since they provide no useful information at this point. Signed-off-by:
-
Yangbo Lu authored
The ocelot_ace_rule is port specific now. Make it flexible to be able to support multiple ports too. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by:
-
David S. Miller authored
Leon Romanovsky says: ==================== Clean driver, module and FW versions This is second batch of the series which removes various static versions in favour of globaly defined Linux kernel version. The first part with better cover letter can be found here https://lore.kernel.org/lkml/20200224085311.460338-1-leon@kernel.org The code is based on 68e2c376 ("Merge branch 'hsr-several-code-cleanup-for-hsr-module'") and WIP branch is https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=ethtool ==================== Signed-off-by:
-
