aboutsummaryrefslogtreecommitdiff
path: root/include/uapi/linux/ax25.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2023-12-31 12:51:25 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2023-12-31 12:51:25 -0800
commit610a9b8f49fbcf1100716370d3b5f6f884a2835a (patch)
treeb6ae7b3d197e7285faec7ea897162b451bb9189e /include/uapi/linux/ax25.h
parent2639772a11c860628c5f7007842eca52a1c34d78 (diff)
Linux 6.7-rc8v6.7-rc8
Diffstat (limited to 'include/uapi/linux/ax25.h')
0 files changed, 0 insertions, 0 deletions
generated by cgit
lt;kvalo@codeaurora.org> 2018-11-06iwlegacy: 4965-mac: mark expected switch fall-throughGustavo A. R. Silva1-1/+1 In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 2018-10-13iwlegacy: Add a lock assertion in il4965_send_rxon_assoc()Jia-Ju Bai1-0/+2 The variables il->staging.filter_flags, rxon1->filter_flags and rxon2->filter_flags need to be protected by the mutex lock il->mutex. This patch adds a lock assertion of il->mutex to check whether this lock is held. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 2018-10-13iwlwifi: mvm: check return value of rs_rate_from_ucode_rate()Luca Coelho1-5/+19 The rs_rate_from_ucode_rate() function may return -EINVAL if the rate is invalid, but none of the callsites check for the error, potentially making us access arrays with index IWL_RATE_INVALID, which is larger than the arrays, causing an out-of-bounds access. This will trigger KASAN warnings, such as the one reported in the bugzilla issue mentioned below. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=200659 Cc: stable@vger.kernel.org Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 2018-10-08iwlwifi: mvm: kill INACTIVE queue stateJohannes Berg4-115/+66 We don't really need this state: instead of having an inactive state where we can awaken zombie queues again if needed, just keep them in their normal state unless a new queue is actually needed and there's no other way of getting one. We do this here by making the inactivity check not free queues unless instructed that we now really need to allocate one to a specific station, and in that case it'll just free the queue immediately, without doing any inactivity step inbetween. The only downside is a little bit more processing in this case, but the code complexity is lower. Additionally, this fixes a corner case: due to the way the code worked, we could only ever reuse an inactive queue if it was the reserved queue for a station, as iwl_mvm_find_free_queue() would never consider returning an inactive queue. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> 2018-10-08iwlwifi: mvm: move iwl_mvm_sta_alloc_queue() downJohannes Berg1-205/+205 We want to call iwl_mvm_inactivity_check() from here in the next patch, so need to move the code down to be able to. Fix a minor checkpatch complaint while at it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> 2018-10-08iwlwifi: mvm: make iwl_mvm_scd_queue_redirect() staticJohannes Berg2-7/+3 This function is only used in the file where it's declared, so just make it static. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> 2018-10-08iwlwifi: mvm: make queue TID change more explicitJohannes Berg1-28/+25 Instead of iterating all the queues after having potentially changed some queue configurations, rechecking if that was done, mark the ones that do need a TID change explicitly in a bitmap and use that to send the change to the firmware. While at it, also rename iwl_mvm_change_queue_owner() to iwl_mvm_change_queue_tid() since that's more obvious - the "kind" of owner isn't immediately clear right now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> 2018-10-08iwlwifi: mvm: remove RECONFIGURING queue stateJohannes Berg2-26/+15 We set the queue to this state, only to pretty much immediately move it out of it again. However, we can't even hit any of the code that checks if the queue is reconfiguring, because all of this happens under mvm->mutex and we hold the all the way from marking the queue as RECONFIGURING to marking it as READY again. Additionally, the queue that became RECONFIGURING would've been in SHARED state before, and it can safely stay in that state. In case of errors, it previously would have stayed in RECONFIGURING which it could never have left again. Remove the state entirely and just track the queues that need to be reconfigured in a separate, local, bitmap. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> 2018-10-08iwlwifi: mvm: reconfigure queues during inactivity checkJohannes Berg1-11/+7 We currently reconfigure the queues after the inactivity check, but only in one of the two callers. This might leave queues in a state where the TID owner is wrong, if called when reserving a queue for a new station. Clean this up and do the reconfiguration inside the inactivity check function. This requires changing the locking, but one of the two places already holds the mvm mutex and the other easily can. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> 2018-10-08iwlwifi: mvm: move queue reconfiguration into new functionJohannes Berg1-31/+33