1. 16 12月, 2018 1 次提交
  2. 21 11月, 2018 1 次提交
  3. 10 11月, 2018 2 次提交
  4. 26 5月, 2018 1 次提交
    • A
      cxgb4/cxgb4vf: Notify link changes to OS-dependent code · e2f4f4e9
      Arjun Vynipadath 提交于
      We have a confusion of two different abstractions in the Common
      Code:  Physical Link (Port) and Logical Network Interface (Virtual
      Interface), and we haven't been properly managing the state of the
      intersection of those two abstractions.
      On the one hand we have the Physical state of the Link -- up or down --
      and on the other we have the logical state of the VI, enabled or not.
      {ethN} refers to both the Physical and Logical State. In this case,
      ifconfig only affects/interrogates the Logical State of a VI,
      and ethtool only deals with the Physical State. And these are different.
      
      So, just because we disable the VI, we don't really want to change the
      Physical Link Up/Down state.  Thus, the previous hack to set
      "lc->link_ok = 0" when we disable a VI is completely incorrect.
      
      Where we get into trouble is where the Physical Link State and the
      Logical VI State cross swords.  And that happens in
      t4_handle_get_port_info() where we need to manage/safe the Physical
      Link State, but we also need to know when the Logical VI State has
      changed and pass that back up to the OS-dependent Driver routine
      t4_os_link_changed() which is concerned about the Logical Interface.
      
      So we enable a VI and that causes Firmware to send us a new Port
      Information message, but if none of the Physical Link State
      particulars have changed, we don't call t4_os_link_changed().
      
      This fix uses the existing OS Contract APIs for the Common Code to
      inform the OS-dependent portion of the Host Driver when the "Link" (really
      Logical Network Interface) is "up" or "down". A new API
      t4_enable_pi_params() is added which calls t4_enable_vi_params() and,
      if that is successful, then calls back to the OS Contract API
      t4_os_link_changed() notifying the OS-dependent layer of the
      potential Link State change.
      
      Original Work by : Casey Leedom <leedom@chelsio.com>
      Signed-off-by: NSantosh Rastapur <santosh@chelsio.com>
      Signed-off-by: NArjun Vynipadath <arjun@chelsio.com>
      Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e2f4f4e9
  5. 18 4月, 2018 1 次提交
  6. 27 3月, 2018 1 次提交
  7. 12 3月, 2018 1 次提交
  8. 05 3月, 2018 1 次提交
  9. 24 1月, 2018 1 次提交
  10. 29 12月, 2017 1 次提交
  11. 03 11月, 2017 1 次提交
  12. 21 8月, 2017 1 次提交
  13. 15 8月, 2017 1 次提交
  14. 07 1月, 2017 1 次提交
  15. 09 12月, 2016 2 次提交
  16. 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
  17. 29 8月, 2016 1 次提交
  18. 15 8月, 2016 1 次提交
  19. 26 7月, 2016 1 次提交
  20. 26 6月, 2016 1 次提交
    • H
      cxgb4vf: Synchronize access to mailbox · b38066da
      Hariprasad Shenai 提交于
      The issue comes when there are multiple threads attempting to use the
      mailbox facility at the same time. The issue is the for the Virtual
      Function Driver, the only way to get the Virtual Interface statistics
      is to issue mailbox commands to ask the firmware for the VI Stats.
      And, because the VI Stats command can only retrieve a smallish number of
      stats per mailbox command, we have to issue three mailbox commands in quick
      succession. When ethtool or netstat command to get interface stats and
      interface up/down is run in a loop for every 0.1 sec, we observed
      mailbox collisions. And out of the two commands one would fail with
      the present code, since we don't queue the second command.
      
      To overcome the above issue, added a queue to access the mailbox.
      Whenever a mailbox command is issued add it to the queue. If its at the
      head issue the mailbox command, else wait for the existing command to
      complete. Usually command takes less than a milli-second to complete.
      Also timeout from the loop, if the command under execution takes
      long time to run.
      
      In reality, the number of mailbox access collisions is going to be very
      rare since no one runs such abusive script.
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b38066da
  21. 16 6月, 2016 1 次提交
  22. 30 4月, 2016 1 次提交
  23. 07 4月, 2016 1 次提交
  24. 11 3月, 2016 4 次提交
  25. 03 3月, 2016 2 次提交
  26. 19 2月, 2016 1 次提交
  27. 22 10月, 2015 1 次提交
  28. 13 5月, 2015 1 次提交
  29. 20 3月, 2015 1 次提交
  30. 15 1月, 2015 1 次提交
  31. 13 1月, 2015 2 次提交
  32. 06 1月, 2015 2 次提交