1. 25 1月, 2019 4 次提交
  2. 23 1月, 2019 1 次提交
  3. 19 1月, 2019 3 次提交
  4. 17 1月, 2019 2 次提交
  5. 16 1月, 2019 1 次提交
  6. 19 12月, 2018 2 次提交
    • H
      net: phy: print stack trace in phy_error · fa7b28c1
      Heiner Kallweit 提交于
      So far phy_error() silently stops the PHY state machine. If the network
      driver doesn't inform about a  MDIO error then the user may wonder why
      his network is down. Let's print the stack trace to facilitate search
      for the root cause of the error.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa7b28c1
    • H
      net: phy: improve phy state checking · 2b3e88ea
      Heiner Kallweit 提交于
      Add helpers phy_is_started() and __phy_is_started() to avoid open-coded
      checks whether PHY has been started. To make the check easier move
      PHY_HALTED before PHY_UP in enum phy_state. Further improvements:
      
      phy_start_aneg():
      Return -EBUSY and print warning if function is called from a non-started
      state (DOWN, READY, HALTED). Better check because function is exported
      and drivers may use it incorrectly.
      
      phy_interrupt():
      Return IRQ_NONE also if state is DOWN or READY. We should never receive
      an interrupt in one of these states, but better play safe.
      
      phy_stop():
      Just return and print a warning if PHY is in a non-started state.
      This warning should help to identify drivers with unbalanced calls to
      phy_start() / phy_stop().
      
      phy_state_machine():
      Schedule state machine run only if PHY is in a started state.
      E.g. if state is READY we don't need the state machine, it will be
      started by phy_start().
      
      v2:
      - don't use __func__ within phy_warn_state
      v3:
      - use WARN() instead of printing error message to facilitate debugging
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b3e88ea
  7. 06 12月, 2018 1 次提交
  8. 04 12月, 2018 1 次提交
    • H
      net: phy: improve generic EEE ethtool functions · d1420bb9
      Heiner Kallweit 提交于
      So far the two functions consider neither member eee_enabled nor
      eee_active. Therefore network drivers have to do this in some kind
      of glue code. I think this can be avoided.
      
      Getting EEE parameters:
      When not advertising any EEE mode, we can't consider EEE to be enabled.
      Therefore interpret "EEE enabled" as "we advertise at least one EEE
      mode". It's similar with "EEE active": interpret it as "EEE modes
      advertised by both link partner have at least one mode in common".
      
      Setting EEE parameters:
      If eee_enabled isn't set, don't advertise any EEE mode and restart
      aneg if needed to switch off EEE. If eee_enabled is set and
      data->advertised is empty (e.g. because EEE was disabled), advertise
      everything we support as default. This way EEE can easily switched
      on/off by doing ethtool --set-eee <if> eee on/off, w/o any additional
      parameters.
      
      The changes to both functions shouldn't break any existing user.
      Once the changes have been applied, at least some users can be
      simplified.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1420bb9
  9. 13 11月, 2018 1 次提交
  10. 12 11月, 2018 6 次提交
  11. 10 11月, 2018 1 次提交
  12. 09 11月, 2018 5 次提交
  13. 08 11月, 2018 1 次提交
  14. 16 10月, 2018 4 次提交
  15. 02 10月, 2018 1 次提交
  16. 22 9月, 2018 1 次提交
  17. 20 9月, 2018 1 次提交
  18. 26 7月, 2018 2 次提交
  19. 22 7月, 2018 1 次提交
  20. 17 7月, 2018 1 次提交