Skip to content
This repository was archived by the owner on Nov 14, 2024. It is now read-only.

Fix/assoc resp ies #155

Merged
merged 2 commits into from
Feb 27, 2024
Merged

Fix/assoc resp ies #155

merged 2 commits into from
Feb 27, 2024

Conversation

krish2718
Copy link
Collaborator

No description provided.

@krish2718
[nrf noup] zephyr: Fix association response event processing
29ead88 
fixup! [nrf noup] zephyr: Redesign the events passing to wpa_supplicant from driver

Perform a deep copy of all pointers in the association response event.

Fixes SHEL-2515.

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
@NordicBuilder NordicBuilder mentioned this pull request Feb 25, 2024
Merged
@sachinthegreen sachinthegreen added this to the 2.6.0 milestone Feb 26, 2024
@krish2718
[nrf noup] zephyr: Fix deep copy of remaining events
3cd4b4b 
fixup! [nrf noup] zephyr: Redesign the events passing to wpa_supplicant from driver

The dynamic data for these events are not deep copied.

Fixes SHEL-2515.

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
@sachinthegreen sachinthegreen modified the milestones: 2.6.0, 2.1.0 Feb 26, 2024
@VivekUppunda
Copy link

Just a generic comment. Would it be better to move that function - wpa_supplicant_event_wrapper to a switch statement block at some future time?

@krish2718
Copy link
Collaborator Author

Just a generic comment. Would it be better to move that function - wpa_supplicant_event_wrapper to a switch statement block at some future time?

Sure, but compiler will do it anyway. I have raised a Jira to revamp this entire design, we can do it then. Thanks.

@krish2718 krish2718 merged commit c66e5de into nrfconnect:main Feb 27, 2024
1 check passed
@krish2718 krish2718 deleted the fix/assoc_resp_ies branch February 27, 2024 14:14
@VivekUppunda
Copy link

VivekUppunda commented Feb 28, 2024 •
edited
Loading

Just a generic comment. Would it be better to move that function - wpa_supplicant_event_wrapper to a switch statement block at some future time?

Sure, but compiler will do it anyway. I have raised a Jira to revamp this entire design, we can do it then. Thanks.

Hi Chaitanya,
As far as I have read previously and understand, a switch table is normally created into a jump table by most compilers while an if-else statement would normally be created into a binary tree. What I have read is that if the number of elements in the check is less - an if-else statement is faster but if the number of elements to check progressively increases a switch statement is faster. Whether speed is a requirement here, i think we can always decide if it matters in this case.
But, in this case the compiler is optimizing it, i think it is very good

Thanks and regards
Vivek

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@sachinthegreen sachinthegreen sachinthegreen approved these changes

@VivekUppunda VivekUppunda VivekUppunda approved these changes

@jukkar jukkar Awaiting requested review from jukkar jukkar is a code owner

@rado17 rado17 Awaiting requested review from rado17 rado17 is a code owner

@rlubos rlubos Awaiting requested review from rlubos rlubos is a code owner

@ajayparida ajayparida Awaiting requested review from ajayparida

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
2.6.0
Development

Successfully merging this pull request may close these issues.
3 participants
@krish2718 @VivekUppunda @sachinthegreen