Re: [PATCH 1/3] ACPI: CPPC: Refactor boost ratio handling

On 9/1/26 11:34, Rafael J. Wysocki (Intel) wrote:
> On Tue, Sep 1, 2026 at 5:28 PM Mario Limonciello
> <[email protected]> wrote:
>>
>>
>>
>> On 9/1/26 04:31, K Prateek Nayak wrote:
>>> On 9/1/2026 1:14 AM, Mario Limonciello wrote:
>>>> +int amd_get_max_frequency(unsigned int cpu)
>>>> +{
>>>> +    enum x86_topology_cpu_type type = cpu_data(cpu).topo.cpu_type;
>>>> +    const struct x86_cpu_id *id = x86_match_cpu(amd_zen6_client_ids);
>>>> +    const struct amd_max_freq *max_freq;
>>>> +
>>>> +    if (!id)
>>>> +            return -ENODEV;
>>>> +
>>>> +    max_freq = (const struct amd_max_freq *)id->driver_data;
>>>> +
>>>> +    switch (type) {
>>>> +    case TOPO_CPU_TYPE_PERFORMANCE:
>>>> +            return max_freq->performance;
>>>> +    case TOPO_CPU_TYPE_EFFICIENCY:
>>>> +            return max_freq->efficiency;
>>>> +    case TOPO_CPU_TYPE_LOW_POWER:
>>>> +            return max_freq->low_power;
>>>> +    default:
>>>> +            break;
>>>> +    }
>>>> +
>>>> +    return -EINVAL;
>>>
>>> nit. Since we don't really propagate the error codes returned
>>> by amd_get_max_frequency(), maybe we can return 0 instead of
>>> -ENODEV, -EINVAL and the callers can simply do:
>>>
>>>       max_freq = amd_get_max_frequency(cpu);
>>>       if (!max_freq)
>>>            max_freq = /* Fallback */;
>>>
>>> similar to get_max_boost_ratio() pattern. No strong feelings
>>> either way.
>>>
>>
>> OK.  Will adjust for next version.
>>
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(amd_get_max_frequency);
> 
> Please note though that all CPPC-related material is gated on this patch series:
> 
> https://lore.kernel.org/linux-acpi/[email protected]/
> 
> and there are other multiple series already waiting.
> 
> That queue needs to be flushed I'm afraid.

Thanks, I'll rebase and test on that series.
I was just CC'ed into it today too.