1. 16 Mar, 2015 10 commits
  2. 15 Mar, 2015 18 commits
  3. 14 Mar, 2015 12 commits
    • Florian Fainelli's avatar
      net: dsa: do not use slave MII bus for fixed PHYs · 96026d05
      Florian Fainelli authored
      Commit cd28a1a9 ("net: dsa: fully divert PHY reads/writes if
      requested") introduced a check for particular PHYs that need to be
      accessed using the slave MII bus created by DSA, but this check was too
      inclusive. This would prevent fixed PHYs from being successfully
      registered because those should not go through the slave MII bus created
      by DSA.
      
      Make sure we check that the PHY is not a fixed PHY to prevent that from
      happening.
      
      Fixes: cd28a1a9 ("net: dsa: fully divert PHY reads/writes if requested")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96026d05
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 316ad4be
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2015-03-13
      
      This series contains updates to ixgbe and ixgbevf.
      
      Don adds additional support for X550 MAC types, which require additional
      steps around enabling and disabling Rx.  Also cleans up variable type
      inconsistency.
      
      I provide a patch to allow relaxed ordering to be enabled on SPARC
      architectures.  Also cleans up ixgbevf whitespace and code comments to
      align the driver with networking coding standard.  Lastly cleaned up
      uses of memcpy() where ether_addr_copy() could have been used.
      
      Alex removes some dead code in the ixgbe cleanup patch.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      316ad4be
    • David S. Miller's avatar
      Merge branch 'listener_refactor_part_9' · 6922022a
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      inet: tcp listener refactoring, part 9
      
      This preliminary work pushes socket convergence a bit more:
      
      1) request sock ir_iif is universally set
      
      2) inet_diag can use common helpers to reduce LOC
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6922022a
    • Eric Dumazet's avatar
      inet_diag: factorize code in new inet_diag_msg_common_fill() helper · a4458343
      Eric Dumazet authored
      Now the three type of sockets share a common base, we can factorize
      code in inet_diag_msg_common_fill().
      
      inet_diag_entry no longer requires saddr_storage & daddr_storage
      and the extra copies.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4458343
    • Eric Dumazet's avatar
      inet_diag: adjust inet_sk_diag_fill() bug condition · a07c9207
      Eric Dumazet authored
      inet_sk_diag_fill() only copes with non timewait and non request socks
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a07c9207
    • Eric Dumazet's avatar
      inet: fill request sock ir_iif for IPv4 · 16f86165
      Eric Dumazet authored
      Once request socks will be in ehash table, they will need to have
      a valid ir_iff field.
      
      This is currently true only for IPv6. This patch extends support
      for IPv4 as well.
      
      This means inet_diag_fill_req() can now properly use ir_iif,
      which is better for IPv6 link locals anyway, as request sockets
      and established sockets will propagate consistent netlink idiag_if.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16f86165
    • David S. Miller's avatar
      Merge branch 'tipc-next' · a3795208
      David S. Miller authored
      Jon Maloy says:
      
      ====================
      tipc: some optimizations and impovements
      
      The commits in this series contain some relatively simple changes that
      lead to better throughput across TIPC connections. We also make changes
      to the implementation of link transmission queueing and priority
      handling, in order to make the code more comprehensible and maintainable.
      
      v2: Commit #2: Redesigned tipc_msg_validate() to use pskb_may_pull(),
                     as per feedback from David Miller.
          Commit #3: Some cosmetic changes to tipc_msg_extract(). I tried to
                     replace the unconditional skb_linearize() with calls to
                     pskb_may_pull() at selected locations, but I gave up.
                     First, skb_trim() requires a fully linearized buffer.
                     Second, it doesn't make much sense; the whole buffer
                     will end up linearized, one way or another.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3795208
    • Jon Paul Maloy's avatar
      tipc: clean up handling of message priorities · e3eea1eb
      Jon Paul Maloy authored
      Messages transferred by TIPC are assigned an "importance priority", -an
      integer value indicating how to treat the message when there is link or
      destination socket congestion.
      
      There is no separate header field for this value. Instead, the message
      user values have been chosen in ascending order according to perceived
      importance, so that the message user field can be used for this.
      
      This is not a good solution. First, we have many more users than the
      needed priority levels, so we end up with treating more priority
      levels than necessary. Second, the user field cannot always
      accurately reflect the priority of the message. E.g., a message
      fragment packet should really have the priority of the enveloped
      user data message, and not the priority of the MSG_FRAGMENTER user.
      Until now, we have been working around this problem in different ways,
      but it is now time to implement a consistent way of handling such
      priorities, although still within the constraint that we cannot
      allocate any more bits in the regular data message header for this.
      
      In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
      that will be the only one used apart from the four (lower) user data
      levels. All non-data messages map down to this priority. Furthermore,
      we take some free bits from the MSG_FRAGMENTER header and allocate
      them to store the priority of the enveloped message. We then adjust
      the functions msg_importance()/msg_set_importance() so that they
      read/set the correct header fields depending on user type.
      
      This small protocol change is fully compatible, because the code at
      the receiving end of a link currently reads the importance level
      only from user data messages, where there is no change.
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3eea1eb
    • Jon Paul Maloy's avatar
      tipc: split link outqueue · 05dcc5aa
      Jon Paul Maloy authored
      struct tipc_link contains one single queue for outgoing packets,
      where both transmitted and waiting packets are queued.
      
      This infrastructure is hard to maintain, because we need
      to keep a number of fields to keep track of which packets are
      sent or unsent, and the number of packets in each category.
      
      A lot of code becomes simpler if we split this queue into a transmission
      queue, where sent/unacknowledged packets are kept, and a backlog queue,
      where we keep the not yet sent packets.
      
      In this commit we do this separation.
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05dcc5aa
    • Jon Paul Maloy's avatar
      tipc: eliminate unnecessary call to broadcast ack function · 2cdf3918
      Jon Paul Maloy authored
      The unicast packet header contains a broadcast acknowledge sequence
      number, that may need to be conveyed to the broadcast link for proper
      treatment. Currently, the function tipc_rcv(), which is on the most
      critical data path, calls the function tipc_bclink_acknowledge() to
      have this done. This call is made for each received packet, and results
      in the unconditional grabbing of the broadcast link spinlock.
      
      This is unnecessary, since we can see directly from tipc_rcv() if
      the acknowledged number differs from what has been previously acked
      from the node in question. In the vast majority of cases the numbers
      won't differ, and there is nothing to update.
      
      We now make the call to tipc_bclink_acknowledge() conditional
      to that the two ack values differ.
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cdf3918
    • Jon Paul Maloy's avatar
      tipc: extract bundled buffers by cloning instead of copying · c1336ee4
      Jon Paul Maloy authored
      When we currently extract a bundled buffer from a message bundle in
      the function tipc_msg_extract(), we allocate a new buffer and explicitly
      copy the linear data area.
      
      This is unnecessary, since we can just clone the buffer and do
      skb_pull() on the clone to move the data pointer to the correct
      position.
      
      This is what we do in this commit.
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1336ee4
    • Jon Paul Maloy's avatar
      tipc: eliminate unnecessary linearization of incoming buffers · 1149557d
      Jon Paul Maloy authored
      Currently, TIPC linearizes all incoming buffers directly at reception
      before passing them upwards in the stack. This is clearly a waste of
      CPU resources, and must be avoided.
      
      In this commit, we eliminate this unnecessary linearization. We still
      ensure that at least the message header is linear, and that the buffer
      is linearized where this is still needed, i.e. when unbundling and when
      reversing messages.
      
      In addition, we ensure that fragmented messages are validated after
      reassembly before delivering them upwards in the stack.
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1149557d