[PATCH v3 0/1] cpufreq: ti: Fix probe ordering with k3-socinfo

[PATCH v3 0/1] cpufreq: ti: Fix probe ordering with k3-socinfo

[Akashdeep Kaur]

For K3 SoCs, ti-cpufreq depends on k3-socinfo to provide SoC revision
information via soc_device_match(). If ti-cpufreq probes before
k3-socinfo, soc_device_match() returns NULL, causing incorrect 
revision detection and OPP table initialization failures.

Add EPROBE_DEFER handling in ti-cpufreq when soc_device_match() fails
for K3 SoCs, ensuring k3-socinfo probes first.

Changes in v3
- Simplified to single patch (EPROBE_DEFER only)
- Changed the logic to detect whether the probe is for am62 family SoCs
- Dropped device link patch after analysis as revision information is 
  cached after successful probe. Module reload also works as k3-socinfo 
  stays bound during normal operation
- Link to v2: https://lore.kernel.org/all/20260401105404.1194717-1-a-kaur@ti.com/

Changes in v2
- Added DT bindings documentation for ti,soc-info property
- Reordered patches: bindings first, then driver changes, then DTS
- Link to v1: https://lore.kernel.org/all/20260330120105.2985200-1-a-kaur@ti.com/

Testing
- Verified correct probe ordering on AM625, AM62A7, AM62P5 platforms

Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---

Akashdeep Kaur (1):
  cpufreq: ti: Add EPROBE_DEFER for K3 SoCs

 drivers/cpufreq/ti-cpufreq.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

-- 
2.34.1

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

[Akashdeep Kaur]

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
scaling behavior.
Defer probe when k3-socinfo hasn't registered the SoC device yet.

Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
 drivers/cpufreq/ti-cpufreq.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index a01abc1622eb..72832898f3f5 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -429,6 +429,7 @@ static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
 static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
 			      u32 *revision_value)
 {
+	const struct of_device_id *match;
 	struct device *dev = opp_data->cpu_dev;
 	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);
+		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,
-- 
2.34.1

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

[Zhongqiu Han]

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
> scaling behavior.
> Defer probe when k3-socinfo hasn't registered the SoC device yet.
> 
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
>   drivers/cpufreq/ti-cpufreq.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index a01abc1622eb..72832898f3f5 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -429,6 +429,7 @@ static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
>   static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
>   			      u32 *revision_value)
>   {
> +	const struct of_device_id *match;
>   	struct device *dev = opp_data->cpu_dev;
>   	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?



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


-- 
Thx and BRs,
Zhongqiu Han

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

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

[Zhongqiu Han]

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