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@vger.kernel.org
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 drivers/cpufreq/Kconfig              | 2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 2561b215432a8..4547adf5d2a7d 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -218,7 +218,7 @@ config CPUFREQ_DT
 	  If in doubt, say N.
 
 config CPUFREQ_DT_PLATDEV
-	tristate "Generic DT based cpufreq platdev driver"
+	bool "Generic DT based cpufreq platdev driver"
 	depends on OF
 	help
 	  This adds a generic DT based cpufreq platdev driver for frequency
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 18942bfe9c95f..78ad3221fe077 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -234,5 +234,3 @@ static int __init cpufreq_dt_platdev_init(void)
 			       sizeof(struct cpufreq_dt_platform_data)));
 }
 core_initcall(cpufreq_dt_platdev_init);
-MODULE_DESCRIPTION("Generic DT based cpufreq platdev driver");
-MODULE_LICENSE("GPL");
-- 
2.39.2

Andreas Kemnade <andreas@kemnade.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@vger.kernel.org
> Signed-off-by: Andreas Kemnade <andreas@kemnade.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.

Kevin

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

> Andreas Kemnade <andreas@kemnade.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@vger.kernel.org
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.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

On 04-11-24, 20:14, Andreas Kemnade wrote:
> 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.

Applied this patch for now (with some changes to commit log), as there is no
clean way to fix this for now. Got reports from other folks too about it.

-- 
viresh

Viresh Kumar <viresh.kumar@linaro.org> writes:

> On 04-11-24, 20:14, Andreas Kemnade wrote:
>> 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.
>
> Applied this patch for now (with some changes to commit log), as there is no
> clean way to fix this for now. Got reports from other folks too about it.

Oops, I thought I had replied to this earlier after detailed explanation
from Andreas, but I guess I didn't.

Thanks for applying.

Kevin