1. 28 2月, 2016 8 次提交
  2. 01 2月, 2016 4 次提交
  3. 21 12月, 2015 4 次提交
  4. 20 12月, 2015 2 次提交
  5. 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
  6. 13 12月, 2015 3 次提交
  7. 07 12月, 2015 1 次提交
  8. 02 12月, 2015 3 次提交
  9. 26 11月, 2015 4 次提交
  10. 18 11月, 2015 1 次提交
  11. 13 10月, 2015 1 次提交
    • A
      cfg80211: Add multiple scan plans for scheduled scan · 3b06d277
      Avraham Stern 提交于
      Add the option to configure multiple 'scan plans' for scheduled scan.
      Each 'scan plan' defines the number of scan cycles and the interval
      between scans. The scan plans are executed in the order they were
      configured. The last scan plan will always run infinitely and thus
      defines only the interval between scans.
      The maximum number of scan plans supported by the device and the
      maximum number of iterations in a single scan plan are advertised
      to userspace so it can configure the scan plans appropriately.
      
      When scheduled scan results are received there is no way to know which
      scan plan is being currently executed, so there is no way to know when
      the next scan iteration will start. This is not a problem, however.
      The scan start timestamp is only used for flushing old scan results,
      and there is no difference between flushing all results received until
      the end of the previous iteration or the start of the current one,
      since no results will be received in between.
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3b06d277
  12. 05 10月, 2015 5 次提交
  13. 21 9月, 2015 2 次提交
  14. 28 8月, 2015 1 次提交