1. 29 6月, 2019 1 次提交
  2. 29 4月, 2019 2 次提交
  3. 03 4月, 2019 1 次提交
  4. 22 3月, 2019 1 次提交
  5. 21 2月, 2019 1 次提交
  6. 14 2月, 2019 4 次提交
  7. 29 1月, 2019 2 次提交
    • J
      iwlwifi: pcie: align licensing to dual GPL/BSD · cefec29e
      Johannes Berg 提交于
      These files have a long history of code changes, but analysing
      the remaining code leads to having only a few changes that are
      not already owned by Intel, notably from
       - Andy Lutomirski <luto@amacapital.net>
       - Joonwoo Park <joonwpark81@gmail.com>
       - Kirtika Ruchandani <kirtika@chromium.org>
       - Rajat Jain <rajatja@google.com>
       - Stanislaw Gruszka <sgruszka@redhat.com>
      remaining in the code today.
      
      Note that
       - I myself was working for Intel and for any possibly code
         that might be before my employment there give permission
       - Wizery employees were working for Intel
      
      More specifically, we identified the following commits that
      (partially may) remain today:
      
      25c03d8e Joonwoo Park <joonwpark81@gmail.com>      ("iwlwifi: do not schedule tasklet when rcv unused irq")
      f36d04ab Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: use dma_alloc_coherent")
      387f3381 Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: fix dma mappings and skbs leak")
      2624e96c Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: fix possible data overwrite in hcmd callback")
      bfe4b80e Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: always check if got h/w access before write")
      d536c32b Andy Lutomirski <luto@amacapital.net>     ("iwlwifi: pcie: log when waking the NIC for hcmd submission fails")
      a6d24fad Rajat Jain <rajatja@google.com>           ("iwlwifi: pcie: dump registers when HW becomes inaccessible")
      fb12777a Kirtika Ruchandani <kirtika@chromium.org> ("iwlwifi: Add more call-sites for pcie reg dumper")
      3a73a300 Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: cleanup/fix memory barriers")
      aa5affba Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: dump stack when fail to gain access to the device")
      
      Align the licenses with their permission to clean up and to
      make it all identical.
      
      CC: Joonwoo Park <joonwpark81@gmail.com>
      CC: Stanislaw Gruszka <sgruszka@redhat.com>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Rajat Jain <rajatja@google.com>
      CC: Kirtika Ruchandani <kirtika@chromium.org>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NKirtika Ruchandani <kirtika@chromium.org>
      Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NJoonwoo Park <joonwpark81@gmail.com>
      Acked-by: NRajat Jain <rajatja@google.com>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      cefec29e
    • S
      iwlwifi: pcie: add prints to track virtual ID · 85d78bb1
      Sara Sharon 提交于
      In case there are bugs in this area, this data can
      help with debugging.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      85d78bb1
  8. 26 1月, 2019 1 次提交
  9. 08 1月, 2019 1 次提交
  10. 06 10月, 2018 1 次提交
    • S
      iwlwifi: pcie: avoid empty free RB queue · 868a1e86
      Shaul Triebitz 提交于
      If all free RB queues are empty, the driver will never restock the
      free RB queue.  That's because the restocking happens in the Rx flow,
      and if the free queue is empty there will be no Rx.
      
      Although there's a background worker (a.k.a. allocator) allocating
      memory for RBs so that the Rx handler can restock them, the worker may
      run only after the free queue has become empty (and then it is too
      late for restocking as explained above).
      
      There is a solution for that called 'emergency': If the number of used
      RB's reaches half the amount of all RB's, the Rx handler will not wait
      for the allocator but immediately allocate memory for the used RB's
      and restock the free queue.
      
      But, since the used RB's is per queue, it may happen that the used
      RB's are spread between the queues such that the emergency check will
      fail for each of the queues
      (and still run out of RBs, causing the above symptom).
      
      To fix it, move to emergency mode if the sum of *all* used RBs (for
      all Rx queues) reaches half the amount of all RB's
      Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      868a1e86
  11. 31 8月, 2018 5 次提交
  12. 02 8月, 2018 4 次提交
  13. 26 7月, 2018 4 次提交
  14. 30 5月, 2018 1 次提交
  15. 26 4月, 2018 1 次提交
  16. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  17. 24 8月, 2017 1 次提交
    • L
      iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc() · 10a54d81
      Luca Coelho 提交于
      Work queues cannot be allocated when a mutex is held because the mutex
      may be in use and that would make it sleep.  Doing so generates the
      following splat with 4.13+:
      
      [   19.513298] ======================================================
      [   19.513429] WARNING: possible circular locking dependency detected
      [   19.513557] 4.13.0-rc5+ #6 Not tainted
      [   19.513638] ------------------------------------------------------
      [   19.513767] cpuhp/0/12 is trying to acquire lock:
      [   19.513867]  (&tz->lock){+.+.+.}, at: [<ffffffff924afebb>] thermal_zone_get_temp+0x5b/0xb0
      [   19.514047]
      [   19.514047] but task is already holding lock:
      [   19.514166]  (cpuhp_state){+.+.+.}, at: [<ffffffff91cc4baa>] cpuhp_thread_fun+0x3a/0x210
      [   19.514338]
      [   19.514338] which lock already depends on the new lock.
      
      This lock dependency already existed with previous kernel versions,
      but it was not detected until commit 49dfe2a6 ("cpuhotplug: Link
      lock stacks for hotplug callbacks") was introduced.
      Reported-by: NDavid Weinehall <david.weinehall@intel.com>
      Reported-by: NJiri Kosina <jikos@kernel.org>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      10a54d81
  18. 18 8月, 2017 1 次提交
  19. 30 6月, 2017 1 次提交
  20. 29 6月, 2017 3 次提交
  21. 23 6月, 2017 3 次提交