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

From: Javier Martinez Canillas
Date: Mon Nov 25 2024 - 04:22:43 EST


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