summaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/intel
Commit message (Collapse)AuthorAgeFilesLines
...
* i40e: avoid race condition when sending filters to firmware for additionJacob Keller2017-02-112-51/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor how we add new filters to firmware to avoid a race condition that can occur due to removing filters from the hash temporarily. To understand the race condition, suppose that you have a number of MAC filters, but have not yet added any VLANs. Now, add two VLANs in rapid succession. A possible resulting flow would look something like the following: (1) lock hash for add VLAN (2) add the new MAC/VLAN combos for each current MAC filter (3) unlock hash (4) lock hash for filter sync (5) notice that we have a VLAN, so prepare to update all MAC filters with VLAN=-1 to be VLAN=0. (6) move NEW and REMOVE filters to temporary list (7) unlock hash (8) lock hash for add VLAN (9) add new MAC/VLAN combos. Notice that no MAC filters are currently in the hash list, so we don't add any VLANs <--- BUG! (10) unlock hash (11) sync the temporary lists to firmware (12) lock hash for post-sync (13) move the temporary elements back to the main list .... Because we take filters out of the main hash into temporary lists, we introduce a narrow window where it is possible that other callers to the list will not see some of the filters which were previously added but have not yet been finalized. This results in sometimes dropping VLAN additions, and could also result in failing to add a MAC address on the newly added VLAN. One obvious way to avoid this race condition would be to lock the entire firmware process. Unfortunately this does not work because adminq firmware commands take a mutex which results in a sleep while atomic BUG(). So, we can't use the simplest approach. An alternative approach is to simply not remove the filters from the hash list while adding. Instead, add an i40e_new_mac_filter structure which we will use to track added filters. This avoids the need to remove the filter from the hash list. We'll store a pointer to the original i40e_mac_filter, along with our own copy of the state. We won't update the state directly, so as to avoid race with other code that may modify the state while under the lock. We are safe to read f->macaddr and f->vlan since these only change in two locations. The first is on filter creation, which must have already occurred. The second is inside i40e_correct_vlan_filters which was previously run after creation of this object and can't be run again until after. Thus, we should be safe to read the MAC address and VLAN while outside the lock. We also aren't going to run into a use-after-free issue because the only place where we free filters is when they are marked FAILED or when we remove them inside the sync subtask. Since the subtask has its own critical flag to prevent duplicate runs, we know this won't happen. We also know that the only location to transition a filter from NEW to FAILED is inside the subtask also, so we aren't worried about that either. Use the wrapper i40e_new_mac_filter for additions, and once we've finalized the addition to firmware, we will update the filter state inside a lock, and then free the wrapper structure. In order to avoid a possible race condition with filter deletion, we won't update the original filter state unless it is still I40E_FILTER_NEW when we finish the firmware sync. This approach is more complex, but avoids race conditions related to filters being temporarily removed from the list. We do not need the same behavior for deletion because we always unconditionally removed the filters from the list regardless of the firmware status. Change-Id: I14b74bc2301f8e69433fbe77ebca532db20c5317 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>
* i40e: allow i40e_update_filter_state to skip broadcast filtersJacob Keller2017-02-111-8/+29
| | | | | | | | | | | | | | | | | | | | | | | Fix a bug where we modified the mac_filter_hash while outside a lock, when handling addition of broadcast filters. Normally, we add filters to firmware by batching the additions into lists and issuing 1 update for every few filters. Broadcast filters are handled differently, by instead setting the broadcast promiscuous mode flags. In order to make sure the 1<->1 mapping of filters in our addition array lined up with filters in the hlist tmp_add_list, we had to remove the filter and move it back to the main hash. However, we didn't do this under lock, which could cause consistency problems for the list. Fix this by updating i40e_update_filter_state logic so that it knows to avoid broadcast filters. This ensures that we don't have to remove the filter separately, and can put it back using the normal flow. Change-ID: Id288fade80b3e3a9a54b68cc249188cb95147518 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>
* i40e: don't warn every time we clear an Rx timestamp registerJacob Keller2017-02-111-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The intent of this message was to indicate to a user that we might have missed a timestamp event for a valid packet. The original method of detecting the missed events relied on waiting until all 4 registers were filled. A recent commit d55458c0cd7a5 ("i40e: replace PTP Rx timestamp hang logic") replaced this logic with much better detection scheme that could detect a stalled Rx timestamp register even when other registers were still functional. The new logic means that a message will be displayed almost as soon as a timestamp for a dropped frame occurs. This new logic highlights that the hardware will attempt timestamp for frames which it later decides to drop. The most prominent example is when a multicast PTP frame is received on a multicast address that we are not subscribed to. Because the hardware initiates the Rx timestamp as soon as possible, it will latch an RXTIME register, but then drop the packet. This results in users being confused by the message as they are not expecting to see dropped timestamp messages unless their application also indicates that timestamps were missing. Resolve this by reducing the severity and frequency of the displayed message. We now only print the message if 3 or 4 of the RXTIME registers are stalled and get cleared within the same watchdog event. This ensures that the common case does not constantly display the message. Additionally, since the message is likely not as meaningful to most users, reduce the message to a dev_dbg instead of a dev_warn. Users can still get a count of the number of timestamps dropped by reading the ethtool statistics value, if necessary. Change-ID: I35494442226a444c418dfb4f91a3070d06c8435c 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>
* i40e: Save link FEC info from link up eventHenry Tieman2017-02-114-2/+23
| | | | | | | | | | Store the FEC status bits from the link up event into the hw_link_info structure. Change-ID: I9a7b256f6dfb0dce89c2f503075d0d383526832e Signed-off-by: Henry Tieman <henry.w.tieman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Add bus number info to i40e_bus_info structSudheer Mogilappagari2017-02-116-13/+19
| | | | | | | | | | | | Currently i40e_bus_info has PCI device and function info only and log messages print device number as bus number. Added field to provide bus number info and modified log statements to print bus, device and function information. Change-ID: I811617cee2714cc0d6bade8d369f57040990756f Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Clean up dead codeMitch Williams2017-02-111-10/+3
| | | | | | | | | | The function i40e_client_prepare() can never return an error. So make it void and quit checking its return value. Change-ID: I9ff311e2324dde329eb68648efb2c94aaff856db 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>
* i40e/i40evf : Changed version from 1.6.25 to 1.6.27Bimmy Pujari2017-02-112-2/+2
| | | | | | Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: update comment explaining where FDIR buffers are freedJacob Keller2017-02-111-1/+6
| | | | | | | | | | | | The original comment implies that the only location where the raw_packet buffer will be freed is in i40e_clean_tx_ring() which is incorrect. In fact this isn't even the normal case. Update the comment explaining where the memory is freed. Change-ID: Ie0defc35ed1c3af183f81fdc60b6d783707a5595 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>
* i40e/i40evf: eliminate i40e_pull_tail()Scott Peterson2017-02-112-152/+186
| | | | | | | | | | | | | Reorganize the i40e_pull_tail() logic, doing it in i40e_add_rx_frag() where it's cheaper. The igb driver does this the same way. Also renames i40e_page_is_reserved() to reflect what it actually tests. Change-ID: Icd9cc507aae1fcdc02308b3a09034111b4c24071 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e/i40evf: Moves skb from i40e_rx_buffer to i40e_ringScott Peterson2017-02-114-33/+46
| | | | | | | | | | | | | | | | This patch reduces the size of struct i40e_rx_buffer by one pointer, and makes the i40e driver a little more consistent with the igb driver in terms of packets that span buffers. We do this by moving the skb field from struct i40e_rx_buffer to struct i40e_ring. We pass the skb we already have (or NULL if we don't) to i40e_fetch_rx_buffer(), which skips the skb allocation if we already have one for this packet. Change-ID: I4ad48a531844494ba0c5d8e1a62209a057f661b0 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e/i40evf: Limit DMA sync of RX buffers to actual packet sizeScott Peterson2017-02-112-14/+18
| | | | | | | | | | | On packet RX, we perform a DMA sync for CPU before passing the packet up. Here we limit that sync to the actual length of the incoming packet, rather than always syncing the entire buffer. Change-ID: I626aaf6c37275a8ce9e81efcaa773f327b331487 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40evf: track outstanding client requestMitch Williams2017-02-113-0/+6
| | | | | | | | | | | The iWarp client cannot continue until this operation has been completed by the PF driver. Sleep (with timeout) until the reply from the PF driver has been received. Change-ID: I5dc41b857bba32d0218b7ce167b5da122dadf349 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>
* i40e: don't check params until after checking for client instanceJacob Keller2017-02-111-2/+2
| | | | | | | | | | | We can avoid the minor bit of work by calling check params after we check for the client instance, since we're about to return early in cases where we do not have a client. Change-ID: I56f8ea2ba48d4f571fa331c9ace50819a022fa1c 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>
* Merge branch '40GbE' of ↵David S. Miller2017-02-0414-153/+129
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2017-02-03 This series contains updates to i40e/i40evf only. Jake fixes up the driver to not call i40e_vsi_kill_vlan() or i40e_vsi_add_vlan() when the PVID is set or when the VID is less than 1. Cleaned up a check which really is not needed since there is no real reason why we cannot just call i40e_del_mac_all_vlan() directly. Renamed functions to better reflect their actual purpose and how they function in a more clear manner. Bimmy cleans up unused/deprecated macros. Mitch cleans up unused device ids which were intended for use when running Linux VF drivers under Hyper-V, but found to be not needed. Then cleaned up a function that is no longer needed since the client open and close functions were refactored. Adds a sleep without timeout until the reply from the PF driver has been received since the iWARP client cannot continue until the operation has been completed. Tushar Dave fixes an issue seen on SPARC where the use of the 'packed' directive was causing kernel unaligned errors. Alex does a refactor to pull some data off of the stack and store it in the transmit buffer info section of the transmit ring. Alan fixes a bug which was caused by passing a bad register value to the firmware, by refactoring the macro INTRL_USEC_TO_REG into a static inline function. Also added feedback to the user as to the actual interrupt rate limit being used when it differs from the requested limit. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * i40e: add interrupt rate limit verbosityAlan Brady2017-02-021-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the resolution of the register controlling interrupt rate limiting, setting certain values for the interrupt rate limit make it appear as though the limiting is not completely accurate. The problem is that the interrupt rate limit is getting rounded down to the nearest multiple of 4. This patch fixes the problem by adding some feedback to the user as to the actual interrupt rate limit being used when it differs from the requested limit. Without this patch setting interrupt rate limits may appear to behave inaccurately. Change-ID: I3093cf3f2d437d35a4c4f4bb5af5ce1b85ab21b7 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>
| * i40e: refactor macro INTRL_USEC_TO_REGAlan Brady2017-02-023-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors the macro INTRL_USEC_TO_REG into a static inline function and fixes a couple subtle bugs caused by the macro. This patch fixes a bug which was caused by passing a bad register value to the firmware. If enabling interrupt rate limiting, a non-zero value for the rate limit must be used. Otherwise the firmware sets the interrupt rate limit to the maximum value. Due to the limited resolution of the register, attempting to set a value of 1, 2, or 3 would be rounded down to 0 and limiting was left enabled, causing unexpected behavior. This patch also fixes a possible bug in which using the macro itself can introduce unintended side-affects because the macro argument is used more than once in the macro definition (e.g. a variable post-increment argument would perform a double increment on the variable). Without this patch, attempting to set interrupt rate limits of 1, 2, or 3 results in unexpected behavior and future use of this macro could cause subtle bugs. Change-Id: I83ac842de0ca9c86761923d6e3a4d7b1b95f2b3f 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>
| * i40e: remove unused functionMitch Williams2017-02-022-36/+0
| | | | | | | | | | | | | | | | | | | | After refactoring the client open and close code, this is no longer needed. Remove it. Change-ID: If8e6e32baa354d857c2fd8b2f19404f1786011c4 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>
| * i40e: Remove FPK HyperV VF device IDJayaprakash Shanmugam2017-02-022-2/+0
| | | | | | | | | | | | | | | | | | | | Requirement for VFs to use the VMBus has been removed that's why removing Hyper-V VF device ID. Change-ID: I84f0964f443ee0db3e5e444b5ace996eb71b8280 Signed-off-by: Jayaprakash Shanmugam <jayaprakash.shanmugam@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * i40e: Quick refactor to start moving data off stack and into Tx buffer infoAlexander Duyck2017-02-022-40/+54
| | | | | | | | | | | | | | | | | | | | | | | | This patch does some quick work to pull some of the data off of the stack and hopefully start storing it in the Tx buffer info section of the Tx ring. Ideally we should be moving away from having to store much of anything on the stack and can just maintain it all in the descriptor rings. Change-ID: I4b4715ea1920e122502482b3f9e56a9a6cb1e9fe 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>
| * i40e: remove unnecessary __packedTushar Dave2017-02-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'struct i40e_dma_mem' defined with 'packed' directive causing kernel unaligned errors on sparc. e.g. i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 1.6.16-k i40e: Copyright (c) 2013 - 2014 Intel Corporation. Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300 Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300 Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300 Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300 Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300 i40e 0000:03:00.0: fw 5.1.40981 api 1.5 nvm 5.04 0x80002548 0.0.0 This can be fixed with get_unaligned/put_unaligned(). However no reference in driver shows that 'struct i40e_dma_mem' directly shoved into NIC hardware. But instead fields of the struct are being read and used for hardware. Therefore, __packed is unnecessary for 'struct i40e_dma_mem'. In addition, although 'struct i40e_virt_mem' doesn't cause any unaligned access, keeping it packed is unnecessary as well because of aforementioned reason. This change make 'struct i40e_dma_mem' and 'struct i40e_virt_mem' unpacked. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * i40evf: remove unused device IDMitch Williams2017-02-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | This device ID was intended for use when running Linux VF drivers under Hyper-V, but we have determined that it is not necessary. Since it is unused, and will never be used, remove it. Change-ID: I74998ab4237db043cd400547bb54a0a5e2a37ea5 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>
| * i40e: Deprecating unused macroBimmy Pujari2017-02-024-18/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I40E_MAC_X710 was supposed to be for 10G and I40E_MAC_XL710 was supposed to be for 40G. But function i40e_is_mac_710 sets I40E_MAC_XL710 for all device IDS, I40E_MAC_X710 is not used at all. As there is nothing to compare there is no need for this function. Thus deprecating this extra macro and removing this function entirely and replacing it with a direct check. Change-ID: I7d1769954dccd574a290ac04adb836ebd156730e Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * i40e: when adding or removing MAC filters, correctly handle VLANsJacob Keller2017-02-022-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using i40e_add_filter or i40e_del_filter directly, when adding a MAC address, we should normally be using i40e_add_mac_filter or i40e_del_mac_filter. These functions correctly handle the various cases of VLAN mode or PVID settings. This ensures consistency and avoids the issues that can occur with the recent addition of a WARN_ON() in i40e_sync_vsi_filters. Change-ID: I7fe62db063391fdd1180b2d6a6a3c5ab4307eeee 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>
| * i40e: avoid O(n^2) loop when deleting all filtersJacob Keller2017-02-023-2/+3
| | | | | | | | | | | | | | | | | | | | | | Use __i40e_del_filter instead of using i40e_del_filter() which will avoid doing an additional search to delete a filter we already have the pointer for. Change-ID: Iea5a7e3cafbf8c682ed9d3b6c69cf5ff53f44daf 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>
| * i40e: rename i40e_put_mac_in_vlan and i40e_del_mac_all_vlanJacob Keller2017-02-023-16/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These functions purpose is to add a new MAC filter correctly, whether we're using VLANs or not. Their goal is to ensure that all active VLANs get the new MAC filter. Rename them so that their intent is clear. They function correctly regardless of whether we have any active VLANs or only have I40E_VLAN_ANY filters. The new names convey how they function in a more clear manner. Change-ID: Iec1961f968c0223a7132724a74e26a665750b107 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>
| * i40e: no need to check is_vsi_in_vlan before calling i40e_del_mac_all_vlanJacob Keller2017-02-021-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This function won't be appreciably slower when in VLAN mode, so there is no real reason to not just call it directly. In either case, we still must search the full table for a MAC/VLAN pair. We do get to stop searching a tiny bit early in the case of knowing we are not in VLAN mode, but this is a minor savings and we can avoid the code complexity by not having to worry about the check. Change-ID: I533412195b3a42f51cf629e3675dd5145aea8625 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>
| * i40e: fold the i40e_is_vsi_in_vlan check into i40e_put_mac_in_vlanJacob Keller2017-02-022-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | Fold the check for determining when to call i40e_put_mac_in_vlan directly into the function so that we don't need to decide which function to use ahead of time. This allows us to just call i40e_put_mac_in_vlan directly without having to check ahead of time. Change-ID: Ifff526940748ac14b8418be5df5a149502eed137 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>
| * i40e: don't allow i40e_vsi_(add|kill)_vlan to operate when VID<1Jacob Keller2017-02-022-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have the separate i40e_(add|rm)_vlan_all_mac functions, we should not be using the i40e_vsi_kill_vlan or i40e_vsi_add_vlan functions when PVID is set or when VID is less than 1. This allows us to remove some checks in i40e_vsi_add_vlan and ensures that callers which need to handle VID=0 or VID=-1 don't accidentally invoke the VLAN mode handling used to convert filters when entering VLAN mode. We also update the functions to take u16 instead of s16 as well since they no longer expect to be called with VID=I40E_VLAN_ANY. Change-ID: Ibddf44a8bb840dde8ceef2a4fdb92fd953b05a57 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>
* | ixgbevf: get rid of custom busy polling codeEric Dumazet2017-02-033-215/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In linux-4.5, busy polling was implemented in core NAPI stack, meaning that all custom implementation can be removed from drivers. Not only we remove lot's of code, we also remove one lock operation in fast path, and allow GRO to do its job. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ixgbe: get rid of custom busy polling codeEric Dumazet2017-02-034-224/+5
|/ | | | | | | | | | | | | | In linux-4.5, busy polling was implemented in core NAPI stack, meaning that all custom implementation can be removed from drivers. Not only we remove lot's of code, we also remove one lock operation in fast path, and allow GRO to do its job. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* drivers: net: generalize napi_complete_done()Eric Dumazet2017-01-302-2/+2
| | | | | | | | | | | | napi_complete_done() allows to opt-in for gro_flush_timeout, added back in linux-3.19, commit 3b47d30396ba ("net: gro: add a per device gro flush timer") This allows for more efficient GRO aggregation without sacrifying latencies. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Remove usage of net_device last_rx memberTobias Klauser2017-01-183-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The network stack no longer uses the last_rx member of struct net_device since the bonding driver switched to use its own private last_rx in commit 9f242738376d ("bonding: use last_arp_rx in slave_last_rx()"). However, some drivers still (ab)use the field for their own purposes and some driver just update it without actually using it. Previously, there was an accompanying comment for the last_rx member added in commit 4dc89133f49b ("net: add a comment on netdev->last_rx") which asked drivers not to update is, unless really needed. However, this commend was removed in commit f8ff080dacec ("bonding: remove useless updating of slave->dev->last_rx"), so some drivers added later on still did update last_rx. Remove all usage of last_rx and switch three drivers (sky2, atp and smc91c92_cs) which actually read and write it to use their own private copy in netdev_priv. Compile-tested with allyesconfig and allmodconfig on x86 and arm. Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jay Vosburgh <j.vosburgh@gmail.com> Cc: Veaceslav Falico <vfalico@gmail.com> Cc: Andy Gospodarek <andy@greyhouse.net> Cc: Mirko Lindner <mlindner@marvell.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net:add one common config ARCH_WANT_RELAX_ORDER to support relax orderingMao Wenan2017-01-181-1/+1
| | | | | | | | | | | | | | | Relax ordering(RO) is one feature of 82599 NIC, to enable this feature can enhance the performance for some cpu architecure, such as SPARC and so on. Currently it only supports one special cpu architecture(SPARC) in 82599 driver to enable RO feature, this is not very common for other cpu architecture which really needs RO feature. This patch add one common config CONFIG_ARCH_WANT_RELAX_ORDER to set RO feature, and should define CONFIG_ARCH_WANT_RELAX_ORDER in sparc Kconfig firstly. Signed-off-by: Mao Wenan <maowenan@huawei.com> Reviewed-by: Alexander Duyck <alexander.duyck@gmail.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2017-01-111-3/+3
|\ | | | | | | | | | | | | Two AF_* families adding entries to the lockdep tables at the same time. Signed-off-by: David S. Miller <davem@davemloft.net>
| * mm: rename __page_frag functions to __page_frag_cache, drop order from drainAlexander Duyck2017-01-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does two things. First it goes through and renames the __page_frag prefixed functions to __page_frag_cache so that we can be clear that we are draining or refilling the cache, not the frags themselves. Second we drop the order parameter from __page_frag_cache_drain since we don't actually need to pass it since all fragments are either order 0 or must be a compound page. Link: http://lkml.kernel.org/r/20170104023954.13451.5678.stgit@localhost.localdomain Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | net: intel: e100: use new api ethtool_{get|set}_link_ksettingsPhilippe Reynes2017-01-091-6/+8
| | | | | | | | | | | | | | | | The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes <tremyfr@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: remove useless memset's in drivers get_stats64stephen hemminger2017-01-081-1/+0
| | | | | | | | | | | | | | | | In dev_get_stats() the statistic structure storage has already been zeroed. Therefore network drivers do not need to call memset() again. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: make ndo_get_stats64 a void functionstephen hemminger2017-01-088-37/+24
| | | | | | | | | | | | | | | | | | | | | | | | The network device operation for reading statistics is only called in one place, and it ignores the return value. Having a structure return value is potentially confusing because some future driver could incorrectly assume that the return value was used. Fix all drivers with ndo_get_stats64 to have a void function. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | fm10k: remove FM10K_FLAG_DEBUG_STATSJacob Keller2017-01-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | The debug statistics were removed due to complications with the ethtool statistics API which are not possible to resolve without a new statistics interface. The flag was left behind, but we no longer need it. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k: report the receive timestamp in FM10K_CB(skb)->tstampJacob Keller2017-01-082-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This was accidentally removed when we defeatured the full 1588 Clock support. We need to report the Rx descriptor timestamp value so that applications built on top of the IES API can function properly. Additionally, remove the FM10K_FLAG_RX_TS_ENABLED, as it is not used now that 1588 functionality has been removed. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k: Limit dma sync of RX buffers to actual packet sizeScott Peterson2017-01-081-3/+5
| | | | | | | | | | | | | | | | | | | | | | On packet RX, we perform a dma sync for cpu before passing the packet up. Here we limit that sync to the actual length of the incoming packet, rather than always syncing the entire buffer. Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k: bump version numberJacob Keller2017-01-081-1/+1
| | | | | | | | | | | | Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k: do not clear global mailbox interrupt bitsNgai-Mint Kwan2017-01-081-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Partially revert commit 5e93cbadd3e9 ("fm10k: Reset mailbox global interrupts", 2016-06-07) The register bits related to this commit are now solely being handled by the IES API. Recent changes in the IES API will allow an automatic recovery from improper handling of these bits. Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k: request reset when mbx->state changesNgai-Mint Kwan2017-01-082-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multiple IES API resets can cause a race condition where the mailbox interrupt request bits can be cleared before being handled. This can leave certain mailbox messages from the PF to be untreated and the PF will enter in some inactive state. If this situation occurs, the IES API will initiate a mailbox version reset which, then, trigger a mailbox state change. Once this mailbox transition occurs (from OPEN to CONNECT state), a request for reset will be returned. This ensures that PF will undergo a reset whenever IES API encounters an unknown global mailbox interrupt event or whenever the IES API terminates. Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k: remove extraneous variable definition in fm10k_ethtool.cJacob Keller2017-01-081-12/+9
| | | | | | | | | | | | | | | | | | We don't need to typecast a u8 * into a char *, so just remove the extra variable. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | fm10k-shared: use mac-> instead of hw->mac.Ngai-Mint Kwan2017-01-081-3/+3
| | | | | | | | | | | | | | | | | | | | Since a pointer "mac" to fm10k_mac_info structure exists, use it to access the contents of its members. Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | igb: Fix hw_dbg logging in igb_update_flash_i210Hannu Lounento2017-01-061-2/+2
| | | | | | | | | | | | | | | | | | | | Fix an if statement with hw_dbg lines where the logic was inverted with regards to the corresponding return value used in the if statement. Signed-off-by: Hannu Lounento <hannu.lounento@ge.com> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | igb: add i211 to i210 PHY workaroundTodd Fujinaka2017-01-061-1/+1
| | | | | | | | | | | | | | | | | | i210 and i211 share the same PHY but have different PCI IDs. Don't forget i211 for any i210 workarounds. Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | igb: close/suspend race in netif_device_detachTodd Fujinaka2017-01-061-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to ixgbe, when an interface is part of a namespace it is possible that igb_close() may be called while __igb_shutdown() is running which ends up in a double free WARN and/or a BUG in free_msi_irqs(). Extend the rtnl_lock() to protect the call to netif_device_detach() and igb_clear_interrupt_scheme() in __igb_shutdown() and check for netif_device_present() to avoid calling igb_clear_interrupt_scheme() a second time in igb_close(). Also extend the rtnl lock in igb_resume() to netif_device_attach(). Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | igb: re-assign hw address pointer on reset after PCI errorGuilherme G Piccoli2017-01-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever the igb driver detects the result of a read operation returns a value composed only by F's (like 0xFFFFFFFF), it will detach the net_device, clear the hw_addr pointer and warn to the user that adapter's link is lost - those steps happen on igb_rd32(). In case a PCI error happens on Power architecture, there's a recovery mechanism called EEH, that will reset the PCI slot and call driver's handlers to reset the adapter and network functionality as well. We observed that once hw_addr is NULL after the error is detected on igb_rd32(), it's never assigned back, so in the process of resetting the network functionality we got a NULL pointer dereference in both igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid such bug, this patch re-assigns the hw_addr value in the slot_reset handler. Reported-by: Anthony H Thai <ahthai@us.ibm.com> Reported-by: Harsha Thyagaraja <hathyaga@in.ibm.com> Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
OpenPOWER on IntegriCloud