drivers: bluetooth: silabs: Add hardware-dependent feature detection #97994

ipankr · 2025-10-21T12:01:06Z

Summary

This PR creates a shared base binding for common Bluetooth LE radio hardware capabilities to avoid duplication between vendors and ensure consistent property naming across the Zephyr ecosystem.

Changes

New Base Binding
- Created dts/bindings/bluetooth/ble-radio.yaml with common BLE hardware properties
- Properties prefixed with ble- for consistency
- Ordered chronologically by Bluetooth Core Specification version (5.0, 5.1, 6.0)
Updated Vendor Bindings

Silabs:
- Updated silabs,series2-radio.yaml to include base binding
- Kept vendor-specific ble-tx-high-power-supported property
Nordic:
- Updated nordic,nrf-radio.yaml to include base binding
- Renamed tx-high-power-supported to ble-tx-high-power-supported for consistency
Silicon Labs Device Trees

Updated all Series 2 SoCs with hardware-supported features:
- EFR32xG21: 2M PHY, Coded PHY, TX High Power
- EFR32xG22: 2M PHY, Coded PHY, CTE TX, CTE RX, TX High Power
- EFR32xG24: 2M PHY, Coded PHY, CTE TX, CTE RX, Channel Sounding, TX High Power
- EFR32xG27: 2M PHY, Coded PHY, CTE TX, TX High Power
- EFR32xG29: 2M PHY, Coded PHY, CTE TX, TX High Power
Nordic Device Trees

Updated with consistent property naming:
- nRF52820, nRF52833, nRF52840: Added ble-tx-high-power-supported
- nRF54H20, nRF54L15, nRF54LM20: Renamed to ble-cs-supported
Kconfig Integration

Silabs - Added hardware capability flags (auto-detected from DT):
- HAS_HW_EFR32_RADIO_BLE_2M
- HAS_HW_EFR32_RADIO_BLE_CODED
- HAS_HW_EFR32_RADIO_CTE_TX
- HAS_HW_EFR32_RADIO_CTE_RX
- HAS_HW_EFR32_RADIO_CS
- HAS_HW_EFR32_RADIO_TX_HIGH_POWER
Silabs HCI driver automatically selects controller features based on hardware capabilities.

Nordic - Updated Kconfig to reference renamed properties:
- HAS_HW_NRF_RADIO_CS uses ble-cs-supported
- HAS_HW_NRF_RADIO_TX_PWR_HIGH uses ble-tx-high-power-supported

Testing

Verified on all affected hardware (11 board configurations):

All Silabs: XG21, XG22, XG24, XG27, XG29
All Nordic: nRF52820, nRF52833, nRF52840, nRF54H20, nRF54L15, nRF54LM20

Design Philosophy

This approach harmonizes devicetree bindings across vendors while respecting each vendor's driver architecture.

ipankr · 2025-10-21T12:09:08Z

@jrintaha fyi

jerome-pouiller · 2025-10-21T12:27:11Z

soc/silabs/silabs_s2/Kconfig

+	def_bool $(dt_nodelabel_bool_prop,radio,ble-2mbps-supported)
+
+config HAS_HW_EFR32_RADIO_BLE_CODED
+	def_bool $(dt_nodelabel_bool_prop,radio,ble-coded-phy-supported)


Do we need these intermediate symbols (HAS_HW_EFR32_RADIO_*)?

i think it is easier to define dependencies with these, like for example HAS_HW_EFR32_RADIO_CTE_RX

Not a blocker, but I have always had some doubts about the benefit of adding new global helper symbols. They are sometime used to hide some logic (now or in further PR) and may make the reader work more difficult.

cvinayak · 2025-10-21T12:53:59Z

dts/bindings/net/wireless/silabs,series2-radio.yaml

