[PATCH AUTOSEL 6.17-6.12] clk: scmi: Add duty cycle ops only when duty cycle is supported

[Sasha Levin]

From: Jacky Bai <ping.bai at 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 at nxp.com>
Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>
Signed-off-by: Stephen Boyd <sboyd at kernel.org>
Signed-off-by: Sasha Levin <sashal at 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;
-- 
2.51.0