1. 02 Aug, 2017 9 commits
    • Vivien Didelot's avatar
      net: dsa: qca8k: empty qca8k_get_eee · 193da90e
      Vivien Didelot authored
      phy_ethtool_get_eee is already called by the DSA layer, thus remove the
      duplicated call in the qca8k driver.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      193da90e
    • Vivien Didelot's avatar
      net: dsa: qca8k: do not cache unneeded EEE fields · a2444ab8
      Vivien Didelot authored
      The qca8k driver is currently caching a bitfield of the supported member
      of a ethtool_eee private structure, which is unused.
      
      Only the eee_enabled field of the private ethtool_eee copy is updated,
      thus using p->advertised and p->lp_advertised is also erroneous.
      
      Remove the usage of these private ethtool_eee members and only rely on
      phy_ethtool_get_eee to assign the eee_active member.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2444ab8
    • Vivien Didelot's avatar
      net: dsa: qca8k: enable EEE once · dca20989
      Vivien Didelot authored
      If EEE is queried enabled, qca8k_set_eee calls qca8k_eee_enable_set
      twice (because it is already called in qca8k_eee_init). Fix that.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dca20989
    • Vivien Didelot's avatar
      net: dsa: qca8k: fix EEE init · 06d7b5c3
      Vivien Didelot authored
      The qca8k obviously copied code from the sf2 driver as how to set EEE:
      
          if (e->eee_enabled) {
              p->eee_enabled = qca8k_eee_init(ds, port, phydev);
              if (!p->eee_enabled)
                  ret = -EOPNOTSUPP;
          }
      
      But it did not use the same logic for the EEE init routine, which is
      "Returns 0 if EEE was not enabled, or 1 otherwise". This results in
      returning -EOPNOTSUPP on success and caching EEE enabled on failure.
      
      This patch fixes the returned value of qca8k_eee_init.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06d7b5c3
    • Vivien Didelot's avatar
      net: dsa: PHY device is mandatory for EEE · 7b9cc738
      Vivien Didelot authored
      The port's PHY and MAC are both implied in EEE. The current code does
      not call the PHY operations if the related device is NULL. Change that
      by returning -ENODEV if there's no PHY device attached to the interface.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b9cc738
    • David S. Miller's avatar
      Merge branch 'ravb-wol-magic-packet' · 13e6be2d
      David S. Miller authored
      Niklas Söderlund says:
      
      ====================
      ravb: add wake-on-lan support via magic packet
      
      WoL is enabled in the suspend callback by setting MagicPacket detection
      and disabling all interrupts expect MagicPacket. In the resume path the
      driver needs to reset the hardware to rearm the WoL logic, this prevents
      the driver from simply restoring the registers and to take advantage of
      that ravb was not suspended to reduce resume time. To reset the
      hardware the driver closes the device, sets it in reset mode and reopens
      the device just like it would do in a normal suspend/resume scenario
      without WoL enabled, but it both closes and opens the device in the
      resume callback since the device needs to be reset for WoL to work.
      
      One quirk needed for WoL is that the module clock needs to be prevented
      from being switched off by Runtime PM. To keep the clock alive the
      suspend callback need to call clk_enable() directly to increase the
      usage count of the clock. Then when Runtime PM decreases the clock usage
      count it won't reach 0 and be switched off.
      
      Changes since v2
      - Only do the clock dance to workaround PSCI sleep when resuming if WoL
        is enabled. This was a bug in v2 which resulted in a WARN if resuming
        from PSCI sleep with WoL disabled, thanks Sergei for pointing this
        out!
      - Break out clock dance workaround in separate patch to make it easier
        to revert once a fix is upstream for the clock driver as suggested by
        Sergei.
      
      Changes since v1
      - Fix issue where device would fail to resume from PSCI suspend if WoL
        was enabled, reported by Geert. The fault was that the clock driver
        thinks the clock is on, but PSCI have disabled it, added workaround
        for this in ravb driver which can be removed once the clock driver is
        aware of the PSCI behavior.
      - Only try to restore from wol wake up if netif is running, since this
        is a condition to enable wol in the first place this was a bug in v1.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13e6be2d
    • Niklas Söderlund's avatar
      ravb: add workaround for clock when resuming with WoL enabled · fbf3d034
      Niklas Söderlund authored
      The renesas-cpg-mssr clock driver are not yet aware of PSCI sleep where
      power is cut to the SoC. When resuming from this state with WoL enabled
      the enable count of the ravb clock is 1 and the clock driver thinks the
      clock is already on when PM core enables the clock and increments the
      enable count to 2. This will result in the ravb driver failing to talk
      to the hardware since the module clock is off. Work around this by
      forcing the enable count to 0 and then back to 2 when resuming with WoL
      enabled.
      
      This workaround should be reverted once the renesas-cpg-mssr clock
      driver becomes aware of this PSCI sleep behavior.
      Signed-off-by: default avatarNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbf3d034
    • Niklas Söderlund's avatar
      ravb: add wake-on-lan support via magic packet · 3e3d6477
      Niklas Söderlund authored
      WoL is enabled in the suspend callback by setting MagicPacket detection
      and disabling all interrupts expect MagicPacket. In the resume path the
      driver needs to reset the hardware to rearm the WoL logic, this prevents
      the driver from simply restoring the registers and to take advantage of
      that ravb was not suspended to reduce resume time. To reset the
      hardware the driver closes the device, sets it in reset mode and reopens
      the device just like it would do in a normal suspend/resume scenario
      without WoL enabled, but it both closes and opens the device in the
      resume callback since the device needs to be reset for WoL to work.
      
      One quirk needed for WoL is that the module clock needs to be prevented
      from being switched off by Runtime PM. To keep the clock alive the
      suspend callback need to call clk_enable() directly to increase the
      usage count of the clock. Then when Runtime PM decreases the clock usage
      count it won't reach 0 and be switched off.
      Signed-off-by: default avatarNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3e3d6477
    • David S. Miller's avatar
      Merge branch 'for-upstream' of... · 906a039d
      David S. Miller authored
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2017-08-01
      
      Here's our first batch of Bluetooth patches for the 4.14 kernel:
      
       - Several new USB IDs for the btusb driver
       - Memory leak fix in btusb driver
       - Cleanups & fixes to hci_nokia, hci_serdev and hci_bcm drivers
       - Fixed cleanup path in mrf24j40 (802.15.4) driver probe function
       - A few other smaller cleanups & fixes to drivers
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      906a039d
  2. 01 Aug, 2017 31 commits