- 06 9月, 2019 8 次提交
-
-
由 Emmanuel Grumbach 提交于
CMD_SEND_IN_IDLE, CMD_MAKE_TRANS_IDLE and CMD_WAKE_UP_TRANS are not used. Remove them. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
This code is now stale Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
Remove the now unneeded functions that called those from the transport layer. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
This is always set to IWL_PLAT_PM_MODE_DISABLED Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Alex Malamud 提交于
During D3 state, FW may send packets. As a result, "write" queue pointer will be incremented by FW. Upon resume from D3, driver should adjust its shadows of "write" and "read" pointers to the value reported by FW. 1. Keep TID used during wowlan configuration. 2. Upon resume, set driver's "write" and "read" queue pointers to the value reported by FW. Signed-off-by: NAlex Malamud <alex.malamud@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
This flag should never be set unless integration work with the platform is done. We don't support any platforms officially and don't plan to do so in the near future, so we can remove this option entirely in order to avoid having it enabled by mistake. This has been marked with "depends on EXPERT", so there shouldn't be many systems running with it set. And, if there are systems, they should not be using this flag. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
This is set but never read. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shahar S Matityahu 提交于
The op mode should stop the debug recording and not the transport layer. Rename iwl_fwrt_stop_device into iwl_fw_dbg_stop_sync and move the debug stop recording to it. Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 29 8月, 2019 1 次提交
-
-
由 Luca Coelho 提交于
We need to use a different firmware for C0 versions of killer Qu NICs. Add structures for them and handle them in the if block that detects C0 revisions. Additionally, instead of having an inclusive check for QnJ devices, make the selection exclusive, so that switching to QnJ is the exception, not the default. This prevents us from having to add all the non-QnJ cards to an exclusion list. To do so, only go into the QnJ block if the device has an RF ID type HR and HW revision QnJ. Cc: stable@vger.kernel.org # 5.2 Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190821171732.2266-1-luca@coelho.fiSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 20 8月, 2019 3 次提交
-
-
由 Luca Coelho 提交于
If the HW revision of Qu devices we found is QuZ, then we need to switch the configuration accordingly in order to use the correct FW. Add a block of ifs in order do that. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Luca Coelho 提交于
We have a too generic condition that switches from Qu configurations to QnJ configurations. We need to exclude some configurations so that they are not erroneously switched. Add the ax201 configuration to the list of exclusions. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Emmanuel Grumbach 提交于
Starting from 22560, the byte count is expected to be in bytes and we have now 14 bits. Ajust the code to this. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 31 7月, 2019 2 次提交
-
-
由 Emmanuel Grumbach 提交于
In order to remember how to unmap a memory (as single or as page), we maintain a bit per Transmit Buffer (TBs) in the meta data (structure iwl_cmd_meta). We maintain a bitmap: 1 bit per TB. If the TB is set, we will free the memory as a page. This bitmap was never cleared. Fix this. Cc: stable@vger.kernel.org Fixes: 3cd1980b ("iwlwifi: pcie: introduce new tfd and tb formats") Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ihab Zhaika 提交于
Add a few PCI ID'S for 9000 series. Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 7月, 2019 2 次提交
-
-
由 Luca Coelho 提交于
Add support for C-step devices. Currently we don't have a nice way of matching the step and choosing the proper configuration, so we need to switch the config structs one by one. Cc: stable@vger.kernel.org Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ihab Zhaika 提交于
add two new PCI ID's for 9000 and 20000 series Cc: stable@vger.kernel.org Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 29 6月, 2019 8 次提交
-
-
由 Emmanuel Grumbach 提交于
Sometimes the register status can include interrupts that were masked. We can, for example, get the RF-Kill bit set in the interrupt status register although this interrupt was masked. Then if we get the ALIVE interrupt (for example) that was not masked, we need to *not* service the RF-Kill interrupt. Fix this in the MSI-X interrupt handler. Cc: stable@vger.kernel.org Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
Newest devices have a new firmware load mechanism. This mechanism is called the context info. It means that the driver doesn't need to load the sections of the firmware. The driver rather prepares a place in DRAM, with pointers to the relevant sections of the firmware, and the firmware loads itself. At the end of the process, the firmware sends the ALIVE interrupt. This is different from the previous scheme in which the driver expected the FH_TX interrupt after each section being transferred over the DMA. In order to support this new flow, we enabled all the interrupts. This broke the assumption that we have in the code that the RF-Kill interrupt can't interrupt the firmware load flow. Change the context info flow to enable only the ALIVE interrupt, and re-enable all the other interrupts only after the firmware is alive. Then, we won't see the RF-Kill interrupt until then. Getting the RF-Kill interrupt while loading the firmware made us kill the firmware while it is loading and we ended up dumping garbage instead of the firmware state. Re-enable the ALIVE | RX interrupts from the ISR when we get the ALIVE interrupt to be able to get the RX interrupt that comes immediately afterwards for the ALIVE notification. This is needed for non MSI-X only. Cc: stable@vger.kernel.org Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Emmanuel Grumbach 提交于
We added code to restock the buffer upon ALIVE interrupt when MSI-X is disabled. This was added as part of the context info code. This code was added only if the ISR debug level is set which is very unlikely to be related. Move this code to run even when the ISR debug level is not set. Note that gen2 devices work with MSI-X in most cases so that this path is seldom used. Cc: stable@vger.kernel.org Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shahar S Matityahu 提交于
The 0xF6 command used to start and stop the recording from 22560 devices was removed. This is causing an assert when the driver tries to alter the recording state. Remove the use of the command. Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shahar S Matityahu 提交于
Unite iwl_trans debug related fields under iwl_trans_debug struct to increase readability and keep iwl_trans clean. Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shahar S Matityahu 提交于
There are several flows where the driver checks if it runs in ini mode. Some of these flows are no longer used in ini mode or there is another condition that check the ini mode in the same flow. Either way, those conditions are redundant. Remove the redundant conditions. Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Luca Coelho 提交于
Currently we dump only the first 64 bytes of the PCI config space, which leaves out some important things, such as the base address registers. Increase it to 352 for the PCI device and to 524 for the rootport to make sure we include everything we need. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shahar S Matityahu 提交于
Improve the robustness of the dump collection flow in case of an early error: 1. in iwl_trans_pcie_sync_nmi, disable and enable interrupts only if they were already enabled 2. attempt to initiate dump collection in iwl_fw_dbg_error_collect only if the device is enabled 3. check Tx command queue was already allocated before trying to collect it Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 24 6月, 2019 4 次提交
-
-
由 Oren Givon 提交于
The 22000 series FW that was meant to be used with hr is also the FW that is used for hr1 and has a different RF ID. Add support to load the hr FW when hr1 RF ID is detected. Cc: stable@vger.kernel.org # 5.1+ Signed-off-by: NOren Givon <oren.givon@intel.com> Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ihab Zhaika 提交于
change the fw of 0x02F0 platform from qu to quz Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ihab Zhaika 提交于
add few PCI ID'S for 22000 and chainge few cards structs names Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ihab Zhaika 提交于
add few PCI ID'S for 22000 and fix the wrong name for one of the structs Signed-off-by: NIhab Zhaika <ihab.zhaika@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 01 6月, 2019 4 次提交
-
-
由 Matt Chen 提交于
When try to bring up the AX201 2 killer sku, we run into: [81261.392463] iwlwifi 0000:01:00.0: loaded firmware version 46.8c20f243.0 op_mode iwlmvm [81261.407407] iwlwifi 0000:01:00.0: Detected Intel(R) Dual Band Wireless AX 22000, REV=0x340 [81262.424778] iwlwifi 0000:01:00.0: Collecting data: trigger 16 fired. [81262.673359] iwlwifi 0000:01:00.0: Start IWL Error Log Dump: [81262.673365] iwlwifi 0000:01:00.0: Status: 0x00000000, count: -906373681 [81262.673368] iwlwifi 0000:01:00.0: Loaded firmware version: 46.8c20f243.0 [81262.673371] iwlwifi 0000:01:00.0: 0x507C015D | ADVANCED_SYSASSERT Fix this issue by adding 2 more cfg to avoid modifying the original cfg configuration. Signed-off-by: NMatt Chen <matt.chen@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Shahar S Matityahu 提交于
Read fseq info from FW registers and print it upon fw assert. The print is needed since the fseq version coming from the TLV might not be the actual version that is used. Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Shahar S Matityahu 提交于
The driver attempts to clear persistence bit on any device familiy even though only 9000 and 22000 families require it. Clear the bit only on the relevant device families. Each HW has different address to the write protection register. Use the right register for each HW Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: 8954e1eb ("iwlwifi: trans: Clear persistence bit when starting the FW") Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Emmanuel Grumbach 提交于
When we have a single image (same firmware image for INIT and OPERATIONAL), we couldn't load the driver and register to the stack if we had hardware RF-Kill asserted. Fix this. This required a few changes: 1) Run the firmware as part of the INIT phase even if its ucode_type is not IWL_UCODE_INIT. 2) Send the commands that are sent to the unified image in INIT flow even in RF-Kill. 3) Don't ask the transport to stop the hardware upon RF-Kill interrupt if the RF-Kill is asserted. 4) Allow the RF-Kill interrupt to take us out of L1A so that the RF-Kill interrupt will be received by the host (to enable the radio). Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 29 4月, 2019 3 次提交
-
-
由 Luca Coelho 提交于
We have a solitary and inconspicous ` in the middle of a comment in this function, which should not be there. Remove it. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
If for some reason the device gives us an RX interrupt before we're ready for it, perhaps during device power-on with misconfigured IRQ causes mapping or so, we can crash trying to access the queues. Prevent that by checking that we actually have RXQs and that they were properly allocated. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Johannes Berg 提交于
This will let us introduce a mechanism to start with rfkill faked, and put 0 here to override it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 19 4月, 2019 3 次提交
-
-
由 Luca Coelho 提交于
This device ID and device type was never released, so we can remove it from the PCI IDs list. Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shahar S Matityahu 提交于
Add debug prints to the ini flow and rewrite existing prints to provide more information Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Shaul Triebitz 提交于
TFD_*_SLOTS and IWL_*_QUEUE_SIZE both define the TX queue size (number of TFDs). Get rid of TFD_*_SLOTS and use only IWL_*_QUEUE_SIZE. Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 18 4月, 2019 1 次提交
-
-
由 Shahar S Matityahu 提交于
The driver uses msix causes-register to handle both msix and non msix interrupts when performing sync nmi. On devices that do not support msix this register is unmapped and accessing it causes a kernel panic. Solve this by differentiating the two cases and accessing the proper causes-register in each case. Reported-by: NMichal Hocko <mhocko@kernel.org> Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 08 4月, 2019 1 次提交
-
-
由 Will Deacon 提交于
mmiowb() is now implied by spin_unlock() on architectures that require it, so there is no reason to call it from driver code. This patch was generated using coccinelle: @mmiowb@ @@ - mmiowb(); and invoked as: $ for d in drivers include/linux/qed sound; do \ spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation. If you've ended up bisecting to this commit, you can reintroduce the mmiowb() calls using wmb() instead, which should restore the old behaviour on all architectures other than some esoteric ia64 systems. Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-