1. 18 Dec, 2019 28 commits
  2. 17 Dec, 2019 12 commits
    • Florian Fainelli's avatar
      net: dsa: Make PHYLINK related function static again · 8ae67496
      Florian Fainelli authored
      Commit 77373d49 ("net: dsa: Move the phylink driver calls into
      port.c") moved and exported a bunch of symbols, but they are not used
      outside of net/dsa/port.c at the moment, so no reason to export them.
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ae67496
    • Jon Maloy's avatar
      tipc: don't send gap blocks in ACK messages · b7ffa045
      Jon Maloy authored
      In the commit referred to below we eliminated sending of the 'gap'
      indicator in regular ACK messages, reserving this to explicit NACK
      ditto.
      
      Unfortunately we missed to also eliminate building of the 'gap block'
      area in ACK messages. This area is meant to report gaps in the
      received packet sequence following the initial gap, so that lost
      packets can be retransmitted earlier and received out-of-sequence
      packets can be released earlier. However, the interpretation of those
      blocks is dependent on a complete and correct sequence of gaps and
      acks. Hence, when the initial gap indicator is missing a single gap
      block will be interpreted as an acknowledgment of all preceding
      packets. This may lead to packets being released prematurely from the
      sender's transmit queue, with easily predicatble consequences.
      
      We now fix this by not building any gap block area if there is no
      initial gap to report.
      
      Fixes: commit 02288248 ("tipc: eliminate gap indicator from ACK messages")
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7ffa045
    • David S. Miller's avatar
      Merge branch 'stmmac-dwc-qos-ACPI-device-support' · 2b2d81a6
      David S. Miller authored
      Ajay Gupta says:
      
      ====================
      net: stmmac: dwc-qos: ACPI device support
      
      Version 3 of patches have fixes for comments from Jakub Kicinski.
      
      These two changes are needed to enable ACPI based devices to use stmmac
      driver. First patch is to use generic device api (device_*) instead of
      device tree based api (of_*). Second patch avoids clock and reset accesses
      for Tegra ACPI based devices. ACPI interface will be used to access clock
      and reset for Tegra ACPI devices in later patches.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b2d81a6
    • Ajay Gupta's avatar
      net: stmmac: dwc-qos: avoid clk and reset for acpi device · 1d4605e0
      Ajay Gupta authored
      There are no clocks, resets or gpios referenced by Tegra ACPI
      device so don't access clocks, resets or gpios interface with
      ACPI device.
      
      Clocks, resets and GPIOs for ACPI devices will be handled via
      ACPI interface.
      Signed-off-by: default avatarAjay Gupta <ajayg@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d4605e0
    • Ajay Gupta's avatar
      net: stmmac: dwc-qos: use generic device api · b59c43e0
      Ajay Gupta authored
      Use generic device api so that driver can work both with DT
      or ACPI based devices.
      Signed-off-by: default avatarAjay Gupta <ajayg@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b59c43e0
    • David S. Miller's avatar
      Merge branch 'dwmac-mediatek-add-more-support-for-RMII' · ce2b5a3a
      David S. Miller authored
      Biao Huang says:
      
      ====================
      net-next: stmmac: dwmac-mediatek: add more support for RMII
      
      changes in v2:
       PATCH 1/2 net-next: stmmac: mediatek: add more support for RMII
              As Andrew's comments, add the "rmii_internal" clock to the list of clocks.
      
       PATCH 2/2 net-next: dt-binding: dwmac-mediatek: add more description for RMII
              document the "rmii_internal" clock in dt-bindings
              rewrite the sample dts in dt-bindings.
      
      v1:
      This series is for support RMII when MT2712 SoC provides the reference clock.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce2b5a3a
    • Biao Huang's avatar
      net-next: dt-binding: dwmac-mediatek: add more description for RMII · 882007ed
      Biao Huang authored
      MT2712 SoC can provide RMII reference clock,
      so add corresponding description in dt-binding.
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      882007ed
    • Biao Huang's avatar
      net-next: stmmac: mediatek: add more support for RMII · 71a55a23
      Biao Huang authored
      MT2712 SoC can provide the rmii reference clock, and the clock
      will output from TXC pin only, which means ref_clk pin of external
      PHY should connect to TXC pin in this case.
      Add corresponding clock and timing settings.
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71a55a23
    • David S. Miller's avatar
      Merge branch 'improve-clause-45-support-in-phylink' · 4e133f76
      David S. Miller authored
      Russell King says:
      
      ====================
      improve clause 45 support in phylink
      
      These three patches improve the clause 45 support in phylink, fixing
      some corner cases that have been noticed with the addition of SFP+
      NBASE-T modules, but are actually a little more wisespread than I
      initially realised.
      
      The first issue was spotted with a NBASE-T PHY on a SFP+ module plugged
      into a mvneta platform. When these PHYs are not operating in USXGMII
      mode, but are in a single-lane Serdes mode, they will switch between
      one of several different PHY interface modes.
      
      If we call the MAC validate() function with the current PHY interface
      mode, we will restrict the supported and advertising masks to the link
      modes that the current PHY interface mode supports. For example, if we
      determine that we want to start the PHY with an interface mode of
      2500BASE-X, then this setup will restrict the advertisement and
      supported masks to 2.5G speed link modes.
      
      What we actually want for these PHYs is to allow them to support any
      link modes that the PHY supports _and_ the MAC is also capable of
      supporting. Without knowing the details of the PHY interface modes that
      may be used, we can do this by using PHY_INTERFACE_MODE_NA to validate
      and restrict the link modes to any that the MAC supports.
      
      mvpp2 with the 88X3310 PHY avoids this problem, because the validate()
      implementation allows all MAC supported speeds not only for
      PHY_INTERFACE_MODE_NA, but also for XAUI and 10GKR modes.
      
      The first patch addresses this; current MAC drivers should continue to
      work as-is, but there will be a follow-on patch to fixup at least
      mvpp2.
      
      The second issue addresses a very similar problem that occurs when
      trying to use ethtool to alter the advertisement mask - we call
      the MAC validate() function with the current interface mode, the
      current support and requested advertisement masks. This immediately
      restricts the advertisement in the same way as the above.
      
      This patch series addresses both issues, although the patches are not
      in the above order.
      
      v2: fix patch 3 missing 1G link modes for SGMII and RGMII interface
          modes.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e133f76
    • 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