1. 27 Jun, 2019 12 commits
  2. 26 Jun, 2019 27 commits
    • David S. Miller's avatar
      Merge branch 'macb-build-fixes' · 8b89d8da
      David S. Miller authored
      Palmer Dabbelt says:
      
      ====================
      net: macb: Fix compilation on systems without COMMON_CLK, v2
      
      Our patch to add support for the FU540-C000 broke compilation on at
      least powerpc allyesconfig, which was found as part of the linux-next
      build regression tests.  This must have somehow slipped through the
      cracks, as the patch has been reverted in linux-next for a while now.
      This patch applies on top of the offending commit, which is the only one
      I've even tried it on as I'm not sure how this subsystem makes it to
      Linus.
      
      This patch set fixes the issue by adding a dependency of COMMON_CLK to
      the MACB Kconfig entry, which avoids the build failure by disabling MACB
      on systems where it wouldn't compile.  All known users of MACB have
      COMMON_CLK, so this shouldn't cause any issues.  This is a significantly
      simpler approach than disabling just the FU540-C000 support.
      
      I've also included a second patch to indicate this is a driver for a
      Cadence device that was originally written by an engineer at Atmel.  The
      only relation is that I stumbled across it when writing the first patch.
      
      Changes since v1 <20190624061603.1704-1-palmer@sifive.com>:
      
      * Disable MACB on systems without COMMON_CLK, instead of just disabling
        the FU540-C000 support on these systems.
      * Update the commit message to reflect the driver was written by Atmel.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b89d8da
    • Palmer Dabbelt's avatar
      net: macb: Kconfig: Rename Atmel to Cadence · 302a7cad
      Palmer Dabbelt authored
      The help text makes it look like NET_VENDOR_CADENCE enables support for
      Atmel devices, when in reality it's a driver written by Atmel that
      supports Cadence devices.  This may confuse users that have this device
      on a non-Atmel SoC.
      
      The fix is just s/Atmel/Cadence/, but I did go and re-wrap the Kconfig
      help text as that change caused it to go over 80 characters.
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      302a7cad
    • Palmer Dabbelt's avatar
      net: macb: Kconfig: Make MACB depend on COMMON_CLK · c536a9aa
      Palmer Dabbelt authored
      commit c218ad55 ("macb: Add support for SiFive FU540-C000") added a
      dependency on the common clock framework to the macb driver, but didn't
      express that dependency in Kconfig.  As a result macb now fails to
      compile on systems without COMMON_CLK, which specifically causes a build
      failure on powerpc allyesconfig.
      
      This patch adds the dependency, which results in the macb driver no
      longer being selectable on systems without the common clock framework.
      All known systems that have this device already support the common clock
      framework, so this should not cause trouble for any uses.  Supporting
      both the FU540-C000 and systems without COMMON_CLK is quite ugly.
      
      I've build tested this on powerpc allyesconfig and RISC-V defconfig
      (which selects MACB), but I have not even booted the resulting kernels.
      
      Fixes: c218ad55 ("macb: Add support for SiFive FU540-C000")
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c536a9aa
    • Dave Taht's avatar
      Allow 0.0.0.0/8 as a valid address range · 96125bf9
      Dave Taht authored
      The longstanding prohibition against using 0.0.0.0/8 dates back
      to two issues with the early internet.
      
      There was an interoperability problem with BSD 4.2 in 1984, fixed in
      BSD 4.3 in 1986. BSD 4.2 has long since been retired.
      
      Secondly, addresses of the form 0.x.y.z were initially defined only as
      a source address in an ICMP datagram, indicating "node number x.y.z on
      this IPv4 network", by nodes that know their address on their local
      network, but do not yet know their network prefix, in RFC0792 (page
      19).  This usage of 0.x.y.z was later repealed in RFC1122 (section
      3.2.2.7), because the original ICMP-based mechanism for learning the
      network prefix was unworkable on many networks such as Ethernet (which
      have longer addresses that would not fit into the 24 "node number"
      bits).  Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951)
      or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask
      (and other parameters such as default gateways). 0.x.y.z has had
      16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for
      future use, since 1989.
      
      This patch allows for these 16m new IPv4 addresses to appear within
      a box or on the wire. Layer 2 switches don't care.
      
      0.0.0.0/32 is still prohibited, of course.
      Signed-off-by: default avatarDave Taht <dave.taht@gmail.com>
      Signed-off-by: default avatarJohn Gilmore <gnu@toad.com>
      Acked-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96125bf9
    • David Ahern's avatar
      rtnetlink: skip metrics loop for dst_default_metrics · c22a133a
      David Ahern authored
      dst_default_metrics has all of the metrics initialized to 0, so nothing
      will be added to the skb in rtnetlink_put_metrics. Avoid the loop if
      metrics is from dst_default_metrics.
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c22a133a
    • David S. Miller's avatar
      Merge branch 'skfp-cleanups' · 4191faa2
      David S. Miller authored
      Puranjay Mohan says:
      
      ====================
      net: fddi: skfp: Use PCI generic definitions instead of private duplicates
      
      This patch series removes the private duplicates of PCI definitions in
      favour of generic definitions defined in pci_regs.h.
      
      This driver only uses some of the generic PCI definitons,
      which are included from pci_regs.h and thier private versions
      are removed from skfbi.h with all other private defines.
      
      The skfbi.h defines PCI_REV_ID and other private defines with different
      names, these are renamed to Generic PCI names to make them
      compatible with defines in pci_regs.h.
      
      All unused defines are removed from skfbi.h.
      
      Changes in v5:
      Removed unused PCI definitions which were left in v4
      
      Changes in v4:
      Removed unused PCI definitions which were left in v3
      
      Changes in v3:
      Renamed all local PCI definitions to Generic names.
      Corrected coding style mistakes.
      
      Changes in v2:
      Converted individual patches to a series.
      Made sure that individual patches build correctly
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4191faa2
    • Puranjay Mohan's avatar
      net: fddi: skfp: Remove unused private PCI definitions · 3ce7ee2c
      Puranjay Mohan authored
      Remove unused private PCI definitions from skfbi.h because generic PCI
      symbols are already included from pci_regs.h.
      Signed-off-by: default avatarPuranjay Mohan <puranjay12@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ce7ee2c
    • Puranjay Mohan's avatar
      net: fddi: skfp: Include generic PCI definitions · a08f1c43
      Puranjay Mohan authored
      Include the uapi/linux/pci_regs.h header file which contains the generic
      PCI defines.
      Signed-off-by: default avatarPuranjay Mohan <puranjay12@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a08f1c43
    • Puranjay Mohan's avatar
      net: fddi: skfp: Rename local PCI defines to match generic PCI defines · f8da5dac
      Puranjay Mohan authored
      Rename the PCI_REV_ID and other local defines to Generic PCI define names
      in skfbi.h and drvfbi.c to make it compatible with the pci_regs.h.
      Signed-off-by: default avatarPuranjay Mohan <puranjay12@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f8da5dac
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-for-davem-2019-06-26' of... · a8b79105
      David S. Miller authored
      Merge tag 'wireless-drivers-next-for-davem-2019-06-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valu says:
      
      ====================
      wireless-drivers-next patches for 5.3
      
      First set of patches for 5.3, but not that many patches this time.
      
      This pull request fails to compile with the tip tree due to
      ktime_get_boot_ns() API changes there. It should be easy for Linus to
      fix it in p54 driver once he pulls this, an example resolution here:
      
      https://lkml.kernel.org/r/20190625160432.533aa140@canb.auug.org.au
      
      Major changes:
      
      airo
      
      * switch to use skcipher interface
      
      p54
      
      * support boottime in scan results
      
      rtw88
      
      * add fast xmit support
      
      * add random mac address on scan support
      
      rt2x00
      
      * add software watchdog to detect hangs, it's disabled by default
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8b79105
    • Jon Hunter's avatar
      net: stmmac: Fix crash observed if PHY does not support EEE · 177d935a
      Jon Hunter authored
      If the PHY does not support EEE mode, then a crash is observed when the
      ethernet interface is enabled. The crash occurs, because if the PHY does
      not support EEE, then although the EEE timer is never configured, it is
      still marked as enabled and so the stmmac ethernet driver is still
      trying to update the timer by calling mod_timer(). This triggers a BUG()
      in the mod_timer() because we are trying to update a timer when there is
      no callback function set because timer_setup() was never called for this
      timer.
      
      The problem is caused because we return true from the function
      stmmac_eee_init(), marking the EEE timer as enabled, even when we have
      not configured the EEE timer. Fix this by ensuring that we return false
      if the PHY does not support EEE and hence, 'eee_active' is not set.
      
      Fixes: 74371272 ("net: stmmac: Convert to phylink and remove phylib logic")
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Tested-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      177d935a
    • Jon Hunter's avatar
      net: stmmac: Fix possible deadlock when disabling EEE support · 0867bb97
      Jon Hunter authored
      When stmmac_eee_init() is called to disable EEE support, then the timer
      for EEE support is stopped and we return from the function. Prior to
      stopping the timer, a mutex was acquired but in this case it is never
      released and so could cause a deadlock. Fix this by releasing the mutex
      prior to returning from stmmax_eee_init() when stopping the EEE timer.
      
      Fixes: 74371272 ("net: stmmac: Convert to phylink and remove phylib logic")
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Tested-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0867bb97
    • Eric Dumazet's avatar
      ipv6: fix suspicious RCU usage in rt6_dump_route() · 3b525691
      Eric Dumazet authored
      syzbot reminded us that rt6_nh_dump_exceptions() needs to be called
      with rcu_read_lock()
      
      net/ipv6/route.c:1593 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      2 locks held by syz-executor609/8966:
       #0: 00000000b7dbe288 (rtnl_mutex){+.+.}, at: netlink_dump+0xe7/0xfb0 net/netlink/af_netlink.c:2199
       #1: 00000000f2d87c21 (&(&tb->tb6_lock)->rlock){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline]
       #1: 00000000f2d87c21 (&(&tb->tb6_lock)->rlock){+...}, at: fib6_dump_table.isra.0+0x37e/0x570 net/ipv6/ip6_fib.c:533
      
      stack backtrace:
      CPU: 0 PID: 8966 Comm: syz-executor609 Not tainted 5.2.0-rc5+ #43
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5250
       fib6_nh_get_excptn_bucket+0x18e/0x1b0 net/ipv6/route.c:1593
       rt6_nh_dump_exceptions+0x45/0x4d0 net/ipv6/route.c:5541
       rt6_dump_route+0x904/0xc50 net/ipv6/route.c:5640
       fib6_dump_node+0x168/0x280 net/ipv6/ip6_fib.c:467
       fib6_walk_continue+0x4a9/0x8e0 net/ipv6/ip6_fib.c:1986
       fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:2034
       fib6_dump_table.isra.0+0x38a/0x570 net/ipv6/ip6_fib.c:534
       inet6_dump_fib+0x93c/0xb00 net/ipv6/ip6_fib.c:624
       rtnl_dump_all+0x295/0x490 net/core/rtnetlink.c:3445
       netlink_dump+0x558/0xfb0 net/netlink/af_netlink.c:2244
       __netlink_dump_start+0x5b1/0x7d0 net/netlink/af_netlink.c:2352
       netlink_dump_start include/linux/netlink.h:226 [inline]
       rtnetlink_rcv_msg+0x73d/0xb00 net/core/rtnetlink.c:5182
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5237
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:646 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:665
       sock_write_iter+0x27c/0x3e0 net/socket.c:994
       call_write_iter include/linux/fs.h:1872 [inline]
       new_sync_write+0x4d3/0x770 fs/read_write.c:483
       __vfs_write+0xe1/0x110 fs/read_write.c:496
       vfs_write+0x20c/0x580 fs/read_write.c:558
       ksys_write+0x14f/0x290 fs/read_write.c:611
       __do_sys_write fs/read_write.c:623 [inline]
       __se_sys_write fs/read_write.c:620 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:620
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4401b9
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffc8e134978 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401b9
      RDX: 000000000000001c RSI: 0000000020000000 RDI: 00
      
      Fixes: 1e47b483 ("ipv6: Dump route exceptions if requested")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b525691
    • Eric Dumazet's avatar
      ipv4: fix suspicious RCU usage in fib_dump_info_fnhe() · 93ed54b1
      Eric Dumazet authored
      sysbot reported that we lack appropriate rcu_read_lock()
      protection in fib_dump_info_fnhe()
      
      net/ipv4/route.c:2875 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by syz-executor609/8966:
       #0: 00000000b7dbe288 (rtnl_mutex){+.+.}, at: netlink_dump+0xe7/0xfb0 net/netlink/af_netlink.c:2199
      
      stack backtrace:
      CPU: 0 PID: 8966 Comm: syz-executor609 Not tainted 5.2.0-rc5+ #43
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5250
       fib_dump_info_fnhe+0x9d9/0x1080 net/ipv4/route.c:2875
       fn_trie_dump_leaf net/ipv4/fib_trie.c:2141 [inline]
       fib_table_dump+0x64a/0xd00 net/ipv4/fib_trie.c:2175
       inet_dump_fib+0x83c/0xa90 net/ipv4/fib_frontend.c:1004
       rtnl_dump_all+0x295/0x490 net/core/rtnetlink.c:3445
       netlink_dump+0x558/0xfb0 net/netlink/af_netlink.c:2244
       __netlink_dump_start+0x5b1/0x7d0 net/netlink/af_netlink.c:2352
       netlink_dump_start include/linux/netlink.h:226 [inline]
       rtnetlink_rcv_msg+0x73d/0xb00 net/core/rtnetlink.c:5182
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5237
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:646 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:665
       sock_write_iter+0x27c/0x3e0 net/socket.c:994
       call_write_iter include/linux/fs.h:1872 [inline]
       new_sync_write+0x4d3/0x770 fs/read_write.c:483
       __vfs_write+0xe1/0x110 fs/read_write.c:496
       vfs_write+0x20c/0x580 fs/read_write.c:558
       ksys_write+0x14f/0x290 fs/read_write.c:611
       __do_sys_write fs/read_write.c:623 [inline]
       __se_sys_write fs/read_write.c:620 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:620
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4401b9
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffc8e134978 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401b9
      RDX: 000000000000001c RSI: 0000000020000000 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 0000000000000010 R11: 0000000000000246 R12: 0000000000401a40
      R13: 0000000000401ad0 R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: ee28906f ("ipv4: Dump route exceptions if requested")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93ed54b1
    • Jakub Kicinski's avatar
      Revert "net: ena: ethtool: add extra properties retrieval via get_priv_flags" · eb203bae
      Jakub Kicinski authored
      This reverts commit 315c28d2 ("net: ena: ethtool: add extra properties retrieval via get_priv_flags").
      
      As discussed at netconf and on the mailing list we can't allow
      for the the abuse of private flags for exposing arbitrary device
      labels.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb203bae
    • David S. Miller's avatar
      Merge branch 'net-hns3-some-code-optimizations-bugfixes' · 1b2b01a7
      David S. Miller authored
      Huazhong Tan says:
      
      ====================
      net: hns3: some code optimizations & bugfixes
      
      This patch-set includes code optimizations and bugfixes for
      the HNS3 ethernet controller driver.
      
      [patch 1/11] fixes a selftest issue when doing autoneg.
      
      [patch 2/11 - 3-11] adds two code optimizations about VLAN issue.
      
      [patch 4/11] restores the MAC autoneg state after reset.
      
      [patch 5/11 - 8/11] adds some code optimizations and bugfixes about
      HW errors handling.
      
      [patch 9/11 - 11/11] fixes some issues related to driver loading and
      unloading.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b2b01a7
    • Weihang Li's avatar
      net: hns3: add exception handling when enable NIC HW error interrupts · bcf643c5
      Weihang Li authored
      If we failed to enable NIC HW error interrupts during client
      initialization in some cases, we should do exception handling to clear
      flags and free the resources.
      
      Fixes: 00ea6e5f ("net: hns3: delay and separate enabling of NIC and ROCE HW errors")
      Signed-off-by: default avatarWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bcf643c5
    • Huazhong Tan's avatar
      net: hns3: fixes wrong place enabling ROCE HW error when loading · 72fcd2be
      Huazhong Tan authored
      The ROCE HW errors should only be enabled when initializing ROCE's
      client, the current code enable it no matter initializing NIC or
      ROCE client.
      
      So this patch fixes it.
      
      Fixes: 00ea6e5f ("net: hns3: delay and separate enabling of NIC and ROCE HW errors")
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72fcd2be
    • Huazhong Tan's avatar
      net: hns3: fix race conditions between reset and module loading & unloading · 7cf9c069
      Huazhong Tan authored
      When loading or unloading module, it should wait for the reset task
      done before it un-initializes the client, otherwise the reset task
      may cause a NULL pointer reference.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cf9c069
    • Weihang Li's avatar
      net: hns3: add check to number of buffer descriptors · 987b4ae7
      Weihang Li authored
      This patch adds check to number of bds before we allocate memory for
      them. If we get an invalid bd num in some cases, it will cause a memory
      overflow.
      Signed-off-by: default avatarWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      987b4ae7
    • Weihang Li's avatar
      net: hns3: remove override_pci_need_reset · 9d5e67d1
      Weihang Li authored
      We add override_pci_need_reset to prevent redundant and unwanted PF
      resets if a RAS error occurs in commit 69b51bbb ("net: hns3: fix
      to stop multiple HNS reset due to the AER changes").
      
      Now in HNS3 driver, we use hw_err_reset_req to record reset level that
      we need to recover from a RAS error. This variable cans solve above
      issue as override_pci_need_reset, so this patch removes
      override_pci_need_reset.
      Signed-off-by: default avatarWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d5e67d1
    • Weihang Li's avatar
      net: hns3: modify handling of out of memory in hclge_err.c · b4b9bd92
      Weihang Li authored
      Users should be informed if HNS driver failed to allocate memory for
      descriptor when handling hw errors. This patch solve above issues.
      Signed-off-by: default avatarWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4b9bd92
    • Weihang Li's avatar
      net: hns3: code optimizaition of hclge_handle_hw_ras_error() · 2253db16
      Weihang Li authored
      This patch optimizes hclge_handle_hw_ras_error() to make the code logic
      clearer.
      1. If there was no NIC or Roce RAS when we read
         HCLGE_RAS_PF_OTHER_INT_STS_REG, we return directly.
      2. Because NIC and Roce RAS may occurs at the same time, so we should
         check value of revision at first before we handle Roce RAS instead
         of only checking it in branch of no NIC RAS is detected.
      3. Check HCLGE_STATE_RST_HANDLING each time before we want to return
         PCI_ERS_RESULT_NEED_RESET.
      4. Remove checking of HCLGE_RAS_REG_NFE_MASK and
         HCLGE_RAS_REG_ROCEE_ERR_MASK because if hw_err_reset_req is not
         zero, it proves that we have set it in handling of NIC or Roce RAS.
      Signed-off-by: default avatarWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2253db16
    • Jian Shen's avatar
      net: hns3: restore the MAC autoneg state after reset · d736fc6c
      Jian Shen authored
      When doing global reset, the MAC autoneg state of fibre
      port is set to default, which may cause user configuration
      lost. This patch fixes it by restore the MAC autoneg state
      after reset.
      
      Fixes: 22f48e24 ("net: hns3: add autoneg and change speed support for fibre port")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d736fc6c
    • Jian Shen's avatar
      net: hns3: sync VLAN filter entries when kill VLAN ID failed · fe4144d4
      Jian Shen authored
      When HW is resetting, firmware is unable to handle commands
      from driver. So if remove VLAN device from stack at this time,
      it will fail to remove the VLAN ID from HW VLAN filter, then
      the VLAN filter status is unsynced with stack.
      
      This patch fixes it by recording the VLAN ID delete failed,
      and removes them again when reset complete.
      
      Fixes: 44e626f7 ("net: hns3: fix VLAN offload handle for VLAN inserted by port")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe4144d4
    • Jian Shen's avatar
      net: hns3: remove VF VLAN filter entry inexistent warning print · d0c31df2
      Jian Shen authored
      For VF VLAN filter is disabled when VF VLAN table is full, then the
      new VLAN ID won't be added into VF VLAN table, it will always print
      fail log when remove these VLAN IDs. If user has added too many
      VLANs, it will cause massive verbose print logs.
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0c31df2
    • Jian Shen's avatar
      net: hns3: fix selftest fail issue for fibre port with autoneg on · 7786a996
      Jian Shen authored
      When doing selftest for fibre port with autoneg on, the MAC speed
      may be incorrect, which may cause the selftest failed. This patch
      fixes it by halting autoneg during the selftest.
      
      Fixes: 22f48e24 ("net: hns3: add autoneg and change speed support for fibre port")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7786a996
  3. 25 Jun, 2019 1 commit