1. 30 3月, 2016 7 次提交
  2. 20 3月, 2016 1 次提交
  3. 10 3月, 2016 1 次提交
  4. 07 3月, 2016 1 次提交
    • E
      iwlwifi: mvm: avoid panics with thermal device usage · 91f66a3c
      Emmanuel Grumbach 提交于
      Thermal zone device registration can fail, and in this case
      we don't want to remove WiFi functionality. This is why the
      thermal zone registration function is void, and the flows
      continue even if the thermal zone device registration failed.
      Same applies for the cooling device.
      
      This means that we at least need to remember that the thermal
      zone device didn't register properly and take the minimal
      precautions to avoid panic'ing when we access it.
      
      This was missing.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      91f66a3c
  5. 02 3月, 2016 3 次提交
  6. 28 2月, 2016 9 次提交
  7. 24 2月, 2016 1 次提交
  8. 01 2月, 2016 8 次提交
  9. 08 1月, 2016 2 次提交
  10. 21 12月, 2015 4 次提交
  11. 20 12月, 2015 1 次提交
  12. 16 12月, 2015 1 次提交
    • S
      iwlwifi: mvm: change protocol offload flows · c97dab40
      Sara Sharon 提交于
      RFC4862 states that "In all cases, a node MUST NOT respond to
      a Neighbor Solicitation for a tentative address".
      Currently the driver configures the NS offload and does not wait
      for address to become permanent, thus violating the RFC.
      Just removing the address from the address list is not good enough
      for all cases, since the NS messages are needed for the duplicate
      address detection and should not be discarded.
      
      For d0i3 disable NS offload. Put tentative address in the address
      list so the NS packet will not be filtered out by ucode.
      For D3 the platform will not wake from NS packets - so enable
      NS offload while removing the tentative address from the list.
      
      Given that now NS offload might be disabled, and that the ucode
      uses the IP data for other puroposes (L3 filtering) add two
      independent flags indicating if IPv4\IPv6 data is valid.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      c97dab40
  13. 13 12月, 2015 1 次提交
    • L
      iwlwifi: replace d0i3_mode and wowlan_d0i3 with more generic variables · b7282643
      Luca Coelho 提交于
      The d0i3_mode variable is used to distinguish between transports that
      handle d0i3 entry during suspend by themselves (i.e. the slave
      transports) and those which rely on the op_mode layer to do it.  The
      reason why the former do it by themselves is that they need to
      transition from d0i3 in runtime_suspend into d0i3 in system-wide
      suspend and this transition needs to happen before the op_mode's
      suspend flow is called.
      
      The wowlan_d0i3 element is also a bit confusing, because it just
      reflects the wowlan->any value for the trans to understand.  This is a
      bit unclear in the code and not generic enough for future use.
      
      To make it clearer and to generalize the platform power mode settings,
      introduce two variables to indicate the platform power management
      modes used by the transport.
      
      Additionally, in order not to take too big a step in one patch, treat
      this new variables semantically in the same way as the old d0i3_mode
      element, introducing a iwl_mvm_enter_d0i3_on_suspend() function to
      help with that.
      
      This commit also adds the foundation for a new concept where the
      firmware configuration state (i.e. D0, D3 or D0i3) is abstracted from
      the platform PM mode we are in (i.e. runtime suspend or system-wide
      suspend).
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      b7282643