In case the serialization command timeout happens, it queues a msg
with in schedular thread to process timeout and pass the active timer
as its context, but if before the timeout process is executed the
actual command completion can remove the command from serialization
and it will update the timer data to point to the newly activated
command.
Now when the timer msg is executed the timer is pointing to the newly
activated command instead of actual command which was timed out
and thus remove the new command instead of the original command.
This leads to an issue where the new active command removal is a
failure when its process is completed and thus action remains
incomplete. This can also lead to two commands getting processed at
the same time as the new command was forcefully removed.
To fix this instead of passing the timer context pass the copied
command in msg to scheduler thread and do not delete the command
from serialization if the command is not active.
Change-Id: I14b489172d0f22a9ed3b26b9c94226a4095f1dee
CRs-Fixed: 2950525
Add logic to remove preauth or roam command from serialization
depending on the state the roaming was in.
Change-Id: Ia381d040ce7e15a725eb2402896bf476d3236566
CRs-fixed: 2882994
Vdev object manager reference should be taken before enqueuing
serialization command and it should be released after dequeuing the
command from serialization queue. Currently this reference release is
done before moving the command to active queue from pending queue.
This may lead to vdev object deletion before the command is moved to
active queue and result in use after free access for vdev object.
To resolve this, release vdev object reference after moving the
serialization command to active queue.
Change-Id: Ibef0814a245abb36f526997d848cf15ef6a49a44
CRs-Fixed: 2832676
As part of activaiton of serialization command from pending to
active queue, the lock is released. In the activation API, the
same API to move non scan cmds from pending to active queue can
be called if activation fails. This reentrant API may modify the
pending queue even before the control is given back to the caller
API leading to random behavior when accesing the next cmd from pending
queue via local variables.
Add fix to update queue size from pending queue after command activation
Change-Id: I8082e2a9dd3410369967ab20196853ddfa0639a7
CRs-Fixed: 2801956
While removing command from serialization, it is possible
that with the last command removal of a vdev,
the vdev could be deleted and before attempting the
movement of command from pending vdev queue to active queue,
we need check if the serialization vdev object is valid.
Add a check to ensure that serialization vdev object is
valid before trying to move command from pending to active
for a vdev.
CRs-Fixed: 2807736
Change-Id: Iea6df72eeeb62b7868f30337e7da99039df8b23a
Remove unnecessary assignment in wlan_serialization_destroy_cmd_pool
to avoid false alarm in some static code analysis tool.
Change-Id: I6f53b9c44534dc6297cf872dce0a265e1696d90c
CRs-Fixed: 2751743
Add new scan type SCAN_FOR_CONNECT to support connection manager
infrastructure.
CRs-Fixed: 2713772
Change-Id: I631f3f0324e82ef6cd8b2befbed020649c80bc4c
In wlan_serialization_psoc_disable the timers are freed without
holding lock and at the same time the
wlan_serialization_cleanup_vdev_timers from vdev destroy handler
is accessing the timers, this result in cleanup_vdev_timers
accessing freed timer memory resulting in assert.
Fix is to free timer memory while holding timer lock. Also as the
lock can be used by vdev delete handler after freeing in
psoc_disable, move the init and deinit of the lock to psoc create
and destroy handlers respectively.
Change-Id: Idf822a91022de6b51c7ee1895f71b6fb94fedd72
CRs-Fixed: 2721064
This fixes a CFI failure in callback assignment.
Currently, the callbacks in scheduler_msg are void function
pointers. Update them to have a defined type as
scheduler_msg_process_fn_t to catch type mismatch during
compilation.
Other changes to conform to this new type include:
1. Cast callback to qdf_mc_timer_callback_t when
referencing, and back when assigning
2. Cast wlan_serialization_generic_timer_cb to
take fit into scheduler_msg
3. Cast target_if_vdev_mgr_rsp_timer_cb to fit
into scheduler_msg
Change-Id: I052bc54826d377ae92f5bcc80ca08afb6f5e01e3
CRs-fixed: 2719975
As part of activation of pending cmds after removal of a blocking cmd,
we iterate over the pdev pending list until the queue size and move
non-scan pending cmd to active queue and go to the head of the queue
in the next iteration.
Since we start from head of queue with decreased queue size value, the
last few cmds in the pending is never iterated since queue size has
already reached zero leading to cmds left in pending queue forever.
Add change to restore pending node to previous node of the command that
is moved from pending queue.
Change-Id: If500906c853f21319c04a21c8c68690a71e51ec2
CRs-Fixed: 2713555
While printing the serialization pdev queue, we are not
printing the VDEV id.
Add VDEV id while printing the serialization pdev queues
Change-Id: Ie6ecbf36da3026550fbe54137c546cf8bd7940e4
CRs-Fixed: 2703604
Revert the change for wlan_serialization_generic_timer_cb
from change I760b41b81c006187efb162d410390e1c11878b82.
The change introduced a CFI error because timer callbacks
do not expect a return status.
Change-Id: Iebb17fb82c5b3d4b1393e2b3417c766d118c0674
CRs-fixed: 2687777
Replace the implementation of checking bitmap status with a
standard API qdf_bitmap_empty
Change-Id: I22ee8c25c1d911f65ba4bfe235557444e6333ca4
CRs-Fixed: 2690914
Usage of %p instead of %pK can lead to info leak, so use %pK uppercase
K instead of k.
Change-Id: Ie4f51e053ed28045b9920f274baebef0233f070e
CRs-Fixed: 2677374
The roam sequence in LFR-3.0 is roam scan start notification
from firmware followed by roam start indication and then
roam synch,roam synch frame events. Roam start is sent
after candidate selection and host driver will disable
queues when roam start is received.
But for emergency roam trigger, firmware sends roam start
indication directly without notifying roam scan start to disable
data path queues immediately after deauth received from the AP.
So roam start is received before roam scan is started at firmware
and before candidate selection is done.
After roam start notification, host sends scan abort for all scan
on vdev by setting scan command request type to
WMI_SCN_STOP_VAP_ALL. This results in roam scan getting aborted at
firmare in emergency deauth roaming case and roaming fails.
Introduce new vdev id value based on which the scan module will
abort only host triggered scans setting the flag
WMI_SCN_STOP_HOST_VAP_ALL in the scan request.
Change-Id: I3a162c55d4a008ff986fd957bed395b39c060bb5
CRs-Fixed: 2636410
Currently for SAP case on the disconnection with the
client, host driver sends get stats command for the
disconnected peer to the FW and proceeds with the peer
deletion. There is a race condition where if the peer
gets deleted in the object manager before FW sends the
requested stats in that case host driver drops the
response from the FW.
To resolve above issue send the get stats request command
in serialization before peer delete command gets serialized
which will ensure that get stats response is processed
before peer delete in the object manager.
Change-Id: Iaa63e299ddfd3ca46c80bd79c3461c183fc0a62f
CRs-Fixed: 2664328
The active vdev bitmap used in serialization is
32bits and it is per pdev.
But in cases, where there can be more than 32 vaps
configured, the bit positions of a 32bit bitmap cannot
be used to indicate the active commands for a vdev whose
id is more than 31.
So, we need to increase active cmd vdev bitmap to support
for max number of vdev ids that is possible for a pdev.
Considering the vdev id is per psoc scope and can spread
across pdevs, increasing the size of the bitmap to max
vdevs supported per psoc.
CRs-Fixed: 2656046
Change-Id: Ic7728145b208492af218320fa84f35bb1f918aab
The current API to get if a command is present in the active
queue was executed without the lock acquired. Here, at times
we get the queue size as one, and when we actually get the command
from the active queue, we get nothing.
This could be that the command from the active queue was removed
in another context almost at the same time, when we trying to read
the command from the active queue.
To avoid this, we do the operation of reading the queue size and
reading from the active queue with the queue locks held, so no
other context could remove the command from the active queue while
we are reading the command from the active queue.
CRs-Fixed: 2644038
Change-Id: Icca019320b1ba2d7d751432142b9bad50519d701
Add change to reduce log level for the serialization deinit
debug string as part of bootlog cleanup.
Change-Id: Ibf1cf8352df053df0dba6239f503b868a870a04d
CRs-Fixed: 2623638
CSA channel switch call directly interacts with VDEV
state machine, move CSA restart to go through serialization
service.
CRs-Fixed: 2598123
Change-Id: Ic0bea64b56f54eed354e11d0873ae4423e365cca
Before iterating in pending list, use spinlock to avoid possible
race condition.
Remove function wlan_serialization_get_active_list_next_node_using_psoc
as it not being used and is part of legacy flow which is suppose to be
removed eventually.
Change-Id: I9e7cbd9db8b5a1c45915bf5291cd5011c276d0e2
CRs-Fixed: 2573425
When moving a blocking command from pending to active queue,
we release the lock and call the activation cb.
After the activation cb returns, we update the blocking cmd
waiting flag based on the active cmd node's "is_blocking" param.
If the activation cb is also resulting in removing the command,
then after the cb returns, the active cmd node is returned to the
free pool and our check fails, and we miss to update the blocking
cmd waiting flag, resulting in no further commands moving to the
active queue.
The update to the blocking command should be done atomically,
immediately after it moves to active queue and before releasing
the lock for the activation callback.
Change-Id: Idedccb16ce68bb2166fb3970cd231fe738ec6af2
CRs-Fixed: 2554767
MCL presently sends the vdev delete to firmware via serialization,
with a new requirement vdev delete cannot be sent via serialization.
So, disable the serialization for the vdev before sending the vdev
delete to firmware.
Change-Id: Ieffccaf815eff7627d39b0191a7be121e85965fd
CRs-Fixed: 2566113
In case vdev is logically deleted the serialization active timer fails
to start because it fails to get vdev ref count. Now in this case the
cmd is not removed from the active queue and is just marked
CMD_ACTIVE_MARKED_FOR_REMOVAL because CMD_MARKED_FOR_ACTIVATION is set.
Even during pdev stop as CMD_MARKED_FOR_ACTIVATION is set the command is
not removed.
Fix is to reset CMD_MARKED_FOR_ACTIVATION flag and handle it in same way
as the activate failure case.
Also reset the timer cmd after timer start failure to avoid vdev ref count
release by WLAN_SERIALIZATION_ID even when it failed to take the ref count
in first place.
Change-Id: Ic078efa8ce4ad563087381b8c95eba91894d8a48
CRs-Fixed: 2535245
Log level of some expected prints were set to error level because
of which the prints were coming frequently.
Moving log level of these expected prints from error to debug level.
Change-Id: Ifd2672cd73db02488ce3055ca5e35d423d4f4761
CRs-Fixed: 2522164
The serialization vdev destroy handlers extracts the psoc
from the vdev, and get its psoc component object.
If the pdev or psoc is NULL for some reason, we get a
crash in object manager while trying to retrieve the serialization
psoc object.
So check for valid pdev/psoc before we get the serialization psoc object.
Change-Id: I9ca45654250403a8b5fe674431251defd1aac6e8
CRs-Fixed: 2524231
As a part of vdev manager conversion, vdev delete code is
refactored. Legacy code and naming is removed. In vdev manager
operations, STA_SESSION is addressed as VDEV.
Hence WLAN_SER_CMD_DEL_STA_SESSION macro is renamed to
WLAN_SER_CMD_VDEV_DELETE.
Change-Id: I08bf6b2e69f5635d5ebc2548c18991bbb12b3985
CRs-Fixed: 2508147
The host driver serialization module currently supports upto 4
commands in non scan pending queue. This is calculated at the
wlan_serialization_vdev_create_handler() as:
max_pending_cmds = (WLAN_SER_MAX_PENDING_CMDS /
WLAN_SER_MAX_VDEVS)
But in SAP case, if multiple STA sends deauth at the same time,
4 pending commands in non scan pending queue is not sufficient
and will result in only disassoc from the first 4 STA getting
honored.
The current host wlan driver supports 3 SAP mode and
2 STA vdevs amounting to a total of 5 vdevs supported.
So calculate the total non scan pending commands for
serialization based on the total peers supported for each
mode to fix this issue.
In SAP case, maximum 32 peer are supported and for STA case,
maximum 4 pending commands for serialization. So change the
max pending commands calculation as:
max_pending_cmds = (No. of sap modes supported * 32) +
(No .of STA modes supported *4 )
For MCL case the definition of WLAN_SER_MAX_PENDING_CMDS
will be moved to Kbuild.
For WIN case, the existing maximum count will be retained.
Change-Id: Iff1d9430b45e26812b600560b08e85e6040eafef
CRs-Fixed: 2483520
Add API to support cancellation of a non-scan command to match with the
vdev and is a non-blocking serialization command.
Change-Id: I31556ea8f35b9caf314f10eba0f0f655e3fce806
CRs-Fixed: 2481935
Add change to update the doc section for the list of commands supported
by the serialization module.
Change-Id: I3534d3798291fa259c8ee4de38df8c0e8649e5ab
CRs-Fixed: 2477833
Add API to fetch the vdev queue status and avoid enqueueing command
to serialization queue if the vdev queue is found to be disabled
Change-Id: If615b07dceaeb3113592f24355f254c8e70ca8a2
CRs-Fixed: 2470208
Add change to release vdev reference only on successful removal
of active cmd from serialization active queue.
Change-Id: I2e14f7f53dc38388cdd05f029edc9329f9dd86a7
CRs-Fixed: 2463724
Rmmod process:
wlan_hdd_pld_remove --> hdd_stop_adapter --> hdd_vdev_destroy
--> WLAN_SER_CMD_DEL_STA_SESSION (25) cmd queued --> PLD_FW_DOWN
(will complete wait event as part of qdf_complete_wait_events)
--> hdd_wlan_stop_modules --> cds_disable -->
dispatcher_psoc_disable --> wlan_serialization_psoc_disable -->
wlan_serialization_timer_destroy --> umac_stop --> csr_stop -->
wlan_ser_cancel_non_scan_cmd -> check if timer is present but th
timer are already destroyed, so assert.
Move wlan_serialization_purge_cmd_list into converged API file to
be shared by MCC and WIN.
Change-Id: Iad557e4a05d682c257be0c39049c52950e5eb530
CRs-Fixed: 2451058
The serialization active command removal can happen in two ways
1. Its through wlan_serialization_remove_cmd API
2. Command times out and command timeout handler is called.
In case, cmd times out and handler is called in scheduler
context and as part of the active cmd removal,
the active cmd is removed, and release cmd cb is called
which could delete the vdev(post last reference release).
Then as part of moving cmd from pending to active,
the vdev queues are null, and we see a panic.
We take a vdev reference, when timer for active cmd is started.
For active cmd removal through wlan_serialization_remove_cmd,
we release the reference when the timer is stopped.
To avoid vdev destroy, in case command times out,
and until the command timeout handling is completed,
we hold vdev reference from when timer is started,
until timer handler completes.
Change-Id: I16b6864f75e8bf354da6f8b16c3aaa6cf39d7ac7
CRs-Fixed: 2422422
In the current implementation, we print the ser history
from index 0 to the current index of the ciruclar buffer,
so when buffer overflows we print only few recent items.
Instead, we should print all the elements in the circular buffer
starting from current index to entire length of the circular buffer.
This will print all the elements in the circular buffer
when it overflows and also takes care of printing
required items when buffer is not overflown.
Change-Id: I6c54cb34de7a1ba24ee0204004cc9a203173c66b
CRs-Fixed: 2430483
Since umac cmd is specific to the module adding cmd to serialization
queue, an API is needed to validate the umac_cmd associated with that
serialization context holding the serialization queue lock.
Change-Id: Iadb4deb17ffabd780432a29e7cbd37024fd431fe
CRs-Fixed: 2430764
There is an assert inside the serialization timer cb.
This timer cb can also be called in the scheduler context.
So if we get a scan cancel request, it is posted to scheduler
and after that command timesout, the timer cb is posted
to the scheduler.
So first the cancel is executed and the command is removed.
After that, the timer handler is executed which will find timer->cmd
to NULL.
So, by the time, the timer handler is involved in scheduler context
the command might be cancelled so we return an error when cmd is null
in timer handler cb.
Change-Id: I03651a63de88fe5c6467c5783254ffd006c663d2
CRs-Fixed: 2427323
