1. 29 5月, 2020 2 次提交
  2. 11 5月, 2020 1 次提交
  3. 30 4月, 2020 1 次提交
  4. 26 4月, 2020 2 次提交
  5. 31 3月, 2020 1 次提交
  6. 12 1月, 2020 1 次提交
    • H
      net: hns3: refactor the procedure of VF FLR · f28368bb
      Huazhong Tan 提交于
      Currently, the actual work of VF FLR is handled in the reset task,
      which is asynchronous. So in some case, if the preparing and
      rebuilding are not done, then the VF FLR will trigger some problems,
      for example, makes hardware go into chaos.
      
      So this patch separates the process of VF FLR from reset task, and
      adds a semaphore to serialize this reset and others.
      
      When FLR's preparing fails, if there has other higher level reset
      pending or failing times less than the HCLGE_FLR_RETRY_CNT, this
      preparing should be retried, otherwise it will get into a wrong state.
      
      BTW, while the hardware reports misc interrupt during pcie_flr(),
      the driver can not receive this interrupt anymore, so disable it
      when hclgevf_flr_prepare() return, and re-enable it when enter
      hclgevf_flr_done().
      
      Avoid declaring internal function hclgevf_enable_vector(), this patch
      also moves its definition forward, and removes unused enum
      hnae3_flr_state.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f28368bb
  7. 07 1月, 2020 2 次提交
  8. 06 11月, 2019 1 次提交
  9. 01 11月, 2019 2 次提交
  10. 20 10月, 2019 1 次提交
  11. 09 10月, 2019 5 次提交
  12. 30 8月, 2019 1 次提交
  13. 19 8月, 2019 1 次提交
  14. 10 8月, 2019 2 次提交
  15. 29 7月, 2019 1 次提交
  16. 26 6月, 2019 2 次提交
  17. 15 6月, 2019 2 次提交
  18. 10 6月, 2019 1 次提交
  19. 04 6月, 2019 2 次提交
  20. 27 5月, 2019 1 次提交
  21. 04 5月, 2019 3 次提交
    • J
      net: hns3: add support for FEC encoding control · 7e6ec914
      Jian Shen 提交于
      This patch adds support for FEC encoding control, user can change
      FEC mode by command ethtool --set-fec, and get FEC mode by command
      ethtool --show-fec. The fec capability is changed follow the port
      speed. If autoneg on, the user configure fec mode will be overwritten
      by autoneg result.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e6ec914
    • J
      net: hns3: add autoneg and change speed support for fibre port · 22f48e24
      Jian Shen 提交于
      Previously, our driver only supports phydev to autoneg or change
      port speed. This patch adds support for fibre port, driver gets
      media speed capability and autoneg capability from firmware. If
      the media supports multiple speeds, user can change port speed
      with command "ethtool -s <devname> speed xxxx autoneg off duplex
      full". If autoneg on, the user configuration may be overwritten
      by the autoneg result.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22f48e24
    • J
      net: hns3: add support for multiple media type · 88d10bd6
      Jian Shen 提交于
      Previously, we can only identify copper and fiber type, the
      supported link modes of port information are always showing
      SR type. This patch adds support for multiple media types,
      include SR, LR CR, KR. Driver needs to query the media type
      from firmware periodicly, and updates the port information.
      
      The new port information looks like this:
      Settings for eth0:
              Supported ports: [ FIBRE ]
              Supported link modes:   25000baseCR/Full
                                      25000baseSR/Full
                                      1000baseX/Full
                                      10000baseCR/Full
                                      10000baseSR/Full
                                      10000baseLR/Full
              Supported pause frame use: Symmetric
              Supports auto-negotiation: No
              Supported FEC modes: None BaseR
              Advertised link modes:  Not reported
              Advertised pause frame use: No
              Advertised auto-negotiation: No
              Advertised FEC modes: Not reported
              Speed: 10000Mb/s
              Duplex: Full
              Port: FIBRE
              PHYAD: 0
              Transceiver: internal
              Auto-negotiation: off
              Current message level: 0x00000036 (54)
                                     probe link ifdown ifup
              Link detected: yes
      
      In order to be compatible with old firmware which only support
      sfp speed, we remained using the same query command, and kept
      the former logic.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88d10bd6
  22. 20 4月, 2019 2 次提交
  23. 15 4月, 2019 2 次提交
    • J
      net: hns3: fix VLAN offload handle for VLAN inserted by port · 44e626f7
      Jian Shen 提交于
      Currently, in TX direction, driver implements the TX VLAN offload
      by checking the VLAN header in skb, and filling it into TX descriptor.
      Usually it works well, but if enable inserting VLAN header based on
      port, it may conflict when out_tag field of TX descriptor is already
      used, and cause RAS error.
      
      In RX direction, hardware supports stripping max two VLAN headers.
      For vlan_tci in skb can only store one VLAN tag, when RX VLAN offload
      enabled, driver tells hardware to strip one VLAN header from RX
      packet; when RX VLAN offload disabled, driver tells hardware not to
      strip VLAN header from RX packet. Now if port based insert VLAN
      enabled, all RX packets will have the port based VLAN header. This
      header is useless for stack, driver needs to ask hardware to strip
      it. Unfortunately, hardware can't drop this VLAN header, and always
      fill it into RX descriptor, so driver has to identify and drop it.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44e626f7
    • J
      net: hns3: modify VLAN initialization to be compatible with port based VLAN · 741fca16
      Jian Shen 提交于
      Our hardware supports inserting a specified VLAN header for each
      function when sending packets. User can enable it with command
      "ip link set <devname> vf  <vfid> vlan <vlan id>".
      For this VLAN header is inserted by hardware, not from stack,
      hardware also needs to strip it from received packets before
      sending to stack.  In this case, driver needs to tell
      hardware which VLAN to insert or strip.
      
      The current VLAN initialization doesn't allow inserting
      VLAN header by hardware, this patch modifies it, in order be
      compatible with VLAN inserted base on port.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      741fca16
  24. 10 3月, 2019 1 次提交