From nobody Sat Oct 4 09:41:02 2025 Received: from relay.smtp-ext.broadcom.com (relay.smtp-ext.broadcom.com [192.19.166.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98893278146; Mon, 18 Aug 2025 16:14:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.19.166.228 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755533701; cv=none; b=P0YBSxvF0LP4arrjl4chJJv5Naqz/IlbEwWnQ2izB/THhH5WepLkHsZFDl+oxhrkrCCRpUlatEm/gahQVkvEDLt0m5Bc5B7UiTLi3pafECjeVlkagyX+mQKnXuWfKVz/MwkfAq8uQ0nUaYg7deLG42FJmDH/sQpxPlaFRi6/mSw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755533701; c=relaxed/simple; bh=Crynj0KpYqual1/+N1DhoLywG80ccPOdKO1wbUlhKtQ=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=s9j+DSeEiLRTHQXUaw69/IgUTXwBGutLDfkLRene5bAAcvNTGANS7mh6PuHzB64C2I7Rvev/iWTW8RRRMD5pDZxYHsLfoH4ru2t/56JxVMxc9HdiJ0Kc2WSCRq9lP73GFNN/pck2ZnwCcvEaoP5ZS4oBYPamt+lORZh+fjZryu4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=tyklk9Lt; arc=none smtp.client-ip=192.19.166.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="tyklk9Lt" Received: from mail-acc-it-01.broadcom.com (mail-acc-it-01.acc.broadcom.net [10.35.36.83]) by relay.smtp-ext.broadcom.com (Postfix) with ESMTP id 6FE2CC009BE2; Mon, 18 Aug 2025 09:08:40 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.smtp-ext.broadcom.com 6FE2CC009BE2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com; s=dkimrelay; t=1755533320; bh=Crynj0KpYqual1/+N1DhoLywG80ccPOdKO1wbUlhKtQ=; h=From:To:Cc:Subject:Date:From; b=tyklk9LtR8WtVWv5s5RuPNr2iiJYYrEBq6Hn+n8qg7W9Fp50jM+uGLwyzKltuG3Rr su/L2riiDDzlNn1jFzsHq5shbPj26+nKL916s2IjlD2MT4e7CBIPtcg7y8gFF40m36 cSGNshL1RjmslXnPNXLYIklrYI4Eq0TeZy5qIALI= Received: from stbirv-lnx-1.igp.broadcom.net (stbirv-lnx-1.igp.broadcom.net [10.67.48.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail-acc-it-01.broadcom.com (Postfix) with ESMTPSA id 51D7C4002F44; Mon, 18 Aug 2025 12:08:34 -0400 (EDT) From: Florian Fainelli To: linux-kernel@vger.kernel.org Cc: Florian Fainelli , Sudeep Holla , Cristian Marussi , "Rafael J. Wysocki" , Viresh Kumar , Mike Tipton , Peng Fan , arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org Subject: [PATCH v3] cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus() Date: Mon, 18 Aug 2025 08:50:48 -0700 Message-Id: <20250818155048.551054-1-florian.fainelli@broadcom.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Broadcom STB platforms were early adopters (2017) of the SCMI framework and= as a result, not all deployed systems have a Device Tree entry where SCMI protocol 0x13 (PERFORMANCE) is declared as a clock provider, nor are the CPU Device Tree node(s) referencing protocol 0x13 as their clock provider. This was clarified in commit e11c480b6df1 ("dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13") in 2023. For those platforms, we allow the checks done by scmi_dev_used_by_cpus() to continue, and in the event of not having done an early return, we key off the documented compatible string and give them a pass to continue to use scmi-cpufreq. Reviewed-by: Sudeep Holla Fixes: 6c9bb8692272 ("cpufreq: scmi: Skip SCMI devices that aren't used by = the CPUs") Signed-off-by: Florian Fainelli --- Changes in v3: - corrected multi-line comment - added details about when STB platforms used SCMI and which commit clarifid the binding requirements Changes in v2: - do not leverage the SCMI quirks framework which in spirit is for dealing with SCMI firmware implementations, this right here, specifically pertains to an older Device Tree. This also makes it easier to backport that change into stable trees where the commit in the Fixes tag is already present. There is no dependency upon the presence of the SCMI quirks framework drivers/cpufreq/scmi-cpufreq.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c index ef078426bfd5..38c165d526d1 100644 --- a/drivers/cpufreq/scmi-cpufreq.c +++ b/drivers/cpufreq/scmi-cpufreq.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -424,6 +425,15 @@ static bool scmi_dev_used_by_cpus(struct device *scmi_= dev) return true; } =20 + /* + * Older Broadcom STB chips had a "clocks" property for CPU node(s) + * that did not match the SCMI performance protocol node, if we got + * there, it means we had such an older Device Tree, therefore return + * true to preserve backwards compatibility. + */ + if (of_machine_is_compatible("brcm,brcmstb")) + return true; + return false; } =20 --=20 2.34.1