1. 04 3月, 2016 1 次提交
  2. 03 3月, 2016 23 次提交
  3. 02 3月, 2016 4 次提交
    • A
      phy: micrel: Disable auto negotiation on startup · 99f81afc
      Alexandre Belloni 提交于
      Disable auto negotiation on init to properly detect an already plugged
      cable at boot.
      
      At boot, when the phy is started, it is in the PHY_UP state.
      However, if a cable is plugged at boot, because auto negociation is already
      enabled at the time we get the first interrupt, the phy is already running.
      But the state machine then switches from PHY_UP to PHY_AN and calls
      phy_start_aneg(). phy_start_aneg() will not do anything because aneg is
      already enabled on the phy. It will then wait for a interrupt before going
      further. This interrupt will never happen unless the cable is unplugged and
      then replugged.
      
      It was working properly before 321beec5 (net: phy: Use interrupts when
      available in NOLINK state) because switching to NOLINK meant starting
      polling the phy, even if IRQ were enabled.
      
      Fixes: 321beec5 (net: phy: Use interrupts when available in NOLINK state)
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99f81afc
    • A
      phy: micrel: Ensure interrupts are reenabled on resume · f5aba91d
      Alexandre Belloni 提交于
      At least on ksz8081, when getting back from power down, interrupts are
      disabled. ensure they are reenabled if they were previously enabled.
      
      This fixes resuming which is failing on the xplained boards from atmel
      since 321beec5 (net: phy: Use interrupts when available in NOLINK
      state)
      
      Fixes: 321beec5 (net: phy: Use interrupts when available in NOLINK state)
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5aba91d
    • G
      ppp: lock ppp->flags in ppp_read() and ppp_poll() · edffc217
      Guillaume Nault 提交于
      ppp_read() and ppp_poll() can be called concurrently with ppp_ioctl().
      In this case, ppp_ioctl() might call ppp_ccp_closed(), which may update
      ppp->flags while ppp_read() or ppp_poll() is reading it.
      The update done by ppp_ccp_closed() isn't atomic due to the bit mask
      operation ('ppp->flags &= ~(SC_CCP_OPEN | SC_CCP_UP)'), so concurrent
      readers might get transient values.
      Reading incorrect ppp->flags may disturb the 'ppp->flags & SC_LOOP_TRAFFIC'
      test in ppp_read() and ppp_poll(), which in turn can lead to improper
      decision on whether the PPP unit file is ready for reading or not.
      
      Since ppp_ccp_closed() is protected by the Rx and Tx locks (with
      ppp_lock()), taking the Rx lock is enough for ppp_read() and ppp_poll()
      to guarantee that ppp_ccp_closed() won't update ppp->flags
      concurrently.
      
      The same reasoning applies to ppp->n_channels. The 'n_channels' field
      can also be written to concurrently by ppp_ioctl() (through
      ppp_connect_channel() or ppp_disconnect_channel()). These writes aren't
      atomic (simple increment/decrement), but are protected by both the Rx
      and Tx locks (like in the ppp->flags case). So holding the Rx lock
      before reading ppp->n_channels also prevents concurrent writes.
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      edffc217
    • I
      bna: fix list corruption · a7f4b988
      Ivan Vecera 提交于
      Use list_move_tail() to move MAC address entry from list of pending
      to list of active entries. Simple list_add_tail() leaves the entry
      also in the first list, this leads to list corruption.
      
      Cc: Rasesh Mody <rasesh.mody@qlogic.com>
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Acked-by: NRasesh Mody <rasesh.mody@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7f4b988
  4. 01 3月, 2016 1 次提交
    • N
      3c59x: mask LAST_FRAG bit from length field in ring · a6522c08
      Neil Horman 提交于
      Recently, I fixed a bug in 3c59x:
      
      commit 6e144419
      Author: Neil Horman <nhorman@tuxdriver.com>
      Date:   Wed Jan 13 12:43:54 2016 -0500
      
          3c59x: fix another page map/single unmap imbalance
      
      Which correctly rebalanced dma mapping and unmapping types.  Unfortunately it
      introduced a new bug which causes oopses on older systems.
      
      When mapping dma regions, the last entry for a packet in the 3c59x tx ring
      encodes a LAST_FRAG bit, which is encoded as the high order bit of the buffers
      length field.  When it is unmapped the LAST_FRAG bit is cleared prior to being
      passed to the unmap function.  Unfortunately the commit above fails to do that
      masking.  It was missed in testing because the system on which I tested it had
      an intel iommu, the driver for which ignores the size field, using only the DMA
      address as the token to identify the mapping to be released.  However, on older
      systems that rely on swiotlb (or other dma drivers that key off that length
      field), not masking off that LAST_FRAG high order bit results in parsing a huge
      size to be release, leading to all sorts of odd corruptions and the like.
      
      Fix is easy, just mask the length with 0xFFF.  It should really be
      &(LAST_FRAG-1), but 0xFFF is the style of the file, and I'd like to make this
      fix minimal and correct before making it prettier.
      
      Appies to the net tree cleanly.  All testing on both iommu and swiommu based
      systems produce good results
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6522c08
  5. 27 2月, 2016 1 次提交
  6. 26 2月, 2016 6 次提交
  7. 25 2月, 2016 2 次提交
  8. 24 2月, 2016 2 次提交