Re: [RFC PATCH] cpufreq: dt-platdev: Fix module autoloading

[Javier Martinez Canillas]

Maxime Ripard <mripard@xxxxxxxxxx> writes:

Hello Maxime,

> On Fri, Nov 22, 2024 at 06:09:16PM +0100, Javier Martinez Canillas wrote:

[...]

>> > FWIW, the OPP table is defined at the top of r8a779f0.dtsi and
>> > referenced just a few more lines below, where the CPU nodes are
>> > defined.
>> >
>> > As far as I understand, there are two options to fix this:
>> >    1. Revert the patch that allows the cpufreq-dt-platdev driver to be
>> >       built as a module. There's little benefit in allowing that anyway
>> >       because the overhead at init time is minimal when the driver is
>> >       unused, and driver can't be unloaded.
>> >    2. Modify the driver and create an explicit of_device_id table of
>> >       supported platforms for v2 too (like the existing one for v1) and
>> >       use that instead of the cpu0_node_has_opp_v2_prop() call and the
>> >       blacklist. That would of course also eliminate the blacklist.
>> >
>> 
>> Agreed with this. Likely (1) is the easiest path and (2) would make the
>> driver more aligned with the rest of the kernel (that have a list of OF
>> device IDs to autoload / match instead of some custom logic).
>> 
>> But I guess that (2) would be riskier, since not adding a platform that
>> uses v2 will cause a regression.
>
> Also, 2 probably wouldn't work. Devices under /cpus don't get a struct
> device created for them, so it wouldn't probe.
>

Yeah, but the cpufreq-dt-platdev driver has a of_device_id table for the
OPPv1 that matches the actual SoC, not the cpu device nodes.

So for (2) I was thinking to do the same. But yes, agreed tha (1) is the
best option here.

> Maxime

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat