Re: [PATCH v6 05/19] xen/cpufreq: refactor cmdline "cpufreq=xxx"

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.08.2025 07:47, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Wednesday, July 16, 2025 11:01 PM
>>
>> On 11.07.2025 05:50, Penny Zheng wrote:
>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>> @@ -64,12 +64,53 @@ LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
>>>  /* set xen as default cpufreq */
>>>  enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
>>>
>>> -enum cpufreq_xen_opt __initdata cpufreq_xen_opts[2] = { CPUFREQ_xen,
>>> -                                                        CPUFREQ_none };
>>> +enum cpufreq_xen_opt __initdata cpufreq_xen_opts[NR_CPUFREQ_OPTS] = {
>>> +    CPUFREQ_xen,
>>> +    CPUFREQ_none
>>> +};
>>>  unsigned int __initdata cpufreq_xen_cnt = 1;
>>
>> Given this, isn't the array index 1 initializer quite pointless above? Or 
>> else, if you
>> really mean to explicitly fill all slots with CPUFREQ_none (despite that 
>> deliberately
>> having numeric value 0), why not
>> "[1 ... NR_CPUFREQ_OPTS - 1] = CPUFREQ_none" (or using ARRAY_SIZE(), as
>> per below)?
>>
> 
> The cpufreq_xen_cnt initialized as 1 is to have default  CPUFREQ_xen value 
> when there is no "cpufreq=xxx" cmdline option
> I suppose you are pointing out that the macro NR_CPUFREQ_OPTS is pointless, 
> as we could use ARRAY_SIZE().

That I'm suggesting further down, yes. But here I'm questioning the array
initializer: As said, I think only slot 0 needs explicit initializing. Or
else the initializer would need touching again when the array size is
grown. Which would be nice to avoid, providing doing so is correct.

Jan