1. 11 Oct, 2015 3 commits
  2. 07 Oct, 2015 1 commit
  3. 29 Sep, 2015 2 commits
  4. 22 Sep, 2015 1 commit
    • Russell King's avatar
      net: dsa: actually force the speed on the CPU port · 53adc9e8
      Russell King authored
      Commit 54d792f2 ("net: dsa: Centralise global and port setup
      code into mv88e6xxx.") merged in the 4.2 merge window broke the link
      speed forcing for the CPU port of Marvell DSA switches.  The original
      code was:
              /* MAC Forcing register: don't force link, speed, duplex
               * or flow control state to any particular values on physical
               * ports, but force the CPU port and all DSA ports to 1000 Mb/s
               * full duplex.
              if (dsa_is_cpu_port(ds, p) || ds->dsa_port_mask & (1 << p))
                      REG_WRITE(addr, 0x01, 0x003e);
                      REG_WRITE(addr, 0x01, 0x0003);
      but the new code does a read-modify-write:
                      reg = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_PCS_CTRL);
                      if (dsa_is_cpu_port(ds, port) ||
                          ds->dsa_port_mask & (1 << port)) {
                              reg |= PORT_PCS_CTRL_FORCE_LINK |
                                      PORT_PCS_CTRL_LINK_UP |
                                      PORT_PCS_CTRL_DUPLEX_FULL |
                              if (mv88e6xxx_6065_family(ds))
                                      reg |= PORT_PCS_CTRL_100;
                                      reg |= PORT_PCS_CTRL_1000;
      The link speed in the PCS control register is a two bit field.  Forcing
      the link speed in this way doesn't ensure that the bit field is set to
      the correct value - on the hardware I have here, the speed bitfield
      remains set to 0x03, resulting in the speed not being forced to gigabit.
      We must clear both bits before forcing the link speed.
      Fixes: 54d792f2
       ("net: dsa: Centralise global and port setup code into mv88e6xxx.")
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 15 Sep, 2015 7 commits
  6. 31 Aug, 2015 3 commits
  7. 23 Aug, 2015 1 commit
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: set 802.1Q mode to Fallback · f5117ce4
      Vivien Didelot authored
      The current Secure port mode requires the port-based VLANs to also be
      valid in the 802.1Q VLAN Table Unit. The current hardware bridging
      support only configures the port-based VLANs, thus is broken.
      A new patchset is required to adapt the hardware bridging code to fully
      support the Secure port mode.
      In the meantime, change the 802.1Q mode of every ports to Fallback,
      which filtering is more permissive, and doesn't add this restriction to
      handle port-based and tagged-based VLANs.
      Fixes: 8efdda4a
       ("net: dsa: mv88e6xxx: use port 802.1Q mode Secure")
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 18 Aug, 2015 2 commits
  9. 13 Aug, 2015 6 commits
  10. 11 Aug, 2015 7 commits
  11. 09 Aug, 2015 4 commits
  12. 03 Aug, 2015 1 commit
  13. 27 Jul, 2015 1 commit
  14. 20 Jul, 2015 1 commit
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: fix fid_mask when leaving bridge · 40a71660
      Vivien Didelot authored
      The mv88e6xxx_priv_state structure contains an fid_mask, where 1 means
      the FID is free to use, 0 means the FID is in use.
      This patch fixes the bit clear in mv88e6xxx_leave_bridge() when
      assigning a new FID to a port.
      Example scenario: I have 7 ports, port 5 is CPU, port 6 is unused (no
      PHY). After setting the ports 0, 1 and 2 in bridge br0, and ports 3 and
      4 in bridge br1, I have the following fid_mask: 0b111110010110 (0xf96).
      Indeed, br0 uses FID 0, and br1 uses FID 3.
      After setting nomaster for port 0, I get the wrong fid_mask: 0b10 (0x2).
      With this patch we correctly get 0b111110010100 (0xf94), meaning port 0
      uses FID 1, br0 uses FID 0, and br1 uses FID 3.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>