1. 06 6月, 2019 1 次提交
  2. 01 6月, 2019 1 次提交
  3. 31 5月, 2019 3 次提交
  4. 08 5月, 2019 1 次提交
  5. 04 5月, 2019 1 次提交
  6. 19 4月, 2019 1 次提交
  7. 21 3月, 2019 1 次提交
    • H
      net: phy: improve handling link_change_notify callback · 5c5f626b
      Heiner Kallweit 提交于
      Currently the Phy driver's link_change_notify callback is called
      whenever the state machine is run (every second if polling), no matter
      whether the state changed or not. This isn't needed and may confuse
      users considering the name of the callback. Actually it contradicts
      its kernel-doc description. Therefore let's change the behavior and
      call this callback only in case of an actual state change.
      
      This requires changes to the at803x and rockchip drivers.
      at803x can be simplified so that it reacts on a state change to
      PHY_NOLINK only.
      The rockchip driver can also be much simplified. We simply re-init
      the AFE/DSP registers whenever we change to PHY_RUNNING and speed
      is 100Mbps. This causes very small overhead because we do this even
      if the speed was 100Mbps already. But this is negligible and
      I think justified by the much simpler code.
      
      Changes are compile-tested only.
      
      A little bit problematic seems to be to find somebody with the
      hardware to test the changes to the two PHY drivers. See also [0].
      David may be able to test the Rockchip driver.
      
      [0] https://marc.info/?t=153782508800006&r=1&w=2Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c5f626b
  8. 04 3月, 2019 1 次提交
  9. 15 2月, 2019 2 次提交
  10. 14 2月, 2019 1 次提交
  11. 07 2月, 2019 1 次提交
  12. 25 1月, 2019 4 次提交
  13. 23 1月, 2019 1 次提交
  14. 19 1月, 2019 3 次提交
  15. 17 1月, 2019 2 次提交
  16. 16 1月, 2019 1 次提交
  17. 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
  18. 06 12月, 2018 1 次提交
  19. 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
  20. 13 11月, 2018 1 次提交
  21. 12 11月, 2018 6 次提交
  22. 10 11月, 2018 1 次提交
  23. 09 11月, 2018 3 次提交