The recent change to use platform devices to load ACPI PPC and PCC
drivers caused that a misleading warning is reported when a respective
module cannot be loaded because another CPU frequency driver is already
registered:

kernel: acpi-cpufreq: probe of acpi-cpufreq failed with error -17

Address it by changing the return code in acpi-cpufreq and pcc-cpufreq
for this case from -EEXIST to -ENODEV which silences the warning in
call_driver_probe().

The change has also a benefit for users of init_module() as this return
code is propagated out from the syscall. The previous -EEXIST code made
the callers, such as kmod, wrongly believe that the module was already
loaded instead of that it failed to load.

Fixes: 691a63712347 ("ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers")
Reported-by: Kevin Locke <kevin@kevinlocke.name>
Link: https://lore.kernel.org/lkml/ZFreh8SDMX67EaB6@kevinlocke.name/
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 drivers/cpufreq/pcc-cpufreq.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 29904395e95f..b2f05d27167e 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -975,7 +975,7 @@ static int __init acpi_cpufreq_probe(struct platform_device *pdev)
 
 	/* don't keep reloading if cpufreq_driver exists */
 	if (cpufreq_get_current_driver())
-		return -EEXIST;
+		return -ENODEV;
 
 	pr_debug("%s\n", __func__);
 
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index 1d2cfea9858a..73efbcf5513b 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -583,7 +583,7 @@ static int __init pcc_cpufreq_probe(struct platform_device *pdev)
 
 	/* Skip initialization if another cpufreq driver is there. */
 	if (cpufreq_get_current_driver())
-		return -EEXIST;
+		return -ENODEV;
 
 	if (acpi_disabled)
 		return -ENODEV;
-- 
2.35.3

On Thu, 2023-05-11 at 14:53 +0200, Petr Pavlu wrote:
> Address it by changing the return code in acpi-cpufreq and pcc-cpufreq
> for this case from -EEXIST to -ENODEV which silences the warning in
> call_driver_probe().
> 
> The change has also a benefit for users of init_module() as this return
> code is propagated out from the syscall. The previous -EEXIST code made
> the callers, such as kmod, wrongly believe that the module was already
> loaded instead of that it failed to load.

Thanks for addressing this issue so quickly!

I can confirm that with this patch applied I no longer receive
kernel: acpi-cpufreq: probe of acpi-cpufreq failed with error -17
at boot.  Additionally, modprobe acpi-cpufreq now produces
modprobe: ERROR: could not insert 'acpi_cpufreq': No such device
rather than silently failing (without --first-time) to load the
module as it did before, which seems good to me.

Tested-by: Kevin Locke <kevin@kevinlocke.name>

Cheers,
Kevin

On Sun, May 14, 2023 at 3:16 PM Kevin Locke <kevin@kevinlocke.name> wrote:
>
> On Thu, 2023-05-11 at 14:53 +0200, Petr Pavlu wrote:
> > Address it by changing the return code in acpi-cpufreq and pcc-cpufreq
> > for this case from -EEXIST to -ENODEV which silences the warning in
> > call_driver_probe().
> >
> > The change has also a benefit for users of init_module() as this return
> > code is propagated out from the syscall. The previous -EEXIST code made
> > the callers, such as kmod, wrongly believe that the module was already
> > loaded instead of that it failed to load.
>
> Thanks for addressing this issue so quickly!
>
> I can confirm that with this patch applied I no longer receive
> kernel: acpi-cpufreq: probe of acpi-cpufreq failed with error -17
> at boot.  Additionally, modprobe acpi-cpufreq now produces
> modprobe: ERROR: could not insert 'acpi_cpufreq': No such device
> rather than silently failing (without --first-time) to load the
> module as it did before, which seems good to me.
>
> Tested-by: Kevin Locke <kevin@kevinlocke.name>

Applied as 6.4-rc material, thanks!