Re: [PATCH v10 3/4] reset: cix: add sky1 audss auxiliary reset driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The reset driver accesses hardware registers via MMIO regmap without ensuring the parent Clock and Reset Unit (CRU) is runtime-resumed, leading to bus faults.
--

--- Patch [3]: [PATCH v10 3/4] reset: cix: add sky1 audss auxiliary reset driver ---
commit 7b77b8d6748a307fae0e5cb9afa8e1010bc6766c
Author: Joakim Zhang <joakim.zhang@cixtech.com>
Subject: reset: cix: add sky1 audss auxiliary reset driver

This commit adds an auxiliary reset controller driver for the Cix Sky1 Audio
Subsystem CRU. It exposes 16 software reset lines using a regmap retrieved
from the parent device.

> diff --git a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> new file mode 100644
> index 0000000000000..d31d80e1251a8
> --- /dev/null
> +++ b/drivers/reset/reset-sky1-audss.c

[ ... ]

> +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> +				unsigned long id, bool assert)
> +{
> +	struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> +	const struct sky1_audss_reset_map *signal = &priv->map[id];
> +	unsigned int value = assert ? 0 : signal->mask;
> +
> +	return regmap_update_bits(priv->regmap, signal->offset, signal->mask, value);

[Severity: High]
Does this code need to ensure the parent Clock and Reset Unit (CRU) is
runtime-resumed before accessing the hardware registers?

If the parent clock controller driver drops its runtime PM reference (e.g.,
after its probe finishes), the CRU device might be suspended and its internal
clocks disabled. Could accessing the regmap here without first waking up the
parent device (such as by using pm_runtime_get_sync()) result in a bus fault?

> +}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720051505.1252774-1-joakim.zhang@cixtech.com?part=3