An error occurred fetching the project authors.
  1. 30 Mar, 2020 3 commits
  2. 18 Mar, 2020 2 commits
  3. 15 Mar, 2020 1 commit
  4. 10 Mar, 2020 2 commits
  5. 04 Mar, 2020 1 commit
  6. 27 Feb, 2020 1 commit
  7. 17 Feb, 2020 6 commits
  8. 20 Jan, 2020 2 commits
  9. 14 Jan, 2020 1 commit
  10. 06 Jan, 2020 2 commits
  11. 05 Jan, 2020 2 commits
  12. 03 Jan, 2020 1 commit
  13. 17 Dec, 2019 2 commits
    • 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
  14. 15 Dec, 2019 2 commits
  15. 11 Dec, 2019 8 commits
  16. 24 Nov, 2019 1 commit
  17. 20 Nov, 2019 2 commits
  18. 16 Nov, 2019 1 commit