Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 26 11月, 2013 2 次提交
  3. 09 8月, 2013 2 次提交
  5. 06 8月, 2013 1 次提交
  7. 26 7月, 2013 1 次提交
  9. 16 7月, 2013 1 次提交
  11. 25 6月, 2013 2 次提交
    • J
      iwlwifi: always use 'rxq' as RX queue struct name · fecba09e
      由 Johannes Berg 提交于 
      A few places use just 'q', use 'rxq' there like all
other places.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fecba09e
    • J
      iwlwifi: pcie: rework RX buffer list init and freeing · c7df1f4b
      由 Johannes Berg 提交于 
      The PCIe code has an array of buffer descriptors (RXBs) that have pages
and DMA mappings attached. In regular use, the array isn't used and the
buffers are either on the hardware receive queue or the rx_free/rx_used
lists for recycling.

Occasionally, during module unload, we'd see a warning from this:

WARNING: at lib/list_debug.c:32 __list_add+0x91/0xa0()
list_add corruption. prev->next should be next (c31c98cc), but was c31c80bc. (prev=c31c80bc).
Pid: 519, comm: rmmod Tainted: G        W  O 3.4.24-dev #3
Call Trace:
 [<c10335b2>] warn_slowpath_common+0x72/0xa0
 [<c1033683>] warn_slowpath_fmt+0x33/0x40
 [<c12e31d1>] __list_add+0x91/0xa0
 [<fdf2083c>] iwl_pcie_rxq_free_rbs+0xcc/0xe0 [iwlwifi]
 [<fdf21b3f>] iwl_pcie_rx_free+0x3f/0x210 [iwlwifi]
 [<fdf2dd7a>] iwl_trans_pcie_free+0x2a/0x90 [iwlwifi]

The reason for this seems to be that in iwl_pcie_rxq_free_rbs() we use
the array to free all buffers (the hardware receive queue isn't in use
any more at this point). The function also adds all buffers to rx_used
because it's also used during initialisation (when no freeing happens.)
This can cause the warning because it may add entries to the list that
are already on it. Luckily, this is harmless because it can only happen
when the entire data structure is freed anyway, since during init both
lists are initialized from scratch.

Disentangle this code and treat init and free separately. During init
we just need to put them onto the list after freeing all buffers (for
switching between 4k/8k buffers); during free no list manipulations
are necessary at all.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c7df1f4b
  13. 13 6月, 2013 2 次提交
  15. 28 2月, 2013 1 次提交
    • J
      iwlwifi: use coherent DMA memory for command header · 38c0f334
      由 Johannes Berg 提交于 
      Recently in commit 8a964f44
("iwlwifi: always copy first 16 bytes of commands") we fixed
the problem that the hardware writes back to the command and
that could overwrite parts of the data that was still needed
and would thus be corrupted.

Investigating this problem more closely we found that this
write-back isn't really ordered very well with respect to
other DMA traffic. Therefore, it sometimes happened that the
write-back occurred after unmapping the command again which
is clearly an issue and could corrupt the next allocation
that goes to that spot, or (better) cause IOMMU faults.

To fix this, allocate coherent memory for the first 16 bytes
of each command, containing the write-back part, and use it
for all queues. All the dynamic DMA mappings only need to be
TO_DEVICE then. This ensures that even when the write-back
happens "too late" it can't hit memory that has been freed
or a mapping that doesn't exist any more.

Since now the actual command is no longer modified, we can
also remove CMD_WANT_HCMD and get rid of the DMA sync that
was necessary to update the scratch pointer.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      38c0f334
  17. 05 2月, 2013 1 次提交
    • J
      iwlwifi: use threaded interrupt handler · 2bfb5092
      由 Johannes Berg 提交于 
      With new transports coming up, move to threaded
interrupt handling now. This has the advantage
that we can use the same locking scheme with all
different transports we may need to implement.

Note that the TX path obviously still runs in a
tasklet, so some spin_lock() calls need to change
to spin_lock_bh() calls to properly lock out the
TX path.

In my test on a Calpella platform this has no
impact on throughput or latency.

Also add lockdep annotations to avoid lockups due
to catch sending synchronous commands or using
locks that connect with them from the irq thread.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2bfb5092
  19. 24 1月, 2013 2 次提交
  21. 16 1月, 2013 2 次提交
  23. 03 1月, 2013 2 次提交
  25. 11 12月, 2012 1 次提交
    • E
      iwlwifi: don't handle masked interrupt · 25a17265
      由 Emmanuel Grumbach 提交于 
      This can lead to a panic if the driver isn't ready to
handle them. Since our interrupt line is shared, we can get
an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks
that even when the interrupt is being freed).

If the op_mode has gone away, we musn't call it. To avoid
this the transport disables the interrupts when the hw is
stopped and the op_mode is leaving.
If there is an event that would cause an interrupt the INTA
register is updated regardless of the enablement of the
interrupts: even if the interrupts are disabled, the INTA
will be changed, but the device won't issue an interrupt.
But the ISR can be called at any time, so we ought ignore
the value in the INTA otherwise we can call the op_mode
after it was freed.

