1. 20 2月, 2017 1 次提交
  2. 26 1月, 2017 1 次提交
  3. 24 1月, 2017 1 次提交
  4. 10 1月, 2017 1 次提交
    • Z
      phy state machine: failsafe leave invalid RUNNING state · 811a9191
      Zefir Kurtisi 提交于
      While in RUNNING state, phy_state_machine() checks for link changes by
      comparing phydev->link before and after calling phy_read_status().
      This works as long as it is guaranteed that phydev->link is never
      changed outside the phy_state_machine().
      
      If in some setups this happens, it causes the state machine to miss
      a link loss and remain RUNNING despite phydev->link being 0.
      
      This has been observed running a dsa setup with a process continuously
      polling the link states over ethtool each second (SNMPD RFC-1213
      agent). Disconnecting the link on a phy followed by a ETHTOOL_GSET
      causes dsa_slave_get_settings() / dsa_slave_get_link_ksettings() to
      call phy_read_status() and with that modify the link status - and
      with that bricking the phy state machine.
      
      This patch adds a fail-safe check while in RUNNING, which causes to
      move to CHANGELINK when the link is gone and we are still RUNNING.
      Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      811a9191
  5. 02 12月, 2016 1 次提交
  6. 30 11月, 2016 1 次提交
  7. 16 11月, 2016 1 次提交
  8. 13 11月, 2016 1 次提交
  9. 18 10月, 2016 3 次提交
  10. 17 10月, 2016 3 次提交
  11. 14 10月, 2016 1 次提交
    • A
      net: phy: Trigger state machine on state change and not polling. · 3c293f4e
      Andrew Lunn 提交于
      The phy_start() is used to indicate the PHY is now ready to do its
      work. The state is changed, normally to PHY_UP which means that both
      the MAC and the PHY are ready.
      
      If the phy driver is using polling, when the next poll happens, the
      state machine notices the PHY is now in PHY_UP, and kicks off
      auto-negotiation, if needed.
      
      If however, the PHY is using interrupts, there is no polling. The phy
      is stuck in PHY_UP until the next interrupt comes along. And there is
      no reason for the PHY to interrupt.
      
      Have phy_start() schedule the state machine to run, which both speeds
      up the polling use case, and makes the interrupt use case actually
      work.
      
      This problems exists whenever there is a state change which will not
      cause an interrupt. Trigger the state machine in these cases,
      e.g. phy_error().
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Cc: Kyle Roeschley <kyle.roeschley@ni.com>
      Tested-by: NKyle Roeschley <kyle.roeschley@ni.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c293f4e
  12. 26 8月, 2016 1 次提交
  13. 11 5月, 2016 2 次提交
  14. 19 4月, 2016 1 次提交
  15. 22 1月, 2016 2 次提交
    • F
      net: phy: Fix phy_mac_interrupt() · deccd16f
      Florian Fainelli 提交于
      Commit 5ea94e76 ("phy: add phy_mac_interrupt()") to use with
      PHY_IGNORE_INTERRUPT added a cancel_work_sync() into phy_mac_interrupt()
      which is allowed to sleep, whereas phy_mac_interrupt() is expected to be
      callable from interrupt context.
      
      Now that we have fixed how the PHY state machine treats
      PHY_IGNORE_INTERRUPT with respect to state changes, we can just set the
      new link state, and queue the PHY state machine for execution so it is
      going to read the new link state.
      
      For that to work properly, we need to update phy_change() not to try to
      invoke any interrupt callbacks if we have configured the PHY device for
      PHY_IGNORE_INTERRUPT, because that PHY device and its driver are not
      required to implement those.
      
      Fixes: 5ea94e76 ("phy: add phy_mac_interrupt() to use with PHY_IGNORE_INTERRUPT")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      deccd16f
    • F
      net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS · d5c3d846
      Florian Fainelli 提交于
      Commit 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed
      a hunk in phy_state_machine() in the PHY_RUNNING case which was not
      needed. The change essentially makes the PHY library treat PHY devices
      with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even
      though the intent is not to do it.
      
      Fix this by reverting that specific hunk, which makes the PHY state
      machine wait for state changes, and stay in the PHY_RUNNING state for as
      long as needed.
      
      Fixes: 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5c3d846
  16. 08 1月, 2016 3 次提交
  17. 04 12月, 2015 1 次提交
  18. 18 11月, 2015 1 次提交
  19. 29 8月, 2015 1 次提交
  20. 26 8月, 2015 1 次提交
  21. 18 8月, 2015 1 次提交
  22. 11 7月, 2015 2 次提交
  23. 27 5月, 2015 1 次提交
  24. 21 5月, 2015 1 次提交
    • T
      net: phy: Make sure phy_start() always re-enables the phy interrupts · c15e10e7
      Tim Beale 提交于
      This is an alternative way of fixing:
       commit db9683fb ("net: phy: Make sure PHY_RESUMING state change
                            is always processed")
      
      When the PHY state transitions from PHY_HALTED to PHY_RESUMING, there are
      two things we need to do:
      1). Re-enable interrupts (and power up the physical link, if powered down)
      2). Update the PHY state and net-device based on the link status.
      
      There's no strict reason why #1 has to be done from within the main
      phy_state_machine() function. There is a risk that other changes to the
      PHY (e.g. setting speed/duplex, which calls phy_start_aneg()) could cause
      a subsequent state transition before phy_state_machine() has processed
      the PHY_RESUMING state change. This would leave the PHY with interrupts
      disabled and/or still in the BMCR_PDOWN/low-power mode.
      
      Moving enabling the interrupts and phy_resume() into phy_start() will
      guarantee this work always gets done. As the PHY is already in the HALTED
      state and interrupts are disabled, it shouldn't conflict with any work
      being done in phy_state_machine(). The downside of this change is that if
      the PHY_RESUMING state is ever entered from anywhere else, it'll also have
      to repeat this work.
      Signed-off-by: NTim Beale <tim.beale@alliedtelesis.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15e10e7
  25. 17 5月, 2015 2 次提交
    • T
      net: phy: Make sure PHY_RESUMING state change is always processed · db9683fb
      Tim Beale 提交于
      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: NTim Beale <tim.beale@alliedtelesis.co.nz>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db9683fb
    • F
      net: phy: Add state machine state transitions debug prints · 3e2186e0
      Florian Fainelli 提交于
      It can be useful to debug the PHY state machine, add dynamic debug
      prints of the old and new PHY devices state under a friendly format.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e2186e0
  26. 16 5月, 2015 1 次提交
    • F
      net: phy: Allow EEE for all RGMII variants · 7e140696
      Florian Fainelli 提交于
      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: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e140696
  27. 21 2月, 2015 1 次提交
  28. 27 1月, 2015 1 次提交
  29. 12 11月, 2014 1 次提交
  30. 28 8月, 2014 1 次提交