- 10 Dec, 2012 3 commits
-
-
Emmanuel Grumbach authored
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:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
We know that we have issues with the fw in the reclaim path. This is why iwl_reclaim doesn't complain too loud when it happens since it is recoverable. Somehow, the caller of iwl_reclaim however WARNed when it happens. This doesn't make any sense. When I digged into the history of that code, I discovered that this bug occurs only when we receive a BA notification. So move the W/A in the BA notification handling code where it was before. This patch addresses: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387 Cc: stable@vger.kernel.org Reported-by:
Florian Reitmeir <florian@reitmeir.org> Signed-off-by:
-
Tim Gardner authored
The WARN_ON_ONCE() check for scan_request will not correctly detect a NULL pointer for scan_type == IWL_SCAN_NORMAL. Make it explicit that the check only applies to normal scans. Convert WARN_ON_ONCE to WARN_ON since priv->scan_request really _can't_ be NULL for normal scans. If it is then we should emit frequent warnings. This smatch warning led to scrutiny of iwlagn_request_scan(): drivers/net/wireless/iwlwifi/dvm/scan.c:894 iwlagn_request_scan() error: we previously assumed 'priv->scan_request' could be null (see line 792) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Reviewed-by:
-
- 07 Dec, 2012 1 commit
-
-
Johannes Berg authored
By using a few temporary variables, smatch can track what's happening and stops complaining that we access beyond the tid_data array. This also makes the generated code a bit smaller, so it's a win all around. Reviewed-by:
-
- 06 Dec, 2012 3 commits
-
-
Emmanuel Grumbach authored
Since the device is taken down in stop_hw, call reset_ict from there too. Signed-off-by:
-
Emmanuel Grumbach authored
New transports may handle it internally for better performance. Also move the tracing inside PRPH access which will make the output more readable: iwlwifi_dev_ioread_prph32: Read 0x0 from SCD_AGGR_SEL (32-bit) instead of the corresponding accesses to HBUS_TARG_PRPH_*. Signed-off-by:
-
Eytan Lifshitz authored
Since we will have several forms of NVM (EEPROM, OTP, etc.) and they will have different layouts, make the parsed data more generic. This allows functional code to be independent of a specific layout. Also change some variables and function names from having "eeprom" to "nvm" in their name. Signed-off-by:
Eytan Lifshitz <eytan.lifshitz@intel.com> Reviewed-by:
-
- 29 Nov, 2012 1 commit
-
-
Emmanuel Grumbach authored
Don't return a hard coded -EFAULT, but rather the error that occurred in the flow. Signed-off-by:
-
- 28 Nov, 2012 2 commits
-
-
Emmanuel Grumbach authored
Since the op_mode is leaving, the transport should set its pointer to it to NULL to not point to freed memory. Signed-off-by:
-
Emmanuel Grumbach authored
The FH (DMA engine) tells the driver the index of the last ready (closed) Rx buffer. This data is in closed_rb_num. If we read this data several times we may get inconsistencies between the code and the debug prints which can make it harder to debug issues here. Signed-off-by:
-
- 21 Nov, 2012 1 commit
-
-
Emmanuel Grumbach authored
Signed-off-by:
-
- 19 Nov, 2012 13 commits
-
-
Sachin Kamat authored
iwl-trans.h was included twice. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Emmanuel Grumbach authored
This will allow to reduce slightly the number of interrupts without sacrificing too much the latency in the Rx path. Signed-off-by:
-
Emmanuel Grumbach authored
It is not used outside pcie/rx.c. Signed-off-by:
-
Emmanuel Grumbach authored
Really trivial clean up. Signed-off-by:
-
Emmanuel Grumbach authored
Also, prefer the if(!X) notation over if(X == 0). Signed-off-by:
-
Johannes Berg authored
When software crypto is enabled, it isn't safe to enable MFP since the firmware interprets some management packets, and with MFP it would do so without proper validation. Reviewed-by:
Assaf Krauss <assaf.krauss@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
One one just a wrapper of the second, squash them. Signed-off-by:
-
Emmanuel Grumbach authored
Rename static functions. Function moved from trans.c to tx.c. A few could be made static, others had to be exported. Functions that implement the transport API are prefixed by iwl_trans_pcie_, the others by iwl_pcie_. Signed-off-by:
-
Emmanuel Grumbach authored
Functions that implement the transport API are prefixed by iwl_trans_pcie_, the others by iwl_pcie_. Signed-off-by:
-
Emmanuel Grumbach authored
Rename static functions. Function moved from trans.c to rx.c. A few could be made static, others had to be exported. Also, don't use rxb or rxbuf, but rb which stands for receive buffer. Signed-off-by:
-
Emmanuel Grumbach authored
This is its natural place Signed-off-by:
-
Emmanuel Grumbach authored
1) s/tx_queue/txq for the sake of consistency. 2) s/rx_queue/rxq for the sake of consistency. 3) Make all functions begin with iwl_pcie_ iwl_queue_init and iwl_queue_space are an exception since they are not PCIE specific although they are in pcie subdir. 4) s/trans_pcie_get_cmd_string/get_cmd_string it is much shorter and used in debug prints which are long lines. 5) s/iwl_bg_rx_replenish/iwl_pcie_rx_replenish_work this better emphasizes that it is a work 6) remove invalid kernelDOC markers pcie/tx.c and pcie/trans.c still needs to be cleaned up. Signed-off-by:
-
Emmanuel Grumbach authored
Signed-off-by:
-
- 14 Nov, 2012 2 commits
-
-
Emmanuel Grumbach authored
This is not needed, the comment there was wrong, it is only needed when MSI was *not* enabled. Signed-off-by:
-
Emmanuel Grumbach authored
The allocation failure will already be very verbose. Signed-off-by:
-
- 09 Nov, 2012 1 commit
-
-
Johannes Berg authored
When a firmware error occurs, don't just abort synchronous commands but also return an error (-EIO) and block any new commands as well. Currently, an error is only returned if WANT_SKB was set which is confusing and can lead to issues. Blocking is done until a new firmware image is loaded. Reviewed-by:
-
- 07 Nov, 2012 4 commits
-
-
Johannes Berg authored
The printk message should say RX, not TX. Reviewed-by:
-
Johannes Berg authored
There's no need to print the PCI resource length and base address, nor the hardware revision ID (which can be found in lspci) Reviewed-by:
-
Johannes Berg authored
There's no reason to print these all the time, the messages aren't all that interesting. Leave them as DEBUG_INFO though, just in case. Reviewed-by:
-
Johannes Berg authored
If the EEPROM reading was successful, don't print a message by default, the EEPROM version isn't all that interesting. Change the message to DEBUG_INFO priority so it can still be obtained. Reviewed-by:
-
- 05 Nov, 2012 6 commits
-
-
Emmanuel Grumbach authored
People tend not to set the fields they want to leave as 0. So make sure the struct is zeroed properly. Signed-off-by:
-
Emmanuel Grumbach authored
The ALIVE response of new fw inclues the base address of the SCD in SRAM. Until we read it from a prph register, which was set by the fw. Since the fw might well stop updating the prph register, add a WARN when there is an inconsitency between the ALIVE response and the register to catch any change in the behavior. Reviewed-by:
-
Johannes Berg authored
Instead of open-coding it with a temporary list_head pointer, just use list_first_entry. Reviewed-by:
-
Johannes Berg authored
The flush_control parameter to iwlagn_txfifo_flush is passed as an internal value (context flags) and then sent to the device, that can't be right. Fix the confusion by removing the parameter, always use IWL_DROP_ALL that is redefined according to the firmware API in the flush control. Signed-off-by:
-
Johannes Berg authored
There's no reason to clear the CTL_AMPDU flag on transmitted frame status, it's not used by the driver here and mac80211 only uses it for some rate statistics. Also remove a stray space in the function. Reviewed-by:
-
Johannes Berg authored
The flush command really flushes queues, not FIFOs, and the first 32 bits indicate the queues to flush, not FIFOs. Change the command accordingly. Reviewed-by:
-
- 31 Oct, 2012 2 commits
-
-
Emmanuel Grumbach authored
When we unregister from mac80211 it will down the device anyway. Signed-off-by:
-
Emmanuel Grumbach authored
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:
-
- 29 Oct, 2012 1 commit
-
-
Johannes Berg authored
Clarify the documentation to indicate that these flags can only be used at the end, i.e. after them a copy TFD (no flags set) is invalid. Reported-by:
Inbal Hacohen <inbal.hacohen@intel.com> Reviewed-by:
-
