aboutsummaryrefslogtreecommitdiffstats
path: root/drivers (follow)
AgeCommit message (Collapse)AuthorFilesLines
2018-02-16net: dsa: mv88e6xxx: Release mutex between each ATU readAndrew Lunn1-6/+8
The PTP code needs low latency access to the PTP hardware timestamps. Reading all the ATU entries in one go adds a lot of latency to the PTP code. So take and release the reg_lock mutex for each individual MAC address in the ATU, allowing the PTP thread jump in between. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-16net: dsa: mv88e6xxx: Release mutex between each statistics readAndrew Lunn1-4/+6
The PTP code needs low latency access to the PTP hardware timestamps. Reading all the statistics in one go adds a lot of latency to the PTP code. So take and release the reg_lock mutex for each individual statistics, allowing the PTP thread jump in between. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-15Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-nextDavid S. Miller6-50/+115
Johan Hedberg says: ==================== pull request: bluetooth-next 2018-02-15 Here's the first bluetooth-next pull request targetting the 4.17 kernel release. - Fixes & cleanups to Atheros and Marvell drivers - Support for two new Realtek controllers - Support for new Intel Bluetooth controller - Fix for supporting multiple slave-role Bluetooth LE connections ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-15net/ipv4: Remove fib table id from rtableDavid Ahern1-1/+0
Remove rt_table_id from rtable. It was added for getroute to return the table id that was hit in the lookup. With the changes for fibmatch the table id can be extracted from the fib_info returned in the fib_result so it no longer needs to be in rtable directly. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-15tun: Add ioctl() SIOCGSKNS cmd to allow obtaining net ns of tun deviceKirill Tkhai1-2/+14
This patch adds possibility to get tun device's net namespace fd in the same way we allow to do that for sockets. Socket ioctl numbers do not intersect with tun-specific, and there is already SIOCSIFHWADDR used in tun code. So, SIOCGSKNS number is choosen instead of custom-made for this functionality. Note, that open_related_ns() uses plain get_net_ns() and it's safe (net can't be already dead at this moment): tun socket is allocated via sk_alloc() with zero last arg (kern = 0). So, each alive socket increments net::count, and the socket is definitely alive during ioctl syscall. Also, common variable net is introduced, so small cleanup in TUNSETIFF is made. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller9-92/+2133
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2018-02-14 This patch series enables the new mqprio hardware offload mechanism creating traffic classes on VFs for XL710 devices. The parameters needed to configure these traffic classes/queue channels are provides by the user via the tc tool. A maximum of four traffic classes can be created on each VF. This patch series also enables application of cloud filters to each of these traffic classes. The cloud filters are applied using the tc-flower classifier. Example: 1. tc qdisc add dev vf0 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\ queues 2@0 2@2 1@4 1@5 hw 1 mode channel 2. tc qdisc add dev vf0 ingress 3. ethtool -K vf0 hw-tc-offload on 4. ip link set eth0 vf 0 spoofchk off 5. tc filter add dev vf0 protocol ip parent ffff: prio 1 flower dst_ip\ 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: phy: dp83867: Add binding for the CLK_OUT pin muxing optionWadim Egorov1-0/+19
The DP83867 has a muxing option for the CLK_OUT pin. It is possible to set CLK_OUT for different channels. Create a binding to select a specific clock for CLK_OUT pin. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14cxgb4: speed up on-chip memory readRahul Lakkireddy1-9/+28
Use readq() (via t4_read_reg64()) to read 64-bits at a time. Read residual in 32-bit multiples. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14cxgb4: rework on-chip memory readRahul Lakkireddy3-73/+192
Rework logic to read EDC and MC. Do 32-bit reads at a time. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add workaround for 6341 timestampingBrandon Streiff2-0/+22
88E6341 devices default to timestamping at the PHY, but due to a hardware issue, timestamps via this component are unreliable. For this family, configure the PTP hardware to force the timestamping to occur at the MAC. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add rx/tx timestamping supportBrandon Streiff7-4/+788
This patch implements RX/TX timestamping support. The Marvell PTP hardware supports RX timestamping individual message types, but for simplicity we only support the EVENT receive filter since few if any clients bother with the more specific filter types. checkpatch and reverse Christmas tree changes by Andrew Lunn. Re-factor duplicated code paths and avoid IfOk anti-pattern, use the common ptp worker thread from the class layer and time stamp UDP/IPv4 frames as well as Layer-2 frame by Richard Cochran. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add support for event captureBrandon Streiff3-2/+207
This patch adds support for configuring mv88e6xxx GPIO lines as PTP pins, so that they may be used for time stamping external events or for periodic output. Checkpatch and reverse Christmas tree fixes by Andrew Lunn Periodic output removed by Richard Cochran, until a better abstraction of a VCO is added to Linux in general. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add support for GPIO configurationBrandon Streiff6-0/+334
MV88E6352 and later switches support GPIO control through the "Scratch & Misc" global2 register. (Older switches do too, though with a slightly different register interface. Only the 6352-style is implemented here.) Add a new file, global2_scratch.c, for operations in the Scratch & Misc space. Additionally, add a GPIO operations structure to present an abstract view over GPIO manipulation. Reverse Christmas tree and unsigned has been replaced with unsigned int by Andrew Lunn. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: expose switch time as a PTP hardware clockBrandon Streiff6-0/+326
This patch adds basic support for exposing the 32-bit timestamp counter inside the mv88e6xxx switch as a ptp_clock. Adjfine implemented by Richard Cochran. Andrew Lunn: fix return value of PTP stub function. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add accessors for PTP/TAI registersBrandon Streiff5-1/+251
This patch implements support for accessing the Precision Time Protocol and Time Application Interface registers via the AVB register interface in the Global 2 register. The register interface differs slightly between different models; older models use a 3-bit operations field, while newer models use a 2-bit field. The operations values and the special "global port" values are different between the two. This is a similar split to the differences in the "Ingress Rate" register between models, so, like in that case, we call the two variants "6352" and "6390" and create an ops structure to abstract between the two. checkpatch fixups by Andrew Lunn Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: export g2 register accessorsBrandon Streiff2-4/+29
Let the mv88e6xxx_g2_* register accessor functions be accessible outside of global2.c. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14i40e: Add and delete cloud filterAvinash Dayanand4-12/+470
This patch provides support to add or delete cloud filter for queue channels created for ADq on VF. We are using the HW's cloud filter feature and programming it to act as a TC filter applied to a group of queues. There are two possible modes for a VF when applying a cloud filter 1. Basic Mode: Intended to apply filters that don't need a VF to be Trusted. This would include the following Dest MAC + L4 port Dest MAC + VLAN + L4 port 2. Advanced Mode: This mode is only for filters with combination that requires VF to be Trusted. Dest IP + L4 port When cloud filters are applied on a trusted VF and for some reason the same VF is later made as untrusted then all cloud filters will be deleted. All cloud filters has to be re-applied in such a case. Cloud filters are also deleted when queue channel is deleted. Testing-Hints: ============= 1. Adding Basic Mode filter should be possible on a VF in Non-Trusted mode. 2. In Advanced mode all filters should be able to be created. Steps: ====== 1. Enable ADq and create TCs using TC mqprio command 2. Apply cloud filter. 3. Turn-off the spoof check. 4. Pass traffic. Example: ======== 1. tc qdisc add dev enp4s2 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\ queues 2@0 2@2 1@4 1@5 hw 1 mode channel 2. tc qdisc add dev enp4s2 ingress 3. ethtool -K enp4s2 hw-tc-offload on 4. ip link set ens261f0 vf 0 spoofchk off 5. tc filter add dev enp4s2 protocol ip parent ffff: prio 1 flower\ dst_ip 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2 Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Add support to apply cloud filtersHarshitha Ramamurthy3-5/+810
This patch enables a tc filter to be applied as a cloud filter for the VF. This patch adds functions which parse the tc filter, extract the necessary fields needed to configure the filter and package them in a virtchnl message to be sent to the PF to apply them. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40e: Service request to configure bandwidth for ADq on a VFAvinash Dayanand2-3/+54
This patch handles the request from ADq enabled VF to allocate bandwidth to each traffic class which means for each VSI. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Add support to configure bw via tc toolHarshitha Ramamurthy3-3/+67
This patch adds support to configure bandwidth for the traffic classes via tc tool. The required information is passed to the PF which is used in the process of setting up the traffic classes. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40e: Delete queue channel for ADq on VFAvinash Dayanand1-0/+63
This patch takes care of freeing up all the VSIs, queues and other ADq related software and hardware resources, when a user requests for deletion of ADq on VF. Example command: tc qdisc del dev eth0 root Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Alloc queues for ADq on VFAvinash Dayanand2-0/+20
This patch allocates number of queues requested by the user as a part of TC command when ADq is enabled on a VF. In order to be consistent in design with PF implementation of ADq, don't allow to set channels via ethtool from VF when ADq is already enabled. This means the users will not be able to change the number of queues/channels via ethtool for a VF when ADq is ON. In order to be able to use set channels, users will be required to disable ADq first and then try setting the channels again. When ADq is enabled on VF, it goes through a reset during which VSIs and queues are re-configured. Meanwhile if we receive link status message from PF even before the queues are re-configured, just ignore this link up message. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40e: Enable ADq and create queue channel/s on VFAvinash Dayanand3-69/+379
This patch enables ADq and creates queue channels on a VF. An ADq enabled VF can have up to 4 VSIs and each one of them represents a traffic class and this is termed as a queue channel. Each of these VSIs can have up to 4 queues. This patch services the request for enabling ADq and adds queue channel based on the TC mqprio info provided by the user in the VF. Initially a check is made to see if spoof check is OFF, if not ADq will not be enabled. PF notifies VF for a reset in order to complete the creation of ADq resources i.e. creation of additional VSIs and allocation of queues as per TC information, all in the reset path. Steps: ====== 1. Turn off the spoof check 2. Enable ADq using tc mqprio command with or without rate limit. 3. Pass traffic. Example: ======== % ip link set dev eth0 vf 0 spoofchk off % tc qdisc add dev $iface root mqprio num_tc 4 map\ 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 queues\ 4@0 4@4 4@8 4@8 hw 1 mode channel Expected results: ================= 1. Total number of queues for the VF should be sum of queues of all TCs. 2. Traffic flow should be normal without errors. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: add ndo_setup_tc callback to i40evfHarshitha Ramamurthy3-1/+257
This patch introduces the callback to the ndo_setup_tc function in the VF driver. We add a wrapper function to make room for the upcoming cloud filter patches which add calls to different functions from setup_tc. First, we add support for capability exchange for ADQ between the PF and VF. Next, we add support to take in the mqprio configuration and configure queues as per the traffic classes, rate limit and the priorities specified by the user. This is done by passing the channel config to the PF driver through a virtchannel message. The flags and bits added, track if ADq is enabled, set max number of traffic classes to 4 and provide ability to negotiate capability with the PF. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Fix link up issue when queues are disabledAvinash Dayanand3-8/+22
One of the previous patch fixes the link up issue by ignoring it if i40evf is not in __I40EVF_RUNNING state. However this doesn't fix the race condition when queues are disabled esp for ADq on VF. Hence check if all queues are enabled before starting all queues. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: Make VF reset warning message more clearHarshitha Ramamurthy1-1/+1
When the PF resets the VF, the VF puts out a warning message indicating that the VF received a reset message from the PF. Make this message more clear so that we do not mistakenly think that the PF is undergoing a reset. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: use __dev_[um]c_sync routines in .set_rx_modeJacob Keller1-39/+56
Similar to changes done to the PF driver in commit 6622f5cdbaf3 ("i40e: make use of __dev_uc_sync and __dev_mc_sync"), replace our home-rolled method for updating the internal status of MAC filters with __dev_uc_sync and __dev_mc_sync. These new functions use internal state within the netdev struct in order to efficiently break the question of "which filters in this list need to be added or removed" into singular "add this filter" and "delete this filter" requests. This vastly improves our handling of .set_rx_mode especially with large number of MAC filters being added to the device, and even results in a simpler .set_rx_mode handler. Under some circumstances, such as when attached to a bridge, we may receive a request to delete our own permanent address. Prevent deletion of this address during i40evf_addr_unsync so that we don't accidentally stop receiving traffic. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: i40e: Change ethtool check from MAC to HW flagDave Ertman3-10/+13
The MAC, FW Version and NPAR check used to determine if shutting off the FW LLDP engine is supported is not using the usual feature check mechanism. This patch fixes the problem by moving the feature check to i40e_sw_init in order to set a flag in pf->hw_features that ethtool will use for priv_flags disable operation. Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: do not force filter failure in overflow promiscuousAlan Brady1-14/+1
Broadcast filters can now cause overflow promiscuous to trigger when adding "too many" VLANs to all the ports of a device and the driver needs a way to exit overflow promiscuous once triggered. Currently the driver looks to see if there are "too many" filters and/or we have any failed filters to determine when it is safe to exit overflow promiscuous. If we trigger overflow promiscuous with broadcast filters, any new filters added will be "auto-failed" until we exit overflow promiscuous. Since the user can't manually remove the failed broadcast filters for VLANs (nor should we expect the user to do such), there is no way to exit overflow promiscuous without reloading the driver. The easiest way to do this is to remove the shortcut to "auto-fail" filters in overflow promiscuous. If the user removes the VLANs, the failed filters will be removed and since we're no longer "auto-failing" new filters, we'll eventually get a good set of filters and exit overflow promiscuous. This has the side benefit of making filter state more explicit in that if a filter says it's failed we know for a fact it failed and not just assuming it will if we're in overflow promiscuous. This is nice because if the user removes some filters and then adds some, even if we're in overflow promiscuous, the filter might succeed; we were just assuming it won't because the user hasn't rectified other existing failed filters. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: refactor promisc_changed in i40e_sync_vsi_filtersAlan Brady1-22/+20
This code here is quite complex and easy to screw up. Let's see if we can't improve the readability and maintainability a bit. This refactors out promisc_changed into two variables 'old_overflow' and 'new_overflow' which makes it a bit clearer when we're concerned about when and how overflow promiscuous is changed. This also makes so that we no longer need to pass a boolean pointer to i40e_aqc_add_filters. Instead we can simply check if we changed the overflow promiscuous flag since the function start. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: Use an iterator of the same type as the listHarshitha Ramamurthy1-4/+7
When iterating through the linked list of VLAN filters, make the iterator the same type as that of the linked list. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: broadcast filters can trigger overflow promiscuousAlan Brady1-2/+4
When adding a bunch of VLANs to all the ports on a device, it's possible to run out of space for broadcast filters. The driver should trigger overflow promiscuous in this circumstance to prevent traffic from being unexpectedly dropped. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: don't leak memory addressesMitch Williams2-41/+12
Could a Bad Person do Bad Things to a server if they found these addresses printed in the log? Who knows? But let's not take that risk. Remove pointers from a bunch of printks. In some cases, I was able to adjust the message to indicate whether or not the value was null. In others, I just removed the entire message as there was really no hope of saving it. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: use GFP_ATOMIC under spin lockWei Yongjun1-4/+4
A spin lock is taken here so we should use GFP_ATOMIC. Fixes: 504398f0a78e ("i40evf: use spinlock to protect (mac|vlan)_filter_list") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: Make local function i40e_get_link_speed staticWei Yongjun1-1/+1
Fixes the following sparse warning: drivers/net/ethernet/intel/i40e/i40e_main.c:5440:5: warning: symbol 'i40e_get_link_speed' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13mlxsw: spectrum: Use NL_SET_ERR_MSG_MODArkadi Sharshevsky3-24/+16
Use NL_SET_ERR_MSG_MOD helper which adds the module name instead of specifying the prefix each time. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Move SPAN code to separate modulePetr Machata6-348/+433
For the upcoming work on SPAN, it makes sense to move the current code to a module of its own. It already has a well-defined API boundary to the mirror management (which is used from matchall and ACL code). A couple more functions need to be exported for the functions that spectrum.c needs to use for MTU handling and subsystem init/fini. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Drop struct span_entry.usedPetr Machata2-5/+2
The member ref_count already determines whether a given SPAN entry is used, and is as easy to use as a dedicated boolean. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Fix a coding style nitPetr Machata1-2/+2
Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Distinguish between IPv4/6 tunnelsPetr Machata3-91/+72
struct ip_tunnel_parm, where GRE and several other tunnel types hold information, is IPv4-specific. The current router / ipip code in mlxsw however uses it as if it were generic. Make it clear that it's not. Rename many functions from _params_ to _params4_. mlxsw_sp_ipip_parms_saddr() and _daddr() take a proto argument to dispatch on it. Move the dispatch logic to mlxsw_sp_ipip_netdev_saddr() and _daddr(), and replace with single-protocol functions. In struct mlxsw_sp_ipip_entry, move the "parms" field to a (for the time being, singleton) union. Update users throughout. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum_ipip: Add a forgotten includePetr Machata1-0/+1
struct ip_tunnel_parm, which is used in spectrum_ipip.h, is defined in if_tunnel.h. However, the former neglects to include the latter. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13dpaa_eth: fix incorrect commentJake Moroni1-1/+1
The comment stated that a thread was started, but that is not the case. Signed-off-by: Jake Moroni <mail@jakemoroni.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13net: Convert loopback_net_opsKirill Tkhai1-0/+1
These pernet_operations have only init() method. It allocates memory for net_device, calls register_netdev() and assigns net::loopback_dev. register_netdev() is allowed be used without additional locks, as it's synchronized on rtnl_lock(). There are many examples of using this functon directly from ioctl(). The only difference, compared to ioctl(), is that net is not completely alive at this moment. But it looks like, there is no way for parallel pernet_operations to dereference the net_device, as the most of struct net_device lists, where it's linked, are related to net, and the net is not liked. The exceptions are net_device::unreg_list, close_list, todo_list, used for unregistration, and ::link_watch_list, where net_device may be linked to global lists. Unregistration of loopback_dev obviously can't happen, when loopback_net_init() is executing, as the net as alive. It occurs in default_device_ops, which currently requires net_mutex, and it behaves as a barrier at the moment. It will be considered in next patch. Speaking about link_watch_list, it seems, there is no way for loopback_dev at time of registration to be linked in lweventlist and be available for another pernet_operations. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by: Andrei Vagin <avagin@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller12-457/+769
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2018-02-12 This series contains updates to i40e and i40evf. Alan fixes a spelling mistake in code comments. Fixes an issue on older firmware versions or NPAR enabled PFs which do not support the I40E_FLAG_DISABLE_FW_LLDP flag and would get into a situation where any attempt to change any priv flag would be forbidden. Alex got busy with the ITR code and made several cleanups and fixes so that we can more easily understand what is going on. The fixes included a computational fix when determining the register offset, as well as a fix for unnecessarily toggling the CLEARPBA bit which could lead to potential lost events if auto-masking is not enabled. Filip adds a necessary delay to recover after a EMP reset when using firmware version 4.33. Paweł adds a warning message for MFP devices when the link-down-on-close flag is set because it may affect other partitions. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12i40e/i40evf: Add support for new mechanism of updating adaptive ITRAlexander Duyck8-257/+528
This patch replaces the existing mechanism for determining the correct value to program for adaptive ITR with yet another new and more complicated approach. The basic idea from a 30K foot view is that this new approach will push the Rx interrupt moderation up so that by default it starts in low latency and is gradually pushed up into a higher latency setup as long as doing so increases the number of packets processed, if the number of packets drops to 4 to 1 per packet we will reset and just base our ITR on the size of the packets being received. For Tx we leave it floating at a high interrupt delay and do not pull it down unless we start processing more than 112 packets per interrupt. If we start exceeding that we will cut our interrupt rates in half until we are back below 112. The side effect of these patches are that we will be processing more packets per interrupt. This is both a good and a bad thing as it means we will not be blocking processing in the case of things like pktgen and XDP, but we will also be consuming a bit more CPU in the cases of things such as network throughput tests using netperf. One delta from this versus the ixgbe version of the changes is that I have made the interrupt moderation a bit more aggressive when we are in bulk mode by moving our "goldilocks zone" up from 48 to 96 to 56 to 112. The main motivation behind moving this is to address the fact that we need to update less frequently, and have more fine grained control due to the separate Tx and Rx ITR times. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-12i40e/i40evf: Split container ITR into current_itr and target_itrAlexander Duyck8-86/+115
This patch is mostly prep-work for replacing the current approach to programming the dynamic aka adaptive ITR. Specifically here what we are doing is splitting the Tx and Rx ITR each into two separate values. The first value current_itr represents the current value of the register. The second value target_itr represents the desired value of the register. The general plan by doing this is to allow for deferring the update of the ITR value under certain circumstances. For now we will work with what we have, but in the future I hope to change the behavior so that we always only update one ITR at a time using some simple logic to determine which ITR requires an update. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-12i40evf: Correctly populate rxitr_idx and txitr_idxAlexander Duyck1-9/+15
While testing code for the recent ITR changes I found that updating the Tx ITR appeared to have no effect with everything defaulting to the Rx ITR. A bit of digging narrowed it down the fact that we were asking the PF to associate all causes with ITR 0 as we weren't populating the itr_idx values for either Rx or Tx. To correct it I have added the configuration for these values to this patch. In addition I did some minor clean-up to just add a local pointer for the vector map instead of dereferencing it based off of the index repeatedly. In my opinion this makes the resultant code a bit more readable and saves us a few characters. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-12i40e/i40evf: Use usec value instead of reg value for ITR definesAlexander Duyck6-56/+79
Instead of using the register value for the defines when setting up the ring ITR we can just use the actual values and avoid the use of shifts and macros to translate between the values we have and the values we want. This helps to make the code more readable as we can quickly translate from one value to the other. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-12net: make getname() functions return length rather than use int* parameterDenys Vlasenko11-49/+36
Changes since v1: Added changes in these files: drivers/infiniband/hw/usnic/usnic_transport.c drivers/staging/lustre/lnet/lnet/lib-socket.c drivers/target/iscsi/iscsi_target_login.c drivers/vhost/net.c fs/dlm/lowcomms.c fs/ocfs2/cluster/tcp.c security/tomoyo/network.c Before: All these functions either return a negative error indicator, or store length of sockaddr into "int *socklen" parameter and return zero on success. "int *socklen" parameter is awkward. For example, if caller does not care, it still needs to provide on-stack storage for the value it does not need. None of the many FOO_getname() functions of various protocols ever used old value of *socklen. They always just overwrite it. This change drops this parameter, and makes all these functions, on success, return length of sockaddr. It's always >= 0 and can be differentiated from an error. Tests in callers are changed from "if (err)" to "if (err < 0)", where needed. rpc_sockname() lost "int buflen" parameter, since its only use was to be passed to kernel_getsockname() as &buflen and subsequently not used in any way. Userspace API is not changed. text data bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> CC: David S. Miller <davem@davemloft.net> CC: linux-kernel@vger.kernel.org CC: netdev@vger.kernel.org CC: linux-bluetooth@vger.kernel.org CC: linux-decnet-user@lists.sourceforge.net CC: linux-wireless@vger.kernel.org CC: linux-rdma@vger.kernel.org CC: linux-sctp@vger.kernel.org CC: linux-nfs@vger.kernel.org CC: linux-x25@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12i40e/i40evf: Don't bother setting the CLEARPBA bitAlexander Duyck2-2/+20
The CLEARPBA bit in the dynamic interrupt control register actually has no effect either way on the hardware. As per errata 28 in the XL710 specification update the interrupt is actually cleared any time the register is written with the INTENA_MSK bit set to 0. As such the act of toggling the enable bit actually will trigger the interrupt being cleared and could lead to potential lost events if auto-masking is not enabled. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>