Current version of the test is using "git-submodule foreach", which
requires submodules to be initialized. Non-initialized submodules are
ignored. Our CI is not performing submodule initialization, but instead
it only downloads the submodule content in tools/ci/ci_fetch_submodule.py
from cache and copies it into the submodule path.
Since we already know the submodule path from .gitconfig, we can use it
as argument to git-ls-tree and avoid calling git-submodule at all. This
allows to perform the test even if the submodules are not initialization
and also it makes the code simpler.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Previously, "soc/chip_revision.h" contained a static assert to check that the
CONFIG_ESP_REV_MIN_FULL <= CONFIG_ESP_REV_MAX_FULL. There are two issues with
this assert:
- Contained in a header file, so it is only compiled if the "chip_revision.h"
is included somewhere
- CONFIG_ESP_REV_MIN_FULL and CONFIG_ESP_REV_MAX_FULL are defined in
"esp_hw_support", which is a G0 component. This creates a reverse dependency
of G0 on G1.
This commit moves the static assert "revision.c" in "esp_hw_support".
This commit refactors the USBH and the USB Host Library in the following ways:
- USBH now presents an abstraction of an endpoint (via usbh_ep_handle_t)
- Added separate functions to enqueue/dequeue URBs to a particular endpoint
- USB Host Library no longer calls HCD API directly. Calls USBH endpoint API
instead.
- Renamed "notif_cb" to "proc_req_cb" (Processing Request Callback)
- This is to avoid confusion with FreerTOS task notifications and Host
Library client event notifications.
- The processing functions of each layer (i.e., "xxx_process()") request
calls via the "proc_req_cb"
- The main handling function (i.e., usb_host_lib_handle_events()) is
responsible for calling the required "xxx_process()" of each layer
1. Discard commit frame received at confirmed state in SAE STA
2. Bugfix NVS get values for sae pwe
3. Bugfix memory leak caused by assoc retry timer and assoc IE
4. Bugfix store nvs authmode security values
Enable FTM for ESP32C2 and update wifi libs with below fixes -
1. Bugfixes in Initiator and Responder mode
2. Fix wrong RTT value in first FTM procedure without connection
3. Update FTM calibration values for ESP32S2, S3, C3 and C2
4. Update distance estimation logic
5. Add some useful command parameters in FTM example
6. Fix bug when number of FTM measurement frames received is more
than (number_of_brusts * FTMs per brust).
Co-authored-by: Sarvesh Bodakhe <sarvesh.bodakhe@espressif.com>
idf.py spawns gdb process within a thread and uses Thread.join() to wait
for the gdb process to finish. As CTRL+C(SIGINT) is used by gdb to interrupt the
running program, we catch the SIGINT while waiting on the gdb to finish,
and try Thread.join() again.
With cpython's commit
commit a22be4943c119fecf5433d999227ff78fc2e5741
Author: Victor Stinner <vstinner@python.org>
Date: Mon Sep 27 14:20:31 2021 +0200
bpo-45274: Fix Thread._wait_for_tstate_lock() race condition (GH-28532)
this logic doesn't work anymore, because cpython internally marks the
thread as stopped when join() is interrupted with an exception. IMHO
this is broken in cpython and there is a bug report about this
https://github.com/python/cpython/issues/90882. Problem is that
waiting on a thread to finish is based on acquiring a lock. Meaning
join() is waiting on _tstate_lock. If this wait is interrupted, the
above referenced commit adds a logic that checks if the lock is help,
meaning the thread is done and marks the thread as stopped. But there is
no way to tell if the lock was acquired by us running join() or if it's
held by someone else e.g. still by the thread bootstrap code. Meaning
the thread is still running.
I may be missing something, but I don't see any reason why to spawn gdb
process within a thread. This change removes the thread and spawns gdb
directly. Instead waiting on a thread, we wait on the process to finish,
replacing join() with wait() and avoiding this problem.
Closes https://github.com/espressif/esp-idf/issues/11871
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
