1. 20 Feb, 2022 3 commits
  2. 19 Feb, 2022 29 commits
    • Volodymyr Mytnyk's avatar
      net: prestera: acl: fix 'client_map' buff overflow · 48c77bdf
      Volodymyr Mytnyk authored
      smatch warnings:
      drivers/net/ethernet/marvell/prestera/prestera_acl.c:103
      prestera_acl_chain_to_client() error: buffer overflow
      'client_map' 3 <= 3
      
      	prestera_acl_chain_to_client(u32 chain_index, ...)
              ...
      	u32 client_map[] = {
      		PRESTERA_HW_COUNTER_CLIENT_LOOKUP_0,
      		PRESTERA_HW_COUNTER_CLIENT_LOOKUP_1,
      		PRESTERA_HW_COUNTER_CLIENT_LOOKUP_2
      	};
      	if (chain_index > ARRAY_SIZE(client_map))
      	...
      
      Fixes: fa5d824c ("net: prestera: acl: add multi-chain support offload")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarVolodymyr Mytnyk <vmytnyk@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48c77bdf
    • Ahmad Fatoum's avatar
      net: dsa: microchip: add ksz8563 to ksz9477 I2C driver · 173a272a
      Ahmad Fatoum authored
      The KSZ9477 SPI driver already has support for the KSZ8563. The same switch
      chip can also be managed via i2c and we have an KSZ9477 I2C driver, but
      that one lacks the relevant compatible entry. Add it.
      
      DT bindings already describe this compatible.
      Signed-off-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      173a272a
    • Dan Carpenter's avatar
      net/smc: unlock on error paths in __smc_setsockopt() · 7a11455f
      Dan Carpenter authored
      These two error paths need to release_sock(sk) before returning.
      
      Fixes: a6a6fe27 ("net/smc: Dynamic control handshake limitation by socket options")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarD. Wythe <alibuda@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a11455f
    • Oleksij Rempel's avatar
      net: dsa: microchip: ksz9477: export HW stats over stats64 interface · a7f4f13a
      Oleksij Rempel authored
      Provide access to HW offloaded packets over stats64 interface.
      The rx/tx_bytes values needed some fixing since HW is accounting size of
      the Ethernet frame together with FCS.
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7f4f13a
    • David S. Miller's avatar
      Merge branch 'phylink-remove-pcs_poll' · 0d0350c4
      David S. Miller authored
      Russell King says:
      
      ====================
      net: phylink: remove pcs_poll
      
      This small series removes the now unused pcs_poll members from DSA and
      phylink. "git grep pcs_poll drivers/net/ net/" on net-next confirms that
      the only places that reference this are in DSA core code and phylink
      code:
      
      drivers/net/phy/phylink.c:              if (pl->config->pcs_poll || pcs->poll)
      drivers/net/phy/phylink.c:              poll |= pl->config->pcs_poll;
      net/dsa/port.c: dp->pl_config.pcs_poll = ds->pcs_poll;
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d0350c4
    • Russell King (Oracle)'s avatar
      net: phylink: remove phylink_config's pcs_poll · 64b4a0f8
      Russell King (Oracle) authored
      phylink_config's pcs_poll is no longer used, let's get rid of it.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64b4a0f8
    • Russell King (Oracle)'s avatar
      net: dsa: remove pcs_poll · ccfbf44d
      Russell King (Oracle) authored
      With drivers converted over to using phylink PCS, there is no need for
      the struct dsa_switch member "pcs_poll" to exist anymore - there is a
      flag in the struct phylink_pcs which indicates whether this PCS needs
      to be polled which supersedes this.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ccfbf44d
    • Juhee Kang's avatar
      net: hsr: fix suspicious RCU usage warning in hsr_node_get_first() · e7f27420
      Juhee Kang authored
      When hsr_create_self_node() calls hsr_node_get_first(), the suspicious
      RCU usage warning is occurred. The reason why this warning is raised is
      the callers of hsr_node_get_first() use rcu_read_lock_bh() and
      other different synchronization mechanisms. Thus, this patch solved by
      replacing rcu_dereference() with rcu_dereference_bh_check().
      
      The kernel test robot reports:
          [   50.083470][ T3596] =============================
          [   50.088648][ T3596] WARNING: suspicious RCU usage
          [   50.093785][ T3596] 5.17.0-rc3-next-20220208-syzkaller #0 Not tainted
          [   50.100669][ T3596] -----------------------------
          [   50.105513][ T3596] net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage!
          [   50.113799][ T3596]
          [   50.113799][ T3596] other info that might help us debug this:
          [   50.113799][ T3596]
          [   50.124257][ T3596]
          [   50.124257][ T3596] rcu_scheduler_active = 2, debug_locks = 1
          [   50.132368][ T3596] 2 locks held by syz-executor.0/3596:
          [   50.137863][ T3596]  #0: ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x3be/0xb80
          [   50.147470][ T3596]  #1: ffff88807ec9d5f0 (&hsr->list_lock){+...}-{2:2}, at: hsr_create_self_node+0x225/0x650
          [   50.157623][ T3596]
          [   50.157623][ T3596] stack backtrace:
          [   50.163510][ T3596] CPU: 1 PID: 3596 Comm: syz-executor.0 Not tainted 5.17.0-rc3-next-20220208-syzkaller #0
          [   50.173381][ T3596] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
          [   50.183623][ T3596] Call Trace:
          [   50.186904][ T3596]  <TASK>
          [   50.189844][ T3596]  dump_stack_lvl+0xcd/0x134
          [   50.194640][ T3596]  hsr_node_get_first+0x9b/0xb0
          [   50.199499][ T3596]  hsr_create_self_node+0x22d/0x650
          [   50.204688][ T3596]  hsr_dev_finalize+0x2c1/0x7d0
          [   50.209669][ T3596]  hsr_newlink+0x315/0x730
          [   50.214113][ T3596]  ? hsr_dellink+0x130/0x130
          [   50.218789][ T3596]  ? rtnl_create_link+0x7e8/0xc00
          [   50.223803][ T3596]  ? hsr_dellink+0x130/0x130
          [   50.228397][ T3596]  __rtnl_newlink+0x107c/0x1760
          [   50.233249][ T3596]  ? rtnl_setlink+0x3c0/0x3c0
          [   50.238043][ T3596]  ? is_bpf_text_address+0x77/0x170
          [   50.243362][ T3596]  ? lock_downgrade+0x6e0/0x6e0
          [   50.248219][ T3596]  ? unwind_next_frame+0xee1/0x1ce0
          [   50.253605][ T3596]  ? entry_SYSCALL_64_after_hwframe+0x44/0xae
          [   50.259669][ T3596]  ? __sanitizer_cov_trace_cmp4+0x1c/0x70
          [   50.265423][ T3596]  ? is_bpf_text_address+0x99/0x170
          [   50.270819][ T3596]  ? kernel_text_address+0x39/0x80
          [   50.275950][ T3596]  ? __kernel_text_address+0x9/0x30
          [   50.281336][ T3596]  ? unwind_get_return_address+0x51/0x90
          [   50.286975][ T3596]  ? create_prof_cpu_mask+0x20/0x20
          [   50.292178][ T3596]  ? arch_stack_walk+0x93/0xe0
          [   50.297172][ T3596]  ? kmem_cache_alloc_trace+0x42/0x2c0
          [   50.302637][ T3596]  ? rcu_read_lock_sched_held+0x3a/0x70
          [   50.308194][ T3596]  rtnl_newlink+0x64/0xa0
          [   50.312524][ T3596]  ? __rtnl_newlink+0x1760/0x1760
          [   50.317545][ T3596]  rtnetlink_rcv_msg+0x413/0xb80
          [   50.322631][ T3596]  ? rtnl_newlink+0xa0/0xa0
          [   50.327159][ T3596]  netlink_rcv_skb+0x153/0x420
          [   50.331931][ T3596]  ? rtnl_newlink+0xa0/0xa0
          [   50.336436][ T3596]  ? netlink_ack+0xa80/0xa80
          [   50.341095][ T3596]  ? netlink_deliver_tap+0x1a2/0xc40
          [   50.346532][ T3596]  ? netlink_deliver_tap+0x1b1/0xc40
          [   50.351839][ T3596]  netlink_unicast+0x539/0x7e0
          [   50.356633][ T3596]  ? netlink_attachskb+0x880/0x880
          [   50.361750][ T3596]  ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
          [   50.368003][ T3596]  ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
          [   50.374707][ T3596]  ? __phys_addr_symbol+0x2c/0x70
          [   50.379753][ T3596]  ? __sanitizer_cov_trace_cmp8+0x1d/0x70
          [   50.385568][ T3596]  ? __check_object_size+0x16c/0x4f0
          [   50.390859][ T3596]  netlink_sendmsg+0x904/0xe00
          [   50.395715][ T3596]  ? netlink_unicast+0x7e0/0x7e0
          [   50.400722][ T3596]  ? __sanitizer_cov_trace_const_cmp4+0x1c/0x70
          [   50.407003][ T3596]  ? netlink_unicast+0x7e0/0x7e0
          [   50.412119][ T3596]  sock_sendmsg+0xcf/0x120
          [   50.416548][ T3596]  __sys_sendto+0x21c/0x320
          [   50.421052][ T3596]  ? __ia32_sys_getpeername+0xb0/0xb0
          [   50.426427][ T3596]  ? lockdep_hardirqs_on_prepare+0x400/0x400
          [   50.432721][ T3596]  ? __context_tracking_exit+0xb8/0xe0
          [   50.438188][ T3596]  ? lock_downgrade+0x6e0/0x6e0
          [   50.443041][ T3596]  ? lock_downgrade+0x6e0/0x6e0
          [   50.447902][ T3596]  __x64_sys_sendto+0xdd/0x1b0
          [   50.452759][ T3596]  ? lockdep_hardirqs_on+0x79/0x100
          [   50.457964][ T3596]  ? syscall_enter_from_user_mode+0x21/0x70
          [   50.464150][ T3596]  do_syscall_64+0x35/0xb0
          [   50.468565][ T3596]  entry_SYSCALL_64_after_hwframe+0x44/0xae
          [   50.474452][ T3596] RIP: 0033:0x7f3148504e1c
          [   50.479052][ T3596] Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b
          [   50.498926][ T3596] RSP: 002b:00007ffeab5f2ab0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
          [   50.507342][ T3596] RAX: ffffffffffffffda RBX: 00007f314959d320 RCX: 00007f3148504e1c
          [   50.515393][ T3596] RDX: 0000000000000048 RSI: 00007f314959d370 RDI: 0000000000000003
          [   50.523444][ T3596] RBP: 0000000000000000 R08: 00007ffeab5f2b04 R09: 000000000000000c
          [   50.531492][ T3596] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
          [   50.539455][ T3596] R13: 00007f314959d370 R14: 0000000000000003 R15: 0000000000000000
      
      Fixes: 4acc45db ("net: hsr: use hlist_head instead of list_head for mac addresses")
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Reported-and-tested-by: syzbot+f0eb4f3876de066b128c@syzkaller.appspotmail.com
      Signed-off-by: default avatarJuhee Kang <claudiajkang@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7f27420
    • Christophe JAILLET's avatar
      atm: nicstar: Use kcalloc() to simplify code · 92c54a65
      Christophe JAILLET authored
      Use kcalloc() instead of kmalloc_array() and a loop to set all the values
      of the array to NULL.
      
      While at it, remove a duplicated assignment to 'scq->num_entries'.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92c54a65
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-one-step-register' · 32d51cef
      David S. Miller authored
      Radu Bulie says:
      
      ====================
      Provide direct access to 1588 one step register
      
      DPAA2 MAC supports 1588 one step timestamping.
      If this option is enabled then for each transmitted PTP event packet,
      the 1588 SINGLE_STEP register is accessed to modify the following fields:
      
      -offset of the correction field inside the PTP packet
      -UDP checksum update bit,  in case the PTP event packet has
       UDP encapsulation
      
      These values can change any time, because there may be multiple
      PTP clients connected, that receive various 1588 frame types:
      - L2 only frame
      - UDP / Ipv4
      - UDP / Ipv6
      - other
      
      The current implementation uses dpni_set_single_step_cfg to update the
      SINLGE_STEP register.
      Using an MC command  on the Tx datapath for each transmitted 1588 message
      introduces high delays, leading to low throughput and consequently to a
      small number of supported PTP clients. Besides these, the nanosecond
      correction field from the PTP packet will contain the high delay from the
      driver which together with the originTimestamp will render timestamp
      values that are unacceptable in a GM clock implementation.
      
      This patch series replaces the dpni_set_single_step_cfg function call from
      the Tx datapath for 1588 messages (when one step timestamping is enabled)
      with a callback that either implements direct access to the SINGLE_STEP
      register, eliminating the overhead caused by the MC command that will need
      to be dispatched by the MC firmware through the MC command portal
      interface or falls back to the dpni_set_single_step_cfg in case the MC
      version does not have support for returning the single step register
      base address.
      
      In other words all the delay introduced by dpni_set_single_step_cfg
      function will be eliminated (if MC version has support for returning the
      base address of the single step register), improving the egress driver
      performance for PTP packets when single step timestamping is enabled.
      
      The first patch adds a new attribute that contains the base address of
      the SINGLE_STEP register. It will be used to directly update the register
      on the Tx datapath.
      
      The second patch updates the driver such that the SINGLE_STEP
      register is either accessed directly if MC version >= 10.32 or is
      accessed through dpni_set_single_step_cfg command when 1588 messages
      are transmitted.
      
      Changes in v2:
       - move global function pointer into the driver's private structure in 2/2
       - move repetitive code outside the body of the callback functions  in 2/2
       - update function dpaa2_ptp_onestep_reg_update_method  and remove goto
         statement from non error path in 2/2
      
      Changes in v3:
       - remove static storage class specifier from within the structure in 2/2
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32d51cef
    • Radu Bulie's avatar
      dpaa2-eth: Update SINGLE_STEP register access · c4680c97
      Radu Bulie authored
      DPAA2 MAC supports 1588 one step timestamping.
      If this option is enabled then for each transmitted PTP event packet,
      the 1588 SINGLE_STEP register is accessed to modify the following fields:
      
      -offset of the correction field inside the PTP packet
      -UDP checksum update bit,  in case the PTP event packet has
       UDP encapsulation
      
      These values can change any time, because there may be multiple
      PTP clients connected, that receive various 1588 frame types:
      - L2 only frame
      - UDP / Ipv4
      - UDP / Ipv6
      - other
      
      The current implementation uses dpni_set_single_step_cfg to update the
      SINLGE_STEP register.
      Using an MC command  on the Tx datapath for each transmitted 1588 message
      introduces high delays, leading to low throughput and consequently to a
      small number of supported PTP clients. Besides these, the nanosecond
      correction field from the PTP packet will contain the high delay from the
      driver which together with the originTimestamp will render timestamp
      values that are unacceptable in a GM clock implementation.
      
      This patch updates the Tx datapath for 1588 messages when single step
      timestamp is enabled and provides direct access to SINGLE_STEP register,
      eliminating the  overhead caused by the dpni_set_single_step_cfg
      MC command. MC version >= 10.32 implements this functionality.
      If the MC version does not have support for returning the
      single step register base address, the driver will use
      dpni_set_single_step_cfg command for updates operations.
      
      All the delay introduced by dpni_set_single_step_cfg
      function will be eliminated (if MC version has support for returning the
      base address of the single step register), improving the egress driver
      performance for PTP packets when single step timestamping is enabled.
      
      Before these changes the maximum throughput for 1588 messages with
      single step hardware timestamp enabled was around 2000pps.
      After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps.
      Signed-off-by: default avatarRadu Bulie <radu-andrei.bulie@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4680c97
    • Radu Bulie's avatar
      dpaa2-eth: Update dpni_get_single_step_cfg command · 9572594e
      Radu Bulie authored
      dpni_get_single_step_cfg is an MC firmware command used for
      retrieving the contents of SINGLE_STEP 1588 register available
      in a DPMAC.
      
      This patch adds a new version of this command that returns as an extra
      argument the physical base address of the aforementioned register.
      The address will be used to directly modify the contents of the
      SINGLE_STEP register instead of invoking the MC command
      dpni_set_single_step_cgf. The former approach introduced huge delays on
      the TX datapath when one step PTP events were transmitted. This led to low
      throughput and high latencies observed in the PTP correction field.
      Signed-off-by: default avatarRadu Bulie <radu-andrei.bulie@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9572594e
    • Eric Dumazet's avatar
      net: get rid of rtnl_lock_unregistering() · 8a4fc54b
      Eric Dumazet authored
      After recent patches, and in particular commits
       faab39f6 ("net: allow out-of-order netdev unregistration") and
       e5f80fcf ("ipv6: give an IPv6 dev to blackhole_netdev")
      we no longer need the barrier implemented in rtnl_lock_unregistering().
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a4fc54b
    • Volodymyr Mytnyk's avatar
      net: prestera: flower: fix destroy tmpl in chain · b3ae2d35
      Volodymyr Mytnyk authored
      Fix flower destroy template callback to release template
      only for specific tc chain instead of all chain tempaltes.
      
      The issue was intruduced by previous commit that introduced
      multi-chain support.
      
      Fixes: fa5d824c ("net: prestera: acl: add multi-chain support offload")
      Signed-off-by: default avatarVolodymyr Mytnyk <vmytnyk@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3ae2d35
    • Eric Dumazet's avatar
      bridge: switch br_net_exit to batch mode · 36a29fb6
      Eric Dumazet authored
      cleanup_net() is competing with other rtnl users.
      
      Instead of calling br_net_exit() for each netns,
      call br_net_exit_batch() once.
      
      This gives cleanup_net() ability to group more devices
      and call unregister_netdevice_many() only once for all bridge devices.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Roopa Prabhu <roopa@nvidia.com>
      Cc: Nikolay Aleksandrov <razor@blackwall.org>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36a29fb6
    • David S. Miller's avatar
      Merge branch 'mctp-i2c' · a7cc3464
      David S. Miller authored
      Matt Johnston says:
      
      ====================
      MCTP I2C driver
      
      This patch series adds a netdev driver providing MCTP transport over
      I2C.
      
      I think I've addressed all the points raised in v5. It now has
      mctp_i2c_unregister() to run things in the correct order, waiting for
      the worker thread and I2C rx to complete.
      
      Cheers,
      Matt
      
      --
      
      v6:
       - Changed netdev register/unregister/free to avoid races. Ensure that
         netif functions are not used by irq handler/threads after unregister.
       - Fix incoming I2C hwaddr that was previously incorrect (left
         shifted 1 bit)
       - Add a check that byte_count wire header matches the length received
       - Renamed I2C driver to mctp-i2c-interface
       - Removed __func__ from print messages, added missing newlines
       - Removed sysfs mctp_current_mux file which was used for debug
       - Renamed curr_lock to sel_lock
       - Tidied comment formatting
       - Fix newline in Kconfig
      v5:
       - Fix incorrect format string
      v4:
       - Switch to __i2c_transfer() rather than __i2c_smbus_xfer(), drop 255 byte
         smbus patches
       - Use wait_event_idle() for the sleeping TX thread
       - Use dev_addr_set()
      v3:
       - Added Reviewed-bys for npcm7xx
       - Resend with net-next open
      v2:
       - Simpler Kconfig condition for i2c-mux dependency, from Randy Dunlap
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7cc3464
    • Matt Johnston's avatar
      mctp i2c: MCTP I2C binding driver · f5b8abf9
      Matt Johnston authored
      Provides MCTP network transport over an I2C bus, as specified in
      DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes.
      
      Each I2C bus to be used for MCTP is flagged in devicetree by a
      'mctp-controller' property on the bus node. Each flagged bus gets a
      mctpi2cX net device created based on the bus number. A
      'mctp-i2c-controller' I2C client needs to be added under the adapter. In
      an I2C mux situation the mctp-i2c-controller node must be attached only
      to the root I2C bus. The I2C client will handle incoming I2C slave block
      write data for subordinate busses as well as its own bus.
      
      In configurations without devicetree a driver instance can be attached
      to a bus using the I2C slave new_device mechanism.
      
      The MCTP core will hold/release the MCTP I2C device while responses
      are pending (a 6 second timeout or once a socket is closed, response
      received etc). While held the MCTP I2C driver will lock the I2C bus so
      that the correct I2C mux remains selected while responses are received.
      
      (Ideally we would just lock the mux to keep the current bus selected for
      the response rather than a full I2C bus lock, but that isn't exposed in
      the I2C mux API)
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Signed-off-by: default avatarJeremy Kerr <jk@codeconstruct.com.au>
      Reviewed-by: Wolfram Sang <wsa@kernel.org> # I2C transport parts
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5b8abf9
    • Matt Johnston's avatar
      dt-bindings: net: New binding mctp-i2c-controller · 6881e493
      Matt Johnston authored
      Used to define a local endpoint to communicate with MCTP peripherals
      attached to an I2C bus. This I2C endpoint can communicate with remote
      MCTP devices on the I2C bus.
      
      In the example I2C topology below (matching the second yaml example) we
      have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are
      indicated by the 'mctp-controller' DT property on an I2C bus node.
      
      A mctp-i2c-controller I2C client DT node is placed at the top of the
      mux topology, since only the root I2C adapter will support I2C slave
      functionality.
                                                     .-------.
                                                     |eeprom |
          .------------.     .------.               /'-------'
          | adapter    |     | mux  --@0,i2c5------'
          | i2c1       ----.*|      --@1,i2c6--.--.
          |............|    \'------'           \  \  .........
          | mctp-i2c-  |     \                   \  \ .mctpB  .
          | controller |      \                   \  '.0x30   .
          |            |       \  .........        \  '.......'
          | 0x50       |        \ .mctpA  .         \ .........
          '------------'         '.0x1d   .          '.mctpC  .
                                  '.......'          '.0x31   .
                                                      '.......'
      (mctpX boxes above are remote MCTP devices not included in the DT at
      present, they can be hotplugged/probed at runtime. A DT binding for
      specific fixed MCTP devices could be added later if required)
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarWolfram Sang <wsa@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6881e493
    • Mobashshera Rasool's avatar
      net: ip6mr: add support for passing full packet on wrong mif · 4b340a5a
      Mobashshera Rasool authored
      This patch adds support for MRT6MSG_WRMIFWHOLE which is used to pass
      full packet and real vif id when the incoming interface is wrong.
      While the RP and FHR are setting up state we need to be sending the
      registers encapsulated with all the data inside otherwise we lose it.
      The RP then decapsulates it and forwards it to the interested parties.
      Currently with WRONGMIF we can only be sending empty register packets
      and will lose that data.
      This behaviour can be enabled by using MRT_PIM with
      val == MRT6MSG_WRMIFWHOLE. This doesn't prevent MRT6MSG_WRONGMIF from
      happening, it happens in addition to it, also it is controlled by the same
      throttling parameters as WRONGMIF (i.e. 1 packet per 3 seconds currently).
      Both messages are generated to keep backwards compatibily and avoid
      breaking someone who was enabling MRT_PIM with val == 4, since any
      positive val is accepted and treated the same.
      Signed-off-by: default avatarMobashshera Rasool <mobash.rasool.linux@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b340a5a
    • Alexander Lobakin's avatar
      i40e: remove dead stores on XSK hotpath · 7e1b54d0
      Alexander Lobakin authored
      The 'if (ntu == rx_ring->count)' block in i40e_alloc_rx_buffers_zc()
      was previously residing in the loop, but after introducing the
      batched interface it is used only to wrap-around the NTU descriptor,
      thus no more need to assign 'xdp'.
      
      'cleaned_count' in i40e_clean_rx_irq_zc() was previously being
      incremented in the loop, but after commit f12738b6
      ("i40e: remove unnecessary cleaned_count updates") it gets
      assigned only once after it, so the initialization can be dropped.
      
      Fixes: 6aab0bb0 ("i40e: Use the xsk batched rx allocation interface")
      Fixes: f12738b6 ("i40e: remove unnecessary cleaned_count updates")
      Signed-off-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Acked-by: default avatarMaciej Fijalkowski <maciej.fijalkowski@intel.com>
      Tested-by: default avatarGeorge Kuruvinakunnel <george.kuruvinakunnel@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e1b54d0
    • Jakub Kicinski's avatar
      Merge branch 'add-checks-for-incoming-packet-addresses' · bbcf340d
      Jakub Kicinski authored
      Jeremy Kerr says:
      
      ====================
      Add checks for incoming packet addresses
      
      This series adds a couple of checks for valid addresses on incoming MCTP
      packets. We introduce a couple of helpers in 1/2, and use them in the
      ingress path in 2/2.
      ====================
      
      Link: https://lore.kernel.org/r/20220218042554.564787-1-jk@codeconstruct.com.auSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bbcf340d
    • Jeremy Kerr's avatar
      mctp: add address validity checking for packet receive · 86cdfd63
      Jeremy Kerr authored
      This change adds some basic sanity checks for the source and dest
      headers of packets on initial receive.
      Signed-off-by: default avatarJeremy Kerr <jk@codeconstruct.com.au>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      86cdfd63
    • Jeremy Kerr's avatar
      mctp: replace mctp_address_ok with more fine-grained helpers · cb196b72
      Jeremy Kerr authored
      Currently, we have mctp_address_ok(), which checks if an EID is in the
      "valid" range of 8-254 inclusive. However, 0 and 255 may also be valid
      addresses, depending on context. 0 is the NULL EID, which may be set
      when physical addressing is used. 255 is valid as a destination address
      for broadcasts.
      
      This change renames mctp_address_ok to mctp_address_unicast, and adds
      similar helpers for broadcast and null EIDs, which will be used in an
      upcoming commit.
      Signed-off-by: default avatarJeremy Kerr <jk@codeconstruct.com.au>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cb196b72
    • Jacques de Laval's avatar
      net: Add new protocol attribute to IP addresses · 47f0bd50
      Jacques de Laval authored
      This patch adds a new protocol attribute to IPv4 and IPv6 addresses.
      Inspiration was taken from the protocol attribute of routes. User space
      applications like iproute2 can set/get the protocol with the Netlink API.
      
      The attribute is stored as an 8-bit unsigned integer.
      
      The protocol attribute is set by kernel for these categories:
      
      - IPv4 and IPv6 loopback addresses
      - IPv6 addresses generated from router announcements
      - IPv6 link local addresses
      
      User space may pass custom protocols, not defined by the kernel.
      
      Grouping addresses on their origin is useful in scenarios where you want
      to distinguish between addresses based on who added them, e.g. kernel
      vs. user space.
      
      Tagging addresses with a string label is an existing feature that could be
      used as a solution. Unfortunately the max length of a label is
      15 characters, and for compatibility reasons the label must be prefixed
      with the name of the device followed by a colon. Since device names also
      have a max length of 15 characters, only -1 characters is guaranteed to be
      available for any origin tag, which is not that much.
      
      A reference implementation of user space setting and getting protocols
      is available for iproute2:
      
      https://github.com/westermo/iproute2/commit/9a6ea18bd79f47f293e5edc7780f315ea42ff540Signed-off-by: default avatarJacques de Laval <Jacques.De.Laval@westermo.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/20220217150202.80802-1-Jacques.De.Laval@westermo.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      47f0bd50
    • Jakub Kicinski's avatar
      Merge branch 'ionic-driver-updates' · 6e2e59ea
      Jakub Kicinski authored
      Shannon Nelson says:
      
      ====================
      ionic: driver updates
      
      These are a couple of checkpatch cleanup patches, a bug fix,
      and something to alleviate memory pressure in tight places.
      ====================
      
      Link: https://lore.kernel.org/r/20220217220252.52293-1-snelson@pensando.ioSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6e2e59ea
    • Shannon Nelson's avatar
      ionic: clean up comments and whitespace · ecea8bb4
      Shannon Nelson authored
      Fix up some checkpatch complaints that have crept in:
      doubled words words, mispellled words, doubled lines.
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ecea8bb4
    • Shannon Nelson's avatar
      ionic: prefer strscpy over strlcpy · 799c230e
      Shannon Nelson authored
      Replace strlcpy with strscpy to clean up a checkpatch complaint.
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      799c230e
    • Brett Creeley's avatar
      ionic: Use vzalloc for large per-queue related buffers · 116dce0f
      Brett Creeley authored
      Use vzalloc for per-queue info structs that don't need any
      DMA mapping to help relieve memory pressure found when used
      in our limited SOC environment.
      Signed-off-by: default avatarBrett Creeley <brett@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      116dce0f
    • Shannon Nelson's avatar
      ionic: catch transition back to RUNNING with fw_generation 0 · 12b1b997
      Shannon Nelson authored
      In some graceful updates that get initially triggered by the
      RESET event, especially with older firmware, the fw_generation
      bits don't change but the fw_status is seen to go to 0 then back
      to 1.  However, the driver didn't perform the restart, remained
      waiting for fw_generation to change, and got left in limbo.
      
      This is because the clearing of idev->fw_status_ready to 0
      didn't happen correctly as it was buried in the transition
      trigger: since the transition down was triggered not here
      but in the RESET event handler, the clear to 0 didn't happen,
      so the transition back to 1 wasn't detected.
      
      Fix this particular case by bringing the setting of
      idev->fw_status_ready back out to where it was before.
      
      Fixes: 398d1e37 ("ionic: add FW_STOPPING state")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      12b1b997
  3. 18 Feb, 2022 8 commits