Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
“3085d5e434f45f4bb6c94b42a3772b192dce791c”上不存在“test/legacy_test/test_one_hot_v2_op.py”
切换分支/标签
  1. 17 9月, 2020 1 次提交
  3. 24 8月, 2020 1 次提交
  5. 01 7月, 2020 1 次提交
  7. 24 6月, 2020 1 次提交
    • R
      cxgb4vf: update kernel-doc line comments · 20bb0c8f
      由 Rahul Lakkireddy 提交于 
      Update several kernel-doc line comments to fix warnings reported by
make W=1.

Fixes following class of warnings reported by make W=1 in several
places:
cxgb4vf_main.c:275: warning: Function parameter or member 'persistent'
not described in 'cxgb4vf_change_mac'
cxgb4vf_main.c:275: warning: Excess function parameter 'persist'
description in 'cxgb4vf_change_mac'

Fixes: 16f8bd4b ("cxgb4vf: Add core T4 PCI-E SR-IOV Virtual Function hardware definitions and device communication code")
Fixes: c6e0d914 ("cxgb4vf: Add T4 Virtual Function Scatter-Gather Engine DMA code")
Fixes: e0a8b34a ("cxgb4vf: Add and initialize some sge params for VF driver")
Fixes: c3168cab ("cxgb4/cxgbvf: Handle 32-bit fw port capabilities")
Fixes: 0e23daeb ("drivers/net: chelsio/cxgb*: Convert timers to use timer_setup()")
Fixes: 3f8cfd0d ("cxgb4/cxgb4vf: Program hash region for {t4/t4vf}_change_mac()")
Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20bb0c8f
  9. 06 5月, 2020 1 次提交
  11. 11 3月, 2020 1 次提交
  13. 04 3月, 2020 1 次提交
  15. 31 12月, 2019 1 次提交
  17. 11 8月, 2019 1 次提交
  19. 26 4月, 2019 1 次提交
    • G
      cxgb4/cxgb4vf_main: Mark expected switch fall-through · 05dd2645
      由 Gustavo A. R. Silva 提交于 
      In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.

This patch fixes the following warning:

drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c: In function ‘fwevtq_handler’:
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:520:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
   cpl = (void *)p;
   ~~~~^~~~~~~~~~~
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c:524:2: note: here
  case CPL_SGE_EGR_UPDATE: {
  ^~~~

Warning level 3 was used: -Wimplicit-fallthrough=3

Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.

This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05dd2645
  21. 30 3月, 2019 1 次提交
  23. 02 3月, 2019 3 次提交
  25. 01 3月, 2019 2 次提交
  27. 14 2月, 2019 1 次提交
  29. 04 2月, 2019 1 次提交
  31. 30 1月, 2019 1 次提交
  33. 16 12月, 2018 1 次提交
  35. 21 11月, 2018 1 次提交
  37. 10 11月, 2018 2 次提交
  39. 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
  41. 18 4月, 2018 1 次提交
  43. 27 3月, 2018 1 次提交
  45. 12 3月, 2018 1 次提交
  47. 05 3月, 2018 1 次提交
  49. 24 1月, 2018 1 次提交
  51. 29 12月, 2017 1 次提交
  53. 03 11月, 2017 1 次提交
  55. 21 8月, 2017 1 次提交
  57. 15 8月, 2017 1 次提交
  59. 07 1月, 2017 1 次提交
  61. 09 12月, 2016 2 次提交
  63. 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
  65. 29 8月, 2016 1 次提交
  67. 15 8月, 2016 1 次提交
  69. 26 7月, 2016 1 次提交