| Age | Commit message (Collapse) | Author |
|---|
|
'chan_stats' is (re)allocated in _mwifiex_fw_dpc() ->
mwifiex_init_channel_scan_gap(), which is called whenever the device is
initialized -- at probe or at reset.
But we only free it in we completely unregister the adapter, meaning we
leak a copy of it during every reset.
Let's free it in the shutdown / removal paths instead (and in the
error-handling path), to avoid the leak.
Ideally, we can eventually unify much of mwifiex_shutdown_sw() and
mwifiex_remove_card() (way too much copy-and-paste) to reduce the burden
on bugfixes like this. But that's work for tomorrow.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
When we shut down the device (i.e., during 'reset'), we cancel any
outstanding work, but we don't clear any work-related flags. This can
cause problems if, e.g., we begin to queue a new firmware dump or card
reset while the other one is in progress. That might leave work_flags
with a stale value, and we might begin one of these *after* we've
completely reset the device. That doesn't make sense, because all
firmware context will have been lost by then.
This fixes some forms of cascading failures, where I:
(a) force a firmware dump (cat /sys/kernel/debug/mwifiex/mlan0/device_dump)
(b) run a Wifi scan in parallel (iw mlan0 scan)
(c) the scan times out due to (a) hogging the interface
(d) the command timeout triggers another firmware dump and a reset [*]
(e) the 2nd firmware dump flag persists across the reset
(f) as soon as the interface comes back up, we trigger the pending
firmware dump
(g) subsequent commands time out again, while we are processing the
firmware dump; return to (d)
[*] Note that automatic card_reset() support is not yet implemented for
the mwifiex PCIe driver, so we won't hit *exactly* this behavior yet.
But we can see similarly-confusing behaviors today.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
If we reset because of a command timeout, we should reset this flag.
Otherwise, we might erroneously think the next command after reset is
timing out, and trigger another reset.
The above behavior effectively neuters the automatic card_reset()
behavior, as it means we will never recover from a command timeout
properly (and in fact, we might enter an infinite loop:
timeout -> reset -> (fake) timeout -> reset -> ...
This fixes a bug introduced with introduction of PCIe function level
reset support, but it was carried into the SDIO driver when it was
converted to use the same codepaths. And this is currently mostly a
problem only in the SDIO driver, because it's the only one with
automatic card_reset() support (e.g., on command timeout). But it will
be a problem for PCIe too, as I'm working on supporting automatic
card_reset() for PCIe.
Fixes: c742e623e941 ("mwifiex: sdio card reset enhancement")
Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Command buffers (skb's) are allocated by the main driver, and freed upon
the last use. That last use is often in mwifiex_free_cmd_buffer(). In
the meantime, if the command buffer gets used by the PCI driver, we map
it as DMA-able, and store the mapping information in the 'cb' memory.
However, if a command was in-flight when resetting the device (and
therefore was still mapped), we don't get a chance to unmap this memory
until after the core has cleaned up its command handling.
Let's keep a refcount within the PCI driver, so we ensure the memory
only gets freed after we've finished unmapping it.
Noticed by KASAN when forcing a reset via:
echo 1 > /sys/bus/pci/.../reset
The same code path can presumably be exercised in remove() and
shutdown().
[ 205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
[ 205.400393] ==================================================================
[ 205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28
[ 205.419040] Read of size 16 by task bash/1913
[ 205.423421] =============================================================================
[ 205.431625] BUG skbuff_head_cache (Tainted: G B ): kasan: bad access detected
[ 205.439815] -----------------------------------------------------------------------------
[ 205.439815]
[ 205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
[ 205.456709] alloc_debug_processing+0x124/0x178
[ 205.461282] ___slab_alloc.constprop.58+0x528/0x608
[ 205.466196] __slab_alloc.isra.54.constprop.57+0x44/0x54
[ 205.471542] kmem_cache_alloc+0xcc/0x278
[ 205.475497] __build_skb+0x48/0x114
[ 205.479019] __netdev_alloc_skb+0xe0/0x170
[ 205.483244] mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
[ 205.488759] mwifiex_init_fw+0x40/0x6cc [mwifiex]
[ 205.493584] _mwifiex_fw_dpc+0x158/0x520 [mwifiex]
[ 205.498491] mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
[ 205.503510] mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
[ 205.509643] pci_reset_notify+0x5c/0x6c
[ 205.513519] pci_reset_function+0x6c/0x7c
[ 205.517567] reset_store+0x68/0x98
[ 205.521003] dev_attr_store+0x54/0x60
[ 205.524705] sysfs_kf_write+0x9c/0xb0
[ 205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
[ 205.535064] free_debug_processing+0x264/0x370
[ 205.539550] __slab_free+0x84/0x40c
[ 205.543075] kmem_cache_free+0x1c8/0x2a0
[ 205.547030] __kfree_skb+0xb0/0xbc
[ 205.550465] consume_skb+0x164/0x178
[ 205.554079] __dev_kfree_skb_any+0x58/0x64
[ 205.558304] mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
[ 205.563817] mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
[ 205.569164] mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
[ 205.574353] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[ 205.580398] pci_reset_notify+0x5c/0x6c
[ 205.584274] pci_dev_save_and_disable+0x24/0x6c
[ 205.588837] pci_reset_function+0x30/0x7c
[ 205.592885] reset_store+0x68/0x98
[ 205.596324] dev_attr_store+0x54/0x60
[ 205.600017] sysfs_kf_write+0x9c/0xb0
...
[ 205.800488] Call trace:
[ 205.802980] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190
[ 205.808415] [<ffffffc00020a96c>] show_stack+0x20/0x28
[ 205.813506] [<ffffffc0005d020c>] dump_stack+0xa4/0xcc
[ 205.818598] [<ffffffc0003be44c>] print_trailer+0x158/0x168
[ 205.824120] [<ffffffc0003be5f0>] object_err+0x4c/0x5c
[ 205.829210] [<ffffffc0003c45bc>] kasan_report+0x334/0x500
[ 205.834641] [<ffffffc0003c3994>] check_memory_region+0x20/0x14c
[ 205.840593] [<ffffffc0003c3b14>] __asan_loadN+0x14/0x1c
[ 205.845879] [<ffffffbffc46171c>] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
[ 205.854282] [<ffffffbffc461864>] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
[ 205.862421] [<ffffffbffc462028>] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
[ 205.870302] [<ffffffbffc4620d4>] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
[ 205.877736] [<ffffffbffc1397a8>] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
[ 205.884658] [<ffffffbffc4606b4>] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[ 205.892446] [<ffffffc000635f54>] pci_reset_notify+0x5c/0x6c
[ 205.898048] [<ffffffc00063a044>] pci_dev_save_and_disable+0x24/0x6c
[ 205.904350] [<ffffffc00063cf0c>] pci_reset_function+0x30/0x7c
[ 205.910134] [<ffffffc000641118>] reset_store+0x68/0x98
[ 205.915312] [<ffffffc000771588>] dev_attr_store+0x54/0x60
[ 205.920750] [<ffffffc00046f53c>] sysfs_kf_write+0x9c/0xb0
[ 205.926182] [<ffffffc00046dfb0>] kernfs_fop_write+0x184/0x1f8
[ 205.931963] [<ffffffc0003d64f4>] __vfs_write+0x6c/0x17c
[ 205.937221] [<ffffffc0003d7164>] vfs_write+0xf0/0x1c4
[ 205.942310] [<ffffffc0003d7da0>] SyS_write+0x78/0xd8
[ 205.947312] [<ffffffc000204634>] el0_svc_naked+0x24/0x28
...
[ 205.998268] ==================================================================
This bug has been around in different forms for a while. It was sort of
noticed in commit 955ab095c51a ("mwifiex: Do not kfree cmd buf while
unregistering PCIe"), but it just fixed the double-free, without
acknowledging the potential for use-after-free.
Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
A separate wifi-only firmware was download during pcie function level
reset. It is in fact the tail part of wifi/bt combo firmware. Per
Brian's and Dmitry's suggestion, this patch extract the wifi part from
combo firmware.
After that, the mrvl/pcie8997_wlan_v4.bin image in linux-firmware repo
is redundant (though I guess we keep it around to support older
kernels).
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
This patch correct pcie scratch register name, to keep the same with
chipset side definition.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
mwifiex_dbg will do nothing before adapter->dev get assigned. several logs
lost in this case. it can be avoided by fall back to pr_info.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
If wakeup interrupt handler is called, we know that the wakeup
interrupt number is valid, there is no need to check it.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan
request that should be randomized; the absence of such a flag means we
should not randomize. However, mwifiex was stashing the latest
randomization request and *always* using it for future scans, even those
that didn't set the flag.
Let's zero out the randomization info whenever we get a scan request
without NL80211_SCAN_FLAG_RANDOM_ADDR. I'd prefer to remove
priv->random_mac entirely (and plumb the randomization MAC properly
through the call sequence), but the spaghetti is a little difficult to
unravel here for me.
Fixes: c2a8f0ff9c6c ("mwifiex: support random MAC address for scanning")
Cc: <stable@vger.kernel.org> # 4.9+
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
If iwl_pcie_ctxt_info_init_fw_sec() fails, the previous allocated DMA
memory needs to be freed (it even goes out of scope immediately.)
Do that to prevent the leak.
Fixes: eda50cde58de ("iwlwifi: pcie: add context information support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
If the context info fails to be allocated, the mutex
isn't unlocked properly, fix that.
Fixes: eda50cde58de ("iwlwifi: pcie: add context information support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When FW fails to get block ack, it will send the notification with
0 items in the TFD queue elements. Allow this and handle accordingly.
Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Memory offsets and lengths for A000 HW is different
than currently specified.
Fixes: e34d975e40ff ("iwlwifi: Add a000 HW family support")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In a000 CDB firmware, we cannot update phy context to a
different band - we must first remove it and add it
again. Support this flow for all a000 devices since
we may have various combinations that cause us to fail
regardless if CDB is active.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Address 4 is reversed as well.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The notification infrastructure (iwl_notification_wait_*
functions) allows to wait until a list of notifications
will come up from the firmware and to run a special handler
(notif_wait handler) when those are received.
The operation mode notifies the notification infrastructure
about any Rx being received by the mean of
iwl_notification_wait_notify() which will do two things:
1) call the notif_wait handler
2) wakeup the thread that was waiting for the notification
Typically, only after those two steps happened, the
operation mode will run its own handler for the notification
that was received from the firmware. This means that the
thread that was waiting for that notification can be
running before the operation mode's handler was called.
When the operation mode's handler is ASYNC, things get even
worse since the thread that was waiting for the
notification isn't even guaranteed that the ASYNC callback
was added to async_handlers_list before it starts to run.
This means that even calling
iwl_mvm_wait_for_async_handlers() can't guarantee that
absolutely everything related to that notification has run.
The following can happen:
Thread sending the command Operation mode's Rx path
-------------------------- ------------------------
iwl_init_notification_wait()
iwl_mvm_send_cmd()
iwl_mvm_rx_common()
iwl_notification_wait_notify()
iwl_mvm_wait_for_async_handlers()
// Possibly free some data
// structure
list_add_tail(async_handlers_list);
schedule_work(async_handlers_wk);
// Access the freed structure
Split the 'run notif_wait's handler' and the 'wake up the
thread' parts to fix this. This allows the operation mode
to do the following:
Thread sending the command Operation mode's Rx path
-------------------------- ------------------------
iwl_init_notification_wait()
iwl_mvm_send_cmd()
iwl_mvm_rx_common()
iwl_notification_wait()
// Will run the notif_wait's handler
list_add_tail(async_handlers_list);
schedule_work(async_handlers_wk);
iwl_notification_notify()
iwl_mvm_wait_for_async_handlers()
This way, the waiter is guaranteed that all the handlers
have been run (if SYNC), or at least enqueued (if ASYNC)
by the time it wakes up.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Currently when rate isn't found (invalid rate or CCK rate in high
band) driver is assigning rate -1, which causes mac80211 to dump
it later with the cryptic rate value of 0xFF.
Instead, warn early and dump the frame in mvm.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
For a000 devices, we don't really have multi RX queue for now,
until we have the RX queue configuration API.
Disable RX queue notification for now.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When we load firmware in extended mode (as we do by default for
now) driver should send a command what kind of commands ucode
should stop and wait for before proceeding with phy calibrations.
Support this command. Currently we only do NVM access - so mark
this bit only.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
To utilize the maximum allowed tx power, an additional table was added
to the BIOS. The table consists of up to seven different regions
(currently only three are in use). Each region contains per band:
1. Maximum allowed tx power on the band.
2. Tx power offset for chain A.
3. Tx power offset for chain B.
On init flow driver reads this table by means of ACPI and
passes it to the firmware with GEO_TX_POWER_LIMIT cmd.
The firmware will use this table to enhance tx power with
the offset in the relevant table as well as verifying it does not
violate the maximum allowed tx power.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
This workaround is not needed anymore. Remove it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Identify and load FW for a000 CDB product.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
API was changed once more to support 2 LMACs.
Adapt to change while preserving current functionality.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Add one new PCI ID for the 8265 series.
Add three new PCI ID for the 8275 series.
Signed-off-by: Tzipi Peres <tzipi.peres@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In the end, the firmware doesn't want the SP len as present
in the WMM IE, but rather the actual number of frames.
Fixes: bd3c6cf901a8 ("iwlwifi: mvm: tell the firmware about the U-APSD parameters")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When we get SN that is smaller than SSN of the aggregation,
we shouldn't apply any reordering on them.
Further more, HW NSSN will be zeroed, which can cause us
to make some invalid decisions.
Detect the situation and invalidate the BAID.
Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Change the value of TX_CMD_SEC_KEY_FROM_TABLE flag
in TX_CMD security flags to accommodate a FW API change.
Bump min API for 9000 series devices to 30 to keep the driver aligned
aligned the FW.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Seems like HW is reversing addr3 in the MAC header of de-aggregated
AMSDU. Reverse it back.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
This flag is used for mac80211 reordering. As we do reordering
ourselves, turning it on is misleading and pointless.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Not only that this write is not needed (as FW does this
itself), on newer HW this register is write protected
so trying to write there will cause problems.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In TVQM firmware returns the value of the queue ID and code
should accept it.
The TX queue config API was changed. Move to new API.
This has to be done in parallel in mvm and pcie.
Do not move yet to 512 queues since there are some opens
with enabling it.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In TVQM mode the TX responses were changed to include
queue number since legacy TX queue number retrieval cannot
be scaled up to 512 queues.
Support this change.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In TVQM mode the queue ID is assigned after enablement.
Get rid of assuming pre-defined TX queue ID in functions
that will be used by TVQM allocation path.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The "invalid" label was a bit ugly and unnecessary. Remove it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Change queue allocation to be dynamic. On transport init only
the command queue is being allocated. Other queues are allocated
on demand.
This is due to the huge amount of queues we will soon enable (512)
and as a preparation for TX Virtual Queue Manager feature (TVQM),
where firmware will assign the actual queue number on demand.
This includes also allocation of the byte count table per queue
and not as a contiguous chunk of memory.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
This function is basically the same as gen1, except for clean
ups of old devices configuration that are never used in a000
configuration.
It will also help with refactoring rf_kill later on.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In a000 transport we will allocate queues dynamically.
Right now queue are allocated as one big chunk of memory
and accessed as such.
The dynamic allocation of the queues will require accessing
the queues as pointers.
In order to keep simplicity of pre-a000 tx queues handling,
keep allocating and freeing the memory in the same style,
but move to access the queues in the various functions as
individual pointers.
Dynamic allocation for the a000 devices will be in a separate
patch.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
New transport will be used only by op modes that supports
buffer station offload - hence those will never be called.
Clean it up.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In a000 devices we have 16 bytes for the TFD index and 16 for the
queue, in order to support 512 queues.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Code is basically the same, with a cleanups of old narrow host
command, ampg workarounds, some cosmetic stuff, and usage of
TFH functions when accessing TFD queues.
This enables also the cleanup of iwl_pcie_tfd_set_tb() since
now it won't be called anywhere in the a000 data path
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Move to use the correct structure.
Remove code referring to old command.
Update DMA locations.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Cleanup code that is irrelevant for a000 devices.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
By moving all the code that depends on the new API
we avoid unnecessary indentation in the code.
Signed-off-by: Mordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Newer firmware versions will be able to handle all the
WMM-PS flows internally when we act as a GO. The firwmare
relies on the fact that the drivers puts frames for
different peers in different queues (DQA) to achieve this.
The driver will not be aware of the power state of the peers
anymore.
Tell the firmware about the WMM-PS parameters of earch peer
that connects to us so that it can know what are the
trigger-enabled ACs, the delivery-enableds ACs and the
Service Period length.
This API change is backward compatible since older firmware
versions will simply ignore the newly added values.
Since we don't support ieee80211 TSPECs for now, just copy
the trigger-enabled ACs to the delivery enabled ones.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
There are several occasions where a scan of the same type is requested
concurrently, so logging every time this happens is just noisy and
unnecessary. Remove the logging for these cases.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
This is just a copy-paste in order to make changes tracking
easier.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
For a000 FW moved to 15 as management TID.
The change for us is fairly local - translate old TID to 15
when enabling and disabling a queue, and make sure to cover
it also on TX responses.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
a000 devices queue management is going to change significantly.
We will have 512 queues. Those queues will be assigned number
by the firmware and not by the driver.
In addition, due to SN offload having TX queue shared between TIDs
is impossible
Also, the ADD_STA command no longer updates queues status.
The only point of changing queue in the SCD queue config API.
From driver perspective we have here a new design:
Queue sharing and inactivity checks are disabled.
Once this is done, the only paths that call scd_queue_cfg command
are paths that alloc and release TX queues - which will make future
accommodation to queue number assignment by FW easier.
Since allocating 512 queues statically is not advisable, transport
will allocate the queue on demand, fill the command with DRAM data
and send it. This is reflected in the new transport API.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In a000 devices the TX handling is different in a few ways:
* Queues are allocated dynamically
* DQA is enabled by default
* Driver shouldn't access TFH registers - ucode configures it
all in SCD_QUEUE_CFG command
Support all this in a new API with op mode, where op mode sends
the command, transport will allocate the queue dynamically, fill
in DMA properties, send the command to FW and get the ID back.
Current implementation only sets the new transport API and fills
the DMA properties.
Future patches will complete the other parts.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