+
+  cs-supported:
+    type: boolean
+    description: |
+      If set, the radio hardware supports the BLE Channel Sounding feature.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.
+
+  cte-tx:
+    type: boolean
+    description: |
+      Indicates that the radio can transmit Constant Tone Extensions (CTE)
+      for Direction Finding in Angle of Departure (AoD) mode.
+
+  cte-rx:
+    type: boolean
+    description: |
+      Indicates that the radio can receive and sample Constant Tone Extensions (CTE)
+      for Direction Finding in Angle of Arrival (AoA) mode. Requires cte-tx capability.
+
+  tx-high-power-supported:
+    type: boolean
+    description: |
+      If set, indicates that the radio hardware supports high TX power settings.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.
+
+  ble-2mbps-supported:
+    type: boolean
+    description: |
+      If set, indicates that the radio hardware supports the 2 Mbps BLE mode.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.
+
+  ble-coded-phy-supported:
+    type: boolean
+    description: |
+      If set, indicates that the radio hardware supports coded BLE PHY.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.


Some duplication right?

https://github.com/ipankr/zephyr/blob/72ac2b08f805c9d0ba1d0736577e6f44b57f182a/dts/bindings/net/wireless/nordic%2Cnrf-radio.yaml#L215-L236

Can we have a base radio binding that can be included?

Agreed. Would be good to collect these into a base binding. @cvinayak were you thinking of a generic one for all radios or for Bluetooth LE radios in particular? If the latter would it be in dts/bindings/net/wireless or dts/bindings/bluetooth?. The properties should IMO also have the same namespace (likely ble-* which has been used for the existing properties). The base binding should also only contain features which can be shared accrosss multiple radios, i.e. in practice those features which are based on the Bluetooth standard.

@ipankr just so we're clear, by "base binding" we mean something like a ble-radio.yaml which can be included by the actual radio bindings.

Can we agree on a possible better naming of the features in this file? Or should I go as it is?

Can we agree on a possible better naming of the features in this file? Or should I go as it is?

As I mentioned, at the very least I'd want them to have a common prefix. ble-* would have the benefit of not breaking downstream users of the existing properties.

As I mentioned, at the very least I'd want them to have a common prefix. ble-* would have the benefit of not breaking downstream users of the existing properties.

ble-*.yaml is fine by me. Do add ble-* prefix to Bluetooth technology specific features (tx-high-power-supported is generic wireless where as ble-cs- and ble-ctx- are Bluetooth technology). To keep the scope limited, this PR can include the ble-*.yaml to begin, other vendors and downstream can plan the re-use at their convenience. A github issue to track should suffice.

Since we're close to 4.3, I don't think I'd like to have a mix there where one radio binding uses the new base binding and another doesn't, so I'd suggest to update the nrf-radio.yaml here as well, if you don't mind (for what I've seen, it's just two ble- properties, right?)

if its not too much work, and we have @nordicjm in attention. We can proceed to update nrf too, but not get too much out-of-scope.

jhedberg · 2025-10-22T07:51:39Z

dts/bindings/net/wireless/silabs,series2-radio.yaml

    enum:
      - highest
+
+  ble-tx-high-power-supported:


Even though this isn't based on any spec, but since there's a property with the identical name in the nRF binding, perhaps we'd still want this in the common base binding to avoid duplication (with a mention in the description that the meaning is implementation-specific?). Thoughts from @cvinayak?

see https://github.com/zephyrproject-rtos/zephyr/pull/97994/files#r2451718718

tx-high-power-supported is very generic to wireless. Can we or do we already have a generic,radio.yaml ? this should go there.

I would not put it into a common base, exactly because it is not in the spec and it is very vendor specific

because it is not in the spec

Hence, requesting to revert back to tx-high-power-supported and associate it with Bluetooth.

nordicjm · 2025-10-22T11:00:05Z

drivers/bluetooth/hci/Kconfig.silabs

+	  Use Silicon Labs Wiseconnect 3.x Bluetooth library to connect to the controller.
+
+	# SiWx917 BLE controller currently does not support HCI Command: Host Number of Completed Packets
+	configdefault BT_HCI_ACL_FLOW_CONTROL


wrong indent

what exactly is wrong? It pass the compliance test.

