Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 5月, 2018 3 次提交
    • 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
    • G
      cxgb4: clean up init_one · e8d45292
      由 Ganesh Goudar 提交于 
      clean up init_one and use chip_ver consistently throughout
init_one() for chip version.
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8d45292
    • G
      cxgb4/cxgb4vf: link management changes for new SFP · 57ccaedb
      由 Ganesh Goudar 提交于 
      newer SFPs like SFP28 and QSFP28 Transceiver Modules present
several new possibilities which we haven't faced before. Fix the
assumptions in the code reflecting the more limited capabilities
of previous Transceiver Module systems

Original work by Casey Leedom <leedom@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57ccaedb
  3. 25 5月, 2018 1 次提交
  5. 24 5月, 2018 3 次提交
  7. 22 5月, 2018 1 次提交
  9. 19 5月, 2018 2 次提交
  11. 17 5月, 2018 1 次提交
  13. 15 5月, 2018 4 次提交
  15. 12 5月, 2018 4 次提交
  17. 11 5月, 2018 3 次提交
  19. 04 5月, 2018 1 次提交
  21. 03 5月, 2018 1 次提交
  23. 30 4月, 2018 1 次提交
  25. 18 4月, 2018 1 次提交
  27. 01 4月, 2018 2 次提交
  29. 30 3月, 2018 1 次提交
  31. 27 3月, 2018 1 次提交
  33. 26 3月, 2018 4 次提交
  35. 22 3月, 2018 5 次提交
  37. 18 3月, 2018 1 次提交