I found this bug when the op_mode_start failed, and called
iwl_trans_stop_hw(trans, true). Then I played with the
RFKILL button, and removed the module.
While removing the module, the IRQ is freed, and the ISR is
called (CONFIG_DEBUG_SHIRQ enabled). Panic.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      25a17265
  27. 28 11月, 2012 1 次提交
  29. 19 11月, 2012 4 次提交
  31. 10 11月, 2012 1 次提交
  33. 05 11月, 2012 2 次提交
  35. 01 11月, 2012 1 次提交
    • E
      iwlwifi: handle RFKILL logic in the transport layer · f946b529
      由 Emmanuel Grumbach 提交于 
      No HCMD can be sent while RFKILL is asserted. If a SYNC
command is running while RFKILL is asserted the fw will
silently discard it. This means that the driver needs to
wake the process that sleeps on the CMD_SYNC.

Since the RFKILL interrupt is handled in the transport layer
and the code that sleeps in CMD_SYNC is also in the transport
layer, all this logic can be handled there.
This simplifies the work of the op_mode.

So the transport layer will now return -ERFKILL when a CMD
is sent and RFKILL is asserted. This will be the case even
when the CMD is SYNC. The transport layer will return
-ERFKILL straight away.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f946b529
  37. 29 10月, 2012 1 次提交
  39. 16 10月, 2012 1 次提交
    • J
      iwlwifi: make data frame tracing optional · f042c2eb
      由 Johannes Berg 提交于 
      When tracing in iwlwifi, we get all data. Most of
the time, we don't need it, and it just takes up
a lot of extra space in the trace.

Make this optional by recording the data into two
separate trace events if it is needed. Without it,
record only the content of non-data and EAPOL TX
frames.

As a result, tracing without the data tracepoints
will record meta information including the 802.11
headers for all frames but will not record the
contents of data frames to reduce trace overhead.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f042c2eb
  41. 11 9月, 2012 2 次提交
    • E
      iwlwifi: don't access the HW when it is not available · 7439046d
      由 Emmanuel Grumbach 提交于 
      When we kill the radio with the RF kill button we could access
the HW after having stopped the APM which would result in the
warning below.

The flow goes like this:
* RF kill
	iwlwifi notifies the stack which stops the driver
	fw sends CARD_STATE_NOTIFICATION
* iwl_trans_pcie_stop_device stops the APM
* the tasklet runs and calls to iwl_rx_handle
* iwl_rx_handle calls iwl_rx_queue_restock
* iwl_rx_queue_restock tries to access the HW...

[255908.543823] ------------[ cut here ]------------
[255908.543843] WARNING: at drivers/net/wireless/iwlwifi/iwl-io.c:150 iwl_grab_nic_access+0x79/0xb0 [iwlwifi]()
[255908.543849] Hardware name: Latitude E6410
[255908.543852] Timeout waiting for hardware access (CSR_GP_CNTRL 0x000003d8)
[255908.543856] Modules linked in: iwlmvm iwlwifi mac80211 [...]
[255908.543935] Pid: 0, comm: swapper Tainted: G        W   3.1.0 #1
[255908.543939] Call Trace:
[255908.543950]  [<c1046e42>] warn_slowpath_common+0x72/0xa0
[255908.543980]  [<c1046f13>] warn_slowpath_fmt+0x33/0x40
[255908.543992]  [<fa4bb3b9>] iwl_grab_nic_access+0x79/0xb0 [iwlwifi]
[255908.544004]  [<fa4bb9eb>] iwl_write_direct32+0x2b/0xa0 [iwlwifi]
[255908.544018]  [<fa4c0ff9>] iwl_rx_queue_update_write_ptr+0x89/0x1d0 [iwlwifi]
[255908.544054]  [<fa4c1250>] iwlagn_rx_queue_restock+0x110/0x140 [iwlwifi]
[255908.544067]  [<fa4c234d>] iwl_irq_tasklet+0x82d/0xf40 [iwlwifi]
[255908.544096]  [<c104e11e>] tasklet_action+0xbe/0x100
[255908.544102]  [<c104d91e>] __do_softirq+0xae/0x1f0
[255908.544227] ---[ end trace d150f49345d85009 ]---

Prevent this.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7439046d
    • E
      iwlwifi: some clean up in transport layer · 358a46d4
      由 Emmanuel Grumbach 提交于 
      Remove outdated iwlagn prefix to a few functions and fix comments
that were not accurate.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      358a46d4
  43. 06 9月, 2012 1 次提交
  45. 22 8月, 2012 1 次提交
  47. 26 7月, 2012 1 次提交
    • E
      iwlwifi: get the correct HCMD in the response handler · 96791422
      由 Emmanuel Grumbach 提交于 
      Until now, the response handler of a Host Command got the
exact same pointer that was also given to the DMA engine.
We almost never need to the Host Command that was sent while
handling its response, but when we do need it, we see that
the command has been modified.

This mystery has been elucidated. The FH (our DMA engine)
writes its meta data on the buffer in the DRAM. Of course it
copies the buffer to the NIC first. This was known to happen
for Tx command, but as a matter of fact, it happens to all
TFD brought by the FH which doesn't care much about what it
brings from DRAM to internal SRAM.

So copy the Host Command to yet another buffer so that we
can properly pass the buffer that was sent originally to the
fw. Do that only if it was request by the user since very
few flows need to get the HCMD sent in the response handler.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      96791422
  49. 03 7月, 2012 1 次提交
  51. 18 6月, 2012 1 次提交
  53. 06 6月, 2012 2 次提交