linux-kernel - Re: [PATCH] cpufreq: fix using cpufreq-dt as module

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: <20241104201424.2a42efdd@akair>
Date: Mon, 4 Nov 2024 20:14:24 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Kevin Hilman <khilman@...nel.org>
Cc: rafael@...nel.org, viresh.kumar@...aro.org, zhipeng.wang_1@....com,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-omap@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] cpufreq: fix using cpufreq-dt as module

Am Mon, 04 Nov 2024 10:35:26 -0800
schrieb Kevin Hilman <khilman@...nel.org>:

> Andreas Kemnade <andreas@...nade.info> writes:
> 
> > E.g. omap2plus_defconfig compiles cpufreq-dt as module. As there is
> > no module alias nor a module_init(), cpufreq-dt-platdev will not be
> > used and therefore on several omap platforms there is no cpufreq.
> >
> > Enforce builtin compile of cpufreq-dt-platdev to make it effective.
> >
> > Fixes: 3b062a086984 ("cpufreq: dt-platdev: Support building as
> > module") Cc: stable@...r.kernel.org
> > Signed-off-by: Andreas Kemnade <andreas@...nade.info>  
> 
> I'd much rather see this fixed to work as a module.  You already
> hinted at the right way to do that, so please do that instead.
> 
no clear idea how. What aliases should I add? The cpufreq-dt-platdev is
not a real driver, so I could not create mod_devicetable aliases to
match a given device. It constructs a device under certain conditions
depending on the board compatible, so no simple list of compatibles, it
contains allow and blocklists.

cpufreq-dt then binds to that device and that one can be built as a
module (which then made cpufreq-dt-platdev also a module, causing the
trouble). I do not see any benefit from having cpufreq-dt-platdev as a
module. ti-cpufreq has a similar role and is also just builtin.
It does itself no real work but provides a device cpufreq-dt then binds
to.

Handling module removal would probably need to be added and tested. I
feel not comfortable having such as a regression fix and for stable.

Regards,
Andreas