Re: [PATCH v4 01/15] cpufreq: Allow restricting to internal governors only

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.06.2023 16:04, Jason Andryuk wrote:
> On Thu, Jun 15, 2023 at 9:21 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> Yet then I find this approach a little odd anyway. I think the
>> registration attempts would better be suppressed, thus also not
>> resulting in (apparently) failed init-calls. Especially for the
>> userspace governor this would then also mean / allow to avoid
>> registering of the CPU notifier.
> 
> So are you suggesting that each caller check cpufreq_governor_internal
> and potentially skip calling cpufreq_register_governor()?  e.g. the
> start of cpufreq_gov_userspace_init() would gain:
> 
>     if (cpufreq_governor_internal)
>         return 0
> 
> ?

Right.

> I put the check in cpufreq_register_governor() since then it is
> handled in a single place instead of being spread around.

I understand this was the goal, but I'm still wondering why we would
try registration we know will fail. Plus, as said and even if benign
right now, I'm not happy to see initcall failures being introduced.

> To leave the check in cpufreq_register_governor(),
> cpufreq_gov_userspace_init() could be rearranged to call
> cpufreq_register_governor() first and only call
> register_cpu_notifier() on success?

Might be an option, but would address only part of my concerns.

> Or do you want the whole governor registration to be re-worked to be
> more explicit?  Remove initcalls and have governors registered
> according to the cpufreq driver?

No, I'm not after any extensive re-work.

Jan