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

[Akashdeep Kaur]

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