Skip to content
  1. Dec 18, 2019
    • Russell King's avatar
      net: mvpp2: update mvpp2 validate() implementation · ef8e0b80
      Russell King authored
      
      
      Fix up the mvpp2 validate implementation to adopt the same behaviour as
      mvneta:
      - only allow the link modes that the specified PHY interface mode
        supports with the exception of 1000base-X and 2500base-X.
      - use the basex helper to deal with SFP modules that can be switched
        between 1000base-X vs 2500base-X.
      
      This gives consistent behaviour between mvneta and mvpp2.
      
      This commit depends on "net: phylink: extend clause 45 PHY validation
      workaround" so is not marked for backporting to stable kernels.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef8e0b80
    • Russell King's avatar
      net: phylink: extend clause 45 PHY validation workaround · df3f57ac
      Russell King authored
      Commit e45d1f52
      
       ("net: phylink: support Clause 45 PHYs on SFP+
      modules") added a workaround to support clause 45 PHYs which
      dynamically switch their interface mode on SFP+ modules.  This was
      implemented by validating the PHYs supported/advertising using
      PHY_INTERFACE_MODE_NA, rather than the specific interface mode that
      we attached the PHY with.
      
      However, we already have a situation where phylink is used to connect
      a Marvell 88X3310 PHY which also behaves in exactly the same way, but
      which seemingly doesn't need this.  The reason seems to be that the
      mvpp2 driver sets a whole bunch of link modes for
      PHY_INTERFACE_MODE_10GKR down to 10Mb/s, despite 10GBASE-R not actually
      supporting anything but 10Gb/s speeds.
      
      When testing with drivers that (correctly) take the mvneta approach,
      where the validate() method only returns what can be supported /
      advertised for the specified link mode, we find that Clause 45 PHYs do
      not behave as we expect: their advertisement is restricted to what
      the current link will support, rather than what the PHY supports
      through its dynamic switching.
      
      Extend this workaround to all such cases; if we have a Clause 45 PHY
      attaching via any means, except in USXGMII, XAUI and RXAUI which are
      all unable to support this dynamic switching or have other solutions
      to it, then we need to validate using PHY_INTERFACE_MODE_NA.
      
      This should allow mvpp2 to switch to a more conformant validate()
      implementation.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df3f57ac
    • Russell King's avatar
      net: phylink: improve clause 45 PHY ksettings_set implementation · 5d57c327
      Russell King authored
      
      
      While testing ethtool with the Methode DM7052 module, it was noticed
      that attempting to set the advertising mask results in the mask being
      truncated to the support offered by the currently chosen PHY interface
      mode.
      
      When a PHY dynamically changes the PHY interface mode, limiting the
      advertising mask in this way is not correct - if the PHY happened to
      negotiate 10GBASE-T, and selected 10GBASE-R as the host interface, we
      don't want to restrict the advertisement to just 10GBASE-* modes.
      
      Rework setting the advertisement to take account of this; do not pass
      the requested advertisement through phylink_validate(), but rely on
      the advertisement restriction (supported mask) set when the PHY was
      initially setup.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d57c327
  2. Dec 17, 2019
  3. Dec 16, 2019
  4. Dec 15, 2019