The argument type to iwl_mvm_notify_rx_queue() is currently just
a u8 *, but that's misleading because we actually need the inner
data to be of type struct iwl_mvm_internal_rxq_notif, because we
interpret it when we get it back from the device (to check the
sync bool and possibly the cookie.)
Therefore, clear up any potential confusion and require that the
data passed is of type struct iwl_mvm_internal_rxq_notif *.
Also, while at it, rename the "count" to "notif_size" as "count"
doesn't really clearly say what it's counting.
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.20201209231352.d28e14682bdc.I9ac366aa97db045be4daa4ba263267a3ac6a6a2f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We no longer need code that was introduced to differentiate
between two early versions of 8260.
We can remove this convoluted way to get the hardware version
that was needed because of a bug in the register's
configuration.
Moreover, since we no longer need to access the PRPH
registers, we no longer need to wake up the device,
request ownership, etc...
Remove all that.
This allows us to get the rid of the obsolete comment
about the AUX bus MISC address space which should have
been moved when this code was moved away from here.
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.20201209231352.4a5665ccd8a6.Iff3879405c15758ba661c430e77dc2160ddada1c@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
ofdm_index[] is used to indicate how many power compensation is needed to
current thermal value. For internal PA module or 2.4G band, the min_index
is different from other cases.
This issue originally is reported by Dan. He found the size of ofdm_index[]
is 2, but access index 'i' may be equal to 2 if 'rf' is 2 in case of
'is2t'.
In fact, the chunk of code is added to wrong place, so move it back to
proper place, and then power compensation and buffer overflow are fixed.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201207031903.7599-1-pkshih@realtek.com
HE operation IE in beacons is constructed based on userspace params,
which firmware might not be aware of. This causes firmware not to
configure TXOP duration based RTS threshold which could cause mismatch
in behaviour with respect to what is being advertised in beacons. This
patch sends HE operation IE fetched from beacon to firmware using
WMI interface for configuration.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01228-QCAHKSWPL_SILICONZ-1
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201020183111.25458-4-pradeepc@codeaurora.org
QMI sequence fails if caldata file is not available.
It is observed that 'rmmod ath11k' fails if qmi message fails.
With this patch rmmod/insmod is working.
Logs:
Direct firmware load for IPQ8074/caldata.bin failed with error -2
Falling back to user helper
qmi failed to load CAL: IPQ8074/caldata.bin
qmi failed to load board data file:-11
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00009-QCAHKSWPL_SILICONZ-1
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01699-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1606916215-24643-1-git-send-email-akolli@codeaurora.org
I am trying to get the ath11k driver to work with VyOS and during the
build it tries to discover the firmware blobs which drivers require.
This doesn't work with ath11k because it doesn't use the MODULE_FIRMWARE
macro. This patch fixes that.
Signed-off-by: Devin Bayer <dev@doubly.so>
[kvalo@codeaurora.org: cleanup commit log, move to pci.c]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201202182705.dhkml4nb4rf2vwav@orac
mt76 patches for 5.11
* mt7915 fixes
* mt7615 fixes
* support for more sta interfaces on mt7615/mt7915
* mt7915 encap offload
* performance improvements
* channel noise report on mt7915
* usb/sdio support improvements
* mt7915 testmode support
* mt7915 DBDC support
* warning fixes
When 8822CE is associating with AP, driver will poll status bit of
IQ calibration to confirm the IQ calibration is done, and then move on
the association process. Current polling time for IQ calibration is 6
seconds.
But occasionally driver fails in polling the status bit because the status
bit is not set after IQ calibration is done. When it happends, association
process will be serieously delayed up to 6 seconds. To avoid it, we reduce
polling time to 300ms, in which the IQ calibration can be done.
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/20201208014503.12118-1-pkshih@realtek.com
'const struct dev_pm_ops rtw_pm_ops' is declared by pci.c, and it should be
declare as 'extern' in pci.h. Without 'extern' causes every file including
pci.h has an individual instance of rtw_pm_ops but not reference to the one
declared in pci.c
If kernel config, like test robot, doesn't build driver as module, it leads
multiple definition.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 2e86ef413a ("rtw88: pci: Add prototypes for .probe, .remove and .shutdown")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201208013746.11065-1-pkshih@realtek.com
When driver was developed, FCC regulation didn't enable channel 144
and there was no demand for channel 144 at that time. Although HW
actually supports channel 144, driver didn't announce channel 144.
Therefore, channel 144 (20 MHz), channel 142 (40 MHz) and channel
138 (80 MHz) couldn't be used.
Today, channel 144 has been enabled by regulations and
is gradually being supported. With test requirements,
we declare hw supports channel 144.
Signed-off-by: Zong-Zhe Yang <kevin_yang@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/20201204013823.3729-1-pkshih@realtek.com
