Re: [PATCH v11 2/4] clk: cix: add sky1 audss clock controller

[Brian Masney]

Hi Joakim,

There's one question from Sashiko that I don't see where you answered
that seems to be legit.

On Thu, Jul 23, 2026 at 05:08:06PM +0800, joakim.zhang@xxxxxxxxxxx wrote:
> From: Joakim Zhang <joakim.zhang@xxxxxxxxxxx>
> 
> Add a platform driver for the Cix Sky1 AUDSS CRU. The driver maps
> the CRU registers and registers mux, divider and gate clocks for
> DSP, SRAM, HDA, DMAC, I2S, mailbox, watchdog and timer blocks.
> 
> Four SoC-level audio reference clocks are enabled as inputs to the
> internal clock tree. The driver releases the AUDSS NOC reset, enables
> runtime PM and instantiates the auxiliary reset device.
> 
> Signed-off-by: Joakim Zhang <joakim.zhang@xxxxxxxxxxx>

[snip]

> +static int __maybe_unused sky1_audss_clk_runtime_resume(struct device *dev)
> +{
> +	struct sky1_audss_clks_priv *priv = dev_get_drvdata(dev);
> +	const struct sky1_audss_clks_devtype_data *devtype_data = priv->devtype_data;
> +	unsigned long flags;
> +	int i, ret;
> +
> +	ret = sky1_audss_clks_enable(priv);

>From Sashiko:

    [Severity: High]
    Could this result in a deadlock? When a consumer calls clk_prepare on an
    audss clock, CCF acquires the global prepare_lock mutex and may call
    pm_runtime_resume_and_get. This triggers sky1_audss_clk_runtime_resume,
    which calls sky1_audss_clks_enable. Since sky1_audss_clks_enable executes
    clk_prepare_enable, it will attempt to acquire the non-recursive prepare_lock
    again.

I found drivers/clk/samsung/clk-exynos-audss.c that is similar to your driver and
it calls clk_prepare_enable() in probe.

I'm not concerned about the other feedback from Sashiko.

Brian