summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-02-05iwlwifi: mvm: add Samsung to the PPAG approved listLuca Coelho
Samsung is now approved to use the PPAG feature. Add it to the approved list. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210131201908.07841f1f45ba.I47eb5a9be3c819683a2175e4db89f366bc9508e2@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add HP to the PPAG approved listLuca Coelho
HP is now part of the OEMs in the approved list for the PPAG feature. Add it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210131201908.41e9812977b9.If19d9a47d0070465a4c1349fcb123db32aee85f7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: implement approved list for the PPAG featureLuca Coelho
We should only allow PPAG to be enabled by OEMs that are in the approved list. In order to do this, we need to compare the system vendor string retrieved from SMBIOS to a list maintained in the driver. If the vendor string is not in the list, we don't allow PPAG to be used. For now the list is empty, but entries will be added to it individually, in subsequent patches. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210131201908.c9d35b7d8748.I4e4cf61d8fa6ff91d9b0cab2b1ec9ede4be346f5@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: set enabled in the PPAG command properlyLuca Coelho
When version 2 of the PER_PLATFORM_ANT_GAIN_CMD was implemented, we started copying the values from the command that we have stored into a local instance. But we accidentally forgot to copy the enabled flag, so in practice PPAG is never really enabled. Fix this by copying the flag from our stored data a we should. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210131201908.24d7bf754ad5.I0e8abc2b8747508b6118242533d68c856ca6dffb@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add debugfs entry to trigger a dump as any time-pointMordechay Goodstein
This is used for different tests collecting different types of debug data from fw (e.g latency issues, hw issues etc). 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.20210131201908.0db829694810.I001f39d34ae46c87870d9bd94a4baaa3250578d1@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add tx fail time pointMordechay Goodstein
This helps collect on any tx failure fw data to better understand what went wrong. 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.20210131201908.719de818c09a.I2788e6a4c411aa414eaa67e6b7b21d90ccd9d0c1@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: fwrt: add suspend/resume time pointMordechay Goodstein
We should only collect debug data after exiting suspend state, that's why we delete the current place in d3.c file, and add it to fwrt flows that occur while we can still access the fw and collect debug data. 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.20210131201908.eaf378ed403c.I46fae3ee6da1a4b476515b8ad51ad1c0ea2d8381@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add triggers for MLME eventsMordechay Goodstein
For debug we add auth/assoc failed event and disconnect event. 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.20210131201907.fa62d6770dd1.I5b2ea2e5316ebed94ed77ff0a31d78a9672e4016@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add IML/ROM information for other HW familiesMordechay Goodstein
This makes it easier to debug IML/ROM errors for other HW families as well. 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.20210131201907.4a802b308a0f.I77855abbf6dc1a6edf9c914f3313a87bd78de4df@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: fix CSA AP sideEmmanuel Grumbach
Once the all the stations completed the switch, we need to clear csa_tx_blocked_vif. This was missing. We also need to re-enable the broadcast / multicast stations. 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.20210205110447.f5b813753bdb.Id58979b678974c3ccf44d8b381c68165ac55a3d3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: make iwl_mvm_tt_temp_changed() staticJohannes Berg
This is only needed within tt.c, make it static. 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.20210205110447.20a74526d395.Id24304ec1ae4b3096dbb8112bd146b364920e89e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: cancel the scan delayed work when scan is abortedEmmanuel Grumbach
When we abort the scan because of a firmware crash, we need to cancel the delayed work that monitors the scan completion. Otherwise it'll kick and try to restart the firmware yet another time. 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.20210205110447.a497faa942dd.Ibc155ad36da9de7eb0ddcdd826ddf8dd6607d2ac@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: pcie: add support for SnJ with Hr1Luca Coelho
Add an entry for SnJ with Hr1. This device should use the tx_with_siso_diversity option, but that doesn't work at the moment. So we leave it disabled for now (and use the same struct as Hr2). Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.455e59ba3a4c.I49ebb07382e6d11dc8f50e6a58d579681209cb1d@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: move early time-point before nvm_init in non-unifiedLuca Coelho
We were starting the early time-point too late in non-unified firmwares. Unlike with unified firmwares, we were starting it only after reading the NVM, so errors in the NVM read phase were not logged. Solve this by moving the time-point to the same place as we do with unified firmwares, i.e. just before we go into the wait-alive code. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.bb6d28ceca01.I770fdf3b9b9fa555fe0935926e32cc3509d980de@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: add support for SnJ with Jf devicesLuca Coelho
Add support for SnJ devices with Jf and a workaround for some cases where the devices erroneously show as QnJ devices. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.ae6ed654e557.Ic11ed4df410328359b6a2c997456692901d99468@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: move SnJ and So rules to the new tablesLuca Coelho
We were hardcoding the SnJ and So IDs already at the trans_cfg selection, instead of doing it in a more generic way. Use the generic trans_cfg selection for these devices and move the hardcoded IDs to the new table. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.7e11dcb7b04e.I6f65126175d54b73834c2896013d00ce114ff601@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: slightly clean up rs_fw_set_supp_rates()Johannes Berg
The "supp" variable doesn't need to be unsigned long, only "tmp" is used with for_each_set_bit(). "supp" should just be a u16, since that's how it's sent to the firmware. 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.20210205110447.762e50704a39.I014bc7898f90c734f8e9be2a3efaf9bf8b7db6db@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: fw api: make hdr a zero-size array againJohannes Berg
In struct iwl_tx_cmd, there's no risk (as Arnd implied) that we might access this as an array, as it's really not an array and cannot be - there's only a single 802.11 header per frame. The only reason for this member is for being able to access it a bit more nicely. On the other hand, this structure is used as a sub-struct in a few places, and then some compilers (e.g. clang with certain options) complain as you shouldn't have structs with variable- length fields embedded in other structs. 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.20210205110447.46cd538c90bf.I92179567d96938598806b560be59d787c2a8cc16@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: bump FW API to 60 for AX devicesLuca Coelho
Start supporting API version 60 for AX devices. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210205110447.7b908f5dd970.Id2aec0d7d33921aba77ba9853196f81d5950c31c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: advertise BIGTK client support if availableJohannes Berg
If the firmware has support, then advertise it to the stack and send the key down. Since we re-check the protection in the host anyway, we don't really need to do anything on RX except that we should drop frames that the firmware _knows_ are replay errors, since beacon filtering might otherwise result in replays being possible. 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.20210205110447.f5a3d53301b3.I23e84c9bb0b039d9106a07e9d6847776757f9029@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: always allow maximum A-MSDU on newer devicesJohannes Berg
On devices starting from 9000 series, always allow maximum A-MSDU sizes regardless of the amsdu_size module parameter, which really hasn't meant that for a long time but just controls the receive buffer size. 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.20210117164916.ebf6efb380a9.I237be6ec70bee6ec52a2f379ee1f15b1196488d0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: debugfs: check length precisely in inject_packetJohannes Berg
When we check the length, we only check that the advertised data length fits into the data we have, but currently not that it actually matches correctly. This should be harmless, but if the first two bytes are zero, then the iwl_rx_packet_payload_len() ends up negative, and that might later cause issues if unsigned variables are used, as this is not something that's normally expected. Change the validation here to precisely validate the lengths match, to avoid such issues. 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.20210117164916.5184dfc2a445.I0631d2e4f6ffb93cf06618edb035c45bd6d1d7b9@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: simplify TX power settingJohannes Berg
There's no need to double this code, just put it into the common code that's called in all the cases. 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.20210117164916.1f75d426ebe4.I58f6612f7e168c655bdef206a53e5bc117c84cf5@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: tx: move handing sync/async host command to transMordechay Goodstein
Handling host commands in a sync way is not directly related to PCIe transport, and can serve as common logic for any transport, so move it to trans layer. 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.20210117164916.fde99af4e0f7.I4cab95919eb35cc5bfb26d32dcf5e15419d0e0ef@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add explicit check for non-data frames in get Tx rateKrishnanand Prabhu
In roaming flows and during reassociation, its possible that data frames such as EAPOLs for 4 way handshake/ 802.1x authentication are initially set to higher MCS rate. Though these are pruned down to a lower legacy rate before sending to the FW, driver also emits a kernel warning - intended for non-data frames. Add checks to avoid such warnings for data frames, while also enhancing the debug data printed. Signed-off-by: Krishnanand Prabhu <krishnanand.prabhu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117164916.d9ded010c4ce.Ie1d5a33d7175c0bcb35c10b5729748646671da31@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: debugfs for phy-integration-verDror Moshe
Add debugfs file to print the PHY integration version. File name is: phy_integration_ver Signed-off-by: Dror Moshe <drorx.moshe@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117164916.f5127d919656.Ib714f444390b39cbbf7eb143c5440cc890385981@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: parse phy integration string from FW TLVDror Moshe
Parse phy integration string from FW TLV. Signed-off-by: Dror Moshe <drorx.moshe@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117164916.0c790e930484.I23ef2cb9c871e6adc4aab6be378f3811cb531155@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: csa: do not abort CSA before disconnectShaul Triebitz
While disconnecting from the AP due to bad channel switch params (e.g. too long Tx block), do not send the firmware 'CSA abort' before disconnecting. That causes canceling the immediate quiet and can cause transmitting data before the disconnection happens. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117164916.b9af359a675f.I996fc7eb3d94e9539f8b117017c428448c42c7ad@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: don't send commands during suspend\resume transitionHaim Dreyfuss
D3_CONFIG_CMD and D0I3_END_CMD should be the last\first command upon suspend\resume correspondingly, otherwise, FW will raise an assert (0x342). There are firmware notifications that cause the driver to send a command back to the firmware. If such a notification is sent to the driver while the the driver prepares the firmware for D3, operation, what is likely to happen is that the handling of the notification will try to get the mutex and will wait unil the driver finished configuring the firmware for D3. Then the handling notification will get the mutex and handle the notification which will lead to the aforementioned ASSERT 342. To avoid this, we need to prevent any command to be sent to the firmware between the D3_CONFIG_CMD and the D0I3_END_CMD. Check this in the utility layer that sends the host commands and in the transport layer as well. Flag the D3_CONFIG_CMD and the D0I3_END_CMD commands as commands that must be sent even if the firmware has already been configured for D3 operation. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210117164916.1935a993b471.I3192c93c030576ca16773c01b009c4d93610d6ea@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: don't check system_pm_mode without mutex heldEmmanuel Grumbach
When we want to stop TX'ing because we are suspending, we have two options: either we check system_pm_mode or we check the mvm's status that has a bit for the suspend flow. The latter is better because test_bit is atomic. Also add a call to synchronize_net after we set the bit to make sure that all the new Tx see the bit before we actually complete the suspend flow. 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.20210117130510.243c88781302.I5c0379c5a7e5d49410569e7fcd2fff7a419c6dea@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: remove TRANS_PM_OPSEmmanuel Grumbach
Those were needed for a slave bus that is not longer supported. Remove code that is mainly useless stubs. 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.20210117130510.8f8a735f39dd.If5716eaae0df5e6295a2af927bf3ab0ee074f0a0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: dbg: dump paged memory from index 1Mordechay Goodstein
We skip index 0 that holds CSS section which isn't relevant for paged memory. 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.20210117130510.ad2df68fccbc.I381f931c6e7606c21935ec6667619b209224e408@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwl-trans: iwlwifi: move sync NMI logic to transMordechay Goodstein
The code is not directly related to PCIe transport, and it will help moving sync/async commands logic out of PCIe in the next patches. 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.20210117130510.271f59887fd1.I8ff41236f4e11a25df83d76c982a2a30ba2b9903@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: pcie: properly implement NAPIJohannes Berg
Instead of pretending to have NAPI and then relying entirely on interrupts anyway, properly implement NAPI and schedule the poll when we get an interrupt, re-enabling the interrupt only after the poll completed. 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.20210117130510.a5951ac4fc06.I9c84a147288fcfb1b019572c6758f2d92949f5d7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add support for new flush queue responseMordechay Goodstein
In the new api all the flush in the FW is done before we get the response and in the response we only get the updated read pointer and all queued packets don't get anymore rx_tx per packet to free the queued packet, so driver needs to free all queued packets on flushed queue at once after flush response. 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.20210117130510.4bd0eca8c0ef.I1601aad2eb2cc83f6f73b8ca52be57bb9fd626ab@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: handle CCA-EXT delay firmware notificationJohannes Berg
If there are frequent CCA delays due to the extension channel as detected by the firmware, and we're on 2.4 GHz, then handle this by disconnecting (with a reconnect hint). When we disconnect, we'll also update our capabilities to use only 20 MHz on the next connection (if it's on 2.4 GHz) as to avoid the use of the extension channel that has too much noise. 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.20210117130510.4de9c363b0b5.I709b7e6f73a7537c53f22d7418927691259de8a8@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: scan: fix scheduled scan restart handlingJohannes Berg
When restarting firmware with an ongoing scheduled scan, we don't (and shouldn't) mark it as aborted as mac80211 will be restarting it, and so no event should go out to userspace. The appropriate comment regarding this wasn't moved to this place, so add it. However, we _do_ need to clean up our internal state, since mac80211 will restart the scan, and we'll otherwise get to the WARN_ON() a few lines below for no reason whatsoever. 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.20210117130510.4ddc9b017268.Ie869b628ae56a5d776eba0e7b7f05f42fc566f2e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: remove debugfs injection limitationsJohannes Berg
For testing features where the firmware may send some notifications it can often be a lot easier to do that from a test script. Remove most injection limitations from debugfs to be able to do this. 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.20210117130510.9aff3c6b4607.I03b0ae7df094734451445ffcb7f9f0274969f1c0@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: check more notification sizesJohannes Berg
Some notifications aren't handled by the general RX handler code, due to multi-queue. Add size checks for them explicitly. 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.20210117130510.1370c776cb31.Ic536bd1aee5368969fbf65db85b9b9b5dc9c6034@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-02-05iwlwifi: mvm: add notification size checksJohannes Berg
We shouldn't trust the firmware with the sizes (or contents) of notifications, accessing too much data could cause page faults if the data doesn't fit into the allocated space. This applies more on older NICs where multiple notifications can be in a single RX buffer. Add a general framework for checking a minimum size of any notification in the RX handlers and use it for most. Some RX handlers were already checking and I've moved the checks, some more complex checks I left and made them _NO_SIZE for the RX handlers. 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.20210117130510.3e155d5e5f90.I2121fa4ac7cd7eb98970d84b793796646afa3eed@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-01-25iwl4965: do not process non-QOS frames on txq->sched_retry pathStanislaw Gruszka
We have already WARN_ON(!qc) for non-QOS frame on txq->sched_retry path, but we continue to process, what makes no sense since tid is not initialized. Non QOS frame should never happen when aggregation is enabled on queue, so do not process that. Patch should fix smatch warning: drivers/net/wireless/intel/iwlegacy/4965-mac.c:2822 il4965_hdl_tx() error: uninitialized symbol 'tid'. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210119100621.439134-1-stf_xl@wp.pl
2021-01-25mt7601u: process tx URBs with status EPROTO properlyLorenzo Bianconi
Similar to commit 0e40dbd56d67 ("mt7601u: process URBs in status EPROTO properly"), do not process tx URBs if marked with status set to EPROTO. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/72392e8341aa8591c0b9962661a6ca26b1198f32.1610919534.git.lorenzo@kernel.org
2021-01-25wlcore: Fix command execute failure 19 for wl12xxTony Lindgren
We can currently get a "command execute failure 19" error on beacon loss if the signal is weak: wlcore: Beacon loss detected. roles:0xff wlcore: Connection loss work (role_id: 0). ... wlcore: ERROR command execute failure 19 ... WARNING: CPU: 0 PID: 1552 at drivers/net/wireless/ti/wlcore/main.c:803 ... (wl12xx_queue_recovery_work.part.0 [wlcore]) (wl12xx_cmd_role_start_sta [wlcore]) (wl1271_op_bss_info_changed [wlcore]) (ieee80211_prep_connection [mac80211]) Error 19 is defined as CMD_STATUS_WRONG_NESTING from the wlcore firmware, and seems to mean that the firmware no longer wants to see the quirk handling for WLCORE_QUIRK_START_STA_FAILS done. This quirk got added with commit 18eab430700d ("wlcore: workaround start_sta problem in wl12xx fw"), and it seems that this already got fixed in the firmware long time ago back in 2012 as wl18xx never had this quirk in place to start with. As we no longer even support firmware that early, to me it seems that it's safe to just drop WLCORE_QUIRK_START_STA_FAILS to fix the error. Looks like earlier firmware got disabled back in 2013 with commit 0e284c074ef9 ("wl12xx: increase minimum singlerole firmware version required"). If it turns out we still need WLCORE_QUIRK_START_STA_FAILS with any firmware that the driver works with, we can simply revert this patch and add extra checks for firmware version used. With this fix wlcore reconnects properly after a beacon loss. Cc: Raz Bouganim <r-bouganim@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210115065613.7731-1-tony@atomide.com
2021-01-25mt7601u: use ieee80211_rx_list to pass frames to the network stack as a batchLorenzo Bianconi
Similar to mt76 driver, rely on ieee80211_rx_list in order to improve icache footprint Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/5c72fa2dda45c1ae3f285af80c02f3db23341d85.1610580222.git.lorenzo@kernel.org
2021-01-25rtw88: 8723de: adjust the LTR settingChin-Yen Lee
The LTR mechanism enables PCIE Endpoints to report the service latency requirements and CPU will enter appropriate sleep state to save power based on the LTR value. 8723de provides two registers to config the LTR, and the original setting is too short for CPU to ente sleep state. The patch adjust the LTR setting. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210113014342.3615-1-pkshih@realtek.com
2021-01-25rtlwifi: rtl8821ae: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8821ae, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c, "if (rtlefuse->autoload_failflag == false)" can be replaced with "if (!rtlefuse->autoload_failflag)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-6-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8192se: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8192se, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-5-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8188ee: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8188ee, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c, "if (mac->act_scanning == true)" can be replaced with "if (mac->act_scanning)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-4-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8192c-common: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8192c-common, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c, "else if (initialized == false) {" can be replaced with "else if (!initialized) {" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-3-yashsri421@gmail.com
2021-01-25rtlwifi: rtl_pci: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl_pci, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c, "if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-2-yashsri421@gmail.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-28 15:33:27 +0000