1. 27 Aug, 2020 16 commits
  2. 26 Aug, 2020 24 commits
    • David S. Miller's avatar
      Merge branch 'drivers-net-constify-static-ops-variables' · f0966581
      David S. Miller authored
      Rikard Falkeborn says:
      
      ====================
      drivers/net: constify static ops-variables
      
      This series constifies a number of static ops variables, to allow the
      compiler to put them in read-only memory. Compile-tested only.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0966581
    • Rikard Falkeborn's avatar
      net: ath11k: constify ath11k_thermal_ops · 31ffcb10
      Rikard Falkeborn authored
      The only usage of ath11k_thermal_ops is to pass its address to
      thermal_cooling_device_register() which takes a const pointer. Make it
      const to allow the compiler to put it in read-only memory.
      Signed-off-by: default avatarRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31ffcb10
    • Rikard Falkeborn's avatar
      net: phy: mscc: macsec: constify vsc8584_macsec_ops · 73a9df4c
      Rikard Falkeborn authored
      The only usage of vsc8584_macsec_ops is to assign its address to the
      macsec_ops field in the phydev struct, which is a const pointer. Make it
      const to allow the compiler to put it in read-only memory.
      Signed-off-by: default avatarRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73a9df4c
    • Rikard Falkeborn's avatar
      net: phy: at803x: constify static regulator_ops · 3faaf539
      Rikard Falkeborn authored
      The only usage of vddio_regulator_ops and vddh_regulator_ops is to
      assign their address to the ops field in the regulator_desc struct,
      which is a const pointer. Make them const to allow the compiler to
      put them in read-only memory.
      Signed-off-by: default avatarRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3faaf539
    • Rikard Falkeborn's avatar
      net: renesas: sh_eth: constify bb_ops · b968a44f
      Rikard Falkeborn authored
      The only usage of bb_ops is to assign its address to the ops field in
      the mdiobb_ctrl struct, which is a const pointer. Make it const to allow
      the compiler to put it in read-only memory.
      Signed-off-by: default avatarRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b968a44f
    • Rikard Falkeborn's avatar
      net: ethernet: ravb: constify bb_ops · 3ab4519a
      Rikard Falkeborn authored
      The only usage of bb_ops is to assign its address to the ops field in
      the mdiobb_ctrl struct, which is a const pointer. Make it const to allow
      the compiler to put it in read-only memory.
      Signed-off-by: default avatarRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ab4519a
    • Rikard Falkeborn's avatar
      net: ethernet: qualcomm: constify qca_serdev_ops · 715d0871
      Rikard Falkeborn authored
      The only usage of qca_serdev_ops is to pass its address to
      serdev_device_set_client_ops() which takes a const pointer. Make it
      const to allow the compiler to put it in read-only memory.
      Signed-off-by: default avatarRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      715d0871
    • Wang Hai's avatar
      net: ipa: remove duplicate include · d6fc1923
      Wang Hai authored
      Remove linux/notifier.h which is included more than once
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6fc1923
    • David S. Miller's avatar
      Merge branch 'refactoring-of-ibmvnic-code' · 8396fb8d
      David S. Miller authored
      Lijun Pan says:
      
      ====================
      refactoring of ibmvnic code
      
      This patch series refactor reset_init and init functions,
      and make some other cosmetic changes to make the code
      easier to read and debug. v2 removes __func__ and v1's 1/5.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8396fb8d
    • Lijun Pan's avatar
      ibmvnic: merge ibmvnic_reset_init and ibmvnic_init · 635e442f
      Lijun Pan authored
      These two functions share the majority of the code, hence merge
      them together. In the meanwhile, add a reset pass-in parameter
      to differentiate them. Thus, the code is easier to read and to tell
      the difference between reset_init and regular init.
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      635e442f
    • Lijun Pan's avatar
      ibmvnic: remove never executed if statement · 550f4d46
      Lijun Pan authored
      At the beginning of the function, from_passive_init is set false by
      "adapter->from_passive_init = false;",
      hence the if statement will never run.
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      550f4d46
    • Lijun Pan's avatar
      ibmvnic: improve ibmvnic_init and ibmvnic_reset_init · fa68bfab
      Lijun Pan authored
      When H_SEND_CRQ command returns with H_CLOSED, it means the
      server's CRQ is not ready yet. Instead of resetting immediately,
      we wait for the server to launch passive init.
      ibmvnic_init() and ibmvnic_reset_init() should also return the
      error code from ibmvnic_send_crq_init() call.
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa68bfab
    • Lijun Pan's avatar
      ibmvnic: compare adapter->init_done_rc with more readable ibmvnic_rc_codes · 4c5f6af0
      Lijun Pan authored
      Instead of comparing (adapter->init_done_rc == 1), let it
      be (adapter->init_done_rc == PARTIALSUCCESS).
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c5f6af0
    • David S. Miller's avatar
      Merge branch 'ipv4-nexthop-Various-improvements' · bf82d565
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      ipv4: nexthop: Various improvements
      
      This patch set contains various improvements that I made to the nexthop
      object code while studying it towards my upcoming changes.
      
      While patches #4 and #6 fix bugs, they are not regressions (never
      worked). They also do not occur to me as critical issues, which is why I
      am targeting them at net-next.
      
      Tested with fib_nexthops.sh:
      
      Tests passed: 134
      Tests failed:   0
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf82d565
    • Ido Schimmel's avatar
      selftests: fib_nexthops: Test IPv6 route with group after replacing IPv4 nexthops · 041bc0dc
      Ido Schimmel authored
      Test that an IPv6 route can not use a nexthop group with mixed IPv4 and
      IPv6 nexthops, but can use it after replacing the IPv4 nexthops with
      IPv6 nexthops.
      
      Output without previous patch:
      
      # ./fib_nexthops.sh -t ipv6_fcnal_runtime
      
      IPv6 functional runtime
      -----------------------
      TEST: Route add                                                     [ OK ]
      TEST: Route delete                                                  [ OK ]
      TEST: Ping with nexthop                                             [ OK ]
      TEST: Ping - multipath                                              [ OK ]
      TEST: Ping - blackhole                                              [ OK ]
      TEST: Ping - blackhole replaced with gateway                        [ OK ]
      TEST: Ping - gateway replaced by blackhole                          [ OK ]
      TEST: Ping - group with blackhole                                   [ OK ]
      TEST: Ping - group blackhole replaced with gateways                 [ OK ]
      TEST: IPv6 route with device only nexthop                           [ OK ]
      TEST: IPv6 multipath route with nexthop mix - dev only + gw         [ OK ]
      TEST: IPv6 route can not have a v4 gateway                          [ OK ]
      TEST: Nexthop replace - v6 route, v4 nexthop                        [ OK ]
      TEST: Nexthop replace of group entry - v6 route, v4 nexthop         [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route using a group after removing v4 gateways           [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route using a group after replacing v4 gateways          [FAIL]
      TEST: Nexthop with default route and rpfilter                       [ OK ]
      TEST: Nexthop with multipath default route and rpfilter             [ OK ]
      
      Tests passed:  21
      Tests failed:   1
      
      Output with previous patch:
      
      # ./fib_nexthops.sh -t ipv6_fcnal_runtime
      
      IPv6 functional runtime
      -----------------------
      TEST: Route add                                                     [ OK ]
      TEST: Route delete                                                  [ OK ]
      TEST: Ping with nexthop                                             [ OK ]
      TEST: Ping - multipath                                              [ OK ]
      TEST: Ping - blackhole                                              [ OK ]
      TEST: Ping - blackhole replaced with gateway                        [ OK ]
      TEST: Ping - gateway replaced by blackhole                          [ OK ]
      TEST: Ping - group with blackhole                                   [ OK ]
      TEST: Ping - group blackhole replaced with gateways                 [ OK ]
      TEST: IPv6 route with device only nexthop                           [ OK ]
      TEST: IPv6 multipath route with nexthop mix - dev only + gw         [ OK ]
      TEST: IPv6 route can not have a v4 gateway                          [ OK ]
      TEST: Nexthop replace - v6 route, v4 nexthop                        [ OK ]
      TEST: Nexthop replace of group entry - v6 route, v4 nexthop         [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route using a group after removing v4 gateways           [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route using a group after replacing v4 gateways          [ OK ]
      TEST: Nexthop with default route and rpfilter                       [ OK ]
      TEST: Nexthop with multipath default route and rpfilter             [ OK ]
      
      Tests passed:  22
      Tests failed:   0
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      041bc0dc
    • Ido Schimmel's avatar
      ipv4: nexthop: Correctly update nexthop group when replacing a nexthop · 885a3b15
      Ido Schimmel authored
      Each nexthop group contains an indication if it has IPv4 nexthops
      ('has_v4'). Its purpose is to prevent IPv6 routes from using groups with
      IPv4 nexthops.
      
      However, the indication is not updated when a nexthop is replaced. This
      results in the kernel wrongly rejecting IPv6 routes from pointing to
      groups that only contain IPv6 nexthops. Example:
      
      # ip nexthop replace id 1 via 192.0.2.2 dev dummy10
      # ip nexthop replace id 10 group 1
      # ip nexthop replace id 1 via 2001:db8:1::2 dev dummy10
      # ip route replace 2001:db8:10::/64 nhid 10
      Error: IPv6 routes can not use an IPv4 nexthop.
      
      Solve this by iterating over all the nexthop groups that the replaced
      nexthop is a member of and potentially update their IPv4 indication
      according to the new set of member nexthops.
      
      Avoid wasting cycles by only performing the update in case an IPv4
      nexthop is replaced by an IPv6 nexthop.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      885a3b15
    • Ido Schimmel's avatar
      selftests: fib_nexthops: Test IPv6 route with group after removing IPv4 nexthops · 05290a27
      Ido Schimmel authored
      Test that an IPv6 route can not use a nexthop group with mixed IPv4 and
      IPv6 nexthops, but can use it after deleting the IPv4 nexthops.
      
      Output without previous patch:
      
      # ./fib_nexthops.sh -t ipv6_fcnal_runtime
      
      IPv6 functional runtime
      -----------------------
      TEST: Route add                                                     [ OK ]
      TEST: Route delete                                                  [ OK ]
      TEST: Ping with nexthop                                             [ OK ]
      TEST: Ping - multipath                                              [ OK ]
      TEST: Ping - blackhole                                              [ OK ]
      TEST: Ping - blackhole replaced with gateway                        [ OK ]
      TEST: Ping - gateway replaced by blackhole                          [ OK ]
      TEST: Ping - group with blackhole                                   [ OK ]
      TEST: Ping - group blackhole replaced with gateways                 [ OK ]
      TEST: IPv6 route with device only nexthop                           [ OK ]
      TEST: IPv6 multipath route with nexthop mix - dev only + gw         [ OK ]
      TEST: IPv6 route can not have a v4 gateway                          [ OK ]
      TEST: Nexthop replace - v6 route, v4 nexthop                        [ OK ]
      TEST: Nexthop replace of group entry - v6 route, v4 nexthop         [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route using a group after deleting v4 gateways           [FAIL]
      TEST: Nexthop with default route and rpfilter                       [ OK ]
      TEST: Nexthop with multipath default route and rpfilter             [ OK ]
      
      Tests passed:  18
      Tests failed:   1
      
      Output with previous patch:
      
      bash-5.0# ./fib_nexthops.sh -t ipv6_fcnal_runtime
      
      IPv6 functional runtime
      -----------------------
      TEST: Route add                                                     [ OK ]
      TEST: Route delete                                                  [ OK ]
      TEST: Ping with nexthop                                             [ OK ]
      TEST: Ping - multipath                                              [ OK ]
      TEST: Ping - blackhole                                              [ OK ]
      TEST: Ping - blackhole replaced with gateway                        [ OK ]
      TEST: Ping - gateway replaced by blackhole                          [ OK ]
      TEST: Ping - group with blackhole                                   [ OK ]
      TEST: Ping - group blackhole replaced with gateways                 [ OK ]
      TEST: IPv6 route with device only nexthop                           [ OK ]
      TEST: IPv6 multipath route with nexthop mix - dev only + gw         [ OK ]
      TEST: IPv6 route can not have a v4 gateway                          [ OK ]
      TEST: Nexthop replace - v6 route, v4 nexthop                        [ OK ]
      TEST: Nexthop replace of group entry - v6 route, v4 nexthop         [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route can not have a group with v4 and v6 gateways       [ OK ]
      TEST: IPv6 route using a group after deleting v4 gateways           [ OK ]
      TEST: Nexthop with default route and rpfilter                       [ OK ]
      TEST: Nexthop with multipath default route and rpfilter             [ OK ]
      
      Tests passed:  19
      Tests failed:   0
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05290a27
    • Ido Schimmel's avatar
      ipv4: nexthop: Correctly update nexthop group when removing a nexthop · 863b2558
      Ido Schimmel authored
      Each nexthop group contains an indication if it has IPv4 nexthops
      ('has_v4'). Its purpose is to prevent IPv6 routes from using groups with
      IPv4 nexthops.
      
      However, the indication is not updated when a nexthop is removed. This
      results in the kernel wrongly rejecting IPv6 routes from pointing to
      groups that only contain IPv6 nexthops. Example:
      
      # ip nexthop replace id 1 via 192.0.2.2 dev dummy10
      # ip nexthop replace id 2 via 2001:db8:1::2 dev dummy10
      # ip nexthop replace id 10 group 1/2
      # ip nexthop del id 1
      # ip route replace 2001:db8:10::/64 nhid 10
      Error: IPv6 routes can not use an IPv4 nexthop.
      
      Solve this by updating the indication according to the new set of
      member nexthops.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      863b2558
    • Ido Schimmel's avatar
      ipv4: nexthop: Remove unnecessary rtnl_dereference() · 233c6378
      Ido Schimmel authored
      The pointer is not RCU protected, so remove the unnecessary
      rtnl_dereference(). This suppresses the following warning:
      
      net/ipv4/nexthop.c:1101:24: error: incompatible types in comparison expression (different address spaces):
      net/ipv4/nexthop.c:1101:24:    struct rb_node [noderef] __rcu *
      net/ipv4/nexthop.c:1101:24:    struct rb_node *
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      233c6378
    • Ido Schimmel's avatar
      ipv4: nexthop: Use nla_put_be32() for NHA_GATEWAY · 33d80996
      Ido Schimmel authored
      The code correctly uses nla_get_be32() to get the payload of the
      attribute, but incorrectly uses nla_put_u32() to add the attribute to
      the payload. This results in the following warning:
      
      net/ipv4/nexthop.c:279:59: warning: incorrect type in argument 3 (different base types)
      net/ipv4/nexthop.c:279:59:    expected unsigned int [usertype] value
      net/ipv4/nexthop.c:279:59:    got restricted __be32 [usertype] ipv4
      
      Suppress the warning by using nla_put_be32().
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33d80996
    • Ido Schimmel's avatar
      ipv4: nexthop: Reduce allocation size of 'struct nh_group' · d7d49dc7
      Ido Schimmel authored
      The struct looks as follows:
      
      struct nh_group {
      	struct nh_group		*spare; /* spare group for removals */
      	u16			num_nh;
      	bool			mpath;
      	bool			fdb_nh;
      	bool			has_v4;
      	struct nh_grp_entry	nh_entries[];
      };
      
      But its offset within 'struct nexthop' is also taken into account to
      determine the allocation size.
      
      Instead, use struct_size() to allocate only the required number of
      bytes.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7d49dc7
    • David S. Miller's avatar
      Merge branch 'net_prefetch-API' · 751e4251
      David S. Miller authored
      Tariq Toukan says:
      
      ====================
      net_prefetch API
      
      This patchset adds a common net API for L1 cacheline size-aware prefetch.
      
      Patch 1 introduces the common API in net and aligns the drivers to use it.
      Patches 2 and 3 add usage in mlx4 and mlx5 Eth drivers.
      
      Series generated against net-next commit:
      079f921e Merge tag 'batadv-next-for-davem-20200824' of git://git.open-mesh.org/linux-merge
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      751e4251
    • Tariq Toukan's avatar
      net/mlx4_en: RX, Add a prefetch command for small L1_CACHE_BYTES · aed4d4c6
      Tariq Toukan authored
      A single cacheline might not contain the packet header for
      small L1_CACHE_BYTES values.
      Use net_prefetch() as it issues an additional prefetch
      in this case.
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aed4d4c6
    • Tariq Toukan's avatar
      net/mlx5e: RX, Add a prefetch command for small L1_CACHE_BYTES · e20f0dbf
      Tariq Toukan authored
      A single cacheline might not contain the packet header for
      small L1_CACHE_BYTES values.
      Use net_prefetch() as it issues an additional prefetch
      in this case.
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e20f0dbf