Google Git
Sign in
chromium / chromiumos / third_party / hostap / refs/heads/stabilize-15926.B-wpa_supplicant-2.10.0
commitbae228239be0aa07b96baa50f433034bfc8e3237[log] [tgz]
authorRuth Mekonnen <rmekonnen@chromium.org>Fri Apr 05 07:52:22 2024
committerChromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com>Thu Jun 13 19:17:05 2024
tree3bc50024d41b4236e0ed0c9088732098fda78e27
parent1782380eee10979d9b39c75c836843d6d7456928 [diff]
BACKPORT: FROMLIST: [v3] Emit ScanInProgress6GHz property

Expose whether a 6GHz scan is in progress with the
ScanInProgress6GHz property and flush properties as soon as the
property is updated, so that platforms can choose not to
disconnect while a 6GHz scan is in progress. Once the 6GHz scan
has completed and scan results have been received, the
ScanInProgress6GHz property is reset to false.

Signed-off-by: Ruth Mekonnen <rmekonnen@chromium.org>
(am from https://patchwork.ozlabs.org/patch/1947110/)
(also found at https://marc.info/?i=20240612200948.3322887-1-rmekonnen@chromium.org)

Conflicts:
   wpa_supplicant/events.c - Conflicts caused by crrev/c/5598858
which has not been merged upstream yet

BUG=b:335462190
TEST=apply chromium:5623671, then tast run
wifi.SuspendStress.6ghz* should pass
UPSTREAM-TASK=b:335009805

Change-Id: I04f3b53f3d06e71b89e63928ec2b0aa5127af142
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/hostap/+/5630695
Tested-by: Ruth Mekonnen <rmekonnen@google.com>
Reviewed-by: Matthew Wang <matthewmwang@chromium.org>
Commit-Queue: Ruth Mekonnen <rmekonnen@google.com>
9 files changed
tree: 3bc50024d41b4236e0ed0c9088732098fda78e27
  1. doc/
  2. eap_example/
  3. hostapd/
  4. hs20/
  5. radius_example/
  6. src/
  7. tests/
  8. wlantest/
  9. wpa_supplicant/
  10. wpadebug/
  11. wpaspy/
  12. .gitignore
  13. Android.mk
  14. build_release
  15. CONTRIBUTIONS
  16. COPYING
  17. DIR_METADATA
  18. OWNERS
  19. PRESUBMIT.cfg
  20. README
  21. README.md
  22. unblocked_terms.txt
README.md

Contributing to wpa_supplicant in CrOS

This documents how to develop, test, and submit code to wpa_supplicant in ChromeOS.

Build and deploy

This follows the standard ChromeOS development flow:

cros-workon-${BOARD} wpa_supplicant-cros
emerge-${BOARD} wpa_supplicant-cros
cros deploy ${DUT} wpa_supplicant-cros

Note that wpa_supplicant-cros/current and wpa_supplicant-cros/next are identical. This is a vestige of how we used to uprevs, but now that we've converted to automated merges, we no longer regularly use both directories other than for the occasional rollout of a new feature flag. Please develop in wpa_supplicant-cros/current.

To restart wpa_supplicant after deploying:

(DUT) # restart wpasupplicant

Testing

  1. If applicable, implement the appropriate shill hooks (e.g. supplicant_interface_proxy_interface.h) and execute the appropriate shill flow. See go/shill-cheatsheet for shill development tips.
  2. Use the wpa_supplicant command line interface wpa_cli:
sudo -u wpa -g wpa wpa_cli
  1. Use dbus-send:
dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 \
	/fi/w1/wpa_supplicant1/Interfaces/0 \
        fi.w1.wpa_supplicant1.Interface.AddNetwork \
	...

or gdbus:

gdbus call --system --dest fi.w1.wpa_supplicant1 --object-path \
	/fi/w1/wpa_supplicant1/Interfaces/0 --method \
	fi.w1.wpa_supplicant1.Interface.AddNetwork \
	...
  1. Use hostap_hwsim
  2. Run matfunc tests

Uploading to Gerrit

We try to follow kernel conventions detailed here. For trivial changes, feel free to send them upstream without internal review (see below for more details). Otherwise, upload them with a WIP: prefix to indicate that you'd like internal feedback first. After getting a +1 from relevant reviewers, you should send the patch upstream. For time-sensitive changes, we allow landing the change as FROMLIST with an UPSTREAM-TASK tag at the end specifying a bug number to track the task of upstreaming the change. Please also add the CrOSWiFi-PendingUpstreamReview hotlist to the task and add the patch to go/cros_supplicant_patches. For other changes, we prefer landing the change as UPSTREAM or BACKPORT to avoid accruing technical debt.

If you‘ve landed your change as FROMLIST, make sure to monitor the hostap mailing list so you can revise your patch if necessary. After it has been accepted upstream, revert the original FROMLIST patch and land it as UPSTREAM (or BACKPORT) to update the change to its latest version if necessary. There’s no need to do this if there is no diff between the UPSTREAM and FROMLIST patches. An easy way to do this is to run the following command:

diff <(git show ${FROMLIST_HASH}) <(git show ${UPSTREAM_HASH})

Note that there will always be diffs, but you can skip relanding as long as these diffs are part of the patch itself. Remember to close the task that was opened to track upstreaming, and remove the patch from go/cros_supplicant_patches.

Contributing upstream

For convenience, we suggest subscribing to the hostap mailing list so that your patches will be automatically posted to the list without approval. Note that DMARC restrictions may prevent subscribing to the mailing list with your @google.com email. Sending changes upstream is fairly similar to the kernel process. Follow those instructions to set up your git configuration and for best practices with respect to patch titling and formatting. Note that our wpa_supplicant repository already contains an upstream/main branch that you can use to make sure the patch applies cleanly upstream. Once you are ready to send your patch(es), you can send them to j@w1.fi (Jouni Malinen, the maintainer) and hostap@lists.infradead.org (the mailing list).