modules: hal_silabs: Add Proprietary TRX example

[zohavas]

Add Proprietary TRX example to show SiliconLabs radio board capabilities.

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_silabs	zephyrproject-rtos/hal_silabs@b11b291 (master)	zephyrproject-rtos/hal_silabs#49	zephyrproject-rtos/hal_silabs#49/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[zohavas]

I would like to remove the stale label, the submodule PR is ready and approved waiting for the merge.

[nordicjm]

If I understand this correctly, this is tired to one specific piece of hardware from one vendor and requires binary blobs to even be used - what is the value of this being added here?

@nashif shouldn't this be something for the TSC?

[zohavas]

If I understand this correctly, this is tired to one specific piece of hardware from one vendor and requires binary blobs to even be used - what is the value of this being added here?

@nashif shouldn't this be something for the TSC?

Hi @nordicjm,
Yes this sample application will be able to be only used with silabs hardware, that's why it is position in the silabs_hal repository.
This can be used with any already supported Siliconlab board with the help of the Radio Configurator from Studio.
We want to show the radio capability of the gecko software and silabs hardware, that why we chosen this repository for user to easily find the correct way to use the radio functions.
We have already a similar discussion in the repo PR: zephyrproject-rtos/hal_silabs#49 (comment)

[zohavas]

@henrikbrixandersen I would like to ask if [area: Blobs] is correct as I don't add or modify any libs, only use the existing ones.

[fabiobaltieri]

Hey this is not build in CI in the current state right? I was under the impression that it was (other modules have tests that are included in the normal CI run). If that's the case, distributing this with the OS had limited value, the idea here is that the sample code that ships with the project is maintained and kept up to date, at least it should be built tested.

Regardless, what I'm thinking is that having the sample in the module is going to be a potential extra load for API maintenance, say one of the sample API change, the author of the change has do do the whole module change dance to fix the sample. If every hal starts having a set of in-module samples it'd be a nightmare.

On the other side, if the sample lives in the main repository, a change of the binary blob or hal api would result in the extra step to change the main repo code, but then that's already case as changing the module involve a main PR anyway to update the west file, no extra load there.

So with that in mind I think that that having the sample in the module is a net negative, and this should be:

• moved in the main repo
• get an extra review (at first sight some api and styling are off)
• be relicenced like the other sample
• get an extra review
• get a build file so it gets build tested

There's an argument about having a sample backed by a proprietary blob module but frankly I don't see that as being different than any ble/wifi samples, I think we have platforms with blob for power management as well.

[tgorochowik]

I agree with Fabio, in addition I think we should rename this sample from "proprietary" to something else, if there is no dedicated name then maybe something more descriptive, as the code of this sample is not really proprietary, it's just the blob that is proprietary

[fabiobaltieri]

I think we should rename this sample from "proprietary" to something else

The main repo already has vendor specific samples under samples/boards/, this would fit there just fine, the scope of that directory is a mix of "boards" and "vendor" at this stage but that's not much of an issue IMO.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.