1. 01 12月, 2021 6 次提交
    • M
      net: dsa: mv88e6xxx: Link in pcs_get_state() if AN is bypassed · ede359d8
      Marek Behún 提交于
      Function mv88e6xxx_serdes_pcs_get_state() currently does not report link
      up if AN is enabled, Link bit is set, but Speed and Duplex Resolved bit
      is not set, which testing shows is the case for when auto-negotiation
      was bypassed (we have AN enabled but link partner does not).
      
      An example of such link partner is Marvell 88X3310 PHY, when put into
      the mode where host interface changes between 10gbase-r, 5gbase-r,
      2500base-x and sgmii according to copper speed. The 88X3310 does not
      enable AN in 2500base-x, and so SerDes on mv88e6xxx currently does not
      link with it.
      
      Fix this.
      
      Fixes: a5a6858b ("net: dsa: mv88e6xxx: extend phylink to Serdes PHYs")
      Signed-off-by: NMarek Behún <kabel@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ede359d8
    • M
      net: dsa: mv88e6xxx: Fix inband AN for 2500base-x on 88E6393X family · 163000db
      Marek Behún 提交于
      Inband AN is broken on Amethyst in 2500base-x mode when set by standard
      mechanism (via cmode).
      
      (There probably is some weird setting done by default in the switch for
       this mode that make it cycle in some state or something, because when
       the peer is the mvneta controller, it receives link change interrupts
       every ~0.3ms, but the link is always down.)
      
      Get around this by configuring the PCS mode to 1000base-x (where inband
      AN works), and then changing the SerDes frequency while SerDes
      transmitter and receiver are disabled, before enabling SerDes PHY. After
      disabling SerDes PHY, change the PCS mode back to 2500base-x, to avoid
      confusing the device (if we leave it at 1000base-x PCS mode but with
      different frequency, and then change cmode to sgmii, the device won't
      change the frequency because it thinks it already has the correct one).
      
      The register which changes the frequency is undocumented. I discovered
      it by going through all registers in the ranges 4.f000-4.f100 and
      1e.8000-1e.8200 for all SerDes cmodes (sgmii, 1000base-x, 2500base-x,
      5gbase-r, 10gbase-r, usxgmii) and filtering out registers that didn't
      make sense (the value was the same for modes which have different
      frequency). The result of this was:
      
          reg   sgmii 1000base-x 2500base-x 5gbase-r 10gbase-r usxgmii
        04.f002  005b       0058       0059     005c      005d    005f
        04.f076  3000       0000       1000     4000      5000    7000
        04.f07c  0950       0950       1850     0550      0150    0150
        1e.8000  0059       0059       0058     0055      0051    0051
        1e.8140  0e20       0e20       0e28     0e21      0e42    0e42
      
      Register 04.f002 is the documented Port Operational Confiuration
      register, it's last 3 bits select PCS type, so changing this register
      also changes the frequency to the appropriate value.
      
      Registers 04.f076 and 04.f07c are not writable.
      
      Undocumented register 1e.8000 was the one: changing bits 3:0 from 9 to 8
      changed SerDes frequency to 3.125 GHz, while leaving the value of PCS
      mode in register 04.f002.2:0 at 1000base-x. Inband autonegotiation
      started working correctly.
      
      (I didn't try anything with register 1e.8140 since 1e.8000 solved the
       problem.)
      
      Since I don't have documentation for this register 1e.8000.3:0, I am
      using the constants without names, but my hypothesis is that this
      register selects PHY frequency. If in the future I have access to an
      oscilloscope able to handle these frequencies, I will try to test this
      hypothesis.
      
      Fixes: de776d0d ("net: dsa: mv88e6xxx: add support for mv88e6393x family")
      Signed-off-by: NMarek Behún <kabel@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      163000db
    • M
      net: dsa: mv88e6xxx: Add fix for erratum 5.2 of 88E6393X family · 93fd8207
      Marek Behún 提交于
      Add fix for erratum 5.2 of the 88E6393X (Amethyst) family: for 10gbase-r
      mode, some undocumented registers need to be written some special
      values.
      
      Fixes: de776d0d ("net: dsa: mv88e6xxx: add support for mv88e6393x family")
      Signed-off-by: NMarek Behún <kabel@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93fd8207
    • M
      net: dsa: mv88e6xxx: Save power by disabling SerDes trasmitter and receiver · 7527d662
      Marek Behún 提交于
      Save power on 88E6393X by disabling SerDes receiver and transmitter
      after SerDes is SerDes is disabled.
      Signed-off-by: NMarek Behún <kabel@kernel.org>
      Cc: stable@vger.kernel.org # de776d0d ("net: dsa: mv88e6xxx: add support for mv88e6393x family")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7527d662
    • M
      net: dsa: mv88e6xxx: Drop unnecessary check in mv88e6393x_serdes_erratum_4_6() · 8c3318b4
      Marek Behún 提交于
      The check for lane is unnecessary, since the function is called only
      with allowed lane argument.
      Signed-off-by: NMarek Behún <kabel@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c3318b4
    • M
      net: dsa: mv88e6xxx: Fix application of erratum 4.8 for 88E6393X · 21635d92
      Marek Behún 提交于
      According to SERDES scripts for 88E6393X, erratum 4.8 has to be applied
      every time before SerDes is powered on.
      
      Split the code for erratum 4.8 into separate function and call it in
      mv88e6393x_serdes_power().
      
      Fixes: de776d0d ("net: dsa: mv88e6xxx: add support for mv88e6393x family")
      Signed-off-by: NMarek Behún <kabel@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21635d92
  2. 24 8月, 2021 1 次提交
    • N
      net: dsa: mv88e6xxx: Update mv88e6393x serdes errata · 3b0720ba
      Nathan Rossi 提交于
      In early erratas this issue only covered port 0 when changing from
      [x]MII (rev A 3.6). In subsequent errata versions this errata changed to
      cover the additional "Hardware reset in CPU managed mode" condition, and
      removed the note specifying that it only applied to port 0.
      
      In designs where the device is configured with CPU managed mode
      (CPU_MGD), on reset all SERDES ports (p0, p9, p10) have a stuck power
      down bit and require this initial power up procedure. As such apply this
      errata to all three SERDES ports of the mv88e6393x.
      Signed-off-by: NNathan Rossi <nathan.rossi@digi.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b0720ba
  3. 02 7月, 2021 1 次提交
  4. 28 4月, 2021 1 次提交
    • T
      net: dsa: mv88e6xxx: Fix 6095/6097/6185 ports in non-SERDES CMODE · 6066234a
      Tobias Waldekranz 提交于
      The .serdes_get_lane op used the magic value 0xff to indicate a valid
      SERDES lane and 0 signaled that a non-SERDES mode was set on the port.
      
      Unfortunately, "0" is also a valid lane ID, so even when these ports
      where configured to e.g. RGMII the driver would set them up as SERDES
      ports.
      
      - Replace 0xff with 0 to indicate a valid lane ID. The number is on
        the one hand just as arbitrary, but it is at least the first valid one
        and therefore less of a surprise.
      
      - Follow the other .serdes_get_lane implementations and return -ENODEV
        in the case where no SERDES is assigned to the port.
      
      Fixes: f5be107c ("net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185")
      Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6066234a
  5. 18 3月, 2021 2 次提交
  6. 26 11月, 2020 3 次提交
  7. 02 5月, 2020 2 次提交
  8. 16 3月, 2020 3 次提交
  9. 17 2月, 2020 2 次提交
  10. 28 12月, 2019 1 次提交
  11. 02 9月, 2019 10 次提交
  12. 30 8月, 2019 1 次提交
  13. 28 8月, 2019 4 次提交
  14. 24 6月, 2019 1 次提交
  15. 31 5月, 2019 1 次提交
  16. 05 3月, 2019 1 次提交