summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* net: vlan: suppress "failed to kill vid" warningsJulian Wiedmann2020-02-171-3/+2
| | | | | | | | | | | | | | | | | | | | When a real dev unregisters, vlan_device_event() also unregisters all of its vlan interfaces. For each VID this ends up in __vlan_vid_del(), which attempts to remove the VID from the real dev's VLAN filter. But the unregistering real dev might no longer be able to issue the required IOs, and return an error. Subsequently we raise a noisy warning msg that is not appropriate for this situation: the real dev is being torn down anyway, there shouldn't be any worry about cleanly releasing all of its HW-internal resources. So to avoid scaring innocent users, suppress this warning when the failed deletion happens on an unregistering device. While at it also convert the raw pr_warn() to a more fitting netdev_warn(). Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: stmmac: Get rid of custom STMMAC_DEVICE() macroAndy Shevchenko2020-02-171-20/+15
| | | | | | | | | | Since PCI core provides a generic PCI_DEVICE_DATA() macro, replace STMMAC_DEVICE() with former one. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'Remove-rtnl-lock-dependency-from-flow_action-infra'David S. Miller2020-02-178-27/+26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vlad Buslov says: ==================== Remove rtnl lock dependency from flow_action infra Currently, TC flow_action infrastructure code obtain rtnl lock before accessing action state in tc_setup_flow_action() function and releases it afterwards. This behavior is not supposed to impact TC filter insertion rate because filling flow_action representation is only a small part of creating new filter and expensive operations (hardware offload callbacks, classifiers, cls API code that creates chains and classifiers instances) already support unlocked execution. However, typical vswitch implementation might need to also dump TC filters concurrently, for example to age out unused flows or update flow counters. TC dump is fully serialized and holds rtnl lock during its whole execution in kernel space. As such, it can significantly impact concurrent tasks that try to intermittently obtain rtnl lock when filling intermediate representation for new filter offload (performance evaluation at the end of this mail). Refactor flow_action cls API infrastructure and its dependencies to not rely on rtnl lock for synchronization. Patch set overview: - Refactor tc_setup_flow_action() to obtain action tcf_lock when accessing action state. Fix its dependencies to not obtain tcf_lock themselves and assume that caller already holds it (needs to be done in same patch to prevent deadlock) and not to call sleeping functions (needs to be done in same patch to prevent "sleeping while atomic" dmesg warnings). - Refactor action helper functions to require tcf_lock instead of rtnl. Internally, all of the actions already use tcf_lock for synchronization to accommodate unlocked classifier API, so this change relies on already existing functionality. - Remove rtnl lock and "rtnl_held" argument from tc_setup_flow_action() function. To test the change, multiple concurrent TC instances are invoked with following command: time ls add* | xargs -n 1 -P 100 sudo tc -b Ten batch files with following typical rules (100k each) are used: filter add dev ens1f0_0 protocol ip ingress prio 1 handle 1 flower src_mac e4:11:0:0:0:0 dst_mac e4:12:0:0:0:0 src_ip 192.168.111.1 dst_ip 192.168.111.2 ip_proto udp dst_port 1 src_port 1 action tunnel_key set id 1 src_ip 2.2.2.2 dst_ip 2.2.2.3 dst_port 4789 no_percpu action mirred egress redirect dev vxlan1 no_percpu TC dump of same device is called in infinite loop from five concurrent instances: while true do tc -s filter show dev $NIC ingress >/dev/null done Results obtained on current net-next commit 9f68e3655aae ("Merge tag 'drm-next-2020-01-30' of git://anongit.freedesktop.org/drm/drm"): | net-next | this change ---------------+----------+------------- TC add | 6.3s | 6.3s TC add + dump | 29.3s | 6.8s Test results confirm significant impact of concurrent TC dump. The impact is almost fully mitigated by proposed change (differences can be attributed to contention for chain and tp locks between add and dump TC instances). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: sched: don't take rtnl lock during flow_action setupVlad Buslov2020-02-174-14/+6
| | | | | | | | | | | | | | | | | | Refactor tc_setup_flow_action() function not to use rtnl lock and remove 'rtnl_held' argument that is no longer needed. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: sched: refactor ct action helpers to require tcf_lockVlad Buslov2020-02-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to remove rtnl lock dependency from flow_action representation translator, change rtnl_dereference() to rcu_dereference_protected() in ct action helpers that provide external access to zone and action values. This is safe to do because the functions are not called from anywhere else outside flow_action infrastructure which was modified to obtain tcf_lock when accessing action data in one of previous patches in the series. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: sched: refactor police action helpers to require tcf_lockVlad Buslov2020-02-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to remove rtnl lock dependency from flow_action representation translator, change rcu_dereference_bh_rtnl() to rcu_dereference_protected() in police action helpers that provide external access to rate and burst values. This is safe to do because the functions are not called from anywhere else outside flow_action infrastructure which was modified to obtain tcf_lock when accessing action data in one of previous patches in the series. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: sched: lock action when translating it to flow_action infraVlad Buslov2020-02-173-9/+12
|/ | | | | | | | | | | | | | | | | | In order to remove dependency on rtnl lock, take action's tcfa_lock when constructing its representation as flow_action_entry structure. Refactor tcf_sample_get_group() to assume that caller holds tcf_lock and don't take it manually. This callback is only called from flow_action infra representation translator which now calls it with tcf_lock held, so this refactoring is necessary to prevent deadlock. Allocate memory with GFP_ATOMIC flag for ip_tunnel_info copy because tcf_tunnel_info_copy() is only called from flow_action representation infra code with tcf_lock spinlock taken. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'mvneta-xdp-ethtool-stats'David S. Miller2020-02-161-64/+163
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lorenzo Bianconi says: ==================== add xdp ethtool stats to mvneta driver Rework mvneta stats accounting in order to introduce xdp ethtool statistics in the mvneta driver. Introduce xdp_redirect, xdp_pass, xdp_drop and xdp_tx counters to ethtool statistics. Fix skb_alloc_error and refill_error ethtool accounting ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: mvneta: get rid of xdp_ret in mvneta_swbm_rx_frameLorenzo Bianconi2020-02-161-17/+13
| | | | | | | | | | | | | | | | Get rid of xdp_ret in mvneta_swbm_rx_frame routine since now we can rely on xdp_stats to flush in case of xdp_redirect Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: mvneta: introduce xdp counters to ethtoolLorenzo Bianconi2020-02-161-0/+45
| | | | | | | | | | | | | | | | Add xdp_redirect, xdp_pass, xdp_drop and xdp_tx counters to ethtool statistics Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: mvneta: rely on struct mvneta_stats in mvneta_update_stats routineLorenzo Bianconi2020-02-161-32/+41
| | | | | | | | | | | | | | | | | | | | Introduce mvneta_stats structure in mvneta_update_stats routine signature in order to collect all the rx stats and update them at the end at the napi loop. mvneta_stats will be reused adding xdp statistics support to ethtool. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: mvneta: rely on open-coding updating stats for non-xdp and tx pathLorenzo Bianconi2020-02-161-16/+24
| | | | | | | | | | | | | | | | | | | | In oreder to avoid unnecessary instructions rely on open-coding updating per-cpu stats in mvneta_tx/mvneta_xdp_submit_frame and mvneta_rx_hwbm routines. This patch will be used to add xdp support to ethtool for the mvneta driver Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: mvneta: move refill_err and skb_alloc_err in per-cpu statsLorenzo Bianconi2020-02-161-14/+55
|/ | | | | | | | | | | | | mvneta_ethtool_update_stats routine is currently reporting skb_alloc_error and refill_error only for the first rx queue. Fix the issue moving skb_alloc_err and refill_err in mvneta_pcpu_stats structure. Moreover this patch will be used to introduce xdp statistics to ethtool for the mvneta driver Fixes: 17a96da62716 ("net: mvneta: discriminate error cause for missed packet") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'mv88e6xxx-Add-SERDES-PCS-registers-to-ethtool-dump'David S. Miller2020-02-164-1/+118
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Andrew Lunn says: ==================== mv88e6xxx: Add SERDES/PCS registers to ethtool -d ethtool -d will dump the registers of an interface. For mv88e6xxx switch ports, this dump covers the port specific registers. Extend this with the SERDES/PCS registers, if a port has a SERDES. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: Add 6390 family PCS registers to ethtool -dAndrew Lunn2020-02-163-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | The mv88e6390 has upto 8 sets of PCS registers, depending on how ports 9 and 10 are configured. The can be spread over 8 ports. If a port has a PCS register set, return it along with the port registers. The register space is sparse, so hard code a list of registers which will be returned. It can later be extended, if needed, by append to the end of the list. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: Add 6352 family PCS registers to ethtool -dAndrew Lunn2020-02-163-0/+34
| | | | | | | | | | | | | | | | | | The mv88e6352 has one PCS which can be used for 1000BaseX or SGMII. Add the registers to the dump for the port which the PCS is associated to. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: Allow PCS registers to be retrieved via ethtoolAndrew Lunn2020-02-162-1/+16
|/ | | | | | | | | | ethtool provides a generic mechanism for a driver to return the registers of an ethernet device. DSA uses this to give the port registers associated with an interfaces. Extend this to allow PCS registers to also be returned, if the port has a PCS associated to it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '100GbE' of ↵David S. Miller2020-02-1615-198/+385
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2020-02-15 This series contains updates to ice driver only. Brett adds support for "Queue in Queue" (QinQ) support, by supporting S-tag & C-tag VLAN traffic by disabling pruning when there are no 0x8100 VLAN interfaces currently on top of the PF. Also refactored the port VLAN configuration to re-use the common code for enabling and disabling a port VLAN in single function. Added a helper function to determine if the VF link is up. Fixed how the port VLAN configures the priority bits for a VF interface. Fixed the port VLAN to only see its own broadcast and multicast traffic. Added support to enable and disable all receive queues, by refactoring adding a new function to do the necessary steps to enable/disable a queue with the necessary read flush. Fixed how we set the mapping mode for transmit and receive queues. Added support for VF queues to handle LAN overflow events. Fixed and refactored how receive queues get disabled for VFs, which was being handled one queue at at time, so improve it to handle when the VF is requesting more than one queue to be disabled. Fixed how the virtchnl_queue_select bitmap is validated. Finally a patch not authored by Brett, Bruce cleans up "fallthrough" comments which are unnecessary. Also replaces the "fallthough" comments with the GCC reserved word fallthrough, along with other GCC compiler fixes. Add missing function header comment regarding a function argument that was missing. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ice: use true/false for bool typesBruce Allan2020-02-151-1/+1
| | | | | | | | | | | | | | | | Subject says it all. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: add function argument description to function header commentBruce Allan2020-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | Commit 0290bd291cc0 ("netdev: pass the stuck queue to the timeout handler") introduced a new argument to the function but missed adding the description of the argument to the function header comment. Add it now. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: use proper format for function pointer as a function parameterBruce Allan2020-02-151-1/+1
| | | | | | | | | | | | | | | | | | Compiling with gcc-9.2.1 with W=1 points out warnings about the improper function parameter list. Fix it. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: replace "fallthrough" comments with fallthrough reserved wordBruce Allan2020-02-155-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "fallthrough" comments are used in switch case statements to explicitly indicate the code is intended to fall through to the following statement. Different variants of "fallthough" are acceptable, e.g. "fall through", "fallthrough", "Fall-through". The GCC compiler has an optional warning (-Wimplicit-fallthrough[=n]) to warn when such a comment is not present; the default version of which is enabled when compiling the Linux kernel. There have been recent discussions in kernel mailing lists regarding replacing non-standardized "fallthrough" comments with the pseudo-reserved word 'fallthrough' which will be defined as __attribute__ ((fallthrough)) for versions of gcc that support it (i.e. gcc 7 and newer) or as a nop for versions that do not. Replace "fallthrough" comments with fallthrough reserved word. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: remove unnecessary fallthrough commentsBruce Allan2020-02-156-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fallthrough comments are used to explicitly indicate the code is intended to flow from one case statement to the next in a switch statement rather than break out of the switch statement. They are only needed when a case has one or more statements to execute before falling through to the next case, not when there is a list of cases for which the same statement(s) should be executed. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Fix virtchnl_queue_select bitmap validationBrett Creeley2020-02-151-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in ice_vc_ena_qs_msg() we are incorrectly validating the virtchnl queue select bitmaps. The virtchnl_queue_select rx_queues and tx_queue bitmap is being compared against ICE_MAX_BASE_QS_PER_VF, but the problem is that these bitmaps can have a value greater than ICE_MAX_BASE_QS_PER_VF. Fix this by comparing the bitmaps against BIT(ICE_MAX_BASE_QS_PER_VF). Also, add the function ice_vc_validate_vqs_bitmaps() that checks to see if both virtchnl_queue_select bitmaps are empty along with checking that the bitmaps only have valid bits set. This function can then be used in both the queue enable and disable flows. Arkady Gilinksky's patch on the intel-wired-lan mailing list ("i40e/iavf: Fix msg interface between VF and PF") made me aware of this issue. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Fix and refactor Rx queue disable for VFsBrett Creeley2020-02-152-10/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when a VF driver sends the PF a request to disable Rx queues we will disable them one at a time, even if the VF driver sent us a batch of queues to disable. This is causing issues where the Rx queue disable times out with LFC enabled. This can be improved by detecting when the VF is trying to disable all of its queues. Also remove the variable num_qs_ena from the ice_vf structure as it was only used to see if there were no Rx and no Tx queues active. Instead add a function that checks if both the vf->rxq_ena and vf->txq_ena bitmaps are empty. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Handle LAN overflow event for VF queuesBrett Creeley2020-02-155-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we are not handling LAN overflow events. There can be cases where LAN overflow events occur on VF queues, especially with Link Flow Control (LFC) enabled on the controlling PF. In order to recover from the LAN overflow event caused by a VF we need to determine if the queue belongs to a VF and reset that VF accordingly. The struct ice_aqc_event_lan_overflow returns a copy of the GLDCB_RTCTQ register, which tells us what the queue index is in the global/device space. The global queue index needs to first be converted to a PF space queue index and then it can be used to find if a VF owns it. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Fix implicit queue mapping mode in ice_vsi_get_qsBrett Creeley2020-02-151-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in ice_vsi_get_qs() we set the mapping_mode for Tx and Rx to vsi->[tx|rx]_mapping_mode, but the problem is vsi->[tx|rx]_mapping_mode have not been set yet. This was working because ICE_VSI_MAP_CONTIG is defined to 0. Fix this by being explicit with our mapping mode by initializing the Tx and Rx structure's mapping_mode to ICE_VSI_MAP_CONTIG and then setting the vsi->[tx|rx]_mapping_mode to the [tx|rx]_qs_cfg.mapping_mode values. Also, only assign the vsi->[tx|rx]_mapping_mode when the queues are successfully mapped to the VSI. With this change there was no longer a need to initialize the ret variable to 0 so remove that. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Add support to enable/disable all Rx queues before waitingBrett Creeley2020-02-158-34/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when we enable/disable all Rx queues we do the following sequence for each Rx queue and then move to the next queue. 1. Enable/Disable the Rx queue via register write. 2. Read the configuration register to determine if the Rx queue was enabled/disabled successfully. In some cases enabling/disabling queue 0 fails because of step 2 above. Fix this by doing step 1 for all of the Rx queues and then step 2 for all of the Rx queues. Also, there are cases where we enable/disable a single queue (i.e. SR-IOV and XDP) so add a new function that does step 1 and 2 above with a read flush in between. This change also required a single Rx queue to be enabled/disabled with and without waiting for the change to propagate through hardware. Fix this by adding a boolean wait flag to the necessary functions. Also, add the keywords "one" and "all" to distinguish between enabling/disabling a single Rx queue and all Rx queues respectively. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Only allow tagged bcast/mcast traffic for VF in port VLANBrett Creeley2020-02-151-18/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the VF can see other's broadcast and multicast traffic because it always has a VLAN filter for VLAN 0. Fix this by removing/adding the VF's VLAN 0 filter when a port VLAN is added/removed respectively. This required a few changes. 1. Move where we add VLAN 0 by default for the VF into ice_alloc_vsi_res() because this is when we determine if a port VLAN is present for load and reset. 2. Moved where we kill the old port VLAN filter in ice_set_vf_port_vlan() to the very end of the function because it allows us to save the old port VLAN configuration upon any failure case. 3. During adding/removing of a port VLAN via ice_set_vf_port_vlan() we also need to remove/add the VLAN 0 filter rule respectively. 4. Improve log messages. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Fix Port VLAN priority bitsBrett Creeley2020-02-152-19/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when configuring a port VLAN for a VF we are only shifting the QoS bits by 12. This is incorrect. Fix this by getting rid of the ICE specific VLAN defines and use the kernel VLAN defines instead. Also, don't assign a value to vlanprio until the VLAN ID and QoS parameters have been validated. Also, there are many places we do (le16_to_cpu(vsi->info.pvid) & VLAN_VID_MASK). Instead do (vf->port_vlan_info & VLAN_VID_MASK) because we always save what's stored in vsi->info.pvid to vf->port_vlan_info in the CPU's endianness. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Add helper to determine if VF link is upBrett Creeley2020-02-151-17/+25
| | | | | | | | | | | | | | | | | | | | | | The check for vf->link_up is incorrect because this field is only valid if vf->link_forced is true. Fix this by adding the helper ice_is_vf_link_up() to determine if the VF's link is up. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Refactor port vlan configuration for the VFBrett Creeley2020-02-152-51/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently ice_vsi_manage_pvid() calls ice_vsi_[set|kill]_pvid_fill_ctxt() when enabling/disabling a port VLAN on a VSI respectively. These two functions have some duplication so just move their unique pieces inline in ice_vsi_manage_pvid() and then the duplicate code can be reused for both the enabling/disabling paths. Before this patch the info.pvid field was not being written correctly via ice_vsi_kill_pvid_fill_ctxt() so it was being hard coded to 0 in ice_set_vf_port_vlan(). Fix this by setting the info.pvid field to 0 before calling ice_vsi_update() in ice_vsi_manage_pvid(). We currently use vf->port_vlan_id to keep track of the port VLAN ID and QoS, which is a bit misleading. Fix this by renaming it to vf->port_vlan_info. Also change the name of the argument for ice_vsi_manage_pvid() from vid to pvid_info. In ice_vsi_manage_pvid() only save the fields that were modified in the VSI properties structure on success instead of the entire thing. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ice: Add initial support for QinQBrett Creeley2020-02-154-17/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow support for S-Tag + C-Tag VLAN traffic by disabling pruning when there are no 0x8100 VLAN interfaces currently created on top of the PF. When an 0x8100 VLAN interface is configured, enable pruning and only support single and double C-Tag VLAN traffic. If all of the 0x8100 interfaces that were created on top of the PF are removed via ethtool -K <iface> rx-vlan-filter off or via ip tools, then disable pruning and allow S-Tag + C-Tag traffic again. Add VLAN 0 filter by default for the PF. This is because a bridge sets the default_pvid to 1, sends the request down to ice_vlan_rx_add_vid(), and we never get the request to add VLAN 0 via the 8021q module which causes all untagged traffic to be dropped. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | Merge branch 'sonic-next'David S. Miller2020-02-165-127/+60
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Finn Thain says: ==================== Improvements for SONIC ethernet drivers Now that the necessary sonic driver fixes have been merged, and the merge window has closed again, I'm sending the remainder of my sonic driver patch queue. A couple of these patches will have to be applied in sequence to avoid 'git am' rejects. The others are independent and could have been submitted individually. Please let me know if I should do that. The complete sonic driver patch queue was tested on National Semiconductor hardware (macsonic), qemu-system-m68k (macsonic) and qemu-system-mips64el (jazzsonic). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/macsonic: Remove interrupt handler wrapperFinn Thain2020-02-161-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On m68k, local irqs remain enabled while interrupt handlers execute. Therefore the macsonic driver has had to disable interrupts to avoid re-entering sonic_interrupt(). As of commit 865ad2f2201d ("net/sonic: Add mutual exclusion for accessing shared state"), sonic_interrupt() became re-entrant, and its wrapper became redundant. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/sonic: Start packet transmission immediatelyFinn Thain2020-02-161-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | Give the transmit command as soon as the transmit descriptor is ready. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/sonic: Remove explicit memory barriersFinn Thain2020-02-161-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | The explicit memory barriers are redundant now that proper locking and MMIO accessors have been employed. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/sonic: Remove redundant netif_start_queue() callFinn Thain2020-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transmit queue must be running already otherwise sonic_send_packet() would not have been called. If the queue was stopped by the interrupt handler, the interrupt handler will restart it again. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/sonic: Remove redundant next_tx variableFinn Thain2020-02-162-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The eol_tx variable is the one that matters to the tx algorithm because packets are always placed at the end of the list. The next_tx variable just confuses things so remove it. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/sonic: Refactor duplicated codeFinn Thain2020-02-165-93/+44
| | | | | | | | | | | | | | | | | | | | | | | | No functional change. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/sonic: Remove obsolete commentFinn Thain2020-02-161-5/+0
|/ / | | | | | | | | | | | | | | The comment is meaningless since mark_bh() was removed a long time ago. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch ↵David S. Miller2020-02-162-77/+29
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'sh_eth-get-rid-of-the-dedicated-regiseter-mapping-for-RZ-A1-R7S72100' Sergei Shtylyov says: ==================== sh_eth: get rid of the dedicated regiseter mapping for RZ/A1 (R7S72100) Here's a set of 5 patches against DaveM's 'net-next.git' repo. I changed my mind about the RZ/A1 SoC needing its own register map -- now that we don't depend on the register map array in order to determine whether a given register exists any more, we can add a new flag to determine if the GECMR exists (this register is present only on true GEther chips, not RZ/A1). We also need to add the sh_eth_cpu_data::* flag checks where they were missing so far: in the ethtool API for the register dump. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sh_eth: use Gigabit register map for R7S72100Sergei Shtylyov2020-02-162-68/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The register maps for the Gigabit controllers and the Ether one used on RZ/A1 (AKA R7S72100) are identical except for GECMR which is only present on the true GEther controllers. We no longer use the register map arrays to determine if a given register exists, and have added the GECMR flag to the 'struct sh_eth_cpu_data' in the previous patch, so we're ready to drop the R7S72100 specific register map -- this saves 216 bytes of object code (ARM gcc 4.8.5). Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Tested-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sh_eth: add sh_eth_cpu_data::gecmr flagSergei Shtylyov2020-02-162-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not all Ether controllers having the Gigabit register layout have GECMR -- RZ/A1 (AKA R7S72100) actually has the same layout but no Gigabit speed support and hence no GECMR. In the past, the new register map table was added for this SoC, now I think we should have used the existing Gigabit table with the differences (such as GECMR) covered by the mere flags in the 'struct sh_eth_cpu_data'. Add such flag for GECMR -- and then we can get rid of the R7S72100 specific layout in the next patch... Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Tested-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sh_eth: check sh_eth_cpu_data::no_xdfar when dumping registersSergei Shtylyov2020-02-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding the sh_eth_cpu_data::no_xdfar flag I forgot to add the flag check to __sh_eth_get_regs(), causing the non-existing RDFAR/TDFAR to be considered for dumping on the R-Car gen1/2 SoCs (the register offset check has the final say here)... Fixes: 4c1d45850d5 ("sh_eth: add sh_eth_cpu_data::cexcr flag") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Tested-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sh_eth: check sh_eth_cpu_data::cexcr when dumping registersSergei Shtylyov2020-02-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding the sh_eth_cpu_data::cexcr flag I forgot to add the flag check to __sh_eth_get_regs(), causing the non-existing RX packet counter registers to be considered for dumping on the R7S72100 SoC (the register offset sanity check has the final say here)... Fixes: 4c1d45850d5 ("sh_eth: add sh_eth_cpu_data::cexcr flag") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Tested-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sh_eth: check sh_eth_cpu_data::no_tx_cntrs when dumping registersSergei Shtylyov2020-02-161-4/+6
|/ / | | | | | | | | | | | | | | | | | | | | | | When adding the sh_eth_cpu_data::no_tx_cntrs flag I forgot to add the flag check to __sh_eth_get_regs(), causing the non-existing TX counter registers to be considered for dumping on the R7S72100 SoC (the register offset sanity check has the final say here)... Fixes: ce9134dff6d9 ("sh_eth: add sh_eth_cpu_data::no_tx_cntrs flag") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Tested-by: Chris Brandt <chris.brandt@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'Pause-updates-for-phylib-and-phylink'David S. Miller2020-02-167-90/+258
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Russell King says: ==================== Pause updates for phylib and phylink Currently, phylib resolves the speed and duplex settings, which MAC drivers use directly. phylib also extracts the "Pause" and "AsymPause" bits from the link partner's advertisement, and stores them in struct phy_device's pause and asym_pause members with no further processing. It is left up to each MAC driver to implement decoding for this information. phylink converted drivers are able to take advantage of code therein which resolves the pause advertisements for the MAC driver, but this does nothing for unconverted drivers. It also does not allow us to make use of hardware-resolved pause states offered by several PHYs. This series aims to address this by: 1. Providing a generic implementation, linkmode_resolve_pause(), that takes the ethtool linkmode arrays for the link partner and local advertisements, decoding the result to whether pause frames should be allowed to be transmitted or received and acted upon. I call this the pause enablement state. 2. Providing a phylib implementation, phy_get_pause(), which allows MAC drivers to request the pause enablement state from phylib. 3. Providing a generic linkmode_set_pause() for setting the pause advertisement according to the ethtool tx/rx flags - note that this design has some shortcomings, see the comments in the kerneldoc for this function. 4. Remove the ability in phylink to set the pause states for fixed links, which brings them into line with how we deal with the speed and duplex parameters; we can reintroduce this later if anyone requires it. This could be a userspace-visible change. 5. Split application of manual pause enablement state from phylink's resolution of the same to allow use of phylib's new phy_get_pause() interface by phylink, and make that switch. 6. Resolve the fixed-link pause enablement state using the generic linkmode_resolve_pause() helper introduced earlier. This, in connection with the previous commits, allows us to kill the MLO_PAUSE_SYM and MLO_PAUSE_ASYM flags. 7. make phylink's ethtool pause setting implementation update the pause advertisement in the same way that phylib does, with the same caveats that are present there (as mentioned above w.r.t linkmode_set_pause()). 8. create a more accurate initial configuration for MACs, used when phy_start() is called or a SFP is detected. In particular, this ensures that the pause bits seen by MAC drivers in state->pause are accurate for SGMII. 9. finally, update the kerneldoc descriptions for mac_config() for the above changes. This series has been build-tested against net-next; the boot tested patches are in my "phy" branch against v5.5 plus the queued phylink changes that were merged for 5.6. The next series will introduce the ability for phylib drivers to provide hardware resolved pause enablement state. These patches can be found in my "phy" branch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: phylink: clarify flow control settings in documentationRussell King2020-02-161-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Clarify the expected flow control settings operation in the phylink documentation for each negotiation mode. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: phylink: improve initial mac configurationRussell King2020-02-161-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improve the initial MAC configuration so we get a configuration which more represents the final operating mode, in particular with respect to the flow control settings. We do this by: 1) more fully initialising our phy state, so we can use this as the initial state for PHY based connections. 2) reading the fixed link state. 3) ensuring that in-band mode has sane pause settings for SGMII vs 802.3z negotiation modes. In all three cases, we ensure that state->link is false, just in case any MAC drivers have other ideas by mis-using this member, and we also take account of manual pause mode configuration at this point. This avoids MLO_PAUSE_AN being seen in mac_config() when operating in PHY, fixed mode or inband SGMII mode, thereby giving cleaner semantics to the pause flags. As a result of this, the pause flags now indicate in a mode-independent way what is required from a mac_config() implementation. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 04:27:31 +0000