summaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/intel/fm10k
Commit message (Collapse)AuthorAgeFilesLines
* fm10k: fix memory leakstephen hemminger2015-11-181-1/+3
| | | | | | | | | This was detected by Coverity. The function skb_cow_head leaves skb alone on failure, so caller needs to free. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* drivers/net/intel: use napi_complete_done()Jesse Brandeburg2015-10-161-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per Eric Dumazet's previous patches: (see commit (24d2e4a50737) - tg3: use napi_complete_done()) Quoting verbatim: Using napi_complete_done() instead of napi_complete() allows us to use /sys/class/net/ethX/gro_flush_timeout GRO layer can aggregate more packets if the flush is delayed a bit, without having to set too big coalescing parameters that impact latencies. </end quote> Tested configuration: low latency via ethtool -C ethx adaptive-rx off rx-usecs 10 adaptive-tx off tx-usecs 15 workload: streaming rx using netperf TCP_MAERTS igb: MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.1 () port 0 AF_INET : demo ... Interim result: 941.48 10^6bits/s over 1.000 seconds ending at 1440193171.589 Alignment Offset Bytes Bytes Recvs Bytes Sends Local Remote Local Remote Xfered Per Per Recv Send Recv Send Recv (avg) Send (avg) 8 8 0 0 1176930056 1475.36 797726 16384.00 71905 MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.1 () port 0 AF_INET : demo ... Interim result: 941.49 10^6bits/s over 0.997 seconds ending at 1440193142.763 Alignment Offset Bytes Bytes Recvs Bytes Sends Local Remote Local Remote Xfered Per Per Recv Send Recv Send Recv (avg) Send (avg) 8 8 0 0 1175182320 50476.00 23282 16384.00 71816 i40e: Hard to test because the traffic is incoming so fast (24Gb/s) that GRO always receives 87kB, even at the highest interrupt rate. Other drivers were only compile tested. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* drivers/net: get rid of unnecessary initializations in .get_drvinfo()Ivan Vecera2015-10-161-4/+0
| | | | | | | | | | | | Many drivers initialize uselessly n_priv_flags, n_stats, testinfo_len, eedump_len & regdump_len fields in their .get_drvinfo() ethtool op. It's not necessary as these fields is filled in ethtool_get_drvinfo(). v2: removed unused variable v3: removed another unused variable Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* fm10k: do not use enum as booleanJacob Keller2015-10-131-1/+1
| | | | | | | | | | Check for actual value NETREG_UNINITIALIZED in case it ever changes from the current value of zero. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: use snprintf() instead of sprintf() to avoid buffer overflowJacob Keller2015-10-132-7/+7
| | | | | | | Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: add support for extra debug statisticsJacob Keller2015-09-226-36/+243
| | | | | | | | | | | Add a private ethtool flag to enable display of these statistics, which are generally less useful. However, sometimes it can be useful for debugging purposes. The most useful portion is the ability to see what the PF thinks the VF mailboxes look like. 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: TRIVIAL remove unnecessary commaJacob Keller2015-09-221-2/+2
| | | | | | 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: create "correct" header for the remote end on connectJacob Keller2015-09-221-1/+24
| | | | | | | | | | | | | | | | | When we connect to the mailbox, we insert a fake disconnect header so that the code does not see an invalid header and thus instantly error every time we bring up the mailbox. However, we incorrectly record the tail and head from the local perspective. Since the remote end shouldn't have anything for us, add a "create_fake_disconnect_hdr" function which inverts the TAIL and HEAD fields. This enables us to connect without any errors of either TAIL or HEAD incorrectness, and prevents creating extraneous error messages. This is necessary now since mbx_reset_work does not actually reset the Tx FIFO head and tail pointers, thus head and tail might not be equivalent on a reconnect. 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: drop transmitted messages in Tx FIFO as part of reset_workJacob Keller2015-09-221-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a corner case issue with the PF/VF mailbox code. Currently, fm10k_mbx_reset_work clears various state about the mailbox. However, it does not clear the Tx FIFO head/tail pointers. We can't simply clear these pointers as we unintentionally drop untransmitted messages without error. Doing nothing results in a possible phantom re-transmission of messages, since we leave tx.head and tx.tail intact, but clear the tx_pulled and tail_len values. This means that the PF could continuously re-send a message which triggers a reset in the VF. Upon reset, the VF will re-receive the same message after a reconnect. If we reset the tx.head and tx.tail pointers completely, we end up dropping some messages that were pending before connect. This results in missing LPORT_MSG_READY bits, and VFs will end up reporting no link. However, we can resolve both issues by simply incrementing head to account for the already transmitted messages, before we reset tx_pulled. We do this via the same logic as fm10k_mbx_head_pull. We account for the tail_len which includes all data not yet transmitted, once we account for the acked data which means re-reading the HEAD variable from the message header. Then, we drop messages until we've dropped more than the new tx_pulled value. At this point, resetting tail_len and tx_pulled, but not tx.head and tx.tail will result in prevention of the phantom message. It also prevents us from dropping untransmitted messages upon attempting to Tx into a connect or disconnect header. 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 comment about rtnl_lock around mbx operationsJacob Keller2015-09-221-3/+1
| | | | | | | | | | | This comment is no longer true due to a couple of mailbox locking refactors, and we now don't actually do any rtnl protected operations directly in the mailbox path. Remove this comment as it is factually incorrect and confusing. 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: fix iov_msg_mac_vlan_pf VID checksJacob Keller2015-09-151-33/+52
| | | | | | | | | | | | | | | | | | | | | | The VF will send a message to request multicast addresses with the default VID. In the current code, if the PF has statically assigned a VLAN to a VF, then the VF will not get the multicast addresses. Fix up all of the various VLAN messages to use identical checks (since each check was different). Also use set as a variable, so that it simplifies our check for whether VLAN matches the pf_vid. The new logic will allow set of a VLAN if it is zero, automatically converting to the default VID. Otherwise it will allow setting the PF VID, or any VLAN if PF has not statically assigned a VLAN. This is consistent behavior, and allows VF to request either 0 or the default_vid without silently failing. Note that we need the check for zero since VFs might not get the default VID message in time to actually request non-zero VLANs. 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: Only trigger data path reset if fabric is upAlexander Duyck2015-09-151-0/+6
| | | | | | | | | | | | This change makes it so that we only trigger the data path reset if the fabric is ready to handle traffic. The general idea is to avoid triggering the reset unless the switch API is ready for us. Otherwise we can just postpone the reset until we receive a switch ready notification. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: re-enable VF after a full reset on detection of a Malicious eventJacob Keller2015-09-151-2/+28
| | | | | | | | | | | | | | | | | | Modify behavior of Malicious Driver Detection events. Presently, the hardware disables the VF queues and re-assigns them to the PF. This causes the VF in question to continuously Tx hang, because it assumes that it can transmit over the queues in question. For transient events, this results in continuous logging of malicious events. New behavior is to reset the LPORT and VF state, so that the VF will have to reset and re-enable itself. This does mean that malicious VFs will possibly be able to continue and attempt malicious events again. However, it is expected that system administrators will step in and manually remove or disable the VF in question. 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: TRIVIAL fix typo in fm10k_netdev.cJacob Keller2015-09-151-1/+1
| | | | | Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: send traffic on default VID to VLAN device if we have oneJacob Keller2015-09-153-1/+20
| | | | | | | | | | | | | | | | This patch ensures that VLAN traffic on the default VID will go to the corresponding VLAN device if it exists. To do this, mask the rx_ring VID if we have an active VLAN on that VID. For this to work correctly, we need to update fm10k_process_skb_fields to correctly mask off the VLAN_PRIO_MASK bits and compare them separately, otherwise we incorrectly compare the priority bits with the cleared flag. This also happens to fix a related bug where having priority bits set causes us to incorrectly classify traffic. 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: TRIVIAL fix up ordering of __always_unused and styleJacob Keller2015-09-151-2/+3
| | | | | | | | | | Fix some style issues in debugfs code, and correct ordering of void and __always_unused. Technically, the order does not matter, but preferred style is to put the macro between the type and name. 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 is_slot_appropriateJacob Keller2015-09-153-29/+0
| | | | | | | | | This function is no longer used now that we have updated fm10k_slot_warn functionality. 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: don't store sw_vid at resetJacob Keller2015-09-151-3/+0
| | | | | | | | | | | | | | | If we store the sw_vid at reset of PF, then we accidentally prevent the VF from receiving the message to update its default VID. This only occurs if the VF is created before the PF has come up, which is the standard way of creating VFs when using the module parameter. This fixes an issue where we request the incorrect MAC/VLAN combinations, and prevents us from accidentally reporting some frames as VLAN tagged. 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: allow creation of VLAN interfaces even while downJacob Keller2015-09-151-0/+6
| | | | | | | | | | We re-sync upon going up, so there is little reason to worry about not syncing immediately with switch. This prevents an error that occurs if you add a VLAN interface while down. 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 MAC address on driver loadAlexander Duyck2015-09-151-0/+3
| | | | | | | | | | | | This change adds the MAC address to the list of values recorded on driver load. The MAC address represents the serial number of the unit and allows us to track the value should a card be replaced in a system. The log message should now be similar in output to that of ixgbe. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: Don't assume page fragments are page sizeAlexander Duyck2015-09-151-6/+1
| | | | | | | | | | | | This change pulls out the optimization that assumed that all fragments would be limited to page size. That hasn't been the case for some time now and to assume this is incorrect as the TCP allocator can provide up to a 32K page fragment. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Acked-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: update netdev perm_addr during reinit, instead of at upJacob Keller2015-09-152-15/+15
| | | | | | | | | | | Update the netdev permanent address during fm10k_reinit enables the user to immediately see the new MAC address on the VF even if the device isn't up. The previous code required that the device by opened before changes would appear. 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: update fm10k_slot_warn to use pcie_get_minimum linkJacob Keller2015-09-151-29/+76
| | | | | | | | | | | | | | | This is useful in cases where we connect to a slot at Gen3, but the slot is behind a bus which only connected at Gen2. This generally only happens when a PCIe switch is in the sequence of devices, and can be very confusing when you see slow performance with no obvious cause. I am aware this patch has a few lines that break 80 characters, but there does not seem to be a readable way to format them to less than 80 characters. Suggestions welcome. 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: only prevent removal of default VID rulesJacob Keller2015-09-151-2/+2
| | | | | | | | | | | | | This allows us to correctly add a VLAN even if it matches our default VID. However, we don't want to remove the VID rules once that VLAN is deleted. Correctly remove the stack layers information of the VLAN, but then return to forwarding that VID as untagged frames. If we deleted the VID rules here, we would begin dropping traffic due to VLAN membership violations. 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: disable service task during suspendJacob Keller2015-09-151-0/+19
| | | | | | | | | | | | | | | The service task reads some registers as part of its normal routine, even while the interface is down. Normally this is ok. However, during suspend we have disabled the PCI device. Due to this, registers will read in the same way as a surprise-remove event. Disable the service task while we suspend, and re-enable it after we resume. If we don't do this, the device could be UP when you suspend and come back from resume as closed (since fm10k closes the device when it gets a surprise remove). 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>
* mm: make page pfmemalloc check more robustMichal Hocko2015-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb") added checks for page->pfmemalloc to __skb_fill_page_desc(): if (page->pfmemalloc && !page->mapping) skb->pfmemalloc = true; It assumes page->mapping == NULL implies that page->pfmemalloc can be trusted. However, __delete_from_page_cache() can set set page->mapping to NULL and leave page->index value alone. Due to being in union, a non-zero page->index will be interpreted as true page->pfmemalloc. So the assumption is invalid if the networking code can see such a page. And it seems it can. We have encountered this with a NFS over loopback setup when such a page is attached to a new skbuf. There is no copying going on in this case so the page confuses __skb_fill_page_desc which interprets the index as pfmemalloc flag and the network stack drops packets that have been allocated using the reserves unless they are to be queued on sockets handling the swapping which is the case here and that leads to hangs when the nfs client waits for a response from the server which has been dropped and thus never arrive. The struct page is already heavily packed so rather than finding another hole to put it in, let's do a trick instead. We can reuse the index again but define it to an impossible value (-1UL). This is the page index so it should never see the value that large. Replace all direct users of page->pfmemalloc by page_is_pfmemalloc which will hide this nastiness from unspoiled eyes. The information will get lost if somebody wants to use page->index obviously but that was the case before and the original code expected that the information should be persisted somewhere else if that is really needed (e.g. what SLAB and SLUB do). [akpm@linux-foundation.org: fix blooper in slub] Fixes: c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb") Signed-off-by: Michal Hocko <mhocko@suse.com> Debugged-by: Vlastimil Babka <vbabka@suse.com> Debugged-by: Jiri Bohac <jbohac@suse.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Miller <davem@davemloft.net> Acked-by: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> [3.6+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* fm10k: Fix missing braces after if statementAlexander Duyck2015-06-171-1/+2
| | | | | | | | | | | While reviewing the code I noticed that one of the commits added an if statement followed by a for loop, but the if statement was missing the braces around the loop. This change corrects the coding style error. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Acked-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: fix iov_msg_lport_state_pf issueJacob Keller2015-06-171-0/+8
| | | | | | | | | | | | | | When a VF issues an LPORT_STATE request to enable a port that is already enabled, the PF will first disable the VF LPORT. Then it should re-enable the VF again with the new requested settings. This ensures that any switch rules are cleared by deleting the LPORT on the switch. However, the flow is bugged because we actually check if the VF is enabled at the end, and thus don't re-enable it. Fix the flow so that we actually clear the enabled flags as part of our removal of the LPORT. 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 err_no reference in fm10k_mbx.cJacob Keller2015-06-171-5/+0
| | | | | | | | | | The reference to err_no was left around after a previous code refactor. We never use the value, and it doesn't seem to be used in side a hidden macro reference. Discovered via cppcheck. 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: fix incorrect DIR_NEVATIVE bit in 1588 codeJacob Keller2015-06-172-3/+3
| | | | | | | | | | The SYSTIME_CFG.Adjust Direction bit is actually supposed to indicate that the adjustment is positive. Fix the code to align correctly with hardware and documentation. 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: pack TLV overlay structuresJacob Keller2015-06-171-4/+4
| | | | | | | | | | | | | This patch adds the __attribute__((packed)) indicator to some structures which are overlayed onto a TLV message. These structures must be packed as small as possible in order to correctly align when copied into the mailbox buffer. Without doing so, the receiving mailbox code incorrectly parses the values and we get invalid message responses from the switch manager software. 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: re-map all possible VF queues after a VFLRJacob Keller2015-06-171-0/+6
| | | | | | | | | | | | | | During initialization, the VF counts its rings by walking the TQDLOC registers. This works only if the TQMAP/RQMAP registers are set to map all of the out-of-bound rings back to the first one. This allows the VF to cleanly detect when it has run out of queues. Update the PF code so that it resets the empty TQMAP/RQMAP registers post-VFLR to prevent innocent VF drivers from triggering malicious driver events. Signed-off-by: Matthew Vick <matthew.vick@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: force LPORT delete when updating VLAN or MAC addressJacob Keller2015-06-171-15/+23
| | | | | | | | | | | | | | | Currently, we don't notify the switch at all when the PF administratively sets a new VLAN or MAC address. This causes the old addresses to remain valid on the switch table. Since the PF is overriding any configuration done directly by the VF, we choose to simply re-create the LPORT for the VF. This does mean that all rules for the VF will be dropped when we set something directly via the PF, but it prevents some weird issues where the MAC/VLAN table retains some stale configuration. 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: use dma_set_mask_and_coherent in fm10k_probeJacob Keller2015-06-171-18/+6
| | | | | | | | | | | | | | | | This patch cleans up the use of dma_get_required_mask and uses the simpler dma_set_mask_and_coherent function instead of doing these as separate steps. I removed the dma_get_required_mask call because based on some minimal testing it appears that either (a) we're not doing the right thing with the call or (b) we don't need it anyways. If the value returned is <48bits, we'll end up trying with 48 bits anyways. If it's over 48bits, fm10k can't support that anyways, and we should try 48bits. If 48bits fails, we'll fallback to 32bits. This cleans up some very funky code. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: trivial fixup message style to include a colonJacob Keller2015-06-171-1/+1
| | | | | | | | Also use %d for error values, since printing in hexadecimal is probably not helpful. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: remove extraneous NULL check on l2_accelJacob Keller2015-06-171-2/+1
| | | | | | | | | | l2_accel was checked for NULL at the top of fm10k_dfwd_del_station, and we return if it is not defined. Due to this, we already know it can't be null here so a separate check is meaningless. Discovered via cppcheck. 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: use an unsigned int for i in ethtool_get_stringsJacob Keller2015-06-171-1/+1
| | | | | | | | The value will never be negative, and we use the %u print format. Thus, use unsigned int for the loop counter. Issue found using cppcheck. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: add call to fm10k_clean_all_rx_rings in fm10k_downJacob Keller2015-06-171-0/+1
| | | | | | | | | | | | | | | This prevents a memory leak in fm10k_set_ringparams. The leak occurs because we go down, change ring parameters, and then come up. However, fm10k_down on its own is not clearing the Rx rings. Since fm10k_up assumes the rings are clean we basically drop the buffers and leak a bunch of memory. Eventually we hit dirty page faults and reboot the system. This issue does not occur elsewhere because other flows that involve fm10k_down go through fm10k_close which immediately called fm10k_free_all_rx_resources which properly cleans the rings. 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: fix incorrect free on skb in ts_tx_enqueueJacob Keller2015-06-171-1/+1
| | | | | | | | | | | | | | | | | | This patch resolves a bug in the ts_tx_enqueue code responsible for a NULL pointer dereference and invalid access of the skb list. We incorrectly freed the actual skb we found instead of our copy. Thus the skb queue is essentially invalidated. Resolve this by freeing our clone in the cases where we did not add it to the queue. This also avoids the skb memory leak caused by failure to free the clone. [ 589.719320] BUG: unable to handle kernel NULL pointer dereference at (null) [ 589.722344] IP: [<ffffffffa0310e60>] fm10k_ts_tx_subtask+0xb0/0x160 [fm10k] [ 589.723796] PGD 0 [ 589.725228] Oops: 0000 [#1] SMP 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: move setting shinfo inside ts_tx_enqueueJacob Keller2015-06-171-3/+3
| | | | | | | | | | This patch simplifies the code flow for setting the IN_PROGRESS bit of the shinfo for an skb we will be timestamping. Reported-by: Eric Dumazet <eric.dumazet@gmail.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: use correct ethernet driver Tx timestamp functionJacob Keller2015-06-171-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | skb_complete_tx_timestamp is intended for use by PHY drivers which implement a different method of returning timestamps. This method is intended to be used after a PHY driver accepts a cloned packet via its phy_driver.txtstamp function. It is not correct to use in the standard ethernet driver such as fm10k. This patch fixes the following possible kernel panic. [ 2744.552896] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W OE 3.19.3-200.fc21.x86_64 #1 [ 2744.552899] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.8x23.060520140825 06/05/2014 [ 2744.552901] 0000000000000000 2f4c8b10ea3f9848 ffff88081ee03a38 ffffffff8176e215 [ 2744.552906] 0000000000000000 0000000000000000 ffff88081ee03a78 ffffffff8109bc1a [ 2744.552910] ffff88081ee03c50 ffff88080e55fc00 ffff88080e55fc00 ffffffff81647c50 [ 2744.552914] Call Trace: [ 2744.552917] <IRQ> [<ffffffff8176e215>] dump_stack+0x45/0x57 [ 2744.552931] [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0 [ 2744.552936] [<ffffffff81647c50>] ? skb_queue_purge+0x20/0x40 [ 2744.552941] [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20 [ 2744.552946] [<ffffffff81646911>] skb_release_head_state+0xe1/0xf0 [ 2744.552950] [<ffffffff81647b26>] skb_release_all+0x16/0x30 [ 2744.552954] [<ffffffff81647ba6>] kfree_skb+0x36/0x90 [ 2744.552958] [<ffffffff81647c50>] skb_queue_purge+0x20/0x40 [ 2744.552964] [<ffffffff81751f8d>] packet_sock_destruct+0x1d/0x90 [ 2744.552968] [<ffffffff81642053>] __sk_free+0x23/0x140 [ 2744.552973] [<ffffffff81642189>] sk_free+0x19/0x20 [ 2744.552977] [<ffffffff81647d60>] skb_complete_tx_timestamp+0x50/0x60 [ 2744.552988] [<ffffffffa02eee40>] fm10k_ts_tx_hwtstamp+0xd0/0x100 [fm10k] [ 2744.552994] [<ffffffffa02e054e>] fm10k_1588_msg_pf+0x12e/0x140 [fm10k] [ 2744.553002] [<ffffffffa02edf1d>] fm10k_tlv_msg_parse+0x8d/0xc0 [fm10k] [ 2744.553010] [<ffffffffa02eb2d0>] fm10k_mbx_dequeue_rx+0x60/0xb0 [fm10k] [ 2744.553016] [<ffffffffa02ebf98>] fm10k_sm_mbx_process+0x178/0x3c0 [fm10k] [ 2744.553022] [<ffffffffa02e09ca>] fm10k_msix_mbx_pf+0xfa/0x360 [fm10k] [ 2744.553030] [<ffffffff811030a7>] ? get_next_timer_interrupt+0x1f7/0x270 [ 2744.553036] [<ffffffff810f2a47>] handle_irq_event_percpu+0x77/0x1a0 [ 2744.553041] [<ffffffff810f2bab>] handle_irq_event+0x3b/0x60 [ 2744.553045] [<ffffffff810f5d6e>] handle_edge_irq+0x6e/0x120 [ 2744.553054] [<ffffffff81017414>] handle_irq+0x74/0x140 [ 2744.553061] [<ffffffff810bb54a>] ? atomic_notifier_call_chain+0x1a/0x20 [ 2744.553066] [<ffffffff8177777f>] do_IRQ+0x4f/0xf0 [ 2744.553072] [<ffffffff8177556d>] common_interrupt+0x6d/0x6d [ 2744.553074] <EOI> [<ffffffff81609b16>] ? cpuidle_enter_state+0x66/0x160 [ 2744.553084] [<ffffffff81609b01>] ? cpuidle_enter_state+0x51/0x160 [ 2744.553087] [<ffffffff81609cf7>] cpuidle_enter+0x17/0x20 [ 2744.553092] [<ffffffff810de101>] cpu_startup_entry+0x321/0x3c0 [ 2744.553098] [<ffffffff81764497>] rest_init+0x77/0x80 [ 2744.553103] [<ffffffff81d4f02c>] start_kernel+0x4a4/0x4c5 [ 2744.553107] [<ffffffff81d4e120>] ? early_idt_handlers+0x120/0x120 [ 2744.553110] [<ffffffff81d4e4d7>] x86_64_start_reservations+0x2a/0x2c [ 2744.553114] [<ffffffff81d4e62b>] x86_64_start_kernel+0x152/0x175 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: ignore invalid multicast address entriesJacob Keller2015-06-171-7/+1
| | | | | | | | | | | | | | | | | | This change fixes an issue with adding an invalid multicast address using the iproute2 tool (ip maddr add <MADDR> dev <dev>). The iproute2 tool and the kernel do not validate or filter the multicast addresses when adding them to the multicast list. Thus, when synchronizing this list with an invalid entry, the action will be aborted with an error since the fm10k driver currently validates the list. Consequently, multicast entries beyond the invalid one will not be processed and communicated with the switch via the mailbox. This change makes it so that invalid addresses will simply be skipped and allows synchronizing the full list to proceed. 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: fold fm10k_pull_tail into fm10k_add_rx_fragAlexander Duyck2015-06-171-46/+20
| | | | | | | | | | This change folds the fm10k_pull_tail call into fm10k_add_rx_frag. The advantage to doing this is that the fragment doesn't have to be modified after it is added to the skb. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: Do not assume budget will never be 0 for NAPIAlexander Duyck2015-05-041-2/+2
| | | | | | | | | | The netpoll path will call napi->poll with a budget of 0 in order to clean the Tx rings only. This change updates the fm10k driver so that it will correctly support that instead of cleaning 1 Rx frame if a budget of 0 is received. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* fm10k: Bump driver version to 0.15.2Jeff Kirsher2015-04-141-1/+1
| | | | | | | With the recent driver changes, bump the version. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
* fm10k: corrected VF multicast updateJeff Kirsher2015-04-141-2/+5
| | | | | | | | | | | | | VFs were being improperly added to the switch's multicast group. The error stems from the fact that incorrect arguments were passed to the "update_mc_addr" function. It would seem to be a copy paste error since the parameters are similar to the "update_uc_addr" function. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: mbx_update_max_size does not drop all oversized messagesJeff Kirsher2015-04-141-3/+6
| | | | | | | | | | | | | | | | | | | | | | When we call update_max_size it does not drop all oversized messages. This is due to the difficulty in performing this operation, since it is a FIFO which makes updating anything other than head or tail very difficult. To fix this, modify validate_msg_size to ensure that we error out later when trying to transmit the message that could be oversized. This will generally be a rare condition, as it requires the FIFO to include a message larger than the max_size negotiated during mailbox connect. Note that max_size is always smaller than rx.size so it should be safe to use here. Also, update the update_max_size function header comment to clearly indicate that it does not drop all oversized messages, but only those at the head of the FIFO. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: reset head instead of calling update_max_sizeJeff Kirsher2015-04-141-2/+16
| | | | | | | | | | | | | | | When we forcefully shutdown the mailbox, we then go about resetting max size to 0, and clearing all messages in the FIFO. Instead, we should just reset the head pointer so that the FIFO becomes empty, rather than changing the max size to 0. This helps prevent increment in tx_dropped counter during mailbox negotiation, which is confusing to viewers of Linux ethtool statistics output. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: renamed mbx_tx_dropped to mbx_tx_oversizedJeff Kirsher2015-04-141-1/+1
| | | | | | | | | | | | The use of dropped doesn't really mean dropped mailbox messages, but rather specifically messages which were too large to fit in the remote Rx FIFO. Rename the stat to more clearly indicate what it means. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* fm10k: update xcast mode before synchronizing multicast addressesJeff Kirsher2015-04-141-11/+11
| | | | | | | | | | | | | | When the PF receives a request to update a multicast address for the VF, it checks the enabled multicast mode first. Fix a bug where the VF tried to set a multicast address before requesting the required xcast mode. This ensures the multicast addresses are honored as long as the xcast mode was allowed. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-25 04:01:39 +0000