From: Jacky Bai ping.bai@nxp.com
[ Upstream commit 18db1ff2dea0f97dedaeadd18b0cb0a0d76154df ]
For some of the SCMI based platforms, the oem extended config may be supported, but not for duty cycle purpose. Skip the duty cycle ops if err return when trying to get duty cycle info.
Signed-off-by: Jacky Bai ping.bai@nxp.com Reviewed-by: Sudeep Holla sudeep.holla@arm.com Signed-off-by: Stephen Boyd sboyd@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES – this is a low-risk bug fix that prevents the driver from advertising duty-cycle support on firmware that actually rejects the operation, avoiding real user-visible failures.
- `scmi_clk_ops_alloc()` wires up `get_duty_cycle`/`set_duty_cycle` whenever the duty-cycle feature bit is set (`drivers/clk/clk- scmi.c:311`). Before this patch any clock with `extended_config = true` populated that bit, so consumers believed the duty-cycle API worked even when firmware returned `-EOPNOTSUPP`. - In practice, a refused call bubbles up to drivers that rely on the feature. For example, `clk_set_duty_cycle()` in the AXG TDM interface aborts audio setup if the clock op fails (`sound/soc/meson/axg-tdm- interface.c:249`), so misreporting support breaks real hardware. - The commit now probes firmware once at registration time and only sets `SCMI_CLK_DUTY_CYCLE_SUPPORTED` when `config_oem_get(...SCMI_CLOCK_CFG_DUTY_CYCLE...)` succeeds (`drivers/clk/clk-scmi.c:349` and `drivers/clk/clk-scmi.c:372-377`). This simply reuses the existing accessor (`drivers/clk/clk- scmi.c:187`) and has no side effects beyond skipping the bogus ops. - Change is tiny, localized to the SCMI clock driver, and introduces no ABI or architectural churn; the new call is already required whenever the duty-cycle helpers are invoked, so risk is minimal. - Stable branches need to carry the duty-cycle support addition (`clk: scmi: Add support for get/set duty_cycle operations`, commit 87af9481af53) beforehand; with that prerequisite satisfied, backporting this fix prevents firmware that only supports other OEM configs from breaking consumers.
Given it fixes a regression introduced with duty-cycle support and keeps the driver from lying about capabilities, it fits stable backport criteria.
drivers/clk/clk-scmi.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index 78dd2d9c7cabd..6b286ea6f1218 100644 --- a/drivers/clk/clk-scmi.c +++ b/drivers/clk/clk-scmi.c @@ -346,6 +346,8 @@ scmi_clk_ops_select(struct scmi_clk *sclk, bool atomic_capable, unsigned int atomic_threshold_us, const struct clk_ops **clk_ops_db, size_t db_size) { + int ret; + u32 val; const struct scmi_clock_info *ci = sclk->info; unsigned int feats_key = 0; const struct clk_ops *ops; @@ -367,8 +369,13 @@ scmi_clk_ops_select(struct scmi_clk *sclk, bool atomic_capable, if (!ci->parent_ctrl_forbidden) feats_key |= BIT(SCMI_CLK_PARENT_CTRL_SUPPORTED);
- if (ci->extended_config) - feats_key |= BIT(SCMI_CLK_DUTY_CYCLE_SUPPORTED); + if (ci->extended_config) { + ret = scmi_proto_clk_ops->config_oem_get(sclk->ph, sclk->id, + SCMI_CLOCK_CFG_DUTY_CYCLE, + &val, NULL, false); + if (!ret) + feats_key |= BIT(SCMI_CLK_DUTY_CYCLE_SUPPORTED); + }
if (WARN_ON(feats_key >= db_size)) return NULL;