BLE Channel Sounding patches

[prathibhamadugonde]

bluez5: add BLE Channel Sounding support
There is no clear timeline for the upstream Bluez version for this
feature, hence adding it here.

Add 16 patches to bluez5 enabling Channel Sounding (CS) functionality
for BLE ranging:

• HCI raw interface and CS config/procedure/subevent definitions
• Channel Sounding config parsing in main.conf
• HCI LE event handling in the reflector profile
• RAS(Ranging Service) packet format and GATT notification support
• BPF filter and bt_hci_register_subevent for LE Meta events
• RAP(Ranging Profile) client registration and notification cbs
• Bug fixes: big-endian gatt_ccc_read_cb, uninitialized value,
  measured_freq_offset

Signed-off-by: Prathibha Madugonde prathibha.madugonde@oss.qualcomm.com

[Koen Kooi (koenkooi)]

Please adhere to the commit message style, have a look at Agents.md for a summary. Also assume we, and users, know nothing about bluetooth, so RAP doesn't tell us anything.

[Dmitry Baryshkov (lumag)]

On top of that, why is it being a part of dynamic-layers?
Try getting those changes to OE-Core first and if it is rejected there, let's see what we can do.

[quic-mohamull]

On top of that, why is it being a part of dynamic-layers? Try getting those changes to OE-Core first and if it is rejected there, let's see what we can do.

We posted to oe-core, it got rejected
https://patchwork.yoctoproject.org/project/oe-core/patch/20260609095827.2041722-1-prathm@qti.qualcomm.com/

We have been following up with BlueZ community, there is no clear timeline yet. So adding here as patches.

Can you please suggest which is proper layer to add bluez append file?
We referred https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/openembedded-layer/recipes-connectivity/modemmanager/modemmanager_%25.bbappend

[Dmitry Baryshkov (lumag)]

We have been following up with BlueZ community, there is no clear timeline yet.

Pointer to the discussion, please.

So adding here as patches.

It would be nice if it was explained in the commit message.

Can you please suggest which is proper layer to add bluez append file? We referred https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/openembedded-layer/recipes-connectivity/modemmanager/modemmanager_%25.bbappend

That depends if you consider it to be a part of the BSP or not. meta-qcom is a suitable layer, but we also need to know the upstream ETA, etc.

Coming to my question, do you understand what dynamic layers are and why they are used? If not, please check Yocto docs or common practice. Then check if it applies to your situation.

[Ricardo Salveti (ricardosalveti)]

DCO failing, commit not following the standard from the repo.

And the amount of patches here is not really ideal to have even in our BSP layer (besides, not really pure BSP material from my perspective). Why can't we wait for an upstream release here?

Can you raise an issue against upstream asking for a timeline for the next release?

[Nicolas Dechesne (ndechesne)]

DCO failing, commit not following the standard from the repo.

And the amount of patches here is not really ideal to have even in our BSP layer (besides, not really pure BSP material from my perspective). Why can't we wait for an upstream release here?

Can you raise an issue against upstream asking for a timeline for the next release?

While it makes sense to check when a new upstream release will happen. It won't help much in this case. Since we will still need to backport the new bluez release somewhere, since OE-core LTS branch will not take it.

[quic-mohamull]

We have been following up with BlueZ community, there is no clear timeline yet.

Pointer to the discussion, please.

I have asked it in bluez upstream slack group.

So adding here as patches.

It would be nice if it was explained in the commit message.

ok sure we will update commit message

Can you please suggest which is proper layer to add bluez append file? We referred https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/openembedded-layer/recipes-connectivity/modemmanager/modemmanager_%25.bbappend

That depends if you consider it to be a part of the BSP or not. meta-qcom is a suitable layer, but we also need to know the upstream ETA, etc.

Coming to my question, do you understand what dynamic layers are and why they are used? If not, please check Yocto docs or common practice. Then check if it applies to your situation.

No we are not aware of dynamic layers, we will check and apply.

[Dmitry Baryshkov (lumag)]

No we are not aware of dynamic layers, we will check and apply.

And you didn't. Don't blindly c&p if you don't understand what you are doing.

[Ricardo Salveti (ricardosalveti)]

DCO failing, commit not following the standard from the repo.
And the amount of patches here is not really ideal to have even in our BSP layer (besides, not really pure BSP material from my perspective). Why can't we wait for an upstream release here?
Can you raise an issue against upstream asking for a timeline for the next release?

