[PATCH AUTOSEL 6.17-6.6] ASoC: stm32: sai: manage context in set_sysclk callback

[Sasha Levin]

From: Olivier Moysan <olivier.moysan at foss.st.com>

[ Upstream commit 27fa1a8b2803dfd88c39f03b0969c55f667cdc43 ]

The mclk direction now needs to be specified in endpoint node with
"system-clock-direction-out" property. However some calls to the
set_sysclk callback, related to CPU DAI clock, result in unbalanced
calls to clock API.
The set_sysclk callback in STM32 SAI driver is intended only for mclk
management. So it is relevant to ensure that calls to set_sysclk are
related to mclk only.
Since the master clock is handled only at runtime, skip the calls to
set_sysclk in the initialization phase.

Signed-off-by: Olivier Moysan <olivier.moysan at foss.st.com>
Link: https://patch.msgid.link/20250916123118.84175-1-olivier.moysan@foss.st.com
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- Guarding `stm32_sai_set_sysclk()` until the card is instantiated
  (`sound/soc/stm/stm32_sai_sub.c:675-681`) prevents the early simple-
  card `init` call (`sound/soc/generic/simple-card-utils.c:571`) from
  programming clocks before runtime.
- That init-time call currently triggers a second
  `clk_rate_exclusive_get()` on the shared SAI kernel clock
  (`sound/soc/stm/stm32_sai_sub.c:442`) and another
  `clk_set_rate_exclusive()` on the MCLK
  (`sound/soc/stm/stm32_sai_sub.c:709`) before any matching “0 Hz”
  teardown happens; at shutdown we only drop one reference
  (`sound/soc/stm/stm32_sai_sub.c:692-702`), leaving the clocks
  permanently locked and causing later `-EBUSY` failures.
- The regression shows up as soon as boards tag the CPU endpoint with
  `system-clock-direction-out` (parsed in `simple-card-utils.c:290` and
  already present in ST’s shipping DTs such as
  `arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi:520`), a configuration
  encouraged since commit 5725bce709db; the exclusive clock management
  added in 2cfe1ff22555 made the imbalance fatal.
- The fix is minimal and contained: it simply skips the init-phase
  invocation for a driver that already derives MCLK from the stream
  rate, so the risk of regressions is low while it resolves a real
  runtime bug on current hardware.

 sound/soc/stm/stm32_sai_sub.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 463a2b7d023b9..0ae1eae2a59e2 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -672,6 +672,14 @@ static int stm32_sai_set_sysclk(struct snd_soc_dai *cpu_dai,
 	struct stm32_sai_sub_data *sai = snd_soc_dai_get_drvdata(cpu_dai);
 	int ret;
 
+	/*
+	 * The mclk rate is determined at runtime from the audio stream rate.
+	 * Skip calls to the set_sysclk callback that are not relevant during the
+	 * initialization phase.
+	 */
+	if (!snd_soc_card_is_instantiated(cpu_dai->component->card))
+		return 0;
+
 	if (dir == SND_SOC_CLOCK_OUT && sai->sai_mclk) {
 		ret = stm32_sai_sub_reg_up(sai, STM_SAI_CR1_REGX,
 					   SAI_XCR1_NODIV,
-- 
2.51.0