- 06 Feb, 2015 34 commits
-
-
Emil Tantilov authored
This change combines the reset and watchdog tasklets into a single task. The advantage of this is that we can avoid multiple schedules of the reset task when we have a reset event needed due to either the mailbox going down or transmit packets being present on a link down. CC: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Emil Tantilov authored
This patch cleans up the logic dealing with link down/up by breaking down the link detection and up/down events into separate functions - similar to how these events are handled in other drivers. CC: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
Emil Tantilov authored
This patch adds code to allow for Tx hang checking. The idea is to provide more robust debug info in the event of a transmit unit hang. Similar to the logic in ixgbe. CC: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
Emil Tantilov authored
This patch updates the ordering of the shutdown path so that we attempt to shutdown the rings more gracefully. Basically the big changes are that we shutdown the main Rx filter in the case of Rx and we set the carrier_off state in the case of Tx so that packets stop being delivered from outside the driver. Then we shut down interrupts and NAPI. Finally we stop the rings from performing DMA and clean them. This is a bit more graceful than the previous path. CC: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
Emil Tantilov authored
Clean up the setting of vlan_features by enabling all features at once. Signed-off-by:
-
Don Skidmore authored
Add support VXLAN receive checksum offload in X550 hardware. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Signed-off-by:
-
Don Skidmore authored
We always identify the PHY in our reset_hw path anyway so there is no need to do it in get_invariants(). The reason I even noticed this is that for new hardware (X550em) we don't assign some methods until later in probe and calling phy.ops.read_reg could lead to a panic. Signed-off-by:
-
Don Skidmore authored
My original patch 6a14ee0c "ixgbe: Add X550 support function pointers" accidental set a default value for this structure member twice. Signed-off-by:
-
Emil Tantilov authored
This patch fixes couple of issues introduced by commit 2b509c0c ("ixgbe: cleanup ixgbe_ndo_set_vf_vlan") - fix setting of the VLAN inside ixgbe_enable_port_vlan() - disable the "hide VLAN" bit in PFQDE when port VLAN is disabled Signed-off-by:
Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by:
-
Emil Tantilov authored
X550 provides RSS registers for configuring RSS per VF. This patch introduces ixgbevf_setup_vfmrqc() which uses the VFRETA, VFRSSRK and VFMRQC registers to configure RSS on X550. Signed-off-by:
-
Emil Tantilov authored
This patch enables multiple queues and RSS support for the VF. Maximum of 2 queues are supported due to available vectors. Signed-off-by:
-
Emil Tantilov authored
ixgbe_set_sriov_queues() has the logic to allow multiple queues, this patch just removes the limitation. Signed-off-by:
-
Don Skidmore authored
This patch cleans up prototypes that should have been defined as static. Signed-off-by:
-
Matthew Vick authored
Fix two cases where variables are being set but not used. Signed-off-by:
Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh<Krishneil.k.singh@intel.com> Signed-off-by:
-
Matthew Vick authored
Currently, fm10k_update_xc_addr_pf has an issue where it does not properly drop the upper-most four bits of the VLAN ID due to type promotion. Resolve the issue not by masking off the bits, but by throwing an error if the VLAN ID is out-of-bounds. Reported-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: vxge-config.c:4640:30: warning: Using plain integer as NULL pointer Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Lad, Prabhakar authored
this patch fixes following sparse warning: interface.c:83:5: warning: symbol 'xenvif_poll' was not declared. Should it be static? Signed-off-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static? Alongside drops exporting of gem_ethtool_ops as there is no need. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warnings: bnx2x_main.c:9172:6: warning: symbol 'bnx2x_stop_ptp' was not declared. Should it be static? bnx2x_main.c:13321:6: warning: symbol 'bnx2x_register_phc' was not declared. Should it be static? bnx2x_main.c:14638:5: warning: symbol 'bnx2x_enable_ptp_packets' was not declared. Should it be static? Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warnings: enic_main.c:92:28: warning: symbol 'mod_table' was not declared. Should it be static? enic_main.c:109:28: warning: symbol 'mod_range' was not declared. Should it be static? enic_main.c:1306:5: warning: symbol 'enic_busy_poll' was not declared. Should it be static? Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: enic_ethtool.c:95:6: warning: symbol 'enic_intr_coal_set_rx' was not declared. Should it be static? Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: be_cmds.c:2750:5: warning: symbol 'be_cmd_set_qos' was not declared. Should it be static? Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: cxgb4_dcb.c:25:6: warning: symbol 'dcb_ver_array' was not declared. Should it be static? Alongside making it const. Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warnings: netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared. Should it be static? rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was not declared. Should it be static? rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not declared. Should it be static? Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: resolve message disordering problem When TIPC receives messages from multi-threaded device drivers it may occasionally deliver messages to their destination sockets in the wrong order. This happens despite correct resequencing at the link layer, because the upcall path from link to socket is not protected by any locks. These commits solve this problem by introducing an 'input' message queue in each link, through which messages must be delivered to the upper layers. ==================== Signed-off-by: -
Jon Paul Maloy authored
In a previous commit in this series we resolved a race problem during unicast message reception. Here, we resolve the same problem at multicast reception. We apply the same technique: an input queue serializing the delivery of arriving buffers. The main difference is that here we do it in two steps. First, the broadcast link feeds arriving buffers into the tail of an arrival queue, which head is consumed at the socket level, and where destination lookup is performed. Second, if the lookup is successful, the resulting buffer clones are fed into a second queue, the input queue. This queue is consumed at reception in the socket just like in the unicast case. Both queues are protected by the same lock, -the one of the input queue. Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Jon Paul Maloy authored
The structure 'tipc_port_list' is used to collect port numbers representing multicast destination socket on a receiving node. The list is not based on a standard linked list, and is in reality optimized for the uncommon case that there are more than one multicast destinations per node. This makes the list handling unecessarily complex, and as a consequence, even the socket multicast reception becomes more complex. In this commit, we replace 'tipc_port_list' with a new 'struct tipc_plist', which is based on a standard list. We give the new list stack (push/pop) semantics, someting that simplifies the implementation of the function tipc_sk_mcast_rcv(). Reviewed-by:
-
Jon Paul Maloy authored
The new input message queue in struct tipc_link can be used for delivering connection abort messages to subscribing sockets. This makes it possible to simplify the code for such cases. This commit removes the temporary list in tipc_node_unlock() used for transforming abort subscriptions to messages. Instead, the abort messages are now created at the moment of lost contact, and then added to the last failed link's generic input queue for delivery to the sockets concerned. Reviewed-by:
-
Jon Paul Maloy authored
TIPC handles message cardinality and sequencing at the link layer, before passing messages upwards to the destination sockets. During the upcall from link to socket no locks are held. It is therefore possible, and we see it happen occasionally, that messages arriving in different threads and delivered in sequence still bypass each other before they reach the destination socket. This must not happen, since it violates the sequentiality guarantee. We solve this by adding a new input buffer queue to the link structure. Arriving messages are added safely to the tail of that queue by the link, while the head of the queue is consumed, also safely, by the receiving socket. Sequentiality is secured per socket by only allowing buffers to be dequeued inside the socket lock. Since there may be multiple simultaneous readers of the queue, we use a 'filter' parameter to reduce the risk that they peek the same buffer from the queue, hence also reducing the risk of contention on the receiving socket locks. This solves the sequentiality problem, and seems to cause no measurable performance degradation. A nice side effect of this change is that lock handling in the functions tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that will enable future simplifications of those functions. Reviewed-by:
-
Jon Paul Maloy authored
The list for outgoing traffic buffers from a socket is currently allocated on the stack. This forces us to initialize the queue for each sent message, something costing extra CPU cycles in the most critical data path. Later in this series we will introduce a new safe input buffer queue, something that would force us to initialize even the spinlock of the outgoing queue. A closer analysis reveals that the queue always is filled and emptied within the same lock_sock() session. It is therefore safe to use a queue aggregated in the socket itself for this purpose. Since there already exists a queue for this in struct sock, sk_write_queue, we introduce use of that queue in this commit. Reviewed-by:
-
Jon Paul Maloy authored
The function tipc_msg_eval() is in reality doing two related, but different tasks. First it tries to find a new destination for named messages, in case there was no first lookup, or if the first lookup failed. Second, it does what its name suggests, evaluating the validity of the message and its destination, and returning an appropriate error code depending on the result. This is confusing, and in this commit we choose to break it up into two functions. A new function, tipc_msg_lookup_dest(), first attempts to find a new destination, if the message is of the right type. If this lookup fails, or if the message should not be subject to a second lookup, the already existing tipc_msg_reverse() is called. This function performs prepares the message for rejection, if applicable. Reviewed-by:
-
Jon Paul Maloy authored
The code for enqueuing arriving buffers in the function tipc_sk_rcv() contains long code lines and currently goes to two indentation levels. As a cosmetic preparaton for the next commits, we break it out into a separate function. Reviewed-by:
-
Jon Paul Maloy authored
Despite recent improvements, the handling of error codes and return values at reception of messages in the socket layer is still confusing. In this commit, we try to make it more comprehensible. First, we separate between the return values coming from the functions called by tipc_sk_rcv(), -those are TIPC specific error codes, and the return values returned by tipc_sk_rcv() itself. Second, we don't use the returned TIPC error code as indication for whether a buffer should be forwarded/rejected or not; instead we use the buffer pointer passed along with filter_msg(). This separation is necessary because we sometimes want to forward messages even when there is no error (i.e., protocol messages and successfully secondary looked up data messages). Reviewed-by:
-
Jon Paul Maloy authored
The most common usage of namespace information is when we fetch the own node addess from the net structure. This leads to a lot of passing around of a parameter of type 'struct net *' between functions just to make them able to obtain this address. However, in many cases this is unnecessary. The own node address is readily available as a member of both struct tipc_sock and tipc_link, and can be fetched from there instead. The fact that the vast majority of functions in socket.c and link.c anyway are maintaining a pointer to their respective base structures makes this option even more compelling. In this commit, we introduce the inline functions tsk_own_node() and link_own_node() to make it easy for functions to fetch the node address from those structs instead of having to pass along and dereference the namespace struct. In particular, we make calls to the msg_xx() functions in msg.{h,c} context independent by directly passing them the own node address as parameter when needed. Those functions should be regarded as leaves in the code dependency tree, and it is hence desirable to keep them namspace unaware. Apart from a potential positive effect on cache behavior, these changes make it easier to introduce the changes that will follow later in this series. Reviewed-by:
-
- 05 Feb, 2015 6 commits
-
-
Takashi Iwai authored
Pass the static attribute groups and the driver data via tty_port_register_device_attr() instead of manual device_create_file() and device_remove_file() calls. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David S. Miller authored
Bas Peters says: ==================== Fix checkpatch errors in drivers/isdn/isdnloop This patchset adresses various checkpatch errors in the abovementioned driver. ==================== Signed-off-by: -
Bas Peters authored
drivers: isdn: isdnloop: isdnloop.c: Remove parenthesis around return values, as specified in CodingStyle. Signed-off-by:
Bas Peters <baspeters93@gmail.com> Signed-off-by:
-
Bas Peters authored
Signed-off-by:
-
Bas Peters authored
drivers: isdn: isdnloop: isdnloop.c: remove assignment of variables in if conditions, in accordance with the CodingStyle. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Conflicts: drivers/net/vxlan.c drivers/vhost/net.c include/linux/if_vlan.h net/core/dev.c The net/core/dev.c conflict was the overlap of one commit marking an existing function static whilst another was adding a new function. In the include/linux/if_vlan.h case, the type used for a local variable was changed in 'net', whereas the function got rewritten to fix a stacked vlan bug in 'net-next'. In drivers/vhost/net.c, Al Viro's iov_iter conversions in 'net-next' overlapped with an endainness fix for VHOST 1.0 in 'net'. In drivers/net/vxlan.c, vxlan_find_vni() added a 'flags' parameter in 'net-next' whereas in 'net' there was a bug fix to pass in the correct network namespace pointer in calls to this function. Signed-off-by:
-
