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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <877c8r4qi1.fsf@minerva.mail-host-address-is-not-set>
Date: Mon, 25 Nov 2024 10:22:30 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Radu Rendec <rrendec@...hat.com>, Viresh Kumar
 <viresh.kumar@...aro.org>, robh@...nel.org, arnd@...aro.org,
 linux-kernel@...r.kernel.org, Zhipeng Wang <zhipeng.wang_1@....com>,
 javier@...hile0.org, "Rafael J. Wysocki" <rafael@...nel.org>,
 linux-pm@...r.kernel.org
Subject: Re: [RFC PATCH] cpufreq: dt-platdev: Fix module autoloading

Maxime Ripard <mripard@...nel.org> 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