Skip to content
Snippets Groups Projects
  1. Jan 25, 2019
  2. Jan 23, 2019
  3. Jan 18, 2019
  4. Jan 17, 2019
  5. Jan 15, 2019
  6. Dec 18, 2018
    • Heiner Kallweit's avatar
      net: phy: print stack trace in phy_error · fa7b28c1
      Heiner Kallweit authored
      
      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: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa7b28c1
    • Heiner Kallweit's avatar
      net: phy: improve phy state checking · 2b3e88ea
      Heiner Kallweit authored
      
      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: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b3e88ea
  7. Dec 06, 2018
  8. Dec 03, 2018
    • Heiner Kallweit's avatar
      net: phy: improve generic EEE ethtool functions · d1420bb9
      Heiner Kallweit authored
      
      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: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1420bb9
  9. Nov 13, 2018
  10. Nov 11, 2018
  11. Nov 10, 2018
  12. Nov 08, 2018
  13. Oct 16, 2018
  14. Oct 02, 2018
  15. Sep 22, 2018
  16. Sep 20, 2018
  17. Jul 25, 2018
  18. Jul 21, 2018
  19. Jul 16, 2018
Loading