1. 22 3月, 2019 2 次提交
  2. 14 2月, 2019 1 次提交
  3. 04 2月, 2019 3 次提交
  4. 23 11月, 2018 6 次提交
  5. 11 11月, 2018 1 次提交
  6. 06 10月, 2018 1 次提交
  7. 28 9月, 2018 1 次提交
  8. 31 8月, 2018 4 次提交
  9. 02 8月, 2018 2 次提交
  10. 26 7月, 2018 1 次提交
  11. 26 4月, 2018 1 次提交
  12. 20 4月, 2018 1 次提交
  13. 21 12月, 2017 2 次提交
  14. 05 12月, 2017 1 次提交
  15. 28 11月, 2017 1 次提交
  16. 03 11月, 2017 3 次提交
  17. 06 10月, 2017 2 次提交
  18. 01 8月, 2017 1 次提交
  19. 29 6月, 2017 1 次提交
  20. 23 6月, 2017 2 次提交
    • E
      iwlwifi: add a W/A for a scheduler hardware bug · dcfbd67b
      Emmanuel Grumbach 提交于
      In case we need to move the scheduler write pointer by
      steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck.
      This leads to hardware error interrupts with status:
      0x5A5A5A5A or alike.
      
      In order to work around this, detect in the transport
      layer that we are going to hit this case and tell iwlmvm
      to increment the sequence number of the packets. This
      allows to keep the requirement that the WiFi sequence
      number is in sync with the index in the scheduler Tx queue
      and it also allows to avoid the problematic sequence.
      This means that from time to time, we will start a queue
      from ssn + 1, but that shouldn't be a problem since we
      don't switch to new queues for AMPDU now that we have
      DQA which allows to keep the same queue while toggling
      the AMPDU state.
      
      This bug has been fixed on 9000 devices and up.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      dcfbd67b
    • J
      iwlwifi: pcie: don't report RF-kill enabled while shutting down · 326477e4
      Johannes Berg 提交于
      When toggling the RF-kill pin quickly in succession, the driver can
      get rather confused because it might be in the process of shutting
      down, expecting all commands to go through quickly due to rfkill,
      but the transport already thinks the device is accessible again,
      even though it previously shut it down. This leads to bugs, and I
      even observed a kernel panic.
      
      Avoid this by making the PCIe code only report that the radio is
      enabled again after the higher layers actually decided to shut it
      off.
      
      This also pulls out this common RF-kill checking code into a common
      function called by both transport generations and also moves it to
      the direct method - in the internal helper we don't really care
      about the RF-kill status anymore since we won't report it up until
      the stop anyway.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      326477e4
  21. 06 6月, 2017 3 次提交