1. 18 Nov, 2022 29 commits
    • Jakub Kicinski's avatar
      Merge branch 'implement-devlink-rate-api-and-extend-it' · 24f627a3
      Jakub Kicinski authored
      Michal Wilczynski says:
      
      ====================
      Implement devlink-rate API and extend it
      
      This patch series implements devlink-rate for ice driver. Unfortunately
      current API isn't flexible enough for our use case, so there is a need to
      extend it. Some functions have been introduced to enable the driver to
      export current Tx scheduling configuration.
      
      Pasting justification for this series from commit implementing devlink-rate
      in ice driver(that is a part of this series):
      
      There is a need to support modification of Tx scheduler tree, in the
      ice driver. This will allow user to control Tx settings of each node in
      the internal hierarchy of nodes. As a result user will be able to use
      Hierarchy QoS implemented entirely in the hardware.
      
      This patch implemenents devlink-rate API. It also exports initial
      default hierarchy. It's mostly dictated by the fact that the tree
      can't be removed entirely, all we can do is enable the user to modify
      it. For example root node shouldn't ever be removed, also nodes that
      have children are off-limits.
      
      Example initial tree with 2 VF's:
      
      [root@fedora ~]# devlink port function rate show
      pci/0000:4b:00.0/node_27: type node parent node_26
      pci/0000:4b:00.0/node_26: type node parent node_0
      pci/0000:4b:00.0/node_34: type node parent node_33
      pci/0000:4b:00.0/node_33: type node parent node_32
      pci/0000:4b:00.0/node_32: type node parent node_16
      pci/0000:4b:00.0/node_19: type node parent node_18
      pci/0000:4b:00.0/node_18: type node parent node_17
      pci/0000:4b:00.0/node_17: type node parent node_16
      pci/0000:4b:00.0/node_21: type node parent node_20
      pci/0000:4b:00.0/node_20: type node parent node_3
      pci/0000:4b:00.0/node_14: type node parent node_5
      pci/0000:4b:00.0/node_5: type node parent node_3
      pci/0000:4b:00.0/node_13: type node parent node_4
      pci/0000:4b:00.0/node_12: type node parent node_4
      pci/0000:4b:00.0/node_11: type node parent node_4
      pci/0000:4b:00.0/node_10: type node parent node_4
      pci/0000:4b:00.0/node_9: type node parent node_4
      pci/0000:4b:00.0/node_8: type node parent node_4
      pci/0000:4b:00.0/node_7: type node parent node_4
      pci/0000:4b:00.0/node_6: type node parent node_4
      pci/0000:4b:00.0/node_4: type node parent node_3
      pci/0000:4b:00.0/node_3: type node parent node_16
      pci/0000:4b:00.0/node_16: type node parent node_15
      pci/0000:4b:00.0/node_15: type node parent node_0
      pci/0000:4b:00.0/node_2: type node parent node_1
      pci/0000:4b:00.0/node_1: type node parent node_0
      pci/0000:4b:00.0/node_0: type node
      pci/0000:4b:00.0/1: type leaf parent node_27
      pci/0000:4b:00.0/2: type leaf parent node_27
      
      Let me visualize part of the tree:
      
                              +---------+
                              |  node_0 |
                              +---------+
                                   |
                              +----v----+
                              | node_26 |
                              +----+----+
                                   |
                              +----v----+
                              | node_27 |
                              +----+----+
                                   |
                          |-----------------|
                     +----v----+       +----v----+
                     |   VF 1  |       |   VF 2  |
                     +----+----+       +----+----+
      
      So at this point there is a couple things that can be done.
      For example we could only assign parameters to VF's.
      
      [root@fedora ~]# devlink port function rate set pci/0000:4b:00.0/1 \
                       tx_max 5Gbps
      
      This would cap the VF 1 BW to 5Gbps.
      
      But let's say you would like to create a completely new branch.
      This can be done like this:
      
      [root@fedora ~]# devlink port function rate add \
                       pci/0000:4b:00.0/node_custom parent node_0
      [root@fedora ~]# devlink port function rate add \
                       pci/0000:4b:00.0/node_custom_1 parent node_custom
      [root@fedora ~]# devlink port function rate set \
                       pci/0000:4b:00.0/1 parent node_custom_1
      
      This creates a completely new branch and reassigns VF 1 to it.
      
      A number of parameters is supported per each node: tx_max, tx_share,
      tx_priority and tx_weight.
      ====================
      
      Link: https://lore.kernel.org/r/20221115104825.172668-1-michal.wilczynski@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      24f627a3
    • Michal Wilczynski's avatar
      Documentation: Add documentation for new devlink-rate attributes · 242dd643
      Michal Wilczynski authored
      Provide documentation for newly introduced netlink attributes for
      devlink-rate: tx_priority and tx_weight.
      
      Mention the possibility to export tree from the driver.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      242dd643
    • Michal Wilczynski's avatar
      ice: Add documentation for devlink-rate implementation · 16eb4afc
      Michal Wilczynski authored
      Add documentation to a newly added devlink-rate feature. Provide some
      examples on how to use the commands, which netlink attributes are
      supported and descriptions of the attributes.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      16eb4afc
    • Michal Wilczynski's avatar
      ice: Prevent ADQ, DCB coexistence with Custom Tx scheduler · 80fe30a8
      Michal Wilczynski authored
      ADQ, DCB might interfere with Custom Tx Scheduler changes that user
      might introduce using devlink-rate API.
      
      Check if ADQ, DCB is active, when user tries to change any setting
      in exported Tx scheduler tree. If any of those are active block the user
      from doing so, and log an appropriate message.
      
      Remove the exported hierarchy if user enable ADQ or DCB.
      Prevent ADQ or DCB from getting configured if user already made some
      changes using devlink-rate API.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      80fe30a8
    • Michal Wilczynski's avatar
      ice: Implement devlink-rate API · 42c2eb6b
      Michal Wilczynski authored
      There is a need to support modification of Tx scheduler tree, in the
      ice driver. This will allow user to control Tx settings of each node in
      the internal hierarchy of nodes. As a result user will be able to use
      Hierarchy QoS implemented entirely in the hardware.
      
      This patch implemenents devlink-rate API. It also exports initial
      default hierarchy. It's mostly dictated by the fact that the tree
      can't be removed entirely, all we can do is enable the user to modify
      it. For example root node shouldn't ever be removed, also nodes that
      have children are off-limits.
      
      Example initial tree with 2 VF's:
      
      [root@fedora ~]# devlink port function rate show
      
      pci/0000:4b:00.0/node_27: type node parent node_26
      pci/0000:4b:00.0/node_26: type node parent node_0
      pci/0000:4b:00.0/node_34: type node parent node_33
      pci/0000:4b:00.0/node_33: type node parent node_32
      pci/0000:4b:00.0/node_32: type node parent node_16
      pci/0000:4b:00.0/node_19: type node parent node_18
      pci/0000:4b:00.0/node_18: type node parent node_17
      pci/0000:4b:00.0/node_17: type node parent node_16
      pci/0000:4b:00.0/node_21: type node parent node_20
      pci/0000:4b:00.0/node_20: type node parent node_3
      pci/0000:4b:00.0/node_14: type node parent node_5
      pci/0000:4b:00.0/node_5: type node parent node_3
      pci/0000:4b:00.0/node_13: type node parent node_4
      pci/0000:4b:00.0/node_12: type node parent node_4
      pci/0000:4b:00.0/node_11: type node parent node_4
      pci/0000:4b:00.0/node_10: type node parent node_4
      pci/0000:4b:00.0/node_9: type node parent node_4
      pci/0000:4b:00.0/node_8: type node parent node_4
      pci/0000:4b:00.0/node_7: type node parent node_4
      pci/0000:4b:00.0/node_6: type node parent node_4
      pci/0000:4b:00.0/node_4: type node parent node_3
      pci/0000:4b:00.0/node_3: type node parent node_16
      pci/0000:4b:00.0/node_16: type node parent node_15
      pci/0000:4b:00.0/node_15: type node parent node_0
      pci/0000:4b:00.0/node_2: type node parent node_1
      pci/0000:4b:00.0/node_1: type node parent node_0
      pci/0000:4b:00.0/node_0: type node
      pci/0000:4b:00.0/1: type leaf parent node_27
      pci/0000:4b:00.0/2: type leaf parent node_27
      
      Let me visualize part of the tree:
      
                          +---------+
                          |  node_0 |
                          +---------+
                               |
                          +----v----+
                          | node_26 |
                          +----+----+
                               |
                          +----v----+
                          | node_27 |
                          +----+----+
                               |
                      |-----------------|
                 +----v----+       +----v----+
                 |   VF 1  |       |   VF 2  |
                 +----+----+       +----+----+
      
      So at this point there is a couple things that can be done.
      For example we could only assign parameters to VF's.
      
      [root@fedora ~]# devlink port function rate set pci/0000:4b:00.0/1 \
                       tx_max 5Gbps
      
      This would cap the VF 1 BW to 5Gbps.
      
      But let's say you would like to create a completely new branch.
      This can be done like this:
      
      [root@fedora ~]# devlink port function rate add \
                       pci/0000:4b:00.0/node_custom parent node_0
      [root@fedora ~]# devlink port function rate add \
                       pci/0000:4b:00.0/node_custom_1 parent node_custom
      [root@fedora ~]# devlink port function rate set \
                       pci/0000:4b:00.0/1 parent node_custom_1
      
      This creates a completely new branch and reassigns VF 1 to it.
      
      A number of parameters is supported per each node: tx_max, tx_share,
      tx_priority and tx_weight.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      42c2eb6b
    • Michal Wilczynski's avatar
      ice: Add an option to pre-allocate memory for ice_sched_node · bdf96d96
      Michal Wilczynski authored
      devlink-rate API requires a priv object to be allocated when node still
      doesn't have a parent. This is problematic, because ice_sched_node can't
      be currently created without a parent.
      
      Add an option to pre-allocate memory for ice_sched_node struct. Add
      new arguments to ice_sched_add() and ice_sched_add_elems() that allow
      for pre-allocation of memory for ice_sched_node struct.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bdf96d96
    • Michal Wilczynski's avatar
      ice: Introduce new parameters in ice_sched_node · 16dfa494
      Michal Wilczynski authored
      To support new devlink-rate API ice_sched_node struct needs to store
      a number of additional parameters. This includes tx_max, tx_share,
      tx_weight, and tx_priority.
      
      Add new fields to ice_sched_node struct. Add new functions to configure
      the hardware with new parameters. Introduce new xarray to identify
      nodes uniquely.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      16dfa494
    • Michal Wilczynski's avatar
      devlink: Allow to set up parent in devl_rate_leaf_create() · f2fc15e2
      Michal Wilczynski authored
      Currently the driver is able to create leaf nodes for the devlink-rate,
      but is unable to set parent for them. This wasn't as issue before the
      possibility to export hierarchy from the driver. After adding the export
      feature, in order for the driver to supply correct hierarchy, it's
      necessary for it to be able to supply a parent name to
      devl_rate_leaf_create().
      
      Introduce a new parameter 'parent_name' in devl_rate_leaf_create().
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f2fc15e2
    • Michal Wilczynski's avatar
      devlink: Allow for devlink-rate nodes parent reassignment · 04d674f0
      Michal Wilczynski authored
      Currently it's not possible to reassign the parent of the node using one
      command. As the previous commit introduced a way to export entire
      hierarchy from the driver, being able to modify and reassign parents
      become important. This way user might easily change QoS settings without
      interrupting traffic.
      
      Example command:
      devlink port function rate set pci/0000:4b:00.0/1 parent node_custom_1
      
      This reassigns leaf node parent to node_custom_1.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Reviewed-by: default avatarPrzemek Kitszel <przemyslaw.kitszel@intel.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      04d674f0
    • Michal Wilczynski's avatar
      devlink: Enable creation of the devlink-rate nodes from the driver · caba177d
      Michal Wilczynski authored
      Intel 100G card internal firmware hierarchy for Hierarchicial QoS is very
      rigid and can't be easily removed. This requires an ability to export
      default hierarchy to allow user to modify it. Currently the driver is
      only able to create the 'leaf' nodes, which usually represent the vport.
      This is not enough for HQoS implemented in Intel hardware.
      
      Introduce new function devl_rate_node_create() that allows for creation
      of the devlink-rate nodes from the driver.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      caba177d
    • Michal Wilczynski's avatar
      devlink: Introduce new attribute 'tx_weight' to devlink-rate · 6e2d7e84
      Michal Wilczynski authored
      To fully utilize offload capabilities of Intel 100G card QoS capabilities
      new attribute 'tx_weight' needs to be introduced. This attribute allows
      for usage of Weighted Fair Queuing arbitration scheme among siblings.
      This arbitration scheme can be used simultaneously with the strict
      priority.
      
      Introduce new attribute in devlink-rate that will allow for configuration
      of Weighted Fair Queueing. New attribute is optional.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6e2d7e84
    • Michal Wilczynski's avatar
      devlink: Introduce new attribute 'tx_priority' to devlink-rate · cd502236
      Michal Wilczynski authored
      To fully utilize offload capabilities of Intel 100G card QoS capabilities
      new attribute 'tx_priority' needs to be introduced. This attribute allows
      for usage of strict priority arbiter among siblings. This arbitration
      scheme attempts to schedule nodes based on their priority as long as the
      nodes remain within their bandwidth limit.
      
      Introduce new attribute in devlink-rate that will allow for configuration
      of strict priority. New attribute is optional.
      Signed-off-by: default avatarMichal Wilczynski <michal.wilczynski@intel.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cd502236
    • Jakub Kicinski's avatar
      Merge branch 'autoload-dsa-tagging-driver-when-dynamically-changing-protocol' · 4ab45e97
      Jakub Kicinski authored
      Vladimir Oltean says:
      
      ====================
      Autoload DSA tagging driver when dynamically changing protocol
      
      This patch set solves the issue reported by Michael and Heiko here:
      https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/
      making full use of Michael's suggestion of having two modaliases: one
      gets used for loading the tagging protocol when it's the default one
      reported by the switch driver, the other gets loaded at user's request,
      by name.
      
        # modinfo tag_ocelot
        filename:       /lib/modules/6.1.0-rc4+/kernel/net/dsa/tag_ocelot.ko
        license:        GPL v2
        alias:          dsa_tag:seville
        alias:          dsa_tag:id-21
        alias:          dsa_tag:ocelot
        alias:          dsa_tag:id-15
        depends:        dsa_core
        intree:         Y
        name:           tag_ocelot
        vermagic:       6.1.0-rc4+ SMP preempt mod_unload modversions aarch64
      
      Tested on NXP LS1028A-RDB with the following device tree addition:
      
      &mscc_felix_port4 {
      	dsa-tag-protocol = "ocelot-8021q";
      };
      
      &mscc_felix_port5 {
      	dsa-tag-protocol = "ocelot-8021q";
      };
      
      CONFIG_NET_DSA and everything that depends on it is built as module.
      Everything auto-loads, and "cat /sys/class/net/eno2/dsa/tagging" shows
      "ocelot-8021q". Traffic works as well. Furthermore, "echo ocelot-8021q"
      into the aforementioned sysfs file now auto-loads the driver for it.
      ====================
      
      Link: https://lore.kernel.org/r/20221115011847.2843127-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4ab45e97
    • Vladimir Oltean's avatar
      net: dsa: autoload tag driver module on tagging protocol change · 0184c07a
      Vladimir Oltean authored
      Issue a request_module() call when an attempt to change the tagging
      protocol is made, either by sysfs or by device tree. In the case of
      ocelot (the only driver for which the default and the alternative
      tagging protocol are compiled as different modules), the user is now no
      longer required to insert tag_ocelot_8021q.ko manually.
      
      In the particular case of ocelot, this solves a problem where
      tag_ocelot_8021q.ko is built as module, and this is present in the
      device tree:
      
      &mscc_felix_port4 {
      	dsa-tag-protocol = "ocelot-8021q";
      };
      
      &mscc_felix_port5 {
      	dsa-tag-protocol = "ocelot-8021q";
      };
      
      Because no one attempts to load the module into the kernel at boot time,
      the switch driver will fail to probe (actually forever defer) until
      someone manually inserts tag_ocelot_8021q.ko. This is now no longer
      necessary and happens automatically.
      
      Rename dsa_find_tagger_by_name() to denote the change in functionality:
      there is now feature parity with dsa_tag_driver_get_by_id(), i.o.w. we
      also load the module if it's missing.
      
      Link: https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/Suggested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: Michael Walle <michael@walle.cc> # on kontron-sl28 w/ ocelot_8021q
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0184c07a
    • Vladimir Oltean's avatar
      net: dsa: rename dsa_tag_driver_get() to dsa_tag_driver_get_by_id() · 54c087e8
      Vladimir Oltean authored
      A future patch will introduce one more way of getting a reference on a
      tagging protocl driver (by name). Rename the current method to "by_id".
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      54c087e8
    • Vladimir Oltean's avatar
      net: dsa: strip sysfs "tagging" string of trailing newline · e8666130
      Vladimir Oltean authored
      Currently, dsa_find_tagger_by_name() uses sysfs_streq() which works both
      with strings that contain \n at the end (echo ocelot > .../dsa/tagging)
      and with strings that don't (printf ocelot > .../dsa/tagging).
      
      There will be a problem once we'll want to construct the modalias string
      based on which we auto-load the protocol kernel module. If the sysfs
      buffer ends in a newline, we need to strip it first. This is a
      preparatory patch specifically for that.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e8666130
    • Vladimir Oltean's avatar
      net: dsa: provide a second modalias to tag proto drivers based on their name · 94793a56
      Vladimir Oltean authored
      Currently, tagging protocol drivers have a modalias of
      "dsa_tag:id-<number>", where the number is one of DSA_TAG_PROTO_*_VALUE.
      
      This modalias makes it possible for the request_module() call in
      dsa_tag_driver_get() to work, given the input it has - an integer
      returned by ds->ops->get_tag_protocol().
      
      It is also possible to change tagging protocols at (pseudo-)runtime, via
      sysfs or via device tree, and this works via the name string of the
      tagging protocol rather than via its id (DSA_TAG_PROTO_*_VALUE).
      
      In the latter case, there is no request_module() call, because there is
      no association that the DSA core has between the string name and the ID,
      to construct the modalias. The module is simply assumed to have been
      inserted. This is actually slightly problematic when the tagging
      protocol change should take place at probe time, since it's expected
      that the dependency module should get autoloaded.
      
      For this purpose, let's introduce a second modalias, so that the DSA
      core can call request_module() by name. There is no reason to make the
      modalias by name optional, so just modify the MODULE_ALIAS_DSA_TAG_DRIVER()
      macro to take both the ID and the name as arguments, and generate two
      modaliases behind the scenes.
      Suggested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: Michael Walle <michael@walle.cc> # on kontron-sl28 w/ ocelot_8021q
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      94793a56
    • Vladimir Oltean's avatar
      net: dsa: rename tagging protocol driver modalias · 2610937d
      Vladimir Oltean authored
      It's autumn cleanup time, and today's target are modaliases.
      
      Michael says that for users of modinfo, "dsa_tag-20" is not the most
      suggestive name, and recommends a change to "dsa_tag-id-20".
      
      Andrew points out that other modaliases have a prefix delimited by
      colons, so he recommends "dsa_tag:20" instead of "dsa_tag-20".
      
      To satisfy both proposals, Florian recommends "dsa_tag:id-20".
      
      The modaliases are not stable ABI, and the essential information
      (protocol ID) is still conveyed in the new string, which
      request_module() must be adapted to form.
      
      Link: 20221027210830.3577793-1-vladimir.oltean@nxp.com
      Suggested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Suggested-by: default avatarMichael Walle <michael@walle.cc>
      Suggested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2610937d
    • Vladimir Oltean's avatar
      net: dsa: stop exposing tag proto module helpers to the world · 9999f85b
      Vladimir Oltean authored
      The DSA tagging protocol driver macros are in the public include/net/dsa.h
      probably because that's also where the DSA_TAG_PROTO_*_VALUE macros are
      (MODULE_ALIAS_DSA_TAG_DRIVER hinges on those macro definitions).
      
      But there is no reason to expose these helpers to <net/dsa.h>. That
      header is shared between switch drivers (drivers/net/dsa/), tagging
      protocol drivers (net/dsa/tag_*.c), the DSA core (net/dsa/ sans tag_*.c),
      and the rest of the world (DSA master drivers, network stack, etc).
      Too much exposure.
      
      On the other hand, net/dsa/dsa_priv.h is included only by the DSA core
      and by DSA tagging protocol drivers (or IOW, "friend" modules). Also a
      bit too much exposure - I've contemplated creating a new header which is
      only included by tagging protocol drivers, but completely separating a
      new dsa_tag_proto.h from dsa_priv.h is not immediately trivial - for
      example dsa_slave_to_port() is used both from the fast path and from the
      control path.
      
      So for now, move these definitions to dsa_priv.h which at least hides
      them from the world.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9999f85b
    • Robert Marko's avatar
      dt-bindings: net: ipq4019-mdio: document required clock-names · 4a8c1438
      Robert Marko authored
      IPQ5018, IPQ6018 and IPQ8074 require clock-names to be set as driver is
      requesting the clock based on it and not index, so document that and make
      it required for the listed SoC-s.
      Signed-off-by: default avatarRobert Marko <robimarko@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20221114194734.3287854-4-robimarko@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4a8c1438
    • Robert Marko's avatar
      dt-bindings: net: ipq4019-mdio: require and validate clocks · e50c5036
      Robert Marko authored
      Now that we can match the platforms requiring clocks by compatible start
      using those to allow clocks per compatible and make them required.
      Signed-off-by: default avatarRobert Marko <robimarko@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20221114194734.3287854-3-robimarko@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e50c5036
    • Robert Marko's avatar
      dt-bindings: net: ipq4019-mdio: add IPQ8074 compatible · 05c1cbb9
      Robert Marko authored
      Allow using IPQ8074 specific compatible along with the fallback IPQ4019
      one in order to be able to specify which compatibles require clocks to
      be able to validate them via schema.
      Signed-off-by: default avatarRobert Marko <robimarko@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20221114194734.3287854-2-robimarko@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      05c1cbb9
    • Robert Marko's avatar
      dt-bindings: net: ipq4019-mdio: document IPQ6018 compatible · cbe5f7c0
      Robert Marko authored
      Document IPQ6018 compatible that is already being used in the DTS along
      with the fallback IPQ4019 compatible as driver itself only gets probed
      on IPQ4019 and IPQ5018 compatibles.
      
      This is also required in order to specify which platform require clock to
      be defined and validate it in schema.
      Signed-off-by: default avatarRobert Marko <robimarko@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20221114194734.3287854-1-robimarko@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cbe5f7c0
    • Jakub Kicinski's avatar
      Merge branch 'net-dsa-use-more-appropriate-net_name_-constants-for-user-ports' · 2ffff144
      Jakub Kicinski authored
      Rasmus Villemoes says:
      
      ====================
      net: dsa: use more appropriate NET_NAME_* constants for user ports
      
      The intention of commit 685343fc ("net: add name_assign_type
      netdev attribute") was clearly that drivers be switched over one by
      one to select appropriate NET_NAME_* constants instead of
      NET_NAME_UNKNOWN. This small series attempts to do that for DSA user
      ports.
      
      This is obviously and intentionally user-visible changes, so there's a
      small chance that it could lead to a regression. To make it easy to
      revert either of the "label in DT" and "fallback to eth%d" changes,
      this is done as a refactoring which shouldn't introduce any functional
      change (but by itself adds code which looks a little odd, with the two
      identical assignments in the two branches), followed by changing the
      constant used in each case in two different patches.
      ====================
      
      Link: https://lore.kernel.org/r/20221116105205.1127843-1-linux@rasmusvillemoes.dkSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2ffff144
    • Rasmus Villemoes's avatar
      net: dsa: set name_assign_type to NET_NAME_ENUM for enumerated user ports · b8790661
      Rasmus Villemoes authored
      When a user port does not have a label in device tree, and we thus
      fall back to the eth%d scheme, the proper constant to use is
      NET_NAME_ENUM. See also commit e9f656b7 ("net: ethernet: set
      default assignment identifier to NET_NAME_ENUM"), which in turn quoted
      commit 685343fc ("net: add name_assign_type netdev attribute"):
      
          ... when the kernel has given the interface a name using global
          device enumeration based on order of discovery (ethX, wlanY, etc)
          ... are labelled NET_NAME_ENUM.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.faineli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b8790661
    • Rasmus Villemoes's avatar
      net: dsa: use NET_NAME_PREDICTABLE for user ports with name given in DT · 6fdb0384
      Rasmus Villemoes authored
      When a user port has a label in device tree, the corresponding
      netdevice is, to quote include/uapi/linux/netdevice.h, "predictably
      named by the kernel". This is also explicitly one of the intended use
      cases for NET_NAME_PREDICTABLE, quoting 685343fc ("net: add
      name_assign_type netdev attribute"):
      
        NET_NAME_PREDICTABLE:
          The ifname has been assigned by the kernel in a predictable way
          [...] Examples include [...] and names deduced from hardware
          properties (including being given explicitly by the firmware).
      
      Expose that information properly for the benefit of userspace tools
      that make decisions based on the name_assign_type attribute,
      e.g. a systemd-udev rule with "kernel" in NamePolicy.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.faineli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6fdb0384
    • Rasmus Villemoes's avatar
      net: dsa: refactor name assignment for user ports · 0171a1d2
      Rasmus Villemoes authored
      The following two patches each have a (small) chance of causing
      regressions for userspace and will in that case of course need to be
      reverted.
      
      In order to prepare for that and make those two patches independent
      and individually revertable, refactor the code which sets the names
      for user ports by moving the "fall back to eth%d if no label is given
      in device tree" to dsa_slave_create().
      
      No functional change (at least none intended).
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.faineli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0171a1d2
    • Vincent Mailhol's avatar
      ethtool: doc: clarify what drivers can implement in their get_drvinfo() · f20a0a05
      Vincent Mailhol authored
      Many of the drivers which implement ethtool_ops::get_drvinfo() will
      prints the .driver, .version or .bus_info of struct ethtool_drvinfo.
      To have a glance of current state, do:
      
        $ git grep -W "get_drvinfo(struct"
      
      Printing in those three fields is useless because:
      
        - since [1], the driver version should be the kernel version (at
          least for upstream drivers). Arguably, out of tree drivers might
          still want to set a custom version, but out of tree is not our
          focus.
      
        - since [2], the core is able to provide default values for .driver
          and .bus_info.
      
      In summary, drivers may provide .fw_version and .erom_version, the
      rest is expected to be done by the core.
      
      In struct ethtool_ops doc from linux/ethtool: rephrase field
      get_drvinfo() doc to discourage developers from implementing this
      callback.
      
      In struct ethtool_drvinfo doc from uapi/linux/ethtool.h: remove the
      paragraph mentioning what drivers should do. Rationale: no need to
      repeat what is already written in struct ethtool_ops doc. But add a
      note that .fw_version and .erom_version are driver defined.
      
      Also update the dummy driver and simply remove the callback in order
      not to confuse the newcomers: most of the drivers will not need this
      callback function any more.
      
      [1] commit 6a7e25c7 ("net/core: Replace driver version to be
          kernel version")
      Link: https://git.kernel.org/torvalds/linux/c/6a7e25c7fb48
      
      [2] commit edaf5df2 ("ethtool: ethtool_get_drvinfo: populate
          drvinfo fields even if callback exits")
      Link: https://git.kernel.org/netdev/net-next/c/edaf5df22cb8Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarVincent Mailhol <mailhol.vincent@wanadoo.fr>
      Link: https://lore.kernel.org/r/20221116171828.4093-1-mailhol.vincent@wanadoo.frSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f20a0a05
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 224b744a
      Jakub Kicinski authored
      include/linux/bpf.h
        1f6e04a1 ("bpf: Fix offset calculation error in __copy_map_value and zero_map_value")
        aa3496ac ("bpf: Refactor kptr_off_tab into btf_record")
        f71b2f64 ("bpf: Refactor map->off_arr handling")
      https://lore.kernel.org/all/20221114095000.67a73239@canb.auug.org.au/Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      224b744a
  2. 17 Nov, 2022 8 commits
  3. 16 Nov, 2022 3 commits