@ipankr all Kconfig definitions should start at the beginning of the line. Furthermore, I thought configdefault was only valid for Kconfig.defconfig files, but seems like there's no check for that either.

there is no Kconfig option compliance check, not sure where you got that from. There is one check which checks spacing, it does not check any validity of Kconfig files, and another that checks for "Enable" in the name, and another that checks if it is loadable, that is the extent of testing, e.g. a 700 line file will pass CI

nordicjm · 2025-10-22T11:00:16Z

drivers/bluetooth/hci/Kconfig.silabs

+	select BT_CTLR_DF_ANT_SWITCH_1US_SUPPORT if HAS_HW_EFR32_RADIO_CTE_TX
+	select BT_CTLR_DF_ANT_SWITCH_2US_SUPPORT if HAS_HW_EFR32_RADIO_CTE_TX
+	select BT_SILABS_EFR32_HIGH_POWER if HAS_HW_EFR32_RADIO_TX_HIGH_POWER
+


Suggested change

I would like to keep it for the readability.

no thanks, remove, not allowed under https://docs.zephyrproject.org/latest/contribute/style/kconfig.html

nordicjm · 2025-10-22T11:00:20Z

drivers/bluetooth/hci/Kconfig.silabs

+	select PSA_CRYPTO
+	select SILABS_SISDK_PROTOCOL_CRYPTO
+	select HAS_BT_CTLR
+


Suggested change

I would like to keep it for the readability.

nordicjm · 2025-10-22T11:00:24Z

drivers/bluetooth/hci/Kconfig.silabs

+	select BT_CTLR_SYNC_PERIODIC_SUPPORT
+	select BT_CTLR_SYNC_TRANSFER_RECEIVER_SUPPORT
+	select BT_CTLR_SYNC_TRANSFER_SENDER_SUPPORT
+


Suggested change

I would like to keep it for the readability.

nordicjm · 2025-10-22T11:01:19Z

drivers/bluetooth/hci/Kconfig.silabs

 	  Maximum queued advertising reports.
 	  Additional advertising reports are dropped.

 config BT_SILABS_EFR32_HIGH_POWER


why do you need this when you have it in dts, and it has it's own kconfig below?

It is a declaration. DT just selects it if hw supports it.

there is a symbol in Kconfig which is auto generated, you don't need a duplicate symbol

cvinayak · 2025-10-22T11:06:44Z

dts/bindings/net/wireless/nordic,nrf-radio.yaml

-      If set, indicates that the radio hardware supports coded BLE PHY.
-
-  tx-high-power-supported:
+  ble-tx-high-power-supported:


Suggested change

ble-tx-high-power-supported:

tx-high-power-supported:

Isnt this use of front-end-module, or Tx gain in the multi-protocol radio, right? There is nothing Bluetooth Technology related here, right?

If this is specific to Bluetooth Technology LE Power Class 1 feature, then lets name it accordingly and update the description.

cvinayak · 2025-10-22T11:09:06Z

dts/bindings/net/wireless/silabs,series2-radio.yaml

    enum:
      - highest
+
+  ble-tx-high-power-supported:


see https://github.com/zephyrproject-rtos/zephyr/pull/97994/files#r2451718718

tx-high-power-supported is very generic to wireless. Can we or do we already have a generic,radio.yaml ? this should go there.

cvinayak · 2025-10-22T11:10:51Z

dts/bindings/net/wireless/silabs,series2-radio.yaml

+
+  cs-supported:
+    type: boolean
+    description: |
+      If set, the radio hardware supports the BLE Channel Sounding feature.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.
+
+  cte-tx:
+    type: boolean
+    description: |
+      Indicates that the radio can transmit Constant Tone Extensions (CTE)
+      for Direction Finding in Angle of Departure (AoD) mode.
+
+  cte-rx:
+    type: boolean
+    description: |
+      Indicates that the radio can receive and sample Constant Tone Extensions (CTE)
+      for Direction Finding in Angle of Arrival (AoA) mode. Requires cte-tx capability.
+
+  tx-high-power-supported:
+    type: boolean
+    description: |
+      If set, indicates that the radio hardware supports high TX power settings.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.
+
+  ble-2mbps-supported:
+    type: boolean
+    description: |
+      If set, indicates that the radio hardware supports the 2 Mbps BLE mode.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.
+
+  ble-coded-phy-supported:
+    type: boolean
+    description: |
+      If set, indicates that the radio hardware supports coded BLE PHY.
+      This property should be treated as read-only and should not be overridden;
+      the correct value is provided for your target's SoC already.


