1. 10 Jan, 2018 37 commits
  2. 09 Jan, 2018 3 commits
    • David S. Miller's avatar
      Merge branch 'r8169-improve-runtime-pm' · 61ad6408
      David S. Miller authored
      Heiner Kallweit says:
      
      ====================
      r8169: improve runtime pm
      
      On my system with two network ports I found that runtime PM didn't
      suspend the unused port. Therefore I checked runtime pm in this driver
      in somewhat more detail and this series improves runtime pm in general
      and solves the mentioned issue.
      
      Tested on a system with RTL8168evl (MAC version 34).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61ad6408
    • Heiner Kallweit's avatar
      r8169: improve runtime pm in general and suspend unused ports · a92a0849
      Heiner Kallweit authored
      So far rpm doesn't cover cases like unused ports which are never
      brought up. If they are active at probe time they remain in this state.
      Included in this patch:
      
      - Let the idle notification check whether we can suspend and let it
        schedule the suspend. This way we don't need to have calls to
        pm_schedule_suspend in different places.
      
      - At the end of rtl_open and rtl_init_one send an idle notification
        to allow suspending if the link is down. If a cable is plugged in
        aneg is finished before the suspend timer expires and the suspend
        request is cancelled.
      
      - Change rtl8169_runtime_suspend to power down the chip if the
        interface is down.
      
      Successfully tested on a RTL8168evl (mac version 34).
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a92a0849
    • Heiner Kallweit's avatar
      r8169: improve runtime pm in rtl8169_check_link_status · ef4d5fcc
      Heiner Kallweit authored
      This patch partially reverts commit e4fbce74 "r8169: Fix runtime
      power management" from 2010. At that time the suspend delay was 100ms
      and therefore suspending happened during initial aneg. Currently
      suspend delay is 5s, so suspend starts after aneg and the issue
      doesn't exist any longer. On my system aneg takes almost 3s, to be on
      the safe side let's increase the suspend delay to 10s.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef4d5fcc