Instead of using the clk embedded in the clk_hw (which is meant to go
away), a clock provider which need to interact with its own clock should
request clk reference through the clock provider API.
Signed-off-by: Jerome Brunet <[email protected]>
---
sound/soc/stm/stm32_sai_sub.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 3aa1cf262402..c1561237ee24 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -484,7 +484,10 @@ static int stm32_sai_add_mclk_provider(struct stm32_sai_sub_data *sai)
dev_err(dev, "mclk register returned %d\n", ret);
return ret;
}
- sai->sai_mclk = hw->clk;
+
+ sai->sai_mclk = devm_clk_hw_get_clk(dev, hw, NULL);
+ if (IS_ERR(sai->sai_mclk))
+ return PTR_ERR(sai->sai_mclk);
/* register mclk provider */
return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, hw);
--
2.30.2
Quoting Jerome Brunet (2021-04-10 04:13:52)
> Instead of using the clk embedded in the clk_hw (which is meant to go
> away), a clock provider which need to interact with its own clock should
> request clk reference through the clock provider API.
>
> Signed-off-by: Jerome Brunet <[email protected]>
> ---
Reviewed-by: Stephen Boyd <[email protected]>