Bluetooth: Controller: Allow setting ISO TX/RX buffer count to 0

[yuxCai]

There is no need to allocate TX/RX buffers when the device is an receiver/transmitter only.

[github-actions]

Hello @yuxCai, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[cvinayak]

There is already depends on

[yuxCai]

BT_CTLR_ISO_TX_BUFFERS is set to default BT_ISO_TX_BUF_COUNT if BT_ISO. But when BT_ISO_TX_BUF_COUNT is 0, it will return error because BT_CTLR_ISO_TX_BUFFERS is out of the range

BT_CTLR_ISO_RX_BUFFERS, however, is independent of BT_ISO_RX_BUF_COUNT. I suggest changing the minimum values of the mentioned kconfigs to 0

[cvinayak]

Suggested change

	range 0 30
	range 1 30

[cvinayak]

Suggested change

	range 0 255
	range 1 255

[Thalley]

CONFIG_BT_ISO_TX_BUF_COUNT and CONFIG_BT_ISO_RX_BUF_COUNT are not specific to the controller, and are also being used by the host, so the commit should not start with Bluetooth: Controller.

Furthermore, setting these to 0 might cause issues in the host:

NET_BUF_POOL_FIXED_DEFINE(iso_tx_pool, CONFIG_BT_ISO_TX_BUF_COUNT,
			  BT_ISO_SDU_BUF_SIZE(CONFIG_BT_ISO_TX_MTU),
			  CONFIG_BT_CONN_TX_USER_DATA_SIZE, NULL);

What happens if we define a pool with 0 count?

It should also not be possible to set BT_ISO_TX_BUF_COUNT=0 when BT_ISO_BROADCASTER=y, or BT_ISO_RX_BUF_COUNT=0 when BT_ISO_SYNC_RECEIVER=y.

There are likely several places in iso.c that needs to be guarded if we allow either of them to be 0.

Also consider making some promptless Kconfig options that depend on these, so that if BT_ISO_TX_BUF_COUNT > 0 then BT_ISO_TX gets enabled, and similar for RX.

My requests addressed

[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.

[kartben]

rebased to trigger stuck CI job

[jhedberg]

@yuxCai @cvinayak is the "Controller" prefix actually correct, since this is not modifying a controller-specific file. Are these options used elsewhere? If not, then they should probably be moved into subsys/bluetooth/controller/.

[cvinayak]

@yuxCai @cvinayak is the "Controller" prefix actually correct, since this is not modifying a controller-specific file. Are these options used elsewhere? If not, then they should probably be moved into subsys/bluetooth/controller/.

As already mentioned, these are not (now) Controller Kconfig options after my change requests where addressed (only value may be inherited). The commit title needs correction. Plus, all code that use these Kconfig define need update to handle value of 0.

[Thalley]

@yuxCai @cvinayak is the "Controller" prefix actually correct, since this is not modifying a controller-specific file. Are these options used elsewhere? If not, then they should probably be moved into subsys/bluetooth/controller/.

These options are also used by the host. See #69382 (review)

[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.