1. 21 10月, 2016 1 次提交
    • J
      ethernet: use net core MTU range checking in more drivers · d894be57
      Jarod Wilson 提交于
      Somehow, I missed a healthy number of ethernet drivers in the last pass.
      Most of these drivers either were in need of an updated max_mtu to make
      jumbo frames possible to enable again. In a few cases, also setting a
      different min_mtu to match previous lower bounds. There are also a few
      drivers that had no upper bounds checking, so they're getting a brand new
      ETH_MAX_MTU that is identical to IP_MAX_MTU, but accessible by includes
      all ethernet and ethernet-like drivers all have already.
      
      acenic:
      - min_mtu = 0, max_mtu = 9000
      
      amazon/ena:
      - min_mtu = 128, max_mtu = adapter->max_mtu
      
      amd/xgbe:
      - min_mtu = 0, max_mtu = 9000
      
      sb1250:
      - min_mtu = 0, max_mtu = 1518
      
      cxgb3:
      - min_mtu = 81, max_mtu = 65535
      
      cxgb4:
      - min_mtu = 81, max_mtu = 9600
      
      cxgb4vf:
      - min_mtu = 81, max_mtu = 65535
      
      benet:
      - min_mtu = 256, max_mtu = 9000
      
      ibmveth:
      - min_mtu = 68, max_mtu = 65535
      
      ibmvnic:
      - min_mtu = adapter->min_mtu, max_mtu = adapter->max_mtu
      - remove now redundant ibmvnic_change_mtu
      
      jme:
      - min_mtu = 1280, max_mtu = 9202
      
      mv643xx_eth:
      - min_mtu = 64, max_mtu = 9500
      
      mlxsw:
      - min_mtu = 0, max_mtu = 65535
      - Basically bypassing the core checks, and instead relying on dynamic
        checks in the respective switch drivers' ndo_change_mtu functions
      
      ns83820:
      - min_mtu = 0
      - remove redundant ns83820_change_mtu, only checked for mtu > 1500
      
      netxen:
      - min_mtu = 0, max_mtu = 8000 (P2), max_mtu = 9600 (P3)
      
      qlge:
      - min_mtu = 1500, max_mtu = 9000
      - driver only supports setting mtu to 1500 or 9000, so the core check only
        rules out < 1500 and > 9000, qlge_change_mtu still needs to check that
        the value is 1500 or 9000
      
      qualcomm/emac:
      - min_mtu = 46, max_mtu = 9194
      
      xilinx_axienet:
      - min_mtu = 64, max_mtu = 9000
      
      Fixes: 61e84623 ("net: centralize net_device min/max MTU checking")
      CC: netdev@vger.kernel.org
      CC: Jes Sorensen <jes@trained-monkey.org>
      CC: Netanel Belgazal <netanel@annapurnalabs.com>
      CC: Tom Lendacky <thomas.lendacky@amd.com>
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Hariprasad S <hariprasad@chelsio.com>
      CC: Sathya Perla <sathya.perla@broadcom.com>
      CC: Ajit Khaparde <ajit.khaparde@broadcom.com>
      CC: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
      CC: Somnath Kotur <somnath.kotur@broadcom.com>
      CC: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
      CC: John Allen <jallen@linux.vnet.ibm.com>
      CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
      CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      CC: Jiri Pirko <jiri@mellanox.com>
      CC: Ido Schimmel <idosch@mellanox.com>
      CC: Manish Chopra <manish.chopra@qlogic.com>
      CC: Sony Chacko <sony.chacko@qlogic.com>
      CC: Rajesh Borundia <rajesh.borundia@qlogic.com>
      CC: Timur Tabi <timur@codeaurora.org>
      CC: Anirudha Sarangi <anirudh@xilinx.com>
      CC: John Linn <John.Linn@xilinx.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d894be57
  2. 01 9月, 2016 1 次提交
  3. 02 8月, 2016 1 次提交
  4. 04 3月, 2016 1 次提交
    • J
      net: relax setup_tc ndo op handle restriction · 5eb4dce3
      John Fastabend 提交于
      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: NSingh Krishneil <krishneil.k.singh@intel.com>
      Reported-by: NJake 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: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5eb4dce3
  5. 18 2月, 2016 3 次提交
  6. 17 2月, 2016 2 次提交
  7. 19 11月, 2015 1 次提交
  8. 28 10月, 2015 1 次提交
  9. 23 10月, 2015 1 次提交
    • L
      amd-xgbe: Use wmb before updating current descriptor count · 20a41fba
      Lendacky, Thomas 提交于
      The code currently uses the lightweight dma_wmb barrier before updating
      the current descriptor count. Under heavy load, the Tx cleanup routine
      was seeing the updated current descriptor count before the updated
      descriptor information. As a result, the Tx descriptor was being cleaned
      up before it was used because it was not "owned" by the hardware yet,
      resulting in a Tx queue hang.
      
      Using the wmb barrier insures that the descriptor is updated before the
      descriptor counter preventing the Tx queue hang. For extra insurance,
      the Tx cleanup routine is changed to grab the current decriptor count on
      entry and uses that initial value in the processing loop rather than
      trying to chase the current value.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Tested-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20a41fba
  10. 15 10月, 2015 1 次提交
  11. 05 10月, 2015 2 次提交
  12. 09 7月, 2015 1 次提交
  13. 07 6月, 2015 1 次提交
  14. 25 5月, 2015 1 次提交
  15. 16 5月, 2015 4 次提交
  16. 15 5月, 2015 1 次提交
  17. 10 4月, 2015 3 次提交
  18. 21 3月, 2015 5 次提交
  19. 28 2月, 2015 1 次提交
    • L
      amd-xgbe: Request IRQs only after driver is fully setup · c30e76a7
      Lendacky, Thomas 提交于
      It is possible that the hardware may not have been properly shutdown
      before this driver gets control, through use by firmware, for example.
      Until the driver is loaded, interrupts associated with the hardware
      could go pending. When the IRQs are requested napi support has not
      been initialized yet, but the ISR will get control and schedule napi
      processing resulting in a kernel panic because the poll routine has not
      been set.
      
      Adjust the code so that the driver is fully ready to handle and process
      interrupts as soon as the IRQs are requested. This involves requesting
      and freeing IRQs during start and stop processing and ordering the napi
      add and delete calls appropriately.
      
      Also adjust the powerup and powerdown routines to match the start and
      stop routines in regards to the ordering of tasks, including napi
      related calls.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c30e76a7
  20. 08 2月, 2015 1 次提交
  21. 05 2月, 2015 2 次提交
  22. 17 1月, 2015 4 次提交
  23. 14 1月, 2015 1 次提交