When we have an assert during D3 we want to dump the internal
buffer memory even if are we working in DRAM debug mode.  We should not
block dumping it.

Change-Id: I69aad2d4904c4f8bb653c61e8781a2e07780054f
Signed-off-by: NRotem Saado <rotem.saado@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't support the FPGA versions of this card combination anymore.
Remove the cfg mangling that tries to load it and all the relevant
structures.

Change-Id: I190652101afcab682cfba873d062992f11efca32
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't support QnJ HR STEP A anymore.  Remove the structures we used
for it.

Change-Id: I0dfd88232bdc8ff2dd9c4368b8ed9a0c40c86bc8
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

A couple of SoCs, which can be recognized by PCI device IDs 0xA0F0 and
0x43F0, need a longer wait for the xtal to stabilize.  To handle this,
add a new trans_cfg structure for Qu devices with a larger
xtal_latency value and apply them to the devices recognized by these
IDs.  Also add a flag that allows us to inform the FW that the low
latency xtal should be used.

Change-Id: I8a14c6af45ea14d8e7f1ef38a589158f38d0c0ea
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This new command is mostly backwards compatible, with the exception
that the device_type element was changed into a bitmask.  The device
type bit remains the same (because we only had 0 and 1 anyway), but
when using v1 we can't set any other bits, because that would change
the integer.

Other than that, the struct remains the same and the driver can set
the device_type bit in both cases, but it can only set the low_latency
bit if VER_2 is used.

Change-Id: Ib68d4c821ebcce253b42ed0ea15881fb4e3e01da
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support for requesting trigger-based / non trigger-based
measurements.

Change-Id: Ib4d0c471da9c50d9981541a7f5926db384a0f7ce
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Now that we identify the correct cfgs with the new tables for Qu step
C and QuZ with Jf, we can remove the mangling we do later on.

Change-Id: Ic01ce67db147e897ad2424f0e05a70a00d2c620e
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

All the QnJ devices have a similar matching to the other Qu devices,
but needs a different configuration.  Convert the QnJ devices to the
new table accordingly.

Change-Id: If236ef3d0da3e605a3379922818f5897e0affd7e
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add new generic iwl_trans structures for these devices and apply the
correct cfg depending on the device characteristics.

Since we have to match Qu with IWL_CONFIG_ANY, we also need to move
the Hr devices to the new table, but for now we keep matching on PCI
device and subsystem device IDs.

Change-Id: I14e9146a99621ff11ce50bc746a4b88af508fee0
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We need to use different firmware versions for different HW steps with
certain devices.  Prepare for this differentiation by adding HW step
to the new device table.

Change-Id: Ib1afb7b0c89e9dc2d26e6d32ea19e978c17ba1dd
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

After the refactoring, a few extern declarations were accidentally
left in the iwl-config.h file.  Remove them

Change-Id: I79745e440ed5a0a90db61b0daaae374ecef09e86
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

These values are selected based on the PCI device ID, so the decision
to use them can be made early.  By moving them to the trans_cfg, we
avoid duplicating the large cfg structs for small pieces of
data (sometimes a single boolean).  This will also allow us to make
more decisions based on, for instance, the SoC type in used.

The trans_cfg concept changes a bit, because previously it was used
only to boot the device before reading further characteristics and now
it also contains more data that is associated with the device ID.

Change-Id: Ib71b07ea9e322eb74571dc5e8aa58f17eece5c9c
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We shouldn't do this just for HT/VHT, but be future-proof
and also check for HE.

Change-Id: Icaeff714c00a773681dbfee72558afd1c7121c5d
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The iwl9560_2ac_cfg struct is used for PNJ devices and the
configuration is the same as iwl9260_2ac_cfg, so we can remove the
former to avoid redundancy.

Change-Id: I17ac1802f00bd80006930b922a9fc21df60e3c16
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

That closing brace for the switch statement is misplaced, fix it.

Change-Id: I39af135a9e3fc64337d2cced43a70cb48fe3b9c1
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Modify adaptive dwell number of APs override API
Instead of using channel to index mapping, add the adaptive dwell
override parameters as part of the configuration per channel in the scan
request command.

Support 2 different override values and use them as follows:
1. 10 APs for friendly GO channels in p2p scan.
2. 2 APs for social channels in p2p scan.

Change-Id: I3b461108abf2306c3d054099112f2c3afce1cc92
Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We'll need this data in the future, pass the values.

Change-Id: Iaeff50716e783f5c0bcea86ca1c93ada1560525e
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add the read_config32 op to allow dumping the config space when
needed.

Change-Id: Ib2d254a38a4bfb95dcc3d04eec91781827a0c623
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add a new region type that allows us to dump the PCI config space.
This is mostly the same as dumping a memory region, but reading from
the device's config space instead.

In order to make this generic and independent of the trans type, we
make a function called iwl_dump_ini_config_iter() that calls a new op
in the transport to read its config space.

