1. 01 9月, 2015 2 次提交
  2. 24 8月, 2015 1 次提交
    • V
      net: dsa: mv88e6xxx: set 802.1Q mode to Fallback · f5117ce4
      Vivien Didelot 提交于
      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: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5117ce4
  3. 19 8月, 2015 2 次提交
  4. 14 8月, 2015 6 次提交
  5. 12 8月, 2015 7 次提交
  6. 11 8月, 2015 1 次提交
  7. 10 8月, 2015 5 次提交
  8. 04 8月, 2015 1 次提交
  9. 27 7月, 2015 1 次提交
  10. 22 7月, 2015 1 次提交
    • F
      net: dsa: bcm_sf2: Do not override speed settings · d2eac98f
      Florian Fainelli 提交于
      The SF2 driver currently overrides speed settings for its port
      configured using a fixed PHY, this is both unnecessary and incorrect,
      because we keep feedback to the hardware parameters that we read from
      the PHY device, which in the case of a fixed PHY cannot possibly change
      speed.
      
      This is a required change to allow the fixed PHY code to allow
      registering a PHY with a link configured as DOWN by default and avoid
      some sort of circular dependency where we require the link_update
      callback to run to program the hardware, and we then utilize the fixed
      PHY parameters to program the hardware with the same settings.
      
      Fixes: 246d7f77 ("net: dsa: add Broadcom SF2 switch driver")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2eac98f
  11. 21 7月, 2015 2 次提交
    • F
      net: dsa: bcm_sf2: do not use indirect reads and writes for 7445E0 · b8c6cd1d
      Florian Fainelli 提交于
      7445E0 contains an ECO which disconnected the internal SF2 pseudo-PHY which was
      known to conflict with the external pseudo-PHY of BCM53125 switches. This
      motivated the need to utilize the internal SF2 MDIO controller via indirect
      register reads/writes to control external Broadcom switches due to this address
      conflict (both responded at address 30d).
      
      For 7445E0, the internal pseudo-PHY of the SF2 switch got disconnected, and as
      a consequence this prevents the internal SF2 MDIO bus controller from reading
      data (reads back everything as 0) since the MDI line is tied low.
      
      Fix this by making the indirect register reads and writes conditional to
      7445D0, on 7445E0 we can utilize the SWITCH_MDIO controller (backed by
      mdio-unimac and not the DSA created slave MII bus).
      
      We utilize of_machine_is_compatible() here since this is the only way for use
      to differentiate between these two chips in a way that does not violate layers
      or becomes (too) vendor-specific.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8c6cd1d
    • V
      net: dsa: mv88e6xxx: fix fid_mask when leaving bridge · 40a71660
      Vivien Didelot 提交于
      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: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40a71660
  12. 10 7月, 2015 1 次提交
  13. 23 6月, 2015 7 次提交
  14. 11 6月, 2015 1 次提交
  15. 08 6月, 2015 1 次提交
  16. 18 5月, 2015 1 次提交
    • F
      net: dsa: bcm_sf2: properly propagate carrier down state for MoCA · 4ab7f913
      Florian Fainelli 提交于
      MoCA interfaces require the use of an user-space daemon (mocad) which
      will typically use cmd->autoneg to force the link. This is causing other
      network manager applications not to get proper carrier down
      notifications because of the following sequence of events:
      
      - link down interrupt is received, link is set to 0 by the interrupt
        handler
      - fixed_link update callback runs and updates the BMSR register
        accordingly
      - PHY library polls the PHY for link status, sees the link is down,
        proceeds with reporting that
      - mocad gets notified of the link state and call phy_ethtool_sset()
        with cmd->autoneg set to the link status (0)
      - phy_start_aneg() is called at the end of phy_ethtool_sset() and sets
        the PHY state to PHY_FORCING
      
      Just make sure we notify the interface carrier appropriately when we
      detect that the link is down in our fixed_link update callback. This is
      made local to the bcm_sf2 driver as the PHY library does the right thing
      in any case. This is similar to the GENET change introduced in
      54d7c01d ("net: bcmgenet: enable MoCA
      link state change detection").
      
      Fixes: 246d7f77 ("net: dsa: add Broadcom SF2 switch driver")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ab7f913