- 14 Dec, 2018 12 commits
-
-
Petr Machata authored
Test that attempts to change address in a way that violates Spectrum requirements are vetoed with extack. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Petr Machata authored
On NETDEV_PRE_CHANGEADDR, if the change is related to a RIF interface, verify that it satisfies the criterion that all RIF interfaces have the same MAC address prefix, as indicated by mlxsw_sp.mac_mask. Additionally, besides explicit address changes, check that the address of an interface for which a RIF is about to be added matches the required pattern as well. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
-
Petr Machata authored
The Spectrum hardware demands that all router interfaces in the system have the same first 38 resp. 36 bits of MAC address: the former limit holds on Spectrum, the latter on Spectrum-2. Add a field that refers to the required prefix mask and initialize in mlxsw_sp1_init() and mlxsw_sp2_init(). Signed-off-by:
-
Petr Machata authored
Prepare mlxsw_sp_netdevice_router_port_event() for handling of NETDEV_PRE_CHANGEADDR. Split out the part that deals with the actual changes and call it for the two events currently handled. Signed-off-by:
-
Petr Machata authored
Give interested parties an opportunity to veto an impending HW address change. Signed-off-by:
-
Petr Machata authored
Before NETDEV_CHANGEADDR, bond driver should emit NETDEV_PRE_CHANGEADDR, and allow consumers to veto the address change. To propagate further the return code from NETDEV_PRE_CHANGEADDR, give the function that implements address change a return value. Signed-off-by:
-
Petr Machata authored
A NETDEV_CHANGEADDR event implies a change of address of each of the IPVLANs of this IPVLAN device. Therefore propagate NETDEV_PRE_CHANGEADDR to all the IPVLANs. Signed-off-by:
-
Petr Machata authored
When a port device seeks approval of a potential new MAC address, make sure that should the bridge device end up using this address, all interested parties would agree with it. Signed-off-by:
-
Petr Machata authored
When a port is attached to a bridge, the address of the bridge in question may change as well. Even if it would not change at this point (because the current bridge address is lower), it might end up changing later as a result of detach of another port, which can't be vetoed. Therefore issue NETDEV_PRE_CHANGEADDR regardless of whether the address will be used at this point or not, and make sure all involved parties would agree with the change. Signed-off-by:
-
Petr Machata authored
When a device address is about to be changed, or an address added to the list of device HW addresses, it is necessary to ensure that all interested parties can support the address. Therefore, send the NETDEV_PRE_CHANGEADDR notification, and if anyone bails on it, do not change the address. Signed-off-by:
-
Petr Machata authored
The NETDEV_CHANGEADDR notification is emitted after a device address changes. Extending this message to allow vetoing is certainly possible, but several other notification types have instead adopted a simple two-stage approach: first a "pre" notification is sent to make sure all interested parties are OK with a change that's about to be done. Then the change is done, and afterwards a "post" notification is sent. This dual approach is easier to use: when the change is vetoed, nothing has changed yet, and it's therefore unnecessary to roll anything back. Therefore adopt it for NETDEV_CHANGEADDR as well. To that end, add NETDEV_PRE_CHANGEADDR and an info structure to go along with it. Signed-off-by:
-
Petr Machata authored
A follow-up patch will add a notifier type NETDEV_PRE_CHANGEADDR, which allows vetoing of MAC address changes. One prominent path to that notification is through dev_set_mac_address(). Therefore give this function an extack argument, so that it can be packed together with the notification. Thus a textual reason for rejection (or a warning) can be communicated back to the user. Signed-off-by:
-
- 13 Dec, 2018 15 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5e-updates-2018-12-11 From Eli Britstein, Patches 1-10 adds remote mirroring support. Patches 1-4 refactor encap related code as pre-steps for using per destination encapsulation properties. Patches 5-7 use extended destination feature for single/multi destination scenarios that have a single encap destination. Patches 8-10 enable multiple encap destinations for a TC flow. From, Daniel Jurgens, Patch 11, Use CQE padding for Ethernet CQs, PPC showed up to a 24% improvement in small packet throughput From Eyal Davidovich, patches 12-14, FW monitor counter support FW monitor counters feature came to solve the delayed reporting of FW stats in the atomic get_stats64 ndo, since we can't access the FW at that stage, this feature will enable immediate FW stats updates in the driver via fw events on specific stats updates. Patch 12, cleanup to avoid querying a FW counter when it is not supported Patch 13, Monitor counters FW commands support Patch 14, Use monitor counters in ethernet netdevice to update FW stats reported in the atomic get_stats64 ndo. ==================== Signed-off-by: -
Biao Huang authored
Add MODULE_LICENSE info to fix this: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.o Signed-off-by:
Biao Huang <biao.huang@mediatek.com> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_vport_rep_load': drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1490:21: warning: variable 'upriv' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_vport_rep_unload': drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1557:21: warning: variable 'upriv' set but not used [-Wunused-but-set-variable] It not used any more since commit ef381359 ("net/mlx5e: Replace egdev with indirect block notifications"). Also remove unused variable 'uplink_rpriv' after this change. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== Pass extack to SWITCHDEV_PORT_OBJ_ADD Drivers may need to do validation as a result of port object addition. An example is mlxsw, which needs to check the configuration of a VXLAN device attached to an offloaded bridge. Without a mapped VLAN, the invalidity of the device is not important, but as soon as a pvid, untagged VLAN is configured for the device, it has to be validated and offloaded. Should the validation fail, there's currently no way to communicate details of the failure to the user, beyond an error number. Because currently, extack is not available at all in that area of code, this patch starts down at the RTNL level and progresses up towards the driver(s). In patch #1, ndo_bridge_setlink is updated to include extack, and callbacks of all clients are updated as well (ignoring the argument). In patch #2, the bridge driver is updated to propagate the extack through to the switchdev border, br_switchdev_port_vlan_add(). Patches #3, #4 and #5 then gradually extend switchdev to pass the extack argument through to the switchdev blocking notifier chain. Patches #6 and #7 then update mlxsw to pass the extack argument from VXLAN events resp. port events on to mlxsw_sp_bridge_8021q_vxlan_join(). Finally in patches #8 and #9, the code paths from the previous two patches are verified to yield an error message. v2: - Patch #1: - In ndo_bridge_setlink(), keep the whole extack declaration on the same line. ==================== Signed-off-by: -
Petr Machata authored
Test mapping a VLAN at a port device such that on the same VLAN, there already is an unoffloadable VXLAN device. Signed-off-by:
-
Petr Machata authored
Test mapping a VLAN at a VXLAN device that can't be offloaded. Signed-off-by:
-
Petr Machata authored
After switchdev_handle_port_obj_add() was extended in a preceding patch, mlxsw_sp_port_obj_add() now takes an extack argument. Propagate it further by extending a callee chain from mlxsw_sp_port_vlans_add(), via mlxsw_sp_bridge_port_vlan_add() via mlxsw_sp_port_vlan_bridge_join() via mlxsw_sp_port_vlan_fid_join() to mlxsw_sp_bridge_ops.fid_get, adding an extack argument for each of them. This code path is used when a VLAN is added to a port netdevice if there already is an unoffloadable VXLAN device with that VLAN mapped. mlxsw_sp_bridge_8021d_port_join() is updated to obey the new interfaces changed by the abovementioned code, propagating extack ultimately from NETDEV_CHANGEUPPER events. Signed-off-by:
-
Petr Machata authored
Now that VLAN port object addition notifications carry an extack, propagate it from mlxsw_sp_switchdev_vxlan_vlans_add() through mlxsw_sp_switchdev_vxlan_vlan_add() to mlxsw_sp_bridge_8021q_vxlan_join(). This code path is used when a VLAN is added to a VXLAN netdevice that cannot be offloaded. Signed-off-by:
-
Petr Machata authored
Drivers use switchdev_handle_port_obj_add() to handle recursive descent through lower devices. Change this function prototype to take add_cb that itself takes an extack argument. Decode extack from switchdev_notifier_port_obj_info and pass it to add_cb. Update mlxsw and ocelot drivers which use this helper. Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Reviewed-by:
-
Petr Machata authored
In order to pass extack to the drivers that need it, add an extack field to struct switchdev_notifier_info, and an extack argument to the function call_switchdev_blocking_notifiers(). Also add a helper function switchdev_notifier_info_to_extack(). Signed-off-by:
-
Petr Machata authored
After the previous patch, bridge driver has extack argument available to pass to switchdev. Therefore extend switchdev_port_obj_add() with this argument, updating all callers, and passing the argument through to switchdev_port_obj_notify(). Signed-off-by:
-
Petr Machata authored
ndo_bridge_setlink has been updated in the previous patch to have extack available, and changelink RTNL op has had this argument since the time extack was added. Propagate both through the bridge driver to eventually reach br_switchdev_port_vlan_add(), where it will be used by subsequent patches. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by:
-
Petr Machata authored
Drivers may not be able to implement a VLAN addition or reconfiguration. In those cases it's desirable to explain to the user that it was rejected (and why). To that end, add extack argument to ndo_bridge_setlink. Adapt all users to that change. Following patches will use the new argument in the bridge driver. Signed-off-by:
-
Jonathan Toppins authored
bnxt_en 0000:19:00.0 (unregistered net_device) (uninitialized): hwrm req_type 0x190 seq id 0x6 error 0xffff The message above is commonly seen when a newer driver is used on hardware with older firmware. The issue is this message means nothing to anyone except Broadcom. Remove the message to not confuse users as this message is really not very informative. Signed-off-by:
Jonathan Toppins <jtoppins@redhat.com> Acked-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
- 12 Dec, 2018 13 commits
-
-
David S. Miller authored
Biao Huang says: ==================== add Ethernet driver support for mt2712 Changes in v6: modifications according to comments from Rob/Andrew/Sean: 1. use delay_ps instead of delay stage. 2. add comments in driver to avoid confusion. 2. rewrite set_delay function. 3. modify binding document for properties: tx-delay-ps/rx-delay-ps/pericfg etc. ==================== Signed-off-by: -
Biao Huang authored
The commit adds the device tree binding documentation for the MediaTek DWMAC found on MediaTek MT2712. Signed-off-by:
-
Biao Huang authored
Add Ethernet support for MediaTek SoCs from the mt2712 family Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Add Spectrum-2 multicast routing support Nir says: In Spectrum the firmware provided an abstraction for multicast routing on top of the policy engine. In Spectrum-2 this is no longer the case and the driver must interact directly with the policy engine in order to program multicast routes. Every route is written as an ACL rule, its priority set according to route type (*,G) or (S,G) and its action is an appropriate multicast routing action. Multicast routes are written to a specific ACL group which is bound to the appropriate IP protocol IPv4/IPv6. Patch #1 adds PEMRBT register needed to declare which ACL group is dedicated for each IP protocol multicast routing function. Patch #2 Changes initialization order and puts ACL before router as multicast router now uses ACL module. Patch #3 adds Spectrum-2 ACL keys needed for multicast route matching. Patch #4 adds another ACL profile - in addition to existing flower profile - which allows the multicast routing module to program rules directly into the ACL block. Patch #5 adds the ability to update ACL rules' action, since multicast routes actions may be updated after being configured. Patch #6 separates rule creation operation and rule action creation operation as in multicast router the action is created before the route is inserted. Patch #7 sharpens priority handling in Spectrum-2, to ensure incorrect values are not set to rule's priority. Patch #8 adds the implementation of multicast routing for IPv4 and IPv6 over existing ACL rule programming Finally, patch #9 adds a test for IPv4/IPv6 multicast routing. ==================== Signed-off-by: -
Nir Dotan authored
Introduce basic testing for both IPv4 and IPv6 multicast. The test creates an (S,G) type route, sends traffic and verifies traffic arrives when the route is present and then verifies traffic does not arrive after deleting the route. This test requires smcroute - https://github.com/troglobit/smcroute which is a tool that allows creation of static multicast routes. Signed-off-by:
Nir Dotan <nird@mellanox.com> Signed-off-by:
-
Nir Dotan authored
Add implementation of Spectrum-2 multicast routes for both IPv4 and IPv6 by using ACL module explicitly. In Spectrum-2, multicast routes are set as ACL rules, so initialization takes care of creating dedicated ACL groups and binding them to the appropriate multicast routing protocol IPv4/IPv6, and afterwards routes configuration translates to setting explicit ACL rules. Signed-off-by:
-
Nir Dotan authored
In Spectrum-2, higher priority value wins and priority valid values are in the range of {1,cap_kvd_size-1}. mlxsw_sp_acl_tcam_priority_get converts from lower-bound priorities alike tc flower to Spectrum-2 HW range. Up until now tc flower did not provide priority 0 or reached the maximal value, however multicast routing does provide priority 0. Therefore, Change mlxsw_sp_acl_tcam_priority_get to verify priority is in the correct range. Make sure priority is never set to zero and never exceeds the maximal allowed value. Signed-off-by: -
Nir Dotan authored
Up until now, when ACL rule was created its action was created with it. It suits well for tc flower where ACL rule always needs an action, however it does not suit multicast router, where the action is created prior to setting a route, which in Spectrum-2 is actually an ACL rule. Add support for rule creation without action creation. Do it by adding afa_block argument to mlxsw_sp_acl_rule_create, which if NULL then an action would be created, also add an indication within struct mlxsw_sp_acl_rule_info that tells if the action should be destroyed when the rule is destroyed. Signed-off-by:
-
Nir Dotan authored
Multicast routes actions may be updated after creation. An example for that is an addition of an egress interface to an existing route. So far, as tc flower API dictated, ACL rules were either created or deleted. Since multicast routes in Spectrum-2 are written to ACL as any rule, it is required to allow the update of a rule's action as it may change. Add methods and operations to support updating rule's action. This is supported only for Spectrum-2. Signed-off-by:
-
Nir Dotan authored
Add specific ACL operations needed for programming multicast routing ACL groups and routes. Signed-off-by:
-
Nir Dotan authored
Add virtual router ID fields to Spectrum-2 key blocks set, as the field is required for multicast routing. Signed-off-by:
-
Nir Dotan authored
In Spectrum-2, MC routing is implemented using ACL block explicitly, so router initialization should take place after ACL initialization. Set the initialization of the ACL block before IP router initizalization takes place, so multicast router will be able to allocate ACL data structures and create its required chains. Signed-off-by:
-
Nir Dotan authored
In Spectrum-2, multicast routing is implemented explicitly using policy engine (ACL) block. PEMRBT register is used to bind a dedicated ACL group to a specific IP protocol. Add the register to be later used in multicast router implementation. Signed-off-by:
-
