1. 14 1月, 2015 3 次提交
  2. 13 1月, 2015 5 次提交
  3. 12 1月, 2015 1 次提交
  4. 09 1月, 2015 5 次提交
  5. 07 1月, 2015 4 次提交
  6. 06 1月, 2015 6 次提交
  7. 05 1月, 2015 3 次提交
    • J
      qlcnic: Fix dump_skb output · 3620af0e
      Joe Perches 提交于
      Use normal facilities to avoid printing each byte
      on a separate line.
      
      Now emits at KERN_DEBUG instead of KERN_INFO.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3620af0e
    • G
      enic: reconfigure resources for kdump crash kernel · 3f255dcc
      Govindarajulu Varadarajan 提交于
      When running in kdump kernel, reduce number of resources used by the driver.
      This will enable NIC to operate in low memory kdump kernel environment.
      
      Also change the driver version to .83
      Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f255dcc
    • F
      net: ethernet: cpsw: fix hangs with interrupts · 7ce67a38
      Felipe Balbi 提交于
      The CPSW IP implements pulse-signaled interrupts. Due to
      that we must write a correct, pre-defined value to the
      CPDMA_MACEOIVECTOR register so the controller generates
      a pulse on the correct IRQ line to signal the End Of
      Interrupt.
      
      The way the driver is written today, all four IRQ lines
      are requested using the same IRQ handler and, because of
      that, we could fall into situations where a TX IRQ fires
      but we tell the controller that we ended an RX IRQ (or
      vice-versa). This situation triggers an IRQ storm on the
      reserved IRQ 127 of INTC which will in turn call ack_bad_irq()
      which will, then, print a ton of:
      
      	unexpected IRQ trap at vector 00
      
      In order to fix the problem, we are moving all calls to
      cpdma_ctlr_eoi() inside the IRQ handler and making sure
      we *always* write the correct value to the CPDMA_MACEOIVECTOR
      register. Note that the algorithm assumes that IRQ numbers and
      value-to-be-written-to-EOI are proportional, meaning that a
      write of value 0 would trigger an EOI pulse for the RX_THRESHOLD
      Interrupt and that's the IRQ number sitting in the 0-th index
      of our irqs_table array.
      
      This, however, is safe at least for current implementations of
      CPSW so we will refrain from making the check smarter (and, as
      a side-effect, slower) until we actually have a platform where
      IRQ lines are swapped.
      
      This patch has been tested for several days with AM335x- and
      AM437x-based platforms. AM57x was left out because there are
      still pending patches to enable ethernet in mainline for that
      platform. A read of the TRM confirms the statement on previous
      paragraph.
      Reported-by: NYegor Yefremov <yegorslists@googlemail.com>
      Fixes: 510a1e72 (drivers: net: davinci_cpdma: acknowledge interrupt properly)
      Cc: <stable@vger.kernel.org> # v3.9+
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ce67a38
  8. 03 1月, 2015 13 次提交