- 04 Mar, 2020 40 commits
-
-
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 <vladimir.oltean@nxp.com> Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <vladimir.oltean@nxp.com> Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Allan W. Nielsen <allan.nielsen@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <vladimir.oltean@nxp.com> Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Allan W. Nielsen <allan.nielsen@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Allan W. Nielsen <allan.nielsen@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Allan W. Nielsen <allan.nielsen@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Rely on ethtool to properly present the fact that FW and bus are not available for the gianfar driver. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Rely on ethtool to properly present the fact that FW is not available for the ucc_geth driver. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Rely on ethtool to properly present the fact that FW is not available for the dpaa driver. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need to set static versions because linux kernel is released all together with same version applicable to the whole code base. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Use general linux kernel version instead of static driver version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Use general linux kernel version instead of static driver version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Remove driver version in favor of general linux kernel version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Remove static driver version from the ethtool output. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Convert dlink drivers to use linux kernel version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need in assignments of driver version while linux kernel is released as a monolith where the whole code base is aligned to one general version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Rely on global linux kernel version instead of static value. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Use default ethtool version instead of static variant. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need to overwrite global linux kernel version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need in static driver version, use global linux kernel version instead. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need to set N/A if FW is not available. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Clean the code related to various versions: driver and module. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need to set N/A for the ethtool fields. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Delete driver and module versions in favor of global linux kernel variant. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Size of LIQUIDIO_PACKAGE is 0 and it means that checks of package version never worked, delete dead code. Fixes: 32581245 ("liquidio: Consolidate common functionality") Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Drop driver version in favor of global to linux kernel version. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Remove driver and module version in favor of default one. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
There is no need to explicitly set N/A if FW not available. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Use linux kernel version for ethtool and module versions. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Bjorn Andersson says: ==================== net: qrtr: Nameserver fixes The need to respond to the HELLO message from the firmware was lost in the translation from the user space implementation of the nameserver. Fixing this also means we can remove the FIXME related to launching the ns. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjorn Andersson authored
The 2 second delay before calling qrtr_ns_init() meant that the remote processors would register as endpoints in qrtr and the say_hello() call would therefor broadcast the outgoing HELLO to them. With the HELLO handshake corrected this delay is no longer needed. Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjorn Andersson authored
Lost in the translation from the user space implementation was the detail that HELLO mesages must be exchanged between each node pair. As such the incoming HELLO must be replied to. Similar to the previous implementation no effort is made to prevent two Linux boxes from continuously sending HELLO messages back and forth, this is left to a follow up patch. say_hello() is moved, to facilitate the new call site. Fixes: 0c2204a4 ("net: qrtr: Migrate nameservice to kernel from userspace") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Petr Machata says: ==================== selftests: Use busywait() in a couple places Two helper function for active waiting for an event were recently introduced: busywait() as the active-waiting tool, and until_counter_is() as a configurable predicate that can be plugged into busywait(). Use these in tc_common and mlxsw's qos_defprio instead of hand-coding equivalents. Patches #1 and #2 extend lib.sh facilities to make the transition possible. Patch #3 converts tc_common, and patch #4 qos_defprio. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Instead of hand-coding the busywait() predicate, use the until_counter_is() introduced recently. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Amit Cohen <amitc@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
A function busywait() was recently added based on the logic in __tc_check_packets(). Convert the code in tc_common to use the new function. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Amit Cohen <amitc@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
until_counter_is() currently takes as an argument a number and the condition holds when the current counter value is >= that number. Make the function more generic by taking a partial expression instead of just the number. Convert the two existing users. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Amit Cohen <amitc@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
The function tc_rule_stats_get() fetches a given statistic of a TC rule given the rule preference. Another common way to reference a rule is using its handle. Introduce a dual to the aforementioned function that gets a statistic given rule handle. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Amit Cohen <amitc@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-