summaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet (follow)
Commit message (Collapse)AuthorAgeFilesLines
* net: cxgb3: Use net_device_stats from struct net_deviceTobias Klauser2017-04-072-2/+1
| | | | | | | | | Instead of using a private copy of struct net_device_stats in struct port_info, use stats from struct net_device. Cc: Santosh Raspatur <santosh@chelsio.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: cxgb: Use net_device_stats from struct net_deviceTobias Klauser2017-04-072-2/+1
| | | | | | | | Instead of using a private copy of struct net_device_stats in struct port_info, use stats from struct net_device. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* qede: Support XDP adjustment of headersMintz, Yuval2017-04-073-11/+12
| | | | | | | | | | | | | | | | In case an XDP program is attached, reserve XDP_PACKET_HEADROOM bytes at the beginning of the packet for the program to play with. Modify the XDP logic in the driver to fill-in the missing bits and re-calculate offsets and length after the program has finished running to properly reflect the current status of the packet. We can then go and remove the limitation of not supporting XDP programs where xdp_adjust_head is set. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qede: Add support for ingress headroomMintz, Yuval2017-04-073-17/+24
| | | | | | | | | | | | Driver currently doesn't support any headroom; The only 'available' space it has in the head of the buffer is due to the placement offset. In order to allow [later] support of XDP adjustment of headroom, modify the the ingress flow to properly handle a scenario where the packets would have such. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qede: Prevent VFs from using XDPMintz, Yuval2017-04-071-0/+5
| | | | | | | | | | | | Current implementation of VFs is very tight in regard to queue resources. VFs support for XDP would require quite a bit of additional infrastructure in qede and qed [sharing of queue-zones between queues, more VF cids, mapping of the doorbell bar, etc.]. For now, prevent XDP programs from being attached to VFs. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qede: Correct XDP forward unmappingMintz, Yuval2017-04-073-14/+20
| | | | | | | | | | | | | | | | Driver is currently using dma_unmap_single() with the address it passed to device for the purpose of forwarding, but the XDP transmission buffer was originally a page allocated for the rx-queue. The mapped address is likely to differ from the original mapped address due to the placement offset. This difference is going to get even bigger once we support headroom. Cache the original mapped address of the page, and use it for unmapping of the buffer when completion arrives for the XDP forwarded packet. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qede: Update receive statistic once per NAPIMintz, Yuval2017-04-071-10/+11
| | | | | | | | | | | Currently, each time an ingress packet is passed to networking stack the driver increments a per-queue SW statistic. As we want to have additional fields in the first cache-line of the Rx-queue struct, change flow so this statistic would be updated once per NAPI run. We will later push the statistic to a different cache line. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i40e: close client on remove and shutdownMitch Williams2017-04-071-0/+10
| | | | | | | | | | | When the driver is removed or shut down, close any attached clients (i.e. i40iw). This prevents a panic seen sometimes on forced driver removal or system shutdown when iWarp is running. Change-ID: I4f6161e5a73ffbb2fd5883567b007310302bfcb5 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: register existing client on probeMitch Williams2017-04-071-0/+6
| | | | | | | | | | In some cases, a client (i40iw) may already be present when probe is called. Check for this, and add a client instance if necessary. Change-ID: I2009312694b7ad81f1023919e4c6c86181f21689 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 client instance on driver unloadMitch Williams2017-04-071-0/+3
| | | | | | | | | | When the driver is unloaded, we need to remove the client instance, otherwise we leak memory. Change-ID: If1e7882ac1f6ce15d004722fafbe31afbe0adc9a 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: Add capability exchange for outer checksumPreethi Banala2017-04-076-56/+74
| | | | | | | | | | | | | | | | | | | This patch adds a capability negotiation between VF and PF using ENCAP/ ENCAP_CSUM offload flags in order for the VF to support outer checksum and TSO offloads for encapsulated packets. These capabilities were assumed by default and enabled in current hardware. Going forward, these features needs to be negotiated with PF before advertising to the stack. Additionally, strip out the mac.type checks for X722 since outer checksums are enabled based on the ENCAP_CSUM offload negotiation flag and maintain consistency between drivers in how the features are configured. Change-ID: Ie380a6f57eca557a2bb575b66b12fae36d308920 Signed-off-by: Preethi Banala <preethi.banala@intel.com> Signed-off-by: Alan Brady <alan.brady@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> 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>
* ftgmac100: Work around HW bug in runt frame detectionBenjamin Herrenschmidt2017-04-071-10/+25
| | | | | | | | | | | | | | | | The HW incorrectly calculates the frame size without the vlan tag and compares that against 64. It will thus flag 64-bytes frames with a vlan tag as 60-bytes frames "runt" packets which we'll then drop. Thus we end up dropping ARP packets on vlan's ... It does that whether vlan tag stripping is enabled or not. This works around it by ignoring the "runt" error bit of the frame has been vlan tagged and is at least 60 bytes. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Remove rx descriptor accessorsBenjamin Herrenschmidt2017-04-072-115/+53
| | | | | | | | | Directly access the fields when needed. The accessors add clutter not clarity and in some cases cause unnecessary read-modify-write type access on the slow (uncached) descriptor memory. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Add missing barrier in ftgmac100_rx_packet()Benjamin Herrenschmidt2017-04-071-0/+3
| | | | | Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Directly receive into sk_buffsBenjamin Herrenschmidt2017-04-071-86/+56
| | | | | | | | | | | | | | | | | | | | | | The current driver receive path allocates pages and stashes them into SKB fragments. This is not particularly useful as we don't support jumbo frames (which wouldn't be great with the small FIFOs on all the known implementations) anyway. It also makes us flush the caches and allocate more memory for RX than necessary. So set our RX buf to our max packet size instead (which we bump to 1536 bytes to account for packets with vlan tags etc...) like most other ethernet drivers. Then allocate skbs when populating the receive ring and DMA directly into them. This simplifies the RX path further. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Simplify rx pointer handling in the rx pathBenjamin Herrenschmidt2017-04-071-68/+24
| | | | | | | | | | | | We don't handle fragmented RX packets, so the "looping" helpers to locate the first segment of a packet or to drop a packet aren't actually helping. Take them out and simplify ftgmac100_rx_packet() further as a result. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Simplify rx packets error handlingBenjamin Herrenschmidt2017-04-071-36/+25
| | | | | | | | | | | | The fast path has a single unlikely() test for any error bit, calling into a helper that sets the appropriate statistics. The various netdev_info aren't particularly interesting. If we want to differentiate the various length errors later we can introduce driver specific stats using ethtool. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Cleanup rx checksum handlingBenjamin Herrenschmidt2017-04-071-38/+25
| | | | | | | | Read the descriptor field only once and check for IP header checksum errors as well Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Use a scratch buffer for failed RX allocationsBenjamin Herrenschmidt2017-04-071-4/+38
| | | | | | | | | | | | | | | | | We can occasionally fail to allocate new RX buffers at runtime or when starting the driver. At the moment the latter just fails to open which is fine but the former leaves stale DMA pointers in the ring. Instead, use a scratch page and have all RX ring descriptors point to it by default unless a proper buffer can be allocated. It will help later on when re-initializing the whole ring at runtime on link changes since there is no clean failure path there unlike open(). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Drop support for fragmented receiveBenjamin Herrenschmidt2017-04-071-19/+18
| | | | | | | | | | | | | We don't support jumbo frames, we will never receive a fragmented packet, the RX buffer is always big enough, if not then it's a runaway packet that can be dropped. So take out the loop that handles such things in ftgmac100_rx_packet() which will help with subsequent simplifications and improvements to the RX path Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* ftgmac100: Move ftgmac100_alloc_rx_page() before its usersBenjamin Herrenschmidt2017-04-071-31/+28
| | | | | | | Avoids a forward declaration Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Make OOO archipelagos into an arrayMichal Kalderon2017-04-062-78/+30
| | | | | | | | | | No need to maintain the various open archipelagos as a list - The maximal number of them is known, and we can use the CID as key for random-access into the array. Signed-off-by: Michal Kalderon <Michal.Kalderon@caviumc.om> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Provide iSCSI statistics to managementMintz, Yuval2017-04-063-1/+38
| | | | | | | | Management firmware can query for some basic iSCSI-related statistics. Provide those just as we do for other protocols. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Inform qedi the number of possible CQsMintz, Yuval2017-04-063-2/+19
| | | | | | | | | Now that management firmware is capable of telling us the number of CQs available for a given PF, qed needs to communicate the number to qedi so it would know have many to use. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Add missing stat for new islesMintz, Yuval2017-04-061-0/+2
| | | | | | | | Firmware provides a statistic for the number of out-of-order isles it used - fill it in the iscsi-related statistics. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Don't close the OUT_EN during initMintz, Yuval2017-04-061-12/+0
| | | | | | | | | | | | | | Before initializing the chip's engine, driver currently closes a set of registers on the HW's ingress flow to prevent packets from slipping in while they're not supposed to. This configuration is insufficient, as there are some scenarios where packets would still arrive even when said registers are set, but the management firmware already closes other per-port registers that do suffice, making this setting unnecessray. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Configure cacheline size in HWTomer Tayar2017-04-062-0/+54
| | | | | | | | | | | | Default HW configuration is optimal for an architecture where cache line size is 64B. During chip initialization, properly initialize the cache line size in HW to avoid possible redundant PCI transactions. Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Don't use main-ptt in unrelated flowsRahul Verma2017-04-068-61/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to access HW registers driver needs to acquire a PTT entry [mapping between bar memory and internal chip address]. Since acquiring PTT entries could fail [at least in theory] as their number is finite and other flows can hold them, we reserve special PTT entries for 'important' enough flows - ones we want to guarantee that would not be susceptible to such issues. One such special entry is the 'main' PTT which is meant to be used in flows such as chip initialization and de-initialization. However, there are other flows that are also using that same entry for their own purpose, and might run concurrently with the original flows [notice that for most cases using the main-ptt by mistake, such a race is still impossible, at least today]. This patch re-organizes the various functions that currently use the main_ptt in one of two ways: - If a function shouldn't use the main_ptt it starts acquiring and releasing it's own PTT entry and use it instead. Notice if those functions previously couldn't fail, they now can [as acquisition might fail]. - Change the prototypes so that the main_ptt would be received as a parameter [instead of explicitly accessing it]. This prevents the future risk of adding codes that introduces new use-cases for flows using the main_ptt, ones that might be in race with the actual 'main' flows. Signed-off-by: Rahul Verma <Rahul.Verma@cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: Warn PTT usage by wrong hw-functionMintz, Yuval2017-04-061-0/+7
| | | | | | | | | | PTT entries are per-hwfn; If some errneous flow is trying to use a PTT belonging to a differnet hwfn warn user, as this can break every register accessing flow later and is very hard to root-cause. Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '100GbE' of ↵David S. Miller2017-04-065-133/+239
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2017-04-05 This series contains updates to fm10k only. Phil Turnbull from Oracle fixes an issue where the argument provided to FM10K_REMOVED macro was not what was expecting. Jake modifies the driver to replace the bitwise operators and defines with a BITMAP and enumeration values to avoid race conditions. Also future proof the driver so that developers do not have to remember to re-size the bitmaps when adding new values. Fixed the wording of a code comment to avoid stating that we return a value for a void function. Ngai-Mint makes sure that when configuring the receive ring, we make sure the receive queue is disabled. Fixed an issue where interfaces were resetting because the transmit mailbox FIFO was becoming full since the host was not ready, so ensure the host is ready before queueing up mailbox messages. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * fm10k: do not enqueue mailbox when host not readyNgai-Mint Kwan2017-04-061-25/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interfaces will reset whenever the TX mailbox FIFO has become full. This occurs more frequently whenever the IES API application is not running to process and clear the messages in the FIFO. Thus, this could lead to situations where the interface would enter an infinite reset loop. That is: if the interface is trying to synchronize a huge number of unicast and multicast entries with the IES API application, the TX mailbox FIFO will become full and the interface resets. Once the interface exits reset, it'll try to synchronize the unicast and multicast entries again. Ergo, this creates an infinite loop. Other actions such as multiple mulitcast mode or up/down transitions will fill the TX mailbox FIFO and induce the interface to reset. To correct these situations, check if the interface's "host_ready" flag is enabled before enqueuing any messages to the TX mailbox FIFO. This check will be conducted by a function call. Lastly, this issue mainly affects the PF and, thus, the VF is exempt. 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: disable receive queue when configuring ringNgai-Mint Kwan2017-04-061-0/+1
| | | | | | | | | | | | | | | | | | Write to RXQCTL register to disable the receive queue when configuring the RX ring. Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * fm10k: update function header comment for fm10k_get_stats64Jacob Keller2017-04-061-2/+2
| | | | | | | | | | | | | | | | | | | | Re-word the comment to avoid stating that we return a value for this void function. Additionally, there is no need to mention older kernels, since this is the upstream kernel. 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 service task to reschedule itselfJacob Keller2017-04-062-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If some code path executes fm10k_service_event_schedule(), it is guaranteed that we only queue the service task once, since we use __FM10K_SERVICE_SCHED flag. Unfortunately this has a side effect that if a service request occurs while we are currently running the watchdog, it is possible that we will fail to notice the request and ignore it until the next time the request occurs. This can cause problems with pf/vf mailbox communication and other service event tasks. To avoid this, introduce a FM10K_SERVICE_REQUEST bit. When we successfully schedule (and set the _SCHED bit) the service task, we will clear this bit. However, if we are unable to currently schedule the service event, we just set the new SERVICE_REQUEST bit. Finally, after the service event completes, we will re-schedule if the request bit has been set. This should ensure that we do not miss any service event schedules, since we will re-schedule it once the currently running task finishes. This means that for each request, we will always schedule the service task to run at least once in full after the request came in. This will avoid timing issues that can occur with the service event scheduling. We do pay a cost in re-running many tasks, but all the service event tasks use either flags to avoid duplicate work, or are tolerant of being run multiple times. 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: future-proof state bitmaps using DECLARE_BITMAPJacob Keller2017-04-065-57/+61
| | | | | | | | | | | | | | | | | | | | | | This ensures that future programmers do not have to remember to re-size the bitmaps due to adding new values. Although this is unlikely for this driver, it may happen and it's best to prevent it from ever being an issue. 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 a BITMAP for flags to avoid race conditionsJacob Keller2017-04-065-48/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace bitwise operators and #defines with a BITMAP and enumeration values. This is similar to how we handle the "state" values as well. This has two distinct advantages over the old method. First, we ensure correctness of operations which are currently problematic due to race conditions. Suppose that two kernel threads are running, such as the watchdog and an ethtool ioctl, and both modify flags. We'll say that the watchdog is CPU A, and the ethtool ioctl is CPU B. CPU A sets FLAG_1, which can be seen as CPU A read FLAGS CPU A write FLAGS | FLAG_1 CPU B sets FLAG_2, which can be seen as CPU B read FLAGS CPU A write FLAGS | FLAG_2 However, "|=" and "&=" operators are not actually atomic. So this could be ordered like the following: CPU A read FLAGS -> variable CPU B read FLAGS -> variable CPU A write FLAGS (variable | FLAG_1) CPU B write FLAGS (variable | FLAG_2) Notice how the 2nd write from CPU B could actually undo the write from CPU A because it isn't guaranteed that the |= operation is atomic. In practice the race windows for most flag writes is incredibly narrow so it is not easy to isolate issues. However, the more flags we have, the more likely they will cause problems. Additionally, if such a problem were to arise, it would be incredibly difficult to track down. Second, there is an additional advantage beyond code correctness. We can now automatically size the BITMAP if more flags were added, so that we do not need to remember that flags is u32 and thus if we added too many flags we would over-run the variable. This is not a likely occurrence for fm10k driver, but this patch can serve as an example for other drivers which have many more flags. This particular change does have a bit of trouble converting some of the idioms previously used with the #defines for flags. Specifically, when converting FM10K_FLAG_RSS_FIELD_IPV[46]_UDP flags. This whole operation was actually quite problematic, because we actually stored flags separately. This could more easily show the problem of the above re-ordering issue. This is really difficult to test whether atomics make a difference in practical scenarios, but you can ensure that basic functionality remains the same. This patch has a lot of code coverage, but most of it is relatively simple. While we are modifying these files, update their copyright year. 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: correctly check if interface is removedPhil Turnbull2017-04-061-1/+1
| | | | | | | | | | | | | | | | | | FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'. Fixes: 5cb8db4a4cbc ("fm10k: Add support for VF") Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | net: ethernet: wiznet: avoid format string exposureKees Cook2017-04-061-1/+2
| | | | | | | | | | | | | | | | While unlikely, this makes sure any format strings in the device name can't exposure information via the resulting workqueue name. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | qlge: avoid format string exposure in workqueueKees Cook2017-04-061-1/+2
| | | | | | | | | | | | | | | | While unlikely, this makes sure the workqueue name won't be processed as a format string. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | qed: Correct MSI-x for storageMintz, Yuval2017-04-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When qedr is enabled, qed would try dividing the msi-x vectors between L2 and RoCE, starting with L2 and providing it with sufficient vectors for its queues. Problem is qed would also do that for storage partitions, and as those don't need queues it would lead qed to award those partitions with 0 msi-x vectors, causing them to believe theye're using INTa and preventing them from operating. Fixes: 51ff17251c9c ("qed: Add support for RoCE hw init") Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | mlx4: trust shinfo->gso_segsEric Dumazet2017-04-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | mlx4 is the only driver in the tree making a point to recompute shinfo->gso_segs. Lets remove superfluous code. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Tariq Toukan <tariqt@mellanox.com> Cc: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | qed: fix missing break in OOO_LB_TC caseColin Ian King2017-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | There seems to be a missing break on the OOO_LB_TC case, pq_id is being assigned and then re-assigned on the fall through default case and that seems suspect. Detected by CoverityScan, CID#1424402 ("Missing break in switch") Fixes: b5a9ee7cf3be1 ("qed: Revise QM cofiguration") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net/mlx5e: fix build error without CONFIG_SYSFSTobias Regnery2017-04-061-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9008ae074885 ("net/mlx5e: Minimize mlx5e_{open/close}_locked") copied the calls to netif_set_real_num_{tx,rx}_queues from mlx5e_open_locked to mlx5e_activate_priv_channels and wraps them in an if condition to test for netdev->real_num_{tx,rx}_queues. But netdev->real_num_rx_queues is conditionally compiled in if CONFIG_SYSFS is set. Without CONFIG_SYSFS the build fails: drivers/net/ethernet/mellanox/mlx5/core/en_main.c: In function 'mlx5e_activate_priv_channels': drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2515:12: error: 'struct net_device' has no member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'? Fix this by unconditionally call netif_set_real_num{tx,rx}_queues like before commit 9008ae074885. Fixes: 9008ae074885 ("net/mlx5e: Minimize mlx5e_{open/close}_locked") Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Rework NAPI & interrupts handlingBenjamin Herrenschmidt2017-04-062-61/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First, don't look at the interrupt status in the poll loop to decide what to poll. It's wrong. If we have run out of budget, we may still have RX packets to unqueue but no more RX interrupt pending. So instead move the code looking at the interrupt status into the interrupt handler where it belongs. That avoids a slow MMIO read in the NAPI fast path. We keep the abnormal interrupts enabled while NAPI is scheduled. While at it, actually do something useful in the "error" cases: On AHB bus error, trigger the new reset task, that's about all we can do. On RX packet fifo or descriptor overflows, we need to restart the MAC after having freed things up. So set a flag that NAPI will see and use to perform that restart after harvesting the RX ring. Finally, we shouldn't complete NAPI if there are still outgoing packets that will need harvesting. Waiting for more interrupts is less efficient than letting NAPI run a while longer while the queue drains. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Remove useless tests in interrupt handlerBenjamin Herrenschmidt2017-04-061-8/+3
| | | | | | | | | | | | | | | | | | The interrupt is neither enabled nor registered when the interface isn't running (regardless of whether we use nc-si or not) so the test isn't useful. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Rework MAC reset and initBenjamin Herrenschmidt2017-04-061-39/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HW requires a full MAC reset when changing the speed. Additionally the Aspeed documentation spells out that the MAC needs to be reset twice with a 10us interval. We thus move the speed setting and top level reset code into a new ftgmac100_reset_and_config_mac() function which handles both. Move the ring pointers initialization there too in order to reflect the HW change. Also reduce the timeout for the MAC reset as it shouldn't take more than 300 clock cycles according to the doc. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Add a reset task and use it for link changesBenjamin Herrenschmidt2017-04-061-13/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Link speed changes require a full HW reset. This isn't done properly at the moment. It will involve delays and thus isn't suitable to do from the link poll callback. So let's create a reset_task that we can queue up when the link changes. It will be useful for various cases of error handling as well. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Move the bulk of inits to a separate functionBenjamin Herrenschmidt2017-04-061-29/+42
| | | | | | | | | | | | | | | | | | | | | | | | The link monitoring and error handling code will have to redo the ring inits and HW setup so move the code out of ftgmac100_open() into a dedicated function. This forces a bit of re-ordering of ftgmac100_open() but nothing dramatic. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Request the interrupt only after HW is resetBenjamin Herrenschmidt2017-04-061-9/+10
| | | | | | | | | | | | | | | | The interrupt isn't shared, so this will keep it masked until we have the HW in a known sane state. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ftgmac100: Move napi_add/del to open/closeBenjamin Herrenschmidt2017-04-061-3/+5
| | | | | | | | | | | | | | Rather than probe/remove Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-02 22:54:38 +0100