nRF clock_control_on() is nonblocking

[mbolivar]

Describe the bug

Per discussion in #20708, the non-async clock enable function clock_control_on() should block until the clock is ready, but the nRF clock driver doesn't.

To Reproduce

• call clock_control_on() on an nRF clock that isn't already enabled
• observe clock_start() in nrf_power_clock.c calls clock_async_start() directly with no callback
• without a callback, note clock_async_start() returns before the clock may be ready

Expected behavior

Clock status should be definitely ready by the time clock_control_on() returns.

Impact

Unknown.

Environment (please complete the following information):

nRF platform, possibly others.

Additional context

Discussion in #20708 and #20710.

[ioannisg]

@nordic-krch any updates on this?

[rlubos]

I was about to open an issue when I've found this one.

The nRF radio driver is hit by the nonblocking behavior of clock_control_on - the radio may malfunction when used before HF clock is ready, yet the radio driver itself does not take any extra action to verify that the clock is running as clock_control_on is supposed to block until clock is ready (and it used to work like this until this commit).

[nordic-krch]

im working right now on clock_control driver to straighten this up (and start using onoff service)