Re: [PATCH v3 1/1] cpufreq: ti: Add EPROBE_DEFER for K3 SoCs

[Akashdeep Kaur <a-kaur@ti.com>]

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.
> 
> 
> 
>> +        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