commit | f1e9b5086718ad567dc40e3d5a1456534d51749f | [log] [tgz] |
---|---|---|
author | CrOS WpaSupplicant Merge Bot <chromeos-wpa-supplicant-merge-automation@prod.google.com> | Sat Jun 15 21:14:18 2024 |
committer | Chromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Jun 25 19:36:05 2024 |
tree | 1dfce3335de6c7f6521febf178a8c0210c91c941 | |
parent | bae228239be0aa07b96baa50f433034bfc8e3237 [diff] | |
parent | cb5c4e49c725c14591b88e22fc46b00ffc20384a [diff] |
CHROMIUM: merge-cb5c4e49c from branch/tag: upstream/main into branch: wpa_supplicant-2.10.0 Changelog: ------------------------------------------------------------- Aditya Kumar Singh (7): AP MLD: Fix deferred first link BSS's authentication server init hostapd: Add support to change BSS color from the control interface Remove double "on" from debug prints in CCA event callbacks Update Beacon frames after color change AP MLD: Send link id to the driver during color change tests: Add HE BSS color change test tests: Add color change test for an AP MLD Balamurugan Mahalingam (1): Add a new QCA vendor attribute to set interface offload type Harshitha Prem (1): ACS: Handle scan start request failure with error code -EBUSY Jianmin Zhu (1): Add vendor attributes to detect data stall for consecutive TX no ack Jouni Malinen (9): WNM: Configurable BSS Max Idle Period management on AP WNM: Group rekeying skipping with BSS max idle period management tests: More coverage for WNM BSS max idle period management tests: Use consistent indentation level for clear_regdom_state() WNM: Allow a specific BSS max idle period to be requested WNM: AP configuration to allow BSS max idle period requests WNM: Include BSS max idle period in STATUS command output tests: WNM BSS max idle period management wlantest: Initial support for Multiple BSSID procedure Kiran Kumar Lokere (1): Add new traffic type values for flow report vendor attribute BUG=b:347478091 TEST=ran wifi_matfunc, wifi_perf and hwsim tests. Change-Id: Iaf54176c046a8bd959e602d215e1bfd273eaffd4 Signed-off-by: CrOS WpaSupplicant Merge Bot <chromeos-wpa-supplicant-merge-automation@prod.google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/hostap/+/5630421 Tested-by: Kaidong Wang <kaidong@chromium.org> Reviewed-by: Jintao Lin <jintaolin@chromium.org> Reviewed-by: Matthew Wang <matthewmwang@chromium.org> Commit-Queue: Kaidong Wang <kaidong@chromium.org>
This documents how to develop, test, and submit code to wpa_supplicant in ChromeOS.
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
sudo -u wpa -g wpa wpa_cli
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 \ ...
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.
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).