1. 25 5月, 2021 1 次提交
  2. 19 5月, 2021 1 次提交
  3. 30 4月, 2021 1 次提交
  4. 16 4月, 2021 1 次提交
  5. 30 3月, 2021 1 次提交
  6. 10 2月, 2021 3 次提交
  7. 10 12月, 2020 1 次提交
  8. 09 12月, 2020 2 次提交
    • G
      net: hns3: refine the VLAN tag handle for port based VLAN · 592b0179
      Guojia Liao 提交于
      For DEVICE_VERSION_V2, the hardware only supports max two layer
      VLAN tags, including port based tag inserted by hardware, tag in
      tx buffer descriptor(get from skb->tci) and tag in packet.
      
      For transmit packet:
      If port based VLAN disabled, and vf driver gets a VLAN tag from
      skb, the VLAN tag must be filled to the Outer_VLAN_TAG field
      (tag near to DMAC) of tx buffer descriptor, otherwise it may
      be inserted after the tag in packet.
      
      If port based VLAN enabled, and vf driver gets a VLAN tag from
      skb, the VLAN tag must be filled to the VLAN_TAG field (tag
      far to DMAC) of tx buffer descriptor, otherwise it may be
      conflicted with port based VLAN, and raise a hardware error.
      
      For receive packet:
      The hardware will strip the VLAN tags and fill them in the rx
      buffer descriptor, no matter port based VLAN enable or not.
      Because port based VLAN tag is useless for stack, so vf driver
      needs to discard the port based VLAN tag get from rx buffer
      descriptor when port based VLAN enabled.
      
      So vf must know about the port based VLAN state.
      
      For DEVICE_VERSION_V3, the hardware provides some new
      configuration to improve it.
      
      For transmit packet:
      When enable tag shift mode, hardware will handle the VLAN tag
      in outer_VLAN_TAG field as VLAN_TAG, so it won't conflict with
      port based VLAN. And hardware also make sure the tag before
      the tag in packet. So vf driver doesn't need to specify the tag
      position according to the port based VLAN state anymore.
      
      For receive packet:
      When enable discard mode, hardware will strip and discard the
      port based VLAN tag, so vf driver doesn't need to identify it
      from rx buffer descriptor.
      
      So modify the port based VLAN configuration, simplify the process
      for vf handling the VLAN tag.
      Signed-off-by: NGuojia Liao <liaoguojia@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      592b0179
    • J
      net: hns3: add priv flags support to switch limit promisc mode · 5e7414cd
      Jian Shen 提交于
      Currently, the tx unicast promisc is always enabled when promisc
      mode on. If tx unicast promisc on, a function will receive all
      unicast packet from other functions belong to the same port.
      Add a ethtool private flag to control whether enable tx
      unicast promisc. Then the function is able to filter the
      unknown unicast packets from other function.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      5e7414cd
  9. 08 8月, 2020 1 次提交
    • W
      mm, treewide: rename kzfree() to kfree_sensitive() · 453431a5
      Waiman Long 提交于
      As said by Linus:
      
        A symmetric naming is only helpful if it implies symmetries in use.
        Otherwise it's actively misleading.
      
        In "kzalloc()", the z is meaningful and an important part of what the
        caller wants.
      
        In "kzfree()", the z is actively detrimental, because maybe in the
        future we really _might_ want to use that "memfill(0xdeadbeef)" or
        something. The "zero" part of the interface isn't even _relevant_.
      
      The main reason that kzfree() exists is to clear sensitive information
      that should not be leaked to other future users of the same memory
      objects.
      
      Rename kzfree() to kfree_sensitive() to follow the example of the recently
      added kvfree_sensitive() and make the intention of the API more explicit.
      In addition, memzero_explicit() is used to clear the memory to make sure
      that it won't get optimized away by the compiler.
      
      The renaming is done by using the command sequence:
      
        git grep -w --name-only kzfree |\
        xargs sed -i 's/kzfree/kfree_sensitive/'
      
      followed by some editing of the kfree_sensitive() kerneldoc and adding
      a kzfree backward compatibility macro in slab.h.
      
      [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
      [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]
      Suggested-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>
      Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      453431a5
  10. 15 5月, 2020 1 次提交
  11. 26 4月, 2020 2 次提交
    • J
      net: hns3: optimize the filter table entries handling when resetting · 039ba863
      Jian Shen 提交于
      Currently, the PF driver removes all (including its VFs') MAC/VLAN
      flow director table entries when resetting, and restores them after
      reset completed.
      
      In fact, the hardware will clear all table entries only in IMP
      reset and global reset. So driver only needs to restore the table
      entries in these cases, and needs do nothing when PF reset, FLR
      or other function level reset.
      
      This patch optimizes it by removing unnecessary table entries clear
      and restoring handling in the reset flow, and doing the restoring
      after reset completed.
      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>
      039ba863
    • J
      net: hns3: refactor the MAC address configure · ee4bcd3b
      Jian Shen 提交于
      Currently, the HNS3 driver sync and unsync MAC address in function
      hns3_set_rx_mode(). For PF, it adds and deletes MAC address directly
      in the path of dev_set_rx_mode(). If failed, it won't retry until
      next calling of hns3_set_rx_mode(). On the other hand, if request
      add and remove a same address many times at a short interval, each
      request must be done one by one, can't be merged. For VF, it sends
      mailbox messages to PF to request adding or deleting MAC address in
      the path of function hns3_set_rx_mode(), no matter the address is
      configured success.
      
      This patch refines it by recording the MAC address in function
      hns3_set_rx_mode(), and updating MAC address in the service task.
      If failed, it will retry by the next calling of periodical service
      task. It also uses some state to mark the state of each MAC address
      in the MAC list, which can help merge configure request for a same
      address. With these changes, when global reset or IMP reset occurs,
      we can restore the MAC table with the MAC list.
      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>
      ee4bcd3b
  12. 21 4月, 2020 1 次提交
  13. 22 3月, 2020 3 次提交
  14. 13 3月, 2020 1 次提交
  15. 07 1月, 2020 1 次提交
  16. 21 12月, 2019 1 次提交
  17. 17 12月, 2019 1 次提交
    • Y
      net: hns3: remove mailbox and reset work in hclge_main · 1c6dfe6f
      Yunsheng Lin 提交于
      There are three work (mbx_service_task, service_task,
      rst_service_task) in the HNS3 driver, mbx_service_task is for
      handling mailbox work, service_task is for periodic management
      issue and rst_service_task is for reset related issue, which can
      be handled in a single work.
      
      This patch removes the mbx_service_task and rst_service_task
      work, and moves the related handling to the service_task work
      in order to remove concurrency between the three work and to
      improve efficiency.
      
      BTW, since stats_timer in struct hclge_hw_stats is not needed
      anymore, so removes the definition of struct hclge_hw_stats,
      and moves mac_stats into struct hclge_dev.
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c6dfe6f
  18. 01 11月, 2019 2 次提交
  19. 09 10月, 2019 4 次提交
  20. 19 8月, 2019 1 次提交
  21. 02 8月, 2019 2 次提交
  22. 22 7月, 2019 1 次提交
  23. 06 7月, 2019 1 次提交
  24. 15 6月, 2019 1 次提交
  25. 10 6月, 2019 2 次提交
  26. 29 5月, 2019 1 次提交
  27. 04 5月, 2019 1 次提交
    • 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
  28. 27 4月, 2019 1 次提交