supported:ble vs supported:bluetooth for BLE-capable boards

[travle1]

I want to make sure I understand the intended Zephyr platform metadata convention before assuming there’s an issue here.

I ran into this while testing a Bluetooth LE application on the Silicon Labs xG24 and Seeed XIAO MG24. The application uses the normal Zephyr Bluetooth APIs such as bt_enable(), bt_le_adv_start(), and bt_le_adv_update_data().

It builds successfully for nrf52840dk/nrf52840, xg24_dk2601b, and xiao_mg24.

The Twister metadata contains:

depends_on:
  - ble

The nRF52840 DK is not filtered by that dependency, but the xG24 DK and XIAO MG24 are both filtered with:

No hardware support for {'ble'}

Looking at the board metadata, the nRF52840 DK advertises ble, while the two MG24 boards advertise bluetooth:

# nrf52840dk/nrf52840
supported:
  - ble

# xg24_dk2601b and xiao_mg24
supported:
  - bluetooth

Twister appears to compare these as literal strings in testplan.py:

dep_intersection = ts.depends_on.intersection(set(plat.supported))

So ble and bluetooth are not treated as aliases.

I checked the history to see if the two names are intentionally different platform capabilities. supported: ble and depends_on: ble go back to 2017, while supported: bluetooth appeared later. Silicon Labs added supported: bluetooth in 2024 during a cleanup that also removed bluetooth from testing.ignore_tags.

I couldn’t find documentation or schema definitions that explain a semantic distinction between ble and bluetooth.

Is ble vs bluetooth an intentional distinction in Zephyr platform metadata? For a BLE-capable board, should supported contain ble, bluetooth, or both?

I don’t want to submit a patch without understanding what the intended convention is first. The hardware itself seems fine. Both MG24 targets build the BLE application successfully.

[MLuc24]

There is no intentional distinction, and the reason the two spellings drifted apart is that nothing constrains them. scripts/schemas/twister/platform-schema.yaml declares the field as free-form:

      supported:
        type: array
        items:
          type: string

No enum, no vocabulary, no validation. Combined with the literal set intersection you found in testplan.py, that means ble and bluetooth are simply two unrelated strings that nobody could have been warned about mistyping.

As for which one is the convention now, the tree answers fairly decisively. Counting YAML files by search:

boards/   - ble: 91     - bluetooth: 390
tests/    - ble: 0      - bluetooth: 229
samples/  - ble: 2      - bluetooth: 23

So on the test side it is not close — no in-tree test depends on ble at all. Your application's depends_on: ble is a spelling nothing else in the tree uses, and the MG24 boards declaring bluetooth are following the majority convention rather than deviating from it.

But switching your metadata to depends_on: bluetooth will not simply fix things, because it moves the problem to the other board. I checked boards/nordic/nrf52840dk/nrf52840dk_nrf52840.yaml directly:

supported:
  - adc
  ...
  - ble
  - counter

ble only, no bluetooth. So no single spelling of depends_on covers both your nRF52840 DK and your two MG24 targets today.

Which points at something bigger than your test's metadata, and is probably the thing worth raising: those 229 in-tree test suites declaring depends_on: bluetooth are being filtered out on every board that declares only ble — the nRF52840 DK among them. That is not a naming preference, it is a silent coverage hole on one of the most widely used Bluetooth boards in the project, and it fails the same quiet way you hit rather than erroring.

On the direction of a fix, the numbers make the case: with the test side already at 229 to 0, normalising the ~91 board files onto bluetooth is far less disruptive than moving 229 tests. Whether maintainers would rather keep ble alongside it for compatibility, or teach Twister to alias the two, is their call — but either way the answer to "should a BLE-capable board advertise ble, bluetooth, or both" cannot stay "whichever the vendor picked" without the filtering staying broken.

Worth saying that the board and test counts above come from code search rather than a checkout, so treat them as close rather than exact; the schema snippet and the nRF52840 DK file I read directly.