Skip to content
Snippets Groups Projects
  1. May 16, 2015
    • Tim Beale's avatar
      net: phy: Make sure PHY_RESUMING state change is always processed · db9683fb
      Tim Beale authored
      
      If phy_start_aneg() was called while the phydev is in the PHY_RESUMING
      state, then its state would immediately transition to PHY_AN (or
      PHY_FORCING). This meant the phy_state_machine() never processed the
      PHY_RESUMING state change, which meant interrupts weren't enabled for the
      PHY. If the PHY used low-power mode (i.e. using BMCR_PDOWN), then the
      physical link wouldn't get powered up again.
      
      There seems no point for phy_start_aneg() to make the PHY_RESUMING -->
      PHY_AN transition, as the state machine will do this anyway. I'm not sure
      about the case where autoneg is disabled, as my patch will change
      behaviour so that the PHY goes to PHY_NOLINK instead of PHY_FORCING. An
      alternative solution would be to move the phy_config_interrupt() and
      phy_resume() work out of the state machine and into phy_start().
      
      The background behind this: we're running linux v3.16.7 and from user-space
      we want to enable the eth port (i.e. do a SIOCSIFFLAGS ioctl with the
      IFF_UP flag) and immediately afterward set the interface's speed/duplex.
      Enabling the interface calls .ndo_open() then phy_start() and the PHY
      transitions PHY_HALTED --> PHY_RESUMING. Setting the speed/duplex ends up
      calling phy_ethtool_sset(), which calls phy_start_aneg() (meanwhile the
      phy_state_machine() hasn't processed the PHY_RESUMING state change yet).
      
      Signed-off-by: default avatarTim Beale <tim.beale@alliedtelesis.co.nz>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db9683fb
    • Florian Fainelli's avatar
      net: phy: Allow EEE for all RGMII variants · 7e140696
      Florian Fainelli authored
      
      RGMII interfaces come in multiple flavors: RGMII with transmit or
      receive internal delay, no delays at all, or delays in both direction.
      
      This change extends the initial check for PHY_INTERFACE_MODE_RGMII to
      cover all of these variants since EEE should be allowed for any of these
      modes, since it is a property of the RGMII, hence Gigabit PHY capability
      more than the RGMII electrical interface and its delays.
      
      Fixes: a59a4d19 ("phy: add the EEE support and the way to access to the MMD registers")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e140696
    • Ying Xue's avatar
      rocker: fix a neigh entry leak issue · 1f9993f6
      Ying Xue authored
      
      Once we get a neighbour through looking up arp cache or creating a
      new one in rocker_port_ipv4_resolve(), the neighbour's refcount is
      already taken. But as we don't put the refcount again after it's
      used, this makes the neighbour entry leaked.
      
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f9993f6
  2. May 15, 2015
  3. May 13, 2015
  4. May 11, 2015
  5. May 10, 2015
  6. May 09, 2015
  7. May 07, 2015
  8. May 05, 2015
  9. May 04, 2015
  10. May 03, 2015
  11. May 01, 2015
  12. Apr 30, 2015
Loading