include/drivers: clock_control.h: Add configure() to api

[erwango]

Add configure() function to clock_control API.
This function should enable caller to configure its source clock.

Extracted from #42097 where its usage is illustrated.

Note:
On maintainer's request, initial select() has been replaced by more generic configure()
#42097 is using the initial select() proposal.

Signed-off-by: Erwan Gouriou [email protected]

[galak]

I think we should rename this slightly to be specific to what is getting configure (ie is this just for clock source selection)

[erwango]

This was initially _select() and was then updated to be more generic on this initial comment: #43790 (comment)

[erwango]

@galak Also, given the discussion we had yesterday, maybe it's not bad to 'open' the API given:

• we'll likely have a clock_control overhaul in medium term. Letting experiments happen might be a good thing before and then build on these experiments
• since this api implementation is vendor specific anyway, these isn't much risk anyway

[galak]

My concern with the name is its not clear at all what is being configured an adding an API that vague doesn't make sense to me.

[erwango]

@nordic-krch, @gmarull PR updated according to comments. Thanks for the review

[carlescufi]

API meeting:

• The future of clock control in Zephyr likely needs an overhaul (similar to the one that took place with pinctrl)
• In the meantime, this API is as close as we get to common infrastructure for clock control
• No objections to extending the API as proposed

[MaureenHelm]

No objection to adding this function to the API, but it needs at least one implementation before we merge the PR.

[erwango]

No objection to adding this function to the API, but it needs at least one implementation before we merge the PR.

@MaureenHelm On going in following PR: #42097

[MaureenHelm]

No objection to adding this function to the API, but it needs at least one implementation before we merge the PR.

@MaureenHelm On going in following PR: #42097

Can we close this PR and merge the API change together with the implementation?

[erwango]

Can we close this PR and merge the API change together with the implementation?

Up to you. On my side, no problem to keep it open, as it's easier to access than deep down buried into #42097, if people would like to check it.

[carlescufi]

No objection to adding this function to the API, but it needs at least one implementation before we merge the PR.

@MaureenHelm On going in following PR: #42097

Can we close this PR and merge the API change together with the implementation?

I would personally prefer merging this first @MaureenHelm, for future visibility. But I won't argue if you'd rather not.

[MaureenHelm]

No objection to adding this function to the API, but it needs at least one implementation before we merge the PR.

@MaureenHelm On going in following PR: #42097

Can we close this PR and merge the API change together with the implementation?

I would personally prefer merging this first @MaureenHelm, for future visibility. But I won't argue if you'd rather not.

I'd rather not. Do we have any non-STM32 implementations in the works?

[erwango]

Merged as part of #45053. Closed