- 29 Mar, 2017 40 commits
-
-
Alexander Duyck authored
This patch pulls the code responsible for fetching the Rx buffer and synchronizing DMA into a function, specifically called i40e_get_rx_buffer. The general idea is to allow for better code reuse by pulling this out of i40e_fetch_rx_buffer. We dropped a couple of prefetches since the time between the prefetch being called and the data being accessed was too small to be useful. Change-ID: I4885fce4b2637dbedc8e16431169d23d3d7e79b9 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>
-
Alexander Duyck authored
This change makes it so that we use the length of the packet instead of the DD status bit to determine if a new descriptor is ready to be processed. The obvious advantage is that it cuts down on reads as we don't really even need the DD bit if going from a 0 to a non-zero value on size is enough to inform us that the packet has been completed. Change-ID: Iebdf9cdb36c454ef092df27199b92ad09c374231 Signed-off-by:
-
Jacob Keller authored
This flag hasn't been used since commit 1e1be8f6 ("i40e: ATR policy change to flush the table to clean stale ATR rules"). Lets simplify things and just remove it. Change-ID: I76279d84db8a2fd96f445b96aa413059f9256879 Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
-
Jacob Keller authored
The goto found here for when in MFP mode is pointless. It jumps to the end of a series of if blocks. However, right after this statement is a closing '}' for this if block, which will result in the program flow going to the exact same location as the goto statement indicates. Thus, regardless of whether we are in MFP mode, the program flow will resume from the same location. This arose due to various refactoring which did not notice that this goto became essentially a no-op. To properly understand this diff you will need to view a larger context than is given by default. Change-ID: I088f73c3831aa5c4e2281380c7a3ce605594300c Signed-off-by:
-
Christopher N Bednarz authored
Fix a case where we miss an arq element if a new one is added before we enable interrupts and exit the arq subtask loop. This occurs frequently with RDMA running on Windows VF and causes long delays that prevent SMB from establishing connections. Change-ID: I3e1c8b2b960c12857d9b8275bea2c1563674392e Signed-off-by:
Christopher N Bednarz <christopher.n.bednarz@intel.com> Tested-by:
-
Paul M Stillwell Jr authored
The XL722 doesn't support the AQ command to read/write the control register so enable it to bypass the check and use the direct read/write method. Change-ID: Iefecc737b57207485c90845af5989d5af518bf16 Signed-off-by:
Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by:
-
Alexander Duyck authored
This patch cleans up and addresses several issues in the way that i40e handles private flags. Previously the code was choosing fixed bits and trying to match them up with strings in a somewhat haphazard way. This resulted in the possibility for adding a new bit and causing a mismatch as the private flags are linear bits starting at 0, and the private flags in the driver were split up over a group specific to the PF and a group that was global. What this change does is define an array of structs used to represent the private flags. Contained within the structs are the bits necessary to know which flags to set and/or clear depending on the state of the bit. By doing this we can add new bits in the future with minimal overhead and avoid creating possible mis-matches should we need to remove a flag based on compile options. Change-ID: Ia3214ab04f0ab2f70354ac0997a135f1d01b0acd Signed-off-by:
-
Preethi Banala authored
The current driver mode is to use a write-back mechanism for the head register which indicates transmit completions. The VF driver needs to be able to work on hardware that exclusively uses descriptor write-back, so change the default driver mode of operation to descriptor write-back for VF. In our analysis, performance wasn't significantly different with either write-back method. Change-ID: Ia92e4ec77c2df8dc4515c71d53746d57d77759af Signed-off-by:
Preethi Banala <preethi.banala@intel.com> Signed-off-by:
-
David S. Miller authored
David Ahern says: ==================== netconf: Add support for RTM_DELNETCONF netconf notifications are sent as devices register but not when they are deleted leaving userspace caches out of sync. Add support for RTM_DELNETCONF to ipv4, ipv6 and mpls. MPLS is missing RTM_NEWNETCONF as devices are created, so add it as well. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David Ahern authored
Send netconf notifications for MPLS when the device registers and unregisters. Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
David Ahern authored
Refactor mpls_netconf_notify_devconf to take the event as an input arg. Signed-off-by:
-
David Ahern authored
Send RTM_DELNETCONF notifications when a device is deleted. The message only needs the device index, so modify inet6_netconf_fill_devconf to skip devconf references if it is NULL. Allows a userspace cache to remove entries as devices are deleted. Signed-off-by:
-
David Ahern authored
Refactor inet6_netconf_notify_devconf to take the event as an input arg. Signed-off-by:
-
David Ahern authored
Send RTM_DELNETCONF notifications when a device is deleted. The message only needs the device index, so modify inet_netconf_fill_devconf to skip devconf references if it is NULL. Allows a userspace cache to remove entries as devices are deleted. Signed-off-by:
-
David Ahern authored
Refactor inet_netconf_notify_devconf to take the event as an input arg. Signed-off-by:
-
David Ahern authored
Signed-off-by:
-
Prasad Kanneganti authored
Refactor interrupt moderation code for flexibility because parameters are different for 10G and 25G cards. Currently parameters (for 10G only) come from macros compiled-in to the PF and VF drivers; fix it so that parameters suitable for the card (10G or 25G) come from the NIC firmware via response to a command. Also bump up driver version to 1.5.1 to match newer NIC firmware version. Signed-off-by:
Prasad Kanneganti <prasad.kanneganti@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
Derek Chickles <derek.chickles@cavium.com> Signed-off-by:
-
Vivien Didelot authored
I do not hold the copyright of the DSA core and drivers source files, since these changes have been written as an initiative of my day job. Fix this. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vivien Didelot authored
Set the trunk member of the mv88e6xxx_atu_entry structure regardless its value, so that uninitialized structures gets the correct boolean value. Note that no mainline code is affected by the current behavior. Signed-off-by:
-
Vlad Yasevich authored
This patch adds support for NETDEV_RESEND_IGMP event similar to how it works for IPv4. Signed-off-by:
Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: fix chip definitions The definitions of some of the mv88e6xxx_ops and mv88e6xxx_info structures are misordered and erroneous for 88E6191 and 88E6391. This patch series cleans that up. ==================== Signed-off-by: -
Vivien Didelot authored
We don't support 88E6391 anywhere in the code, so remove the unused mv88e6391_ops structure. Signed-off-by:
-
Vivien Didelot authored
The mv88e6xxx_info structure for the 88E6191 chip was pointing the mv88e6391_ops definition instead of mv88e6191_ops. Fix this. Signed-off-by:
-
Vivien Didelot authored
The related mv88e6xxx_ops structure was misplaced. Reorder it correctly to fix this. Signed-off-by:
-
Vivien Didelot authored
The related mv88e6xxx_ops and mv88e6xxx_info structure were misplaced. Reorder them correctly to fix this. Signed-off-by:
-
David S. Miller authored
Yuval Mintz says: ==================== qed: load/unload mfw series This series correct the unload flow and greatly enhances its initialization flow in regard to interactions between driver and management firmware. Patch #1 makes sure unloading is done under management-firmware's 'criticial section' protection. Patches #2 - #4 move driver into using a newer scheme for loading in regard to the MFW; This newer scheme would help cleaning the device in case a previous instance has dirtied it [preboot, PDA, etc.]. Patches #5 - #6 let driver inform management-firmware on number of resources which are dependent on the non-management firmware used. Patch #7 then uses a new resource [BDQ] instead of some set value. ==================== Signed-off-by: -
Mintz, Yuval authored
Until now, qed used some port-defined value as BDQ index for both iSCSI and FCoE. As management firmware now treats BDQ as a resource and tells each PF its BDQ-range, start using a valure from that range instead. Signed-off-by:
Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by:
-
Tomer Tayar authored
Management firmware is used as an arbiter between the various PFs in matters of resources, but some of the resources that need to be divided are dependent on the non-management firmware used, so management firmware first needs to be told how many resources there are before trying to divide them. As part of the initialization sequence, driver would first inform the management firmware of the available resources under a dedicated resource lock, and afterwards request for various resources which might be based on the previous set values. Signed-off-by:
Tomer Tayar <Tomer.Tayar@cavium.com> Signed-off-by:
-
Tomer Tayar authored
Global locking can't properly be used to synchronize between different PFs in all scenarios, as those instances might reside in different logical partitions [e.g., when a PF is assigned via PDA to some VM]. The management firmware provides a generic infrastructure for device locks. For each 'resource', it's guaranteed it could be acquired by at most a single PF at any given time [or by management firmware]. This patch adds the necessary logic in qed for utilizing said infrastructure, implementing lock/unlock internal APIs. Signed-off-by:
-
Mintz, Yuval authored
During HW initialization, driver would set various registers to their needed values - but it assumes all registers start at their reset-value, so there's no need to re-configure a register's default value. This assumption might be incorrect, e.g., in case of preboot driver running and initializing the driver prior to our driver. To overcome this, we now ask management firmware to initiate a PF-flr early during the initialization sequence. That would return everything in the PF's scope back to default and prevent previous configurations from still being applied. Signed-off-by:
-
Tomer Tayar authored
Management firmware is used as an arbiter between the various PFs in regard to loading - it causes the various PFs to load/unload sequentially and informs each of its appropriate rule in the init. But the existing flow is too weak to handle some scenarios where PFs aren't properly cleaned prior to loading. The significant scenarios falling under this criteria: a. Preboot drivers in some environment can't properly unload. b. Unexpected driver replacement [kdump, PDA]. Modern management firmware supports a more intricate loading flow, where the driver has the ability to overcome previous limitations. This moves qed into using this newer scheme. Notice new scheme is backward compatible, so new drivers would still be able to load properly on top of older management firmwares and vice versa. Signed-off-by:
-
Mintz, Yuval authored
We'll soon need additional information, so start by changing the infrastructure to receive the initializing variables via a parameter struct. Signed-off-by:
-
Tomer Tayar authored
Management firmware is used as arbiter between different PFs which are loading/unloading, but in order to use the synchronization it offers the contending configurations need to be applied either between their LOAD_REQ <-> LOAD_DONE or UNLOAD_REQ <-> UNLOAD_DONE management firmware commands. Existing HW stop flow utilizes 2 different functions: qed_hw_stop() and qed_hw_reset() which don't abide this requirement; Most of the closure is doing outside the scope of the unload request. This patch removes qed_hw_reset() and places the relevant stop functionality underneath the management firmware protection. Signed-off-by:
-
David S. Miller authored
Parthasarathy Bhuvaragan says: ==================== tipc: subscription refcount simplifications The first patch makes the subscription refcount cleanup lockless and the second updates the subscription refcount policy. ==================== Signed-off-by: -
Ying Xue authored
When a new subscription object is inserted into name_seq->subscriptions list, it's under name_seq->lock protection; when a subscription is deleted from the list, it's also under the same lock protection; similarly, when accessing a subscription by going through subscriptions list, the entire process is also protected by the name_seq->lock. Therefore, if subscription refcount is increased before it's inserted into subscriptions list, and its refcount is decreased after it's deleted from the list, it will be unnecessary to hold refcount at all before accessing subscription object which is obtained by going through subscriptions list under name_seq->lock protection. Signed-off-by:
Ying Xue <ying.xue@windriver.com> Reviewed-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Ying Xue authored
After a subscription object is created, it's inserted into its subscriber subscrp_list list under subscriber lock protection, similarly, before it's destroyed, it should be first removed from its subscriber->subscrp_list. Since the subscription list is accessed with subscriber lock, all the subscriptions are valid during the lock duration. Hence in tipc_subscrb_subscrp_delete(), we remove subscription get/put and the extra subscriber unlock/lock. After this change, the subscriptions refcount cleanup is very simple and does not access any lock. Acked-by:
Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> Signed-off-by:
-
Arnd Bergmann authored
A driver must not access the two fields directly but should instead use the helper functions to set the values and keep a consistent internal state: ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe': ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' has no member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'? Fixes: a8f5102a ("net: stmmac: TX and RX queue priority configuration") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Bjorn Andersson authored
With the RPM driver transitioned to RPMSG we can reuse the SMD-RPM driver ontop of GLINK for 8996, without any modifications. Acked-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bjorn Andersson authored
Remove the standalone SMD implementation as we have transitioned the client drivers to use the RPMSG based one. Also remove all dependencies on QCOM_SMD from Kconfig files, in order to keep them selectable in the absence of the removed symbol. Acked-by:
-
Bjorn Andersson authored
By moving these client drivers to use RPMSG instead of the direct SMD API we can reuse them ontop of the newly added GLINK wire-protocol support found in the 820 and 835 Qualcomm platforms. As the new (RPMSG-based) and old SMD implementations are mutually exclusive we have to change all client drivers in one commit, to make sure we have a working system before and after this transition. Acked-by:
Kalle Valo <kvalo@codeaurora.org> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
