1. 14 Jun, 2016 2 commits
  2. 07 Jun, 2016 3 commits
  3. 20 May, 2016 1 commit
  4. 15 May, 2016 7 commits
  5. 12 May, 2016 2 commits
    • Michael Chan's avatar
      bnxt_en: Add workaround to detect bad opaque in rx completion (part 2) · fa7e2812
      Michael Chan authored
      
      
      Add detection and recovery code when the hardware returned opaque value
      does not match the expected consumer index.  Once the issue is detected,
      we skip the processing of all RX and LRO/GRO packets.  These completion
      entries are discarded without sending the SKB to the stack and without
      producing new buffers.  The function will be reset from a workqueue.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa7e2812
    • Michael Chan's avatar
      bnxt_en: Add workaround to detect bad opaque in rx completion (part 1) · 376a5b86
      Michael Chan authored
      
      
      There is a rare hardware bug that can cause a bad opaque value in the RX
      or TPA completion.  When this happens, the hardware may have used the
      same buffer twice for 2 rx packets.  In addition, the driver will also
      crash later using the bad opaque as the index into the ring.
      
      The rx opaque value is predictable and is always monotonically increasing.
      The workaround is to keep track of the expected next opaque value and
      compare it with the one returned by hardware during RX and TPA start
      completions.  If they miscompare, we will not process any more RX and
      TPA completions and exit NAPI.  We will then schedule a workqueue to
      reset the function.
      
      This patch adds the logic to keep track of the next rx consumer index.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      376a5b86
  6. 04 May, 2016 3 commits
  7. 27 Apr, 2016 3 commits
  8. 11 Apr, 2016 4 commits
  9. 05 Apr, 2016 6 commits
  10. 30 Mar, 2016 3 commits
  11. 08 Mar, 2016 4 commits
  12. 03 Mar, 2016 1 commit
    • John Fastabend's avatar
      net: relax setup_tc ndo op handle restriction · 5eb4dce3
      John Fastabend authored
      I added this check in setup_tc to multiple drivers,
      
       if (handle != TC_H_ROOT || tc->type != TC_SETUP_MQPRIO)
      
      Unfortunately restricting to TC_H_ROOT like this breaks the old
      instantiation of mqprio to setup a hardware qdisc. This patch
      relaxes the test to only check the type to make it equivalent
      to the check before I broke it. With this the old instantiation
      continues to work.
      
      A good smoke test is to setup mqprio with,
      
      # tc qdisc add dev eth4 root mqprio num_tc 8 \
        map 0 1 2 3 4 5 6 7 \
        queues 0@0 1@1 2@2 3@3 4@4 5@5 6@6 7@7
      
      Fixes: e4c6734e
      
       ("net: rework ndo tc op to consume additional qdisc handle paramete")
      Reported-by: default avatarSingh Krishneil <krishneil.k.singh@intel.com>
      Reported-by: default avatarJake Keller <jacob.e.keller@intel.com>
      CC: Murali Karicheri <m-karicheri2@ti.com>
      CC: Shradha Shah <sshah@solarflare.com>
      CC: Or Gerlitz <ogerlitz@mellanox.com>
      CC: Ariel Elior <ariel.elior@qlogic.com>
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5eb4dce3
  13. 01 Mar, 2016 1 commit