1. 25 Aug, 2022 3 commits
  2. 24 Aug, 2022 27 commits
  3. 23 Aug, 2022 10 commits
    • Jakub Kicinski's avatar
      docs: netlink: basic introduction to Netlink · 510156a7
      Jakub Kicinski authored
      Provide a bit of a brain dump of netlink related information
      as documentation. Hopefully this will be useful to people
      trying to navigate implementing YAML based parsing in languages
      we won't be able to help with.
      
      I started writing this doc while trying to figure out what
      it'd take to widen the applicability of YAML to good old rtnl,
      but the doc grew beyond that as it usually happens.
      
      In all honesty a lot of this information is new to me as I usually
      follow the "copy an existing example, drink to forget" process
      of writing netlink user space, so reviews will be much appreciated.
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Acked-by: default avatarJonathan Corbet <corbet@lwn.net>
      Link: https://lore.kernel.org/r/20220819200221.422801-2-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      510156a7
    • Jakub Kicinski's avatar
      net: improve and fix netlink kdoc · 30b60554
      Jakub Kicinski authored
      Subsequent patch will render the kdoc from
      include/uapi/linux/netlink.h into Documentation.
      We need to fix the warnings. While at it move
      the comments on struct nlmsghdr to a proper
      kdoc comment.
      
      Link: https://lore.kernel.org/r/20220819200221.422801-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      30b60554
    • Sergei Antonov's avatar
      net: ftmac100: set max_mtu to allow DSA overhead setting · 6c2c782f
      Sergei Antonov authored
      In case ftmac100 is used with a DSA switch, Linux wants to set MTU
      to 1504 to accommodate for DSA overhead. With the default max_mtu
      it leads to the error message:
       ftmac100 92000000.mac eth0: error -22 setting MTU to 1504 to include DSA overhead
      
      ftmac100 supports packet length 1518 (MAX_PKT_SIZE constant), so it is
      safe to report it in max_mtu.
      Signed-off-by: default avatarSergei Antonov <saproj@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20220821160844.474277-1-saproj@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6c2c782f
    • Paolo Abeni's avatar
      Merge branch 'dsa-changes-for-multiple-cpu-ports-part-3' · 52412f55
      Paolo Abeni authored
      Vladimir Oltean says:
      
      ====================
      DSA changes for multiple CPU ports (part 3)
      
      Those who have been following part 1:
      https://patchwork.kernel.org/project/netdevbpf/cover/20220511095020.562461-1-vladimir.oltean@nxp.com/
      and part 2:
      https://patchwork.kernel.org/project/netdevbpf/cover/20220521213743.2735445-1-vladimir.oltean@nxp.com/
      will know that I am trying to enable the second internal port pair from
      the NXP LS1028A Felix switch for DSA-tagged traffic via "ocelot-8021q".
      This series represents part 3 of that effort.
      
      Covered here are some preparations in DSA for handling multiple DSA
      masters:
      - when changing the tagging protocol via sysfs
      - when the masters go down
      as well as preparation for monitoring the upper devices of a DSA master
      (to support DSA masters under a LAG).
      
      There are also 2 small preparations for the ocelot driver, for the case
      where multiple tag_8021q CPU ports are used in a LAG. Both those changes
      have to do with PGID forwarding domains.
      
      Compared to v1, the patches were trimmed down to just another
      preparation stage, and the UAPI changes were pushed further out to part 4.
      https://patchwork.kernel.org/project/netdevbpf/cover/20220523104256.3556016-1-olteanv@gmail.com/
      
      Compared to v2, I had to export a symbol I forgot to
      (ocelot_port_teardown_dsa_8021q_cpu), to avoid a build breakage when the
      felix and seville drivers are built as modules.
      ====================
      
      Link: https://lore.kernel.org/r/20220819174820.3585002-1-vladimir.oltean@nxp.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      52412f55
    • Vladimir Oltean's avatar
      net: mscc: ocelot: adjust forwarding domain for CPU ports in a LAG · 291ac151
      Vladimir Oltean authored
      Currently when we have 2 CPU ports configured for DSA tag_8021q mode and
      we put them in a LAG, a PGID dump looks like this:
      
      PGID_SRC[0] = ports 4,
      PGID_SRC[1] = ports 4,
      PGID_SRC[2] = ports 4,
      PGID_SRC[3] = ports 4,
      PGID_SRC[4] = ports 0, 1, 2, 3, 4, 5,
      PGID_SRC[5] = no ports
      
      (ports 0-3 are user ports, ports 4 and 5 are CPU ports)
      
      There are 2 problems with the configuration above:
      
      - user ports should enable forwarding towards both CPU ports, not just 4,
        and the aggregation PGIDs should prune one CPU port or the other from
        the destination port mask, based on a hash computed from packet headers.
      
      - CPU ports should not be allowed to forward towards themselves and also
        not towards other ports in the same LAG as themselves
      
      The first problem requires fixing up the PGID_SRC of user ports, when
      ocelot_port_assigned_dsa_8021q_cpu_mask() is called. We need to say that
      when a user port is assigned to a tag_8021q CPU port and that port is in
      a LAG, it should forward towards all ports in that LAG.
      
      The second problem requires fixing up the PGID_SRC of port 4, to remove
      ports 4 and 5 (in a LAG) from the allowed destinations.
      
      After this change, the PGID source masks look as follows:
      
      PGID_SRC[0] = ports 4, 5,
      PGID_SRC[1] = ports 4, 5,
      PGID_SRC[2] = ports 4, 5,
      PGID_SRC[3] = ports 4, 5,
      PGID_SRC[4] = ports 0, 1, 2, 3,
      PGID_SRC[5] = no ports
      
      Note that PGID_SRC[5] still looks weird (it should say "0, 1, 2, 3" just
      like PGID_SRC[4] does), but I've tested forwarding through this CPU port
      and it doesn't seem like anything is affected (it appears that PGID_SRC[4]
      is being looked up on forwarding from the CPU, since both ports 4 and 5
      have logical port ID 4). The reason why it looks weird is because
      we've never called ocelot_port_assign_dsa_8021q_cpu() for any user port
      towards port 5 (all user ports are assigned to port 4 which is in a LAG
      with 5).
      
      Since things aren't broken, I'm willing to leave it like that for now
      and just document the oddity.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      291ac151
    • Vladimir Oltean's avatar
      net: mscc: ocelot: set up tag_8021q CPU ports independent of user port affinity · 36a0bf44
      Vladimir Oltean authored
      This is a partial revert of commit c295f983 ("net: mscc: ocelot:
      switch from {,un}set to {,un}assign for tag_8021q CPU ports"), because
      as it turns out, this isn't how tag_8021q CPU ports under a LAG are
      supposed to work.
      
      Under that scenario, all user ports are "assigned" to the single
      tag_8021q CPU port represented by the logical port corresponding to the
      bonding interface. So one CPU port in a LAG would have is_dsa_8021q_cpu
      set to true (the one whose physical port ID is equal to the logical port
      ID), and the other one to false.
      
      In turn, this makes 2 undesirable things happen:
      
      (1) PGID_CPU contains only the first physical CPU port, rather than both
      (2) only the first CPU port will be added to the private VLANs used by
          ocelot for VLAN-unaware bridging
      
      To make the driver behave in the same way for both bonded CPU ports, we
      need to bring back the old concept of setting up a port as a tag_8021q
      CPU port, and this is what deals with VLAN membership and PGID_CPU
      updating. But we also need the CPU port "assignment" (the user to CPU
      port affinity), and this is what updates the PGID_SRC forwarding rules.
      
      All DSA CPU ports are statically configured for tag_8021q mode when the
      tagging protocol is changed to ocelot-8021q. User ports are "assigned"
      to one CPU port or the other dynamically (this will be handled by a
      future change).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      36a0bf44
    • Vladimir Oltean's avatar
      net: dsa: use dsa_tree_for_each_cpu_port in dsa_tree_{setup,teardown}_master · 5dc760d1
      Vladimir Oltean authored
      More logic will be added to dsa_tree_setup_master() and
      dsa_tree_teardown_master() in upcoming changes.
      
      Reduce the indentation by one level in these functions by introducing
      and using a dedicated iterator for CPU ports of a tree.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      5dc760d1
    • Vladimir Oltean's avatar
      net: dsa: all DSA masters must be down when changing the tagging protocol · f41ec1fd
      Vladimir Oltean authored
      The fact that the tagging protocol is set and queried from the
      /sys/class/net/<dsa-master>/dsa/tagging file is a bit of a quirk from
      the single CPU port days which isn't aging very well now that DSA can
      have more than a single CPU port. This is because the tagging protocol
      is a switch property, yet in the presence of multiple CPU ports it can
      be queried and set from multiple sysfs files, all of which are handled
      by the same implementation.
      
      The current logic ensures that the net device whose sysfs file we're
      changing the tagging protocol through must be down. That net device is
      the DSA master, and this is fine for single DSA master / CPU port setups.
      
      But exactly because the tagging protocol is per switch [ tree, in fact ]
      and not per DSA master, this isn't fine any longer with multiple CPU
      ports, and we must iterate through the tree and find all DSA masters,
      and make sure that all of them are down.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      f41ec1fd
    • Vladimir Oltean's avatar
      net: dsa: only bring down user ports assigned to a given DSA master · 7136097e
      Vladimir Oltean authored
      This is an adaptation of commit c0a8a9c2 ("net: dsa: automatically
      bring user ports down when master goes down") for multiple DSA masters.
      When a DSA master goes down, only the user ports under its control
      should go down too, the others can still send/receive traffic.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      7136097e
    • Vladimir Oltean's avatar
      net: dsa: existing DSA masters cannot join upper interfaces · 4f03dcc6
      Vladimir Oltean authored
      All the traffic to/from a DSA master is supposed to be distributed among
      its DSA switch upper interfaces, so we should not allow other upper
      device kinds.
      
      An exception to this is DSA_TAG_PROTO_NONE (switches with no DSA tags),
      and in that case it is actually expected to create e.g. VLAN interfaces
      on the master. But for those, netdev_uses_dsa(master) returns false, so
      the restriction doesn't apply.
      
      The motivation for this change is to allow LAG interfaces of DSA masters
      to be DSA masters themselves. We want to restrict the user's degrees of
      freedom by 1: the LAG should already have all DSA masters as lowers, and
      while lower ports of the LAG can be removed, none can be added after the
      fact.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4f03dcc6