1. 12 Apr, 2023 4 commits
    • David S. Miller's avatar
      Merge branch 'dsa-trace-events' · bbda0f0d
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      DSA trace events
      
      This series introduces the "dsa" trace event class, with the following
      events:
      
      $ trace-cmd list | grep dsa
      dsa
      dsa:dsa_fdb_add_hw
      dsa:dsa_mdb_add_hw
      dsa:dsa_fdb_del_hw
      dsa:dsa_mdb_del_hw
      dsa:dsa_fdb_add_bump
      dsa:dsa_mdb_add_bump
      dsa:dsa_fdb_del_drop
      dsa:dsa_mdb_del_drop
      dsa:dsa_fdb_del_not_found
      dsa:dsa_mdb_del_not_found
      dsa:dsa_lag_fdb_add_hw
      dsa:dsa_lag_fdb_add_bump
      dsa:dsa_lag_fdb_del_hw
      dsa:dsa_lag_fdb_del_drop
      dsa:dsa_lag_fdb_del_not_found
      dsa:dsa_vlan_add_hw
      dsa:dsa_vlan_del_hw
      dsa:dsa_vlan_add_bump
      dsa:dsa_vlan_del_drop
      dsa:dsa_vlan_del_not_found
      
      These are useful to debug refcounting issues on CPU and DSA ports, where
      entries may remain lingering, or may be removed too soon, depending on
      bugs in higher layers of the network stack.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bbda0f0d
    • Vladimir Oltean's avatar
      net: dsa: add trace points for VLAN operations · 02020bd7
      Vladimir Oltean authored
      These are not as critical as the FDB/MDB trace points (I'm not aware of
      outstanding VLAN related bugs), but maybe they are useful to somebody,
      either debugging something or simply trying to learn more.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02020bd7
    • Vladimir Oltean's avatar
      net: dsa: add trace points for FDB/MDB operations · 9538ebce
      Vladimir Oltean authored
      DSA performs non-trivial housekeeping of unicast and multicast addresses
      on shared (CPU and DSA) ports, and puts a bit of pressure on higher
      layers, requiring them to behave correctly (remove these addresses
      exactly as many times as they were added). Otherwise, either addresses
      linger around forever, or DSA returns -ENOENT complaining that entries
      that were already deleted must be deleted again.
      
      To aid debugging, introduce some trace points specifically for FDB and
      MDB - that's where some of the bugs still are right now.
      
      Some bugs I have seen were also due to race conditions, see:
      - 630fd482 ("net: dsa: flush switchdev workqueue on bridge join error path")
      - a2614140 ("net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN")
      
      so it would be good to not disturb the timing too much, hence the choice
      to use trace points vs regular dev_dbg().
      
      I've had these for some time on my computer in a less polished form, and
      they've proven useful. What I found most useful was to enable
      CONFIG_BOOTTIME_TRACING, add "trace_event=dsa" to the kernel cmdline,
      and run "cat /sys/kernel/debug/tracing/trace". This is to debug more
      complex environments with network managers started by the init system,
      things like that.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9538ebce
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Correct cmode to PHY_INTERFACE_ · 18bb56ab
      Andrew Lunn authored
      The switch can either take the MAC or the PHY role in an MII or RMII
      link. There are distinct PHY_INTERFACE_ macros for these two roles.
      Correct the mapping so that the `REV` version is used for the PHY
      role.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20230411023541.2372609-1-andrew@lunn.chSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      18bb56ab
  2. 11 Apr, 2023 12 commits
  3. 10 Apr, 2023 9 commits
  4. 09 Apr, 2023 1 commit
    • Vladimir Oltean's avatar
      net: dsa: replace NETDEV_PRE_CHANGE_HWTSTAMP notifier with a stub · 5a178186
      Vladimir Oltean authored
      There was a sort of rush surrounding commit 88c0a6b5 ("net: create a
      netdev notifier for DSA to reject PTP on DSA master"), due to a desire
      to convert DSA's attempt to deny TX timestamping on a DSA master to
      something that doesn't block the kernel-wide API conversion from
      ndo_eth_ioctl() to ndo_hwtstamp_set().
      
      What was required was a mechanism that did not depend on ndo_eth_ioctl(),
      and what was provided was a mechanism that did not depend on
      ndo_eth_ioctl(), while at the same time introducing something that
      wasn't absolutely necessary - a new netdev notifier.
      
      There have been objections from Jakub Kicinski that using notifiers in
      general when they are not absolutely necessary creates complications to
      the control flow and difficulties to maintainers who look at the code.
      So there is a desire to not use notifiers.
      
      In addition to that, the notifier chain gets called even if there is no
      DSA in the system and no one is interested in applying any restriction.
      
      Take the model of udp_tunnel_nic_ops and introduce a stub mechanism,
      through which net/core/dev_ioctl.c can call into DSA even when
      CONFIG_NET_DSA=m.
      
      Compared to the code that existed prior to the notifier conversion, aka
      what was added in commits:
      - 4cfab356 ("net: dsa: Add wrappers for overloaded ndo_ops")
      - 3369afba ("net: Call into DSA netdevice_ops wrappers")
      
      this is different because we are not overloading any struct
      net_device_ops of the DSA master anymore, but rather, we are exposing a
      rather specific functionality which is orthogonal to which API is used
      to enable it - ndo_eth_ioctl() or ndo_hwtstamp_set().
      
      Also, what is similar is that both approaches use function pointers to
      get from built-in code to DSA.
      
      There is no point in replicating the function pointers towards
      __dsa_master_hwtstamp_validate() once for every CPU port (dev->dsa_ptr).
      Instead, it is sufficient to introduce a singleton struct dsa_stubs,
      built into the kernel, which contains a single function pointer to
      __dsa_master_hwtstamp_validate().
      
      I find this approach preferable to what we had originally, because
      dev->dsa_ptr->netdev_ops->ndo_do_ioctl() used to require going through
      struct dsa_port (dev->dsa_ptr), and so, this was incompatible with any
      attempts to add any data encapsulation and hide DSA data structures from
      the outside world.
      
      Link: https://lore.kernel.org/netdev/20230403083019.120b72fd@kernel.org/Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a178186
  5. 08 Apr, 2023 10 commits
  6. 07 Apr, 2023 4 commits