1. 25 8月, 2015 34 次提交
  2. 24 8月, 2015 6 次提交
    • S
      net: phy: add interrupt support for aquantia phy · 54cf7be9
      Shaohui Xie 提交于
      By implementing config_intr & ack_interrupt, now the phy can support
      link connect/disconnect interrupt.
      Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      54cf7be9
    • D
      Merge tag 'nfc-next-4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next · d9893d13
      David S. Miller 提交于
      Samuel Ortiz says:
      
      ====================
      NFC 4.3 pull request
      
      This is the NFC pull request for 4.3.
      With this one we have:
      
      - A new driver for Samsung's S3FWRN5 NFC chipset. In order to
        properly support this driver, a few NCI core routines needed
        to be exported. Future drivers like Intel's Fields Peak will
        benefit from this.
      
      - SPI support as a physical transport for STM st21nfcb.
      
      - An additional netlink API for sending replies back to userspace
        from vendor commands.
      
      - 2 small fixes for TI's trf7970a
      
      - A few st-nci fixes.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9893d13
    • J
      route: fix breakage after moving lwtunnel state · 751a587a
      Jiri Benc 提交于
      __recnt and related fields need to be in its own cacheline for performance
      reasons. Commit 61adedf3 ("route: move lwtunnel state to dst_entry")
      broke that on 32bit archs, causing BUILD_BUG_ON in dst_hold to be triggered.
      
      This patch fixes the breakage by moving the lwtunnel state to the end of
      dst_entry on 32bit archs. Unfortunately, this makes it share the cacheline
      with __refcnt and may affect performance, thus further patches may be
      needed.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Fixes: 61adedf3 ("route: move lwtunnel state to dst_entry")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      751a587a
    • D
      Merge tag 'linux-can-next-for-4.3-20150820' of... · 31fbde99
      David S. Miller 提交于
      Merge tag 'linux-can-next-for-4.3-20150820' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
      
      Marc Kleine-Budde says:
      
      ====================
      this is a pull request of a two patches for net-next.
      
      The first patch is by Nik Nyby and fixes a typo in a function name. The
      second patch by Lucas Stach demotes register output to debug level.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31fbde99
    • D
      Merge branch 'tipc-failover-fixes' · c5f98b56
      David S. Miller 提交于
      Jon Maloy says:
      
      ====================
      tipc: fix link failover/synch problems
      
      We fix three problems with the new link failover/synch implementation,
      which was introduced earlier in this release cycle. They are all related
      to situations where there is a very short interval between the disabling
      and enabling of interfaces.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5f98b56
    • J
      tipc: fix stale link problem during synchronization · 2be80c2d
      Jon Paul Maloy 提交于
      Recent changes to the link synchronization means that we can now just
      drop packets arriving on the synchronizing link before the synch point
      is reached. This has lead to significant simplifications to the
      implementation, but also turns out to have a flip side that we need
      to consider.
      
      Under unlucky circumstances, the two endpoints may end up
      repeatedly dropping each other's packets, while immediately
      asking for retransmission of the same packets, just to drop
      them once more. This pattern will eventually be broken when
      the synch point is reached on the other link, but before that,
      the endpoints may have arrived at the retransmission limit
      (stale counter) that indicates that the link should be broken.
      We see this happen at rare occasions.
      
      The fix for this is to not ask for retransmissions when a link is in
      state LINK_SYNCHING. The fact that the link has reached this state
      means that it has already received the first SYNCH packet, and that it
      knows the synch point. Hence, it doesn't need any more packets until the
      other link has reached the synch point, whereafter it can go ahead and
      ask for the missing packets.
      
      However, because of the reduced traffic on the synching link that
      follows this change, it may now take longer to discover that the
      synch point has been reached. We compensate for this by letting all
      packets, on any of the links, trig a check for synchronization
      termination. This is possible because the packets themselves don't
      contain any information that is needed for discovering this condition.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2be80c2d