While it makes sense to check when a new upstream release will happen. It won't help much in this case. Since we will still need to backport the new bluez release somewhere, since OE-core LTS branch will not take it.

Since this is all generic stuff, I wonder if it would be better in a different mixin layer (bluez + wpa + whatever other related recipe), at least the separation would be clear, and people could decide to take or not the new recipes based on the layer included.

[Dmitry Baryshkov (lumag)]

Since this is all generic stuff, I wonder if it would be better in a different mixin layer (bluez + wpa + whatever other related recipe), at least the separation would be clear, and people could decide to take or not the new recipes based on the layer included.

I support this idea. This layer then can be used by by other vendors too.

[Ricardo Salveti (ricardosalveti)]

https://lists.yoctoproject.org/g/yocto-patches/message/4225

We should indeed look for a wider meta-mixin-connectivity or similar, but as Paul said in there, ideally we should only land in mixin changes that are already in master.

For patches which are not yet released in master, it would not be a mixin layer, but an extension to master instead.

We should discuss this more, as if we can't really wait for the changes to land in oe master first, the ideal scenario would be to have an extra layer that we also maintain under qualcomm-linux.

[prathibhamadugonde]

https://lists.yoctoproject.org/g/yocto-patches/message/4225

We should indeed look for a wider meta-mixin-connectivity or similar, but as Paul said in there, ideally we should only land in mixin changes that are already in master.

For patches which are not yet released in master, it would not be a mixin layer, but an extension to master instead.

We should discuss this more, as if we can't really wait for the changes to land in oe master first, the ideal scenario would be to have an extra layer that we also maintain under qualcomm-linux.

we can wait for bluez 5.87 version on QLI mainline. However on QLI 2.0 BlueZ version is 5.86 so to bring fixes or features from bluez master we need to add bluez bb append.
On QLI 1.0 we brought upstream fixes to meta-qti-bsp/recipes-connectivity/bluez5

[Dmitry Baryshkov (lumag)]

we can wait for bluez 5.87 version on QLI mainline. However on QLI 2.0 BlueZ version is 5.86 so to bring fixes or features from bluez master we need to add bluez bb append.

That was the point. Wait for bluez 5.87, get it into the OE-Core/master, backport whole 5.87 into a separate mixins layer (probably together with the wpa-supplicant and several other connectivity-related packages, once they get released).

[prathibhamadugonde]

we can wait for bluez 5.87 version on QLI mainline. However on QLI 2.0 BlueZ version is 5.86 so to bring fixes or features from bluez master we need to add bluez bb append.

That was the point. Wait for bluez 5.87, get it into the OE-Core/master, backport whole 5.87 into a separate mixins layer (probably together with the wpa-supplicant and several other connectivity-related packages, once they get released).

We don't want backport whole 5.87 into QLI.2.0 instead we want pick particular feature like Channel Sounding and other critical bug fixes and Channel sounding complete feature will not be part of 5.87. Some implementation of initiator role will be part of bluez master branch.

[Koen Kooi (koenkooi)]

we can wait for bluez 5.87 version on QLI mainline. However on QLI 2.0 BlueZ version is 5.86 so to bring fixes or features from bluez master we need to add bluez bb append.

That was the point. Wait for bluez 5.87, get it into the OE-Core/master, backport whole 5.87 into a separate mixins layer (probably together with the wpa-supplicant and several other connectivity-related packages, once they get released).

We don't want backport whole 5.87 into QLI.2.0 instead we want pick particular feature like Channel Sounding and other critical bug fixes and Channel sounding complete feature will not be part of 5.87. Some implementation of initiator role will be part of bluez master branch.

That would require a separate layer, with a wrynose branch, which we'll need to get a Yocto Project Compatible certification for.

[Dmitry Baryshkov (lumag)]

We don't want backport whole 5.87 into QLI.2.0 instead we want pick particular feature like Channel Sounding and other critical bug fixes and Channel sounding complete feature will not be part of 5.87. Some implementation of initiator role will be part of bluez master branch.

We also don't want to keep and maintain the large series of backported patches here. Also think how to share them with Debian QLI releases? My ideal is the backport of the upstream release + minimal number of the backported patches on top.