Gate PAST on SOC_ESP_NIMBLE_CONTROLLER, mark randomized advertising
channel indexing host columns as NA, and limit controller experimental
status to NimBLE controllers except ESP32-C2.
(cherry picked from commit 7891e0d65a)
Co-authored-by: Wei Yuhan <weiyuhan@espressif.com>
Mark ISOAL/ISO features as experimental when SOC_BLE_ISO_SUPPORTED,
add unsupported Core Spec 6.1-6.3 features, and move NimBLE LL Extended
Feature Set target to 2026/12.
(cherry picked from commit bacdf4ba93)
Co-authored-by: Wei Yuhan <weiyuhan@espressif.com>
Document the create --format option (SPDX 2.2 tag/value and JSON, SPDX 3.0.1
JSON-LD, and CycloneDX 1.6) and the new --file option on idf.py sbom-create and
sbom-check, and generalize the previously SPDX-only wording. Note the NVDAPIKEY
variable for faster online scans, document that sbom-check exits with a non-zero
status when vulnerabilities are found, drop an unused link target, and update the
SBOM reference link. Fix the section heading levels to follow the esp-docs
conventions.
Add USB DFU and OTG console SOC capability flags for esp32s2, esp32s3, and esp32p4.
Use these caps in Kconfig, documentation conditionals, and idf.py DFU actions so USB support
is derived from SOC capabilities instead of hardcoded target names.
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
Restore the use_secure_element field in esp_tls_cfg_t, esp_tls_cfg_server_t
and httpd_ssl_config_t, and esp_transport_ssl_use_secure_element(), as
deprecated no-ops so that existing code keeps compiling. Setting them now
fails at runtime with ESP_ERR_NOT_SUPPORTED, as the feature is accessed
via the esp_key_config_t interface. To be removed in the next major release.
No compile-time deprecation attribute on this release branch; the field and
function stay warning-free here and carry only documentation notes.
Correct "802.154" to "802.15.4" and change the EUI-64 derivation notation
from base_mac[0:3]/base_mac[3:6] to the inclusive base_mac[0:2]/base_mac[3:5]
in the esp32h2/esp32h21/esp32h4 Kconfig.mac help text and the EN/zh_CN
misc_system_api docs.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit 811c64c17c)
Add help text to the esp32h2/esp32h21/esp32h4 Kconfig.mac explaining
that these chips only consume one universally administered MAC address:
the IEEE 802.154 EUI-64 is derived from the base MAC and MAC_EXT, and
Bluetooth reuses the base MAC as-is (no BT offset, since there is no
Wi-Fi).
Add a matching 1-MAC derivation table and note to misc_system_api.rst
(EN and zh_CN) under a new `.. only:: esp32h2 or esp32h21 or esp32h4`
block, and exclude these targets from the generic 4/2 table.
Add an esp32s31-only note stating that the "Four" option may only be
used with a customer-provided custom base MAC range, since ESP32-S31
only provides two universally administered MAC addresses in eFuse.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit e3bc260178)
