aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-12-21mmc: mmci: add hs200 support for stm32 sdmmcYann Gautier1-2/+3
Use feedback clock for HS200 mode, as for SDR104. The HS200 mode can be enabled through DT by using mmc-hs200-1_8v. It is possible to use it on STM32MP13, but not STM32MP15 platforms. Signed-off-by: Ludovic Barre <ludovic.barre@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211215141727.4901-5-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-12-21mmc: mmci: increase stm32 sdmmcv2 clock max freqYann Gautier1-1/+1
The variant->f_max is dependent on the IP, not on the SoC where it is embedded. Set the max frequency of its source clock to 267MHz. The frequency used will be limited by the IOs max frequency, set in the SoC device tree. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211215141727.4901-3-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-12-21mmc: mmci: Add support for sdmmc variant revision v2.2Yann Gautier1-0/+5
The change is only hardware, and does not need driver change: Added hardware flow control during transmit packet with variable delay. The new id is then added to the ids list structure. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211215141727.4901-2-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-12-21Merge branch 'fixes' into nextUlf Hansson1-0/+2
2021-12-21mmc: mmci: stm32: clear DLYB_CR after sending tuning commandYann Gautier1-0/+2
During test campaign, and especially after several unbind/bind sequences, it has been seen that the SD-card on SDMMC1 thread could freeze. The freeze always appear on a CMD23 following a CMD19. Checking SDMMC internal registers shows that the tuning command (CMD19) has failed. The freeze is then due to the delay block involved in the tuning sequence. To correct this, clear the delay block register DLYB_CR register after the tuning commands. Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: 1103f807a3b9 ("mmc: mmci_sdmmc: Add execute tuning with delay block") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211215141727.4901-4-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-12-21xhci: Fresco FL1100 controller should not have BROKEN_MSI quirk set.Mathias Nyman1-1/+4
The Fresco Logic FL1100 controller needs the TRUST_TX_LENGTH quirk like other Fresco controllers, but should not have the BROKEN_MSI quirks set. BROKEN_MSI quirk causes issues in detecting usb drives connected to docks with this FL1100 controller. The BROKEN_MSI flag was apparently accidentally set together with the TRUST_TX_LENGTH quirk Original patch went to stable so this should go there as well. Fixes: ea0f69d82119 ("xhci: Enable trust tx length quirk for Fresco FL11 USB controller") Cc: stable@vger.kernel.org cc: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211221112825.54690-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-21EDAC/sb_edac: Remove redundant initialization of variable rcColin Ian King1-1/+1
The variable rc is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and thus remove it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20211126221848.1125321-1-colin.i.king@gmail.com
2021-12-21firmware: arm_scmi: Add new parameter to mark_txdoneCristian Marussi5-5/+9
Add a new xfer parameter to mark_txdone transport operation which enables the SCMI core to optionally pass back into the transport layer a reference to the xfer descriptor that is being handled. Link: https://lore.kernel.org/r/20211220195646.44498-9-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Add atomic mode support to smc transportCristian Marussi2-6/+64
Add a Kernel configuration option to enable SCMI SMC transport atomic mode operation for selected SCMI transactions and leave it as default disabled. Substitute mutex usages with busy-waiting and declare smc transport as .atomic_enabled if such Kernel configuration option is enabled. Link: https://lore.kernel.org/r/20211220195646.44498-8-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Add support for atomic transportsCristian Marussi2-2/+53
An SCMI transport can be configured as .atomic_enabled in order to signal to the SCMI core that all its TX path is executed in atomic context and that, when requested, polling mode should be used while waiting for command responses. When a specific platform configuration had properly configured such a transport as .atomic_enabled, the SCMI core will also take care not to sleep in the corresponding RX path while waiting for a response if that specific command transaction was requested as atomic using polling mode. Asynchronous commands should not be used in an atomic context and so a warning is emitted if polling was requested for an asynchronous command. Add also a method to check, from the SCMI drivers, if the underlying SCMI transport is currently configured to support atomic transactions: this will be used by upper layers to determine if atomic requests can be supported at all on this SCMI instance. Link: https://lore.kernel.org/r/20211220195646.44498-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Make optee support sync_cmds_completed_on_retCristian Marussi1-8/+9
Declare each OPTEE SCMI channel as not having a completion_irq so as to enable polling mode and then enable also .sync_cmds_completed_on_ret flag in the OPTEE transport descriptor so that real polling is itself effectively bypassed on the rx path: once the optee command invocation has successfully returned the core will directly fetch the response from the shared memory area. Remove OPTEE SCMI transport specific .poll_done callback support since real polling is effectively bypassed when .sync_cmds_completed_on_ret is set. Add OPTEE SCMI transport specific .mark_txdone callback support in order to properly handle channel locking along the tx path. Link: https://lore.kernel.org/r/20211220195646.44498-6-cristian.marussi@arm.com Cc: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Make smc support sync_cmds_completed_on_retCristian Marussi1-9/+9
Enable sync_cmds_completed_on_ret in the SMC transport descriptor and remove SMC specific .poll_done callback support since polling is bypassed when sync_cmds_completed_on_ret is set. Link: https://lore.kernel.org/r/20211220195646.44498-5-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flagCristian Marussi2-10/+32
Add a flag to let the transport signal to the core if its handling of sync command implies that, after .send_message has returned successfully, the requested command can be assumed to be fully and completely executed on SCMI platform side so that any possible response value is already immediately available to be retrieved by a .fetch_response: in other words the polling phase can be skipped in such a case and the response values accessed straight away. Note that all of the above applies only when polling mode of operation was selected by the core: if instead a completion IRQ was found to be available the normal response processing path based on completions will still be followed. Link: https://lore.kernel.org/r/20211220195646.44498-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Make smc transport use common completionsCristian Marussi1-19/+20
When a completion irq is available use it and delegate command completion handling to the core SCMI completion mechanism. If no completion irq is available revert to polling, using the core common polling machinery. Link: https://lore.kernel.org/r/20211220195646.44498-3-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21firmware: arm_scmi: Add configurable polling mode for transportsCristian Marussi2-0/+41
SCMI communications along TX channels can optionally be provided of a completion interrupt; when such interrupt is not available, command transactions should rely on polling, where the SCMI core takes care to repeatedly evaluate the transport-specific .poll_done() function, if available, to determine if and when a request was fully completed or timed out. Such mechanism is already present and working on a single transfer base: SCMI protocols can indeed enable hdr.poll_completion on specific commands ahead of each transfer and cause that transaction to be handled with polling. Introduce a couple of flags to be able to enforce such polling behaviour globally at will: - scmi_desc.force_polling: to statically switch the whole transport to polling mode. - scmi_chan_info.no_completion_irq: to switch a single channel dynamically to polling mode if, at runtime, is determined that no completion interrupt was available for such channel. Link: https://lore.kernel.org/r/20211220195646.44498-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-12-21iwlwifi: mei: wait before mapping the shared areaEmmanuel Grumbach1-0/+6
The shared area is a DMA memory allocated in the host and mapped so that the host and the CSME firmware can exchange data. It is mapped through a dedicated PCI device that is driven by the mei bus driver. The bus driver is in charge of allocating and mapping this memory. It also needs to configure the CSME firmware with a specific set of commands, so that the CSME firmware will know that this memory is meant to be used by its internal WLAN module. For this, the CSME firmware first needs to completely initialize its WLAN module and only then get the mapping request. The problem is that the mei bus enumeration completes before the WLAN is completely ready. This means that the WLAN module's initialization is racing with iwlmei's allocation and mapping flow. Testing showed a problem in resume flows where iwlmei was too fast and the DMA mapping failed. Add a delay to avoid this. This is still racy, but our measurements showed that we have a good margin and we should now be safe. Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211220142940.8b6279e3d0be.I6fe128b0b86149a85535104822c8355b367887c8@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mei: clear the ownership when the driver goes downEmmanuel Grumbach1-0/+1
When the driver is unregistered, CSME will take ownership on the device. Reflect this in the iwlmei object so that we will remember to re-ask for ownership when the driver will register again. Not doing so will cause CSME not to give the host ownership and we will see the following error message when trying to bring up the interface: iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw Couldn't prepare the card but SAP is connected iwlwifi 0000:a9:00.0: Error while preparing HW: -16 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211220142940.c7bb5b7644df.I48498d9fd6e3959562205af67aa5f1a822eb762d@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: yoyo: fix issue with new DBGI_SRAM region read.Mukesh Sisodiya1-1/+1
NIC has been grabbed for reading twice which is leading to NIC hang. Code correction are done for reading data with no grab function. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.55527214f8c9.I1748215ccb3fa20a3491a46a49b12e04eb560ac6@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: fw: fix some scan kernel-docJohannes Berg2-7/+26
Some devices also use iwl_scan_config_v2 struct, so link it in the documentation for SCAN_CFG_CMD. Fix a bunch of kernel-doc as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.3331df94b106.If6c96b0d386e1c5988c8da6b69257e8f2e737f07@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQLuca Coelho1-1/+6
In some rare cases when the HW is in a bad state, we may get this interrupt when prph_info is not set yet. Then we will try to dereference it to check the sleep_notif element, which will cause an oops. Fix that by ignoring the interrupt if prph_info is not set yet. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.0537aa562313.I183bb336345b9b3da196ba9e596a6f189fbcbd09@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: remove card state notification codeJohannes Berg5-38/+0
This notification ID was actually used for something else we never implemented, but luckily we only had some debug code here. Just remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.a67b5b9db259.Ic55b306fcd2a3525b3993f4b7e00622dd95053ba@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: drop too short packets silentlyJohannes Berg1-11/+1
There's little value in this warning, we get a warning here if firmware passes us a short packet, particularly in monitor mode. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.305d12cf51ac.I2e4e6874113b1e5d8ee467b8a2d90820cc6ddde9@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: fix AUX ROC removalAvraham Stern1-3/+6
When IWL_UCODE_TLV_CAPA_SESSION_PROT_CMD is set, removing a time event always tries to cancel session protection. However, AUX ROC does not use session protection so it was never removed. As a result, if the driver tries to allocate another AUX ROC event right after cancelling the first one, it will fail with a warning. In addition, the time event data passed to iwl_mvm_remove_aux_roc_te() is incorrect. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.915e1f69f062.Id837e917f1c2beaca7c1eb33333d622548918a76@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: return op_mode only in case the failure is from MEIMordechay Goodstein1-6/+12
Currently we always return the op_mode with valid pointer in case getting NVM failed, while it's only relevant for cases that CSME is the owner of the nic. Fix this by checking also who's the owner of the nic. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.b1e96021b616.Id0164855f2dd01ecdecf79b239d6ee5974882245@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: support Bz TX checksum offloadJohannes Berg6-10/+78
Support TX checksum offload for Bz devices, where we have full checksum offload (NETIF_F_HW_CSUM) and the hardware doesn't need to parse the IP headers or anything. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.c0f44c98b36d.I75a688f3ac80cbe824c459ece4bb67843b9fce76@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowedMiri Korenblit1-19/+36
If OEM isn't in the allowed list, TAS should be disabled in US/CA. Currently, if the OEM isn't allowed - we're sending the TAS only if we are not in US or CA. But this country check is done before we even know the country (usually the configuration is ZZ in that stage). So do the following instead: 1. Check if the current OEM is in the allowed list 2. If not - add US and CA to tas_block_list_array 3. Send the TAS table to FW. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: correctly set schedule scan profilesAyala Beker2-1/+13
Set scan offload profiles auth algorithms with valid algorithms only. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.525f2d468d22.I4d497d6a0a14ffb833f7edc7e980d26bbf8d7527@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: set protected flag only for NDP rangingAvraham Stern1-1/+1
Don't use protected ranging negotiation for FTM ranging as responders that support only FTM ranging don't expect the FTM request to be protected. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Fixes: 517a5eb9fab2 ("iwlwifi: mvm: when associated with PMF, use protected NDP ranging negotiation") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.f50ed0e3c6b3.Ibff247ee9d4e6e0a1a2d08a3c8a4bbb37e6829dd@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: pcie: add killer devices to the driverYaara Baruch1-2/+16
add killer subsystem devices from the 1675i and 1675s family to the driver. Signed-off-by: Yaara Baruch <yaara.baruch@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219132536.2d5bec2d7b68.Icffb4e27390e6a5c76a0cbe7abf7472558f323d6@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: perform 6GHz passive scan after suspendAvraham Stern1-12/+9
The 6GHz passive scan is performed only once every 50 minutes. However, in case of suspend/resume, the regulatory information is reset, so 6GHz channels may become disabled. Fix it by performing a 6GHz passive scan within 60 seconds after suspend/resume even if the 50 minutes timeout did not expire yet. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Fixes: e8fe3b41c3a3 ("iwlwifi: mvm: Add support for 6GHz passive scan") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.6d5c043372cf.I251dd5618a3f0b8febbcca788eb861f1cd6039bc@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: correctly set channel flagsAyala Beker1-3/+4
In case of forced passive scan on a UHB channel, don't set the direct probe option for this channel. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0ede76a9ca92.Ie64a4df79ea9c485ae3d2fc043319e8f79cefa8e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: always store the PPAG table as the latest version.Miri Korenblit3-31/+33
In case of a conflict between BIOS version and FW version of the PPAG table - the values arrive in the FW in the wrong places. This happens because we're storing the table in different structures depending on the BIOS version, not on the FW version, and so the FW doesn't get what it expect to. Always store the table in a v2 structure (which is a superset of v1 and v0). Also store the table in a structured way and in it's own structure, rather then storing it in the ppag command structure, similarly to the WRDS, EWRD and WGDS tables. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.793a509da7bd.Ia176746a28b816b5f788cce9a281139735909e2a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: bump FW API to 69 for AX devicesLuca Coelho1-1/+1
Start supporting API version 69 for AX devices. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.7d8fe0dffaea.I2de65c1efd9ab464d4158a3d852f73efe63024f8@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: Fix calculation of frame lengthIlan Peer1-0/+27
The RADA might include in the Rx frame the MIC and CRC bytes. These bytes should be removed for non monitor interfaces and should not be passed to mac80211. Fix the Rx processing to remove the extra bytes on non monitor cases. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: test roc running status bits before removing the staNathan Errera1-3/+12
In some cases the sta is being removed twice since we do not test the roc aux running before removing it. Start looking at the bit before removing the sta. Signed-off-by: Nathan Errera <nathan.errera@intel.com> Fixes: 2c2c3647cde4 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: don't pass actual WGDS revision number in table_revisionLuca Coelho2-9/+17
The FW API for PER_CHAIN_LIMIT_OFFSET_CMD is misleading. The element name is table_rev, but it shouldn't actually contain the table revision number, but whether we should use the South Korea scheme or not. Fix the driver so that we only set this value to either 0 or 1. It will only be 1 (meaning South Korea) if the ACPI WGDS table revision is 1. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: 664c011b763e ("iwlwifi: acpi: support reading and storing WGDS revision 2") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.abed3b8119c7.I1fdc2c14577523fcffdfe8fb5902c2d8efde7e09@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: yoyo: support TLV-based firmware resetMukesh Sisodiya5-5/+71
Support resetting the firmware via TLV-based debugging. When applied, this will cause the driver to reset the firmware when the debugging is triggered. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d59b29653a1e.I7b3be4a1ad1a9d5d0e86259740e89ac113c9348b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: change old-SN drop thresholdJohannes Berg1-1/+1
Increment the threshold to avoid dropping too eagerly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0e947ed458c4.Ia376cbea5f59df4b4474f0bd33ab033e84535cce@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: don't trust hardware queue numberJohannes Berg1-0/+3
We don't really have much reason to mistrust the hardware queue number, but if it gets mixed up we still don't want to access some data out of bounds, so drop such frames. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.539aecb91247.I6e555a5185bad30d7d1a4659f9c0b99325425f18@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: handle RX checksum on Bz devicesJohannes Berg1-1/+5
On Bz devices, the hardware checksums including the SNAP header, starting directly after the MAC header, so we don't need the extra checks and can just pass the checksum to mac80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.8ef59da4e05e.Ide87c2dc8fa08eae55c013a625f4ece5184b1b63@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: use a define for checksum flags maskJohannes Berg2-2/+2
For the upcoming Bz devices, we will set NETIF_F_HW_CSUM instead of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM. However, we still need to be able to remove all the checksum bits, so add a mask for the removal, and keep the old define for the feature advertisement. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219121514.f05488ce8b83.I65bb83721498d8433e4ee2b09415eb74ab579445@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: remove module loading failure messageJohannes Berg1-8/+1
When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes when the opmode module cannot be loaded, due to completing the completion before using drv->dev, which can then already be freed. Fix this by removing the (fairly useless) message. Moving the completion later causes a deadlock instead, so that's not an option. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20211210091245.289008-2-luca@coelho.fi Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: isolate offload assist (checksum) calculationJohannes Berg1-26/+19
Isolate the entire calculation of the offload_assist field used for HW checksumming to the iwl_mvm_tx_csum function. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.796ae29c90d9.Icb2f07905bebd9ed4537ca4c453069211ea71799@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: add support for OCE scanAvraham Stern3-2/+20
In case the fw supports OCE scan and one of the OCE feature flags are set in the scan request, set the corresponding flag in the firmware scan request. Note that new firmware that indicates OCE support does not support the probe deferral and suppression feature (which is optional). Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.3dd63c381839.Id79b39f650103bb9b851e31ed6a0178e81988587@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: fix leaks/bad data after failed firmware loadJohannes Berg1-0/+8
If firmware load fails after having loaded some parts of the firmware, e.g. the IML image, then this would leak. For the host command list we'd end up running into a WARN on the next attempt to load another firmware image. Fix this by calling iwl_dealloc_ucode() on failures, and make that also clear the data so we start fresh on the next round. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: fix debug TLV parsingJohannes Berg1-4/+11
Debug TLV parsing was missing size checks, so if a valid but too short TLV was encountered, it would attempt to read it. If the firmware file was arranged to be a multiple of pages long with this happening just before the end, it could crash reading out-of-bounds of a vmalloc area. Fix this by adding the relevant size check. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.84848da8067f.Ifb4f80c95d283ec62e495a7928069af711b5fee2@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: mvm: fix 32-bit build in FTMJohannes Berg1-1/+2
On a 32-bit build, the division here needs to be done using do_div(), otherwise the compiler will try to call a function that doesn't exist, thus failing to build. Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: dump RCM error tablesJohannes Berg3-0/+82
There's another set of error tables on newer (Bz) hardware, support finding and dumping those error tables if present. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.c727a975b434.Ie5ad3fd974b700f1b90867b2b52ef7607799e8fe@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: dump both TCM error tables if presentJohannes Berg3-12/+19
There can be two TCMs in a given device, dump both of the error tables if present. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.887cba319301.Ifdc3f617f7e0e3e39c90e8c208e60f11b3bb9404@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-21iwlwifi: dump CSR scratch from outer functionJohannes Berg1-7/+7
We shouldn't dump this twice if we have two TCMs, and it really doesn't belong to the TCM dump anyway, so move this out. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211210110539.b58a02f27512.Idbfbc430776a7abda0eb086215fb64f2c9307ac0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.