Change-Id: I15151bddf589f13b0e0a45c28b96bbcd73bcfdeb
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some devices require longer time to stabilize the power and XTAL.
This is especially true for devices integrated in the SoC.  Add
support for a new firmware API that allows the driver to set the
latency value accordingly.

Change-Id: I6829a46b89e4e701f80a0e4033f4dd41ee44ed12
Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

commit 97a32539 ("proc: convert everything to "struct proc_ops"")
forget do this convering for prism2_download_aux_dump_proc_fops.

Fixes: 97a32539 ("proc: convert everything to "struct proc_ops"")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200326032432.20384-1-yuehaibing@huawei.com

In previous setting, management packets' sequence numbers will
not increase and always stay at 0. Add hw sequence number support
for mgmt packets.
The table below shows different sequence number setting in the
tx descriptor.

seq num ctrl      | EN_HWSEQ | DISQSELSEL | HW_SSN_SEL
------------------------------------------------------
sw ctrl           |    0     |    N/A     |    N/A
hw ctrl per MACID |    1     |     0      |    N/A
hw ctrl per HWREG |    1     |     1      |HWREG(0/1/2/3)
Signed-off-by: NTzu-En Huang <tehuang@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200326020408.25218-1-yhchuang@realtek.com

We add enable dynamic suspend (autosuspend) support in host driver, and
it can let platform cut down idle power consumption.
To support autosuspend feature in host driver, kernel need to be built
with CONFIG_USB_SUSPEND and autosuspend need to be turn on.
And we also replace wowl feature with adding "needs_remote_wakeup", so
that host still can be waken by wireless device.
Signed-off-by: NWright Feng <wright.feng@cypress.com>
Signed-off-by: NChi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585124429-97371-6-git-send-email-chi-hsien.lin@cypress.com

Will enable FMAC to push more packets to bus tx queue and help
improve throughput when fws queuing is enabled. This change is
required to tune the throughput for passing WMM CERT tests.
Signed-off-by: NMadhan Mohan R <madhanmohan.r@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585124429-97371-5-git-send-email-chi-hsien.lin@cypress.com

The function brcmf_inform_single_bss returns the value as success,
even when the length exceeds the maximum value.
The fix is to send appropriate code on this error.
This issue is observed when Cypress test group reported random fmac
crashes when running their tests and the path was identified from the
crash logs. With this fix the random failure issue in Cypress test group
was resolved.
Reviewed-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NRaveendran Somu <raveendran.somu@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585124429-97371-4-git-send-email-chi-hsien.lin@cypress.com

When the brcmf_fws_process_skb() fails to get hanger slot for
queuing the skb, it tries to free the skb.
But the caller brcmf_netdev_start_xmit() of that funciton frees
the packet on error return value.
This causes the double freeing and which caused the kernel crash.
Signed-off-by: NRaveendran Somu <raveendran.somu@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585124429-97371-3-git-send-email-chi-hsien.lin@cypress.com

When the control transfer gets timed out, the error status
was returned without killing that urb, this leads to using
the same urb. This issue causes the kernel crash as the same
urb is sumbitted multiple times. The fix is to kill the
urb for timeout transfer before returning error
Signed-off-by: NRaveendran Somu <raveendran.somu@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585124429-97371-2-git-send-email-chi-hsien.lin@cypress.com

The nl80211 commands such as 'iw link' can't get current txrate
information from the driver. This commit fills in the tx rate
information from the C2H RA report in the sta_statistics function.
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200320063833.1058-3-chiu@endlessm.com

There's a data field in H2C and C2H commands which is used to
carry channel bandwidth information. Add enumeration to make it
more descriptive in code.
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200320063833.1058-2-chiu@endlessm.com

Sometimes we need to stop the coex mechanism to debug, so that we
can manually control the device through various outer commands.
Hence, add a new debugfs coex_enable to allow us to enable/disable
the coex mechanism when driver is running.

To disable coex
echo 0 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable

To enable coex
echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable

To check coex dm is enabled or not
cat /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200313033008.20070-3-yhchuang@realtek.com

Add a new entry "coex_info" in debugfs to dump coex's states for
us to debug on coex's issues.

The basic concept for co-existence (coex, usually for WiFi + BT)
is to decide a strategy based on the current status of WiFi and
BT. So, it means the WiFi driver requires to gather information
from BT side and choose a strategy (TDMA/table/HW settings).

Althrough we can easily check the current status of WiFi, e.g.,
from kernel log or just dump the hardware registers, it is still
very difficult for us to gather so many different types of WiFi
states (such as RFE config, antenna, channel/band, TRX, Power
save). Also we will need BT's information that is stored in
"struct rtw_coex". So it is necessary for us to have a debugfs
that can dump all of the WiFi/BT information required.

Note that to debug on coex related issues, we usually need a
longer period of time of coex_info dump every 2 seconds (for
example, 30 secs, so we should have 15 times of coex_info's
dump).
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: NChris Chiu <chiu@endlessm.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200313033008.20070-2-yhchuang@realtek.com

