1. 14 Jun, 2023 7 commits
  2. 13 Jun, 2023 23 commits
  3. 12 Jun, 2023 10 commits
    • Uwe Kleine-König's avatar
      net: mlxsw: i2c: Switch back to use struct i2c_driver's .probe() · 3a2cb45c
      Uwe Kleine-König authored
      After commit b8a1a4cd ("i2c: Provide a temporary .probe_new()
      call-back type"), all drivers being converted to .probe_new() and then
      commit 03c835f4 ("i2c: Switch .probe() to not take an id parameter")
      convert back to (the new) .probe() to be able to eventually drop
      .probe_new() from struct i2c_driver.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Tested-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a2cb45c
    • Daniel Golle's avatar
      net: phy: add driver for MediaTek SoC built-in GE PHYs · 98c485ea
      Daniel Golle authored
      Some of MediaTek's Filogic SoCs come with built-in gigabit Ethernet
      PHYs which require calibration data from the SoC's efuse.
      Despite the similar design the driver doesn't share any code with the
      existing mediatek-ge.c.
      Add support for such PHYs by introducing a new driver with basic
      support for MediaTek SoCs MT7981 and MT7988 built-in 1GE PHYs.
      Signed-off-by: default avatarDaniel Golle <daniel@makrotopia.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98c485ea
    • David S. Miller's avatar
      Merge tag 'mlx5-updates-2023-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · a89dc587
      David S. Miller authored
      mlx5-updates-2023-06-09
      
      1) Embedded CPU Virtual Functions
      2) Lightweight local SFs
      
      Daniel Jurgens says:
      ====================
      Embedded CPU Virtual Functions
      
      This series enables the creation of virtual functions on Bluefield (the
      embedded CPU platform). Embedded CPU virtual functions (EC VFs). EC VF
      creation, deletion and management interfaces are the same as those for
      virtual functions in a server with a Connect-X NIC.
      
      When using EC VFs on the ARM the creation of virtual functions on the
      host system is still supported. Host VFs eswitch vports occupy a range
      of 1..max_vfs, the EC VF vport range is max_vfs+1..max_ec_vfs.
      
      Every function (PF, ECPF, VF, EC VF, and subfunction) has a function ID
      associated with it. Prior to this series the function ID and the eswitch
      vport were the same. That is no longer the case, the EC VF function ID
      range is 1..max_ec_vfs. When querying or setting the capabilities of an
      EC VF function an new bit must be set in the query/set HCA cap
      structure.
      
      This is a high level overview of the changes made:
      	- Allocate vports for EC VFs if they are enabled.
      	- Create representors and devlink ports for the EC VF vports.
      	- When querying/setting HCA caps by vport break the assumption
      	  that function ID is the same a vport number and adjust
      	  accordingly.
      	- Create a new type of page, so that when SRIOV on the ARM is
      	  disabled, but remains enabled on the host, the driver can
      	  wait for the correct pages.
      	- Update SRIOV code to support EC VF creation/deletion.
      
      ===================
      
      Lightweight local SFs:
      
      Last 3 patches form Shay Drory:
      
      SFs are heavy weight and by default they come with the full package of
      ConnectX features. Usually users want specialized SFs for one specific
      purpose and using devlink users will almost always override the set of
      advertises features of an SF and reload it.
      
      Shay Drory says:
      ================
      In order to avoid the wasted time and resources on the reload, local SFs
      will probe without any auxiliary sub-device, so that the SFs can be
      configured prior to its full probe.
      
      The defaults of the enable_* devlink params of these SFs are set to
      false.
      
      Usage example:
      Create SF:
      $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11
      $ devlink port function set pci/0000:08:00.0/32768 \
                     hw_addr 00:00:00:00:00:11 state active
      
      Enable ETH auxiliary device:
      $ devlink dev param set auxiliary/mlx5_core.sf.1 \
                    name enable_eth value true cmode driverinit
      
      Now, in order to fully probe the SF, use devlink reload:
      $ devlink dev reload auxiliary/mlx5_core.sf.1
      
      At this point the user have SF devlink instance with auxiliary device
      for the Ethernet functionality only.
      
      ================
      a89dc587
    • David S. Miller's avatar
      Merge branch 'tcp-tx-headless' · 73f49f8c
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      tcp: tx path fully headless
      
      This series completes transition of TCP stack tx path
      to headless packets : All payload now reside in page frags,
      never in skb->head.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73f49f8c
    • Eric Dumazet's avatar
      tcp: remove size parameter from tcp_stream_alloc_skb() · 5882efff
      Eric Dumazet authored
      Now all tcp_stream_alloc_skb() callers pass @size == 0, we can
      remove this parameter.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5882efff
    • Eric Dumazet's avatar
      tcp: remove some dead code · b4a24397
      Eric Dumazet authored
      Now all skbs in write queue do not contain any payload in skb->head,
      we can remove some dead code.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4a24397
    • Eric Dumazet's avatar
      tcp: let tcp_send_syn_data() build headless packets · fbf93406
      Eric Dumazet authored
      tcp_send_syn_data() is the last component in TCP transmit
      path to put payload in skb->head.
      
      Switch it to use page frags, so that we can remove dead
      code later.
      
      This allows to put more payload than previous implementation.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbf93406
    • David S. Miller's avatar
      Merge branch 'ethtool-extack' · f2f069da
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      net: support extack in dump and simplify ethtool uAPI
      
      Ethtool currently requires header nest to be always present even if
      it doesn't have to carry any attr for a given request. This inflicts
      unnecessary pain on the users.
      
      What makes it worse is that extack was not working in dump's ->start()
      callback. Address both of those issues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2f069da
    • Jakub Kicinski's avatar
      net: ethtool: don't require empty header nests · 500e1340
      Jakub Kicinski authored
      Ethtool currently requires a header nest (which is used to carry
      the common family options) in all requests including dumps.
      
        $ cli.py --spec netlink/specs/ethtool.yaml --dump channels-get
        lib.ynl.NlError: Netlink error: Invalid argument
        nl_len = 64 (48) nl_flags = 0x300 nl_type = 2
      	error: -22      extack: {'msg': 'request header missing'}
      
        $ cli.py --spec netlink/specs/ethtool.yaml --dump channels-get \
                 --json '{"header":{}}';  )
        [{'combined-count': 1,
          'combined-max': 1,
          'header': {'dev-index': 2, 'dev-name': 'enp1s0'}}]
      
      Requiring the header nest to always be there may seem nice
      from the consistency perspective, but it's not serving any
      practical purpose. We shouldn't burden the user like this.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      500e1340
    • Jakub Kicinski's avatar
      netlink: support extack in dump ->start() · 5ab8c41c
      Jakub Kicinski authored
      Commit 4a19edb6 ("netlink: Pass extack to dump handlers")
      added extack support to netlink dumps. It was focused on rtnl
      and since rtnl does not use ->start(), ->done() callbacks
      it ignored those. Genetlink on the other hand uses ->start()
      extensively, for parsing and input validation.
      
      Pass the extact in via struct netlink_dump_control and link
      it to cb for the time of ->start(). Both struct netlink_dump_control
      and extack itself live on the stack so we can't keep the same
      extack for the duration of the dump. This means that the extack
      visible in ->start() and each ->dump() callbacks will be different.
      Corner cases like reporting a warning message in DONE across dump
      calls are still not supported.
      
      We could put the extack (for dumps) in the socket struct,
      but layering makes it slightly awkward (extack pointer is decided
      before the DO / DUMP split).
      
      The genetlink dump error extacks are now surfaced:
      
        $ cli.py --spec netlink/specs/ethtool.yaml --dump channels-get
        lib.ynl.NlError: Netlink error: Invalid argument
        nl_len = 64 (48) nl_flags = 0x300 nl_type = 2
      	error: -22	extack: {'msg': 'request header missing'}
      
      Previously extack was missing:
      
        $ cli.py --spec netlink/specs/ethtool.yaml --dump channels-get
        lib.ynl.NlError: Netlink error: Invalid argument
        nl_len = 36 (20) nl_flags = 0x100 nl_type = 2
      	error: -22
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ab8c41c