1. 20 4月, 2022 1 次提交
  2. 17 4月, 2022 6 次提交
  3. 14 4月, 2022 1 次提交
    • V
      net: dsa: felix: fix tagging protocol changes with multiple CPU ports · 00fa91bc
      Vladimir Oltean 提交于
      When the device tree has 2 CPU ports defined, a single one is active
      (has any dp->cpu_dp pointers point to it). Yet the second one is still a
      CPU port, and DSA still calls ->change_tag_protocol on it.
      
      On the NXP LS1028A, the CPU ports are ports 4 and 5. Port 4 is the
      active CPU port and port 5 is inactive.
      
      After the following commands:
      
       # Initial setting
       cat /sys/class/net/eno2/dsa/tagging
       ocelot
       echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging
       echo ocelot > /sys/class/net/eno2/dsa/tagging
      
      traffic is now broken, because the driver has moved the NPI port from
      port 4 to port 5, unbeknown to DSA.
      
      The problem can be avoided by detecting that the second CPU port is
      unused, and not doing anything for it. Further rework will be needed
      when proper support for multiple CPU ports is added.
      
      Treat this as a bug and prepare current kernels to work in single-CPU
      mode with multiple-CPU DT blobs.
      
      Fixes: adb3dccf ("net: dsa: felix: convert to the new .change_tag_protocol DSA API")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Link: https://lore.kernel.org/r/20220412172209.2531865-1-vladimir.oltean@nxp.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      00fa91bc
  4. 13 4月, 2022 2 次提交
    • A
      net: dsa: realtek: don't parse compatible string for RTL8366S · 8e925de6
      Alvin Šipraga 提交于
      This switch is not even supported, but if someone were to actually put
      this compatible string "realtek,rtl8366s" in their device tree, they
      would be greeted with a kernel panic because the probe function would
      dereference NULL. So let's just remove it.
      
      Link: https://lore.kernel.org/all/CACRpkdYdKZs0WExXc3=0yPNOwP+oOV60HRz7SRoGjZvYHaT=1g@mail.gmail.com/Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e925de6
    • A
      net: dsa: realtek: fix Kconfig to assure consistent driver linkage · 2511e0c8
      Alvin Šipraga 提交于
      The kernel test robot reported a build failure:
      
      or1k-linux-ld: drivers/net/dsa/realtek/realtek-smi.o:(.rodata+0x16c): undefined reference to `rtl8366rb_variant'
      
      ... with the following build configuration:
      
      CONFIG_NET_DSA_REALTEK=y
      CONFIG_NET_DSA_REALTEK_SMI=y
      CONFIG_NET_DSA_REALTEK_RTL8365MB=y
      CONFIG_NET_DSA_REALTEK_RTL8366RB=m
      
      The problem here is that the realtek-smi interface driver gets built-in,
      while the rtl8366rb switch subdriver gets built as a module, hence the
      symbol rtl8366rb_variant is not reachable when defining the OF device
      table in the interface driver.
      
      The Kconfig dependencies don't help in this scenario because they just
      say that the subdriver(s) depend on at least one interface driver. In
      fact, the subdrivers don't depend on the interface drivers at all, and
      can even be built even in their absence. Somewhat strangely, the
      interface drivers can also be built in the absence of any subdriver,
      BUT, if a subdriver IS enabled, then it must be reachable according to
      the linkage of the interface driver: effectively what the IS_REACHABLE()
      macro achieves. If it is not reachable, the above kind of linker error
      will be observed.
      
      Rather than papering over the above build error by simply using
      IS_REACHABLE(), we can do a little better and admit that it is actually
      the interface drivers that have a dependency on the subdrivers. So this
      patch does exactly that. Specifically, we ensure that:
      
      1. The interface drivers' Kconfig symbols must have a value no greater
         than the value of any subdriver Kconfig symbols.
      
      2. The subdrivers should by default enable both interface drivers, since
         most users probably want at least one of them; those interface
         drivers can be explicitly disabled however.
      
      What this doesn't do is prevent a user from building only a subdriver,
      without any interface driver. To that end, add an additional line of
      help in the menu to guide users in the right direction.
      
      Link: https://lore.kernel.org/all/202204110757.XIafvVnj-lkp@intel.com/Reported-by: Nkernel test robot <lkp@intel.com>
      Fixes: aac94001 ("net: dsa: realtek: add new mdio interface for drivers")
      Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2511e0c8
  5. 12 4月, 2022 9 次提交
  6. 09 4月, 2022 1 次提交
  7. 31 3月, 2022 1 次提交
  8. 29 3月, 2022 1 次提交
  9. 25 3月, 2022 1 次提交
  10. 22 3月, 2022 4 次提交
  11. 18 3月, 2022 6 次提交
  12. 14 3月, 2022 2 次提交
    • V
      net: dsa: felix: configure default-prio and dscp priorities · 978777d0
      Vladimir Oltean 提交于
      Follow the established programming model for this driver and provide
      shims in the felix DSA driver which call the implementations from the
      ocelot switch lib. The ocelot switchdev driver wasn't integrated with
      dcbnl due to lack of hardware availability.
      
      The switch doesn't have any fancy QoS classification enabled by default.
      The provided getters will create a default-prio app table entry of 0,
      and no dscp entry. However, the getters have been made to actually
      retrieve the hardware configuration rather than static values, to be
      future proof in case DSA will need this information from more call paths.
      
      For default-prio, there is a single field per port, in ANA_PORT_QOS_CFG,
      called QOS_DEFAULT_VAL.
      
      DSCP classification is enabled per-port, again via ANA_PORT_QOS_CFG
      (field QOS_DSCP_ENA), and individual DSCP values are configured as
      trusted or not through register ANA_DSCP_CFG (replicated 64 times).
      An untrusted DSCP value falls back to other QoS classification methods.
      If trusted, the selected ANA_DSCP_CFG register also holds the QoS class
      in the QOS_DSCP_VAL field.
      
      The hardware also supports DSCP remapping (DSCP value X is translated to
      DSCP value Y before the QoS class is determined based on the app table
      entry for Y) and DSCP packet rewriting. The dcbnl framework, for being
      so flexible in other useless areas, doesn't appear to support this.
      So this functionality has been left out.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      978777d0
    • C
      net: dsa: microchip: add spi_device_id tables · e981bc74
      Claudiu Beznea 提交于
      Add spi_device_id tables to avoid logs like "SPI driver ksz9477-switch
      has no spi_device_id".
      Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e981bc74
  13. 11 3月, 2022 1 次提交
  14. 10 3月, 2022 1 次提交
  15. 09 3月, 2022 3 次提交
    • V
      net: dsa: felix: avoid early deletion of host FDB entries · 7e580490
      Vladimir Oltean 提交于
      The Felix driver declares FDB isolation but puts all standalone ports in
      VID 0. This is mostly problem-free as discussed with Alvin here:
      https://patchwork.kernel.org/project/netdevbpf/cover/20220302191417.1288145-1-vladimir.oltean@nxp.com/#24763870
      
      however there is one catch. DSA still thinks that FDB entries are
      installed on the CPU port as many times as there are user ports, and
      this is problematic when multiple user ports share the same MAC address.
      
      Consider the default case where all user ports inherit their MAC address
      from the DSA master, and then the user runs:
      
      ip link set swp0 address 00:01:02:03:04:05
      
      The above will make dsa_slave_set_mac_address() call
      dsa_port_standalone_host_fdb_add() for 00:01:02:03:04:05 in port 0's
      standalone database, and dsa_port_standalone_host_fdb_del() for the old
      address of swp0, again in swp0's standalone database.
      
      Both the ->port_fdb_add() and ->port_fdb_del() will be propagated down
      to the felix driver, which will end up deleting the old MAC address from
      the CPU port. But this is still in use by other user ports, so we end up
      breaking unicast termination for them.
      
      There isn't a problem in the fact that DSA keeps track of host
      standalone addresses in the individual database of each user port: some
      drivers like sja1105 need this. There also isn't a problem in the fact
      that some drivers choose the same VID/FID for all standalone ports.
      It is just that the deletion of these host addresses must be delayed
      until they are known to not be in use any longer, and only the driver
      has this knowledge. Since DSA keeps these addresses in &cpu_dp->fdbs and
      &cpu_db->mdbs, it is just a matter of walking over those lists and see
      whether the same MAC address is present on the CPU port in the port db
      of another user port.
      
      I have considered reusing the generic dsa_port_walk_fdbs() and
      dsa_port_walk_mdbs() schemes for this, but locking makes it difficult.
      In the ->port_fdb_add() method and co, &dp->addr_lists_lock is held, but
      dsa_port_walk_fdbs() also acquires that lock. Also, even assuming that
      we introduce an unlocked variant of the address iterator, we'd still
      need some relatively complex data structures, and a void *ctx in the
      dsa_fdb_walk_cb_t which we don't currently pass, such that drivers are
      able to figure out, after iterating, whether the same MAC address is or
      isn't present in the port db of another port.
      
      All the above, plus the fact that I expect other drivers to follow the
      same model as felix where all standalone ports use the same FID, made me
      conclude that a generic method provided by DSA is necessary:
      dsa_fdb_present_in_other_db() and the mdb equivalent. Felix calls this
      from the ->port_fdb_del() handler for the CPU port, when the database
      was classified to either a port db, or a LAG db.
      
      For symmetry, we also call this from ->port_fdb_add(), because if the
      address was installed once, then installing it a second time serves no
      purpose: it's already in hardware in VID 0 and it affects all standalone
      ports.
      
      This change moves dsa_db_equal() from switch.c to dsa.c, since it now
      has one more caller.
      
      Fixes: 54c31984 ("net: mscc: ocelot: enforce FDB isolation when VLAN-unaware")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e580490
    • V
      net: dsa: felix: actually disable flooding towards NPI port · f2e2662c
      Vladimir Oltean 提交于
      The two blamed commits were written/tested individually but not
      together.
      
      When put together, commit 90897569 ("net: dsa: felix: start off with
      flooding disabled on the CPU port"), which deletes a reinitialization of
      PGID_UC/PGID_MC/PGID_BC, is no longer sufficient to ensure that these
      port masks don't contain the CPU port module.
      
      This is because commit b903a6bd ("net: dsa: felix: migrate flood
      settings from NPI to tag_8021q CPU port") overwrites the hardware
      default settings towards the CPU port module with the settings that used
      to be present on the NPI port treated as a regular port. There, flooding
      is enabled, so flooding would get enabled on the CPU port module too.
      
      Adding conditional logic somewhere within felix_setup_tag_npi() to
      configure either the default no-flood policy or the flood policy
      inherited from the tag_8021q CPU port from a previous call to
      dsa_port_manage_cpu_flood() is getting complicated. So just let the
      migration logic do its thing during initial setup (which will
      temporarily turn on flooding), then turn flooding off for the NPI port
      after felix_set_tag_protocol() finishes. Here we are in felix_setup(),
      so the DSA slave interfaces are not yet created, and this doesn't affect
      traffic in any way.
      
      Fixes: 90897569 ("net: dsa: felix: start off with flooding disabled on the CPU port")
      Fixes: b903a6bd ("net: dsa: felix: migrate flood settings from NPI to tag_8021q CPU port")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2e2662c
    • V
      net: dsa: felix: drop "bool change" from felix_set_tag_protocol · c69f40ac
      Vladimir Oltean 提交于
      We no longer need the workaround in the felix driver to avoid calling
      dsa_port_walk_fdbs() when &dp->fdbs is an uninitialized list, because
      that list is now initialized from all call paths of felix_set_tag_protocol().
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c69f40ac