if its not too much work, and we have @nordicjm in attention. We can proceed to update nrf too, but not get too much out-of-scope.

cvinayak · 2025-10-22T11:12:03Z

dts/vendor/nordic/nrf54h20.dtsi

 				ble-coded-phy-supported;
-				cs-supported;
+				ble-cs-supported;
 				dfe-supported;


dfe-supported ? ble-dfe-supported, right?

Vendor specific configuration is moved to a separate file. Signed-off-by: Ivan Pankratov <[email protected]>

Create a shared base binding (ble-radio.yaml) for common Bluetooth LE radio hardware capabilities to avoid duplication between vendors and ensure consistent property naming across the ecosystem. Properties are prefixed with 'ble-' and ordered chronologically by Bluetooth Core Specification version (5.0, 5.1, 6.0). Each property indicates a hardware capability, not current enablement state. Signed-off-by: Ivan Pankratov <[email protected]>

sonarqubecloud · 2025-10-23T11:17:18Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added area: Bluetooth area: Devicetree Bindings area: Boards/SoCs platform: Silabs Silicon Labs area: Bluetooth HCI Bluetooth HCI Driver labels Oct 21, 2025

zephyrbot requested review from HaavardRei, HoZHel, Martinhoff-maker, PavelVPV, Thalley, alwa-nordic, asmellby, cvinayak, hermabe, jerome-pouiller, jhedberg and sjanc October 21, 2025 12:02

zephyrbot assigned jhedberg and alwa-nordic Oct 21, 2025

jerome-pouiller reviewed Oct 21, 2025

View reviewed changes

cvinayak reviewed Oct 21, 2025

View reviewed changes

cvinayak requested review from anangl, nordicjm and ppryga-nordic October 21, 2025 12:58

ipankr force-pushed the main branch from 72ac2b0 to 47bbe8d Compare October 21, 2025 19:22

zephyrbot added platform: nRF Nordic nRFx area: Devicetree labels Oct 21, 2025

zephyrbot requested review from bjarki-andreasen and masz-nordic October 21, 2025 19:24

zephyrbot requested a review from mbolivar October 21, 2025 19:24

ipankr force-pushed the main branch from 47bbe8d to 1b7b518 Compare October 22, 2025 07:38

jhedberg reviewed Oct 22, 2025

View reviewed changes

nordicjm requested changes Oct 22, 2025

View reviewed changes

cvinayak requested changes Oct 22, 2025

View reviewed changes

zephyrbot requested a review from jhedberg October 23, 2025 11:02

ipankr added 2 commits October 23, 2025 14:10

drivers: bluetooth: efr32: move Silabs Kconfig settings

1167a97

Vendor specific configuration is moved to a separate file. Signed-off-by: Ivan Pankratov <[email protected]>

ipankr force-pushed the main branch from 0dbc3bc to 990a74c Compare October 23, 2025 11:11

drivers: bluetooth: silabs: Add hardware-dependent feature detection #97994

Are you sure you want to change the base?

drivers: bluetooth: silabs: Add hardware-dependent feature detection #97994

Conversation

ipankr commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Testing

Design Philosophy

Uh oh!

ipankr commented Oct 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jhedberg Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nordicjm Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nordicjm Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ipankr commented Oct 21, 2025 •

edited

Loading

jhedberg Oct 21, 2025 •

edited

Loading

nordicjm Oct 24, 2025 •

edited

Loading

nordicjm Oct 24, 2025 •

edited

Loading