1. 03 Jun, 2024 8 commits
    • Vladimir Oltean's avatar
      net: dsa: ocelot: move devm_request_threaded_irq() to felix_setup() · 0367a177
      Vladimir Oltean authored
      The current placement of devm_request_threaded_irq() is inconvenient.
      It is between the allocation of the "felix" structure and
      dsa_register_switch(), both of which we'd like to refactor into a
      function that's common for all switches. But the IRQ is specific to
      felix_vsc9959.
      
      A closer inspection of the felix_irq_handler() code suggests that
      it does things that depend on the data structures having been fully
      initialized. For example, ocelot_get_txtstamp() takes
      &port->tx_skbs.lock, which has only been initialized in
      ocelot_init_port() which has not run yet.
      
      It is not one of those IRQF_SHARED IRQs, so CONFIG_DEBUG_SHIRQ_FIXME
      shouldn't apply here, and thus, it doesn't really matter, because in
      practice, the IRQ will not be triggered so early. Nonetheless, it is a
      good practice for the driver to be prepared for it to fire as soon as it
      is requested.
      
      Create a new felix->info method for running custom code for vsc9959 from
      within felix_setup(), and move the request_irq() call there. The
      ocelot_ext should have an IRQ as well, so this should be a step in the
      right direction for that model (VSC7512) as well.
      
      Some minor changes are made while moving the code. Casts from void *
      aren't necessary, so drop them, and rename felix_irq_handler() to the
      more specific vsc9959_irq_handler().
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0367a177
    • Vladimir Oltean's avatar
      net: dsa: ocelot: consistently use devres in felix_pci_probe() · 4510bbd3
      Vladimir Oltean authored
      Russell King suggested that felix_vsc9959, seville_vsc9953 and
      ocelot_ext have a large portion of duplicated init and teardown code,
      which could be made common [1]. The teardown code could even be
      simplified away if we made use of devres, something which is used here
      and there in the felix driver, just not very consistently.
      
      [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/
      
      Prepare the ground in the felix_vsc9959 driver, by allocating the data
      structures using devres and deleting the kfree() calls. This also
      deletes the "Failed to allocate ..." message, since memory allocation
      errors are extremely loud anyway, and it's hard to miss them.
      Suggested-by: default avatar"Russell King (Oracle)" <linux@armlinux.org.uk>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4510bbd3
    • Vladimir Oltean's avatar
      net: dsa: ocelot: delete open coded status = "disabled" parsing · cc711c52
      Vladimir Oltean authored
      Since commit 6fffbc7a ("PCI: Honor firmware's device disabled
      status"), PCI device drivers with OF bindings no longer need this check.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc711c52
    • Vladimir Oltean's avatar
      net: dsa: ocelot: use devres in seville_probe() · 90ee9a5b
      Vladimir Oltean authored
      Russell King suggested that felix_vsc9959, seville_vsc9953 and
      ocelot_ext have a large portion of duplicated init and teardown code,
      which could be made common [1]. The teardown code could even be
      simplified away if we made use of devres, something which is used here
      and there in the felix driver, just not very consistently.
      
      [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/
      
      Prepare the ground in the seville_vsc9953 driver, by allocating the data
      structures using devres and deleting the kfree() calls. This also
      deletes the "Failed to allocate ..." message, since memory allocation
      errors are extremely loud anyway, and it's hard to miss them.
      Suggested-by: default avatar"Russell King (Oracle)" <linux@armlinux.org.uk>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90ee9a5b
    • Vladimir Oltean's avatar
      net: dsa: ocelot: use devres in ocelot_ext_probe() · 454cfffe
      Vladimir Oltean authored
      Russell King suggested that felix_vsc9959, seville_vsc9953 and
      ocelot_ext have a large portion of duplicated init and teardown code,
      which could be made common [1]. The teardown code could even be
      simplified away if we made use of devres, something which is used here
      and there in the felix driver, just not very consistently.
      
      [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/
      
      Prepare the ground in the ocelot_ext driver, by allocating the data
      structures using devres and deleting the kfree() calls. This also
      deletes the "Failed to allocate ..." message, since memory allocation
      errors are extremely loud anyway, and it's hard to miss them.
      Suggested-by: default avatar"Russell King (Oracle)" <linux@armlinux.org.uk>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarColin Foster <colin.foster@in-advantage.com>
      Tested-by: default avatarColin Foster <colin.foster@in-advantage.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      454cfffe
    • David S. Miller's avatar
      Merge branch 'net-smc-snd_buf-rcv_buf' · 93e30878
      David S. Miller authored
      Guangguan Wang says:
      
      ====================
      net/smc: Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB
      
      SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf.
      The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_
      RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB.
      TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2]
      whose default value is 4MB or 6MB, is much larger than SMC-R's upper
      boundary.
      
      In some scenarios, such as Recommendation System, the communication
      pattern is mainly large size send/recv, where the size of snd_buf and
      rcv_buf greatly affects performance. Due to the upper boundary
      disadvantage, SMC-R performs poor than TCP in those scenarios. So it
      is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf,
      so that the SMC-R's snd_buf and rcv_buf can be configured to larger size
      for performance gain in such scenarios.
      
      The SMC-R rcv_buf's size will be transferred to peer by the field
      rmbe_size in clc accept and confirm message. The length of the field
      rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES
      is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES
      in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum
      value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf
      is 512MB. As the real memory usage is determined by the value of
      net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES
      to the maximum value has no side affects.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93e30878
    • Guangguan Wang's avatar
      net/smc: change SMCR_RMBE_SIZES from 5 to 15 · 2f4b101c
      Guangguan Wang authored
      SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf.
      The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_
      RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB.
      TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2]
      whose default value is 4MB or 6MB, is much larger than SMC-R's upper
      boundary.
      
      In some scenarios, such as Recommendation System, the communication
      pattern is mainly large size send/recv, where the size of snd_buf and
      rcv_buf greatly affects performance. Due to the upper boundary
      disadvantage, SMC-R performs poor than TCP in those scenarios. So it
      is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf,
      so that the SMC-R's snd_buf and rcv_buf can be configured to larger size
      for performance gain in such scenarios.
      
      The SMC-R rcv_buf's size will be transferred to peer by the field
      rmbe_size in clc accept and confirm message. The length of the field
      rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES
      is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES
      in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum
      value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf
      is 512MB. As the real memory usage is determined by the value of
      net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES
      to the maximum value has no side affects.
      Signed-off-by: default avatarGuangguan Wang <guangguan.wang@linux.alibaba.com>
      Co-developed-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Signed-off-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f4b101c
    • Guangguan Wang's avatar
      net/smc: set rmb's SG_MAX_SINGLE_ALLOC limitation only when CONFIG_ARCH_NO_SG_CHAIN is defined · 3ac14b9d
      Guangguan Wang authored
      SG_MAX_SINGLE_ALLOC is used to limit maximum number of entries that
      will be allocated in one piece of scatterlist. When the entries of
      scatterlist exceeds SG_MAX_SINGLE_ALLOC, sg chain will be used. From
      commit 7c703e54 ("arch: switch the default on ARCH_HAS_SG_CHAIN"),
      we can know that the macro CONFIG_ARCH_NO_SG_CHAIN is used to identify
      whether sg chain is supported. So, SMC-R's rmb buffer should be limited
      by SG_MAX_SINGLE_ALLOC only when the macro CONFIG_ARCH_NO_SG_CHAIN is
      defined.
      
      Fixes: a3fe3d01 ("net/smc: introduce sg-logic for RMBs")
      Signed-off-by: default avatarGuangguan Wang <guangguan.wang@linux.alibaba.com>
      Co-developed-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Signed-off-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ac14b9d
  2. 01 Jun, 2024 31 commits
  3. 31 May, 2024 1 commit