Re: [PATCH v3 1/1] cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
From: Zhongqiu Han
Date: Sun May 31 2026 - 23:31:50 EST
On 5/28/2026 9:26 PM, Akashdeep Kaur wrote:
Hi Han,
On 27/05/26 13:29, Zhongqiu Han wrote:
On 5/27/2026 2:25 PM, Akashdeep Kaur wrote:...
On K3 SoCs, ti-cpufreq relies on k3-socinfo to register the SoC
device before soc_device_match() can return valid revision
information. If ti-cpufreq probes before k3-socinfo,
soc_device_match() returns NULL, leading to incorrect CPU frequency
u32 revision;
int ret;
@@ -441,6 +442,15 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
*/
*revision_value = 0x1;
goto done;
+ } else {
+ /* Check if we're on a K3 SoC that needs k3-socinfo */
+ match = dev_get_platdata(dev);
Hi Akashdeep,
Just to double-check: here 'dev' is 'opp_data->cpu_dev'
(get_cpu_device(0)), not 'pdev->dev', right?
In that case, would the 'struct of_device_id' match data actually be
associated with the ti-cpufreq platform device rather than the CPU
device?
Do you think it would be reasonable to add a boolean
`needs_k3_socinfo` flag to `struct ti_cpufreq_soc_data` (similar to the
existing multi_regulator pattern), and check
`opp_data->soc_data->needs_k3_socinfo` instead?
Good catch!! I think the approach to use needs_k3_socinfo is good, i have respinned the series with this approach, please take a look.
Thanks, Akashdeep.
I've shared my comments on v4.
+ if (match && !strncmp(match->compatible, "ti,am62", 7)) {
+ /* SoC info not ready yet, defer */
+ dev_dbg(opp_data->cpu_dev,
+ "Failed to get SoC info, deferring probe\n");
+ return -EPROBE_DEFER;
+ }
}
ret = regmap_read(opp_data->syscon, opp_data->soc_data- >rev_offset,
Thanks and Regards,
Akashdeep Kaur
--
Thx and BRs,
Zhongqiu Han