Fix the warning reported by sparse as:
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4819:17: sparse: sparse: cast from restricted __le16
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4892:17: sparse: sparse: cast from restricted __le16
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Reported-by: Nkbuild test robot <lkp@intel.com>
Acked-by: NJes Sorensen <jes@trained-monkey.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200319064341.49500-1-chiu@endlessm.com

Add mt7615_mcu_wait_response declaration in mt7615.h since it will be
reused adding usb support to mt7615 driver
Reported-by: Nkbuild test robot <lkp@intel.com>
Fixes: 044a4325 ("mt76: mt7615: introduce mt7615_mcu_wait_response")
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/d341335a636b6ccd088dd2cfeec2d296eb4dc8c7.1584534454.git.lorenzo@kernel.org

Fix cid field endianness in unified mt7615_uni_txd header
Reported-by: Nkbuild test robot <lkp@intel.com>
Fixes: 323d7daa ("mt76: mt7615: introduce uni cmd command types")
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/2447b399d3c63885d43f65ba988c057fa96f5236.1584534454.git.lorenzo@kernel.org

Convert fields in mt7663_fw_trailer and mt7663_fw_buf to little-endian
Reported-by: Nkbuild test robot <lkp@intel.com>
Fixes: f40ac0f3 ("mt76: mt7615: introduce mt7663e support")
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/d14dfd7cd91a4dda8c5dcd03e8a70ff11314182e.1584534454.git.lorenzo@kernel.org

After MAC switched power, the hardware's RF registers will have
its default value, but the default value for path B is incorrect.
So, load RF path B first, to decrease the period between MAC on
and RF path B config.

By test, if we load path A first, then there's ~300ms that the
path B is incorrect, it could lead to BT coex's A2DP glitch.
But if we configure path B first, there will only have ~3ms,
significantly lower possibility to have A2DP sound glitch.
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200318095224.12940-1-yhchuang@realtek.com

Driver used to kick off every TX packets, that will waste some
time while we can do better to kick off the TX packets once after
they are all prepared to be transmitted.

For PCI, it uses DMA engine to transfer the SKBs to the device,
and the transition of the state of the DMA engine could be a cost.
Driver can save some time to kick off multiple SKBs once so that
the DMA engine will have only one transition.

So, split rtw_hci_ops::tx() to rtw_hci_ops::tx_write() and
rtw_hci_ops::tx_kick_off() to explicitly kick the SKBs off after
they are written to the prepared buffer. For packets come from
ieee80211_ops::tx(), write one and then kick it off immediately.
For packets queued in TX queue, which come from
ieee80211_ops::wake_tx_queue(), we can dequeue them, write them
to the buffer, and then kick them off together.
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-6-yhchuang@realtek.com

Add a macro TRX_BD_IDX_MASK for access the TX/RX BD indexes.

The hardware has only 12 bits for TX/RX BD indexes, we should not
initialize a TX/RX ring or access the TX/RX BD index with a length
that is larger than TRX_BD_IDX_MASK.
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-5-yhchuang@realtek.com

Each device has only one reserved page shared with all of the
vifs, so it seems not reasonable to pass vif as one of the
arguments to rtw_fw_download_rsvd_page(). If driver is going
to run more than one vif, the content of reserved page could
not be built for all of the vifs.

To fix it, let each vif maintain its own reserved page list,
and build the final reserved page to download to the firmware
from all of the vifs. Hence driver should add reserved pages
to each vif according to the vif->type when adding the vif.

For station mode, add reserved page with rtw_add_rsvd_page_sta().
If the station mode is going to suspend in PNO (net-detect)
mode, remove the reserved pages used for normal mode, and add
new one for wowlan mode with rtw_add_rsvd_page_pno().

For beacon mode, only beacon is required to be added using
rtw_add_rsvd_page_bcn().

This would make the code flow simpler as we don't need to
add reserved pages when vif is running, just add/remove them
when ieee80211_ops::[add|remove]_interface.

When driver is going to download the reserved page, it will
collect pages from all of the vifs, this list is maintained
by rtwdev, with build_list as the pages' member. That way, we
can still build a list of reserved pages to be downloaded.
Also we can get the location of the pages from the list that
is maintained by rtwdev.

The biggest problem is that the first page should always be
beacon, if other type of reserved page is put in the first
page, the tx descriptor and offset could be wrong.
But station mode vif does not add beacon into its list, so
we need to add a dummy page in front of the list, to make
sure other pages will not be put in the first page. As the
dummy page is allocated when building the list, we must free
it before building a new list of reserved pages to firmware.
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-4-yhchuang@realtek.com

Extract skb allocation routines for rsvd_page and h2c.
These routines should also be used by USB and SDIO.

This should not change the logic at all.
memset() for pkt_info is unnecessary, just declare as {0}.
Also skb_put()/memcpy() can be replaced by skb_put_data().
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-3-yhchuang@realtek.com