[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jVwHt-EoZ4YHc+8Df2W9FmO1OxfpjbTDPyW_gsAoYQ=w@mail.gmail.com>
Date: Mon, 15 May 2023 20:01:13 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Kevin Locke <kevin@...inlocke.name>,
Petr Pavlu <petr.pavlu@...e.com>
Cc: viresh.kumar@...aro.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: cpufreq: Prevent a warning when another frequency
driver is loaded
On Sun, May 14, 2023 at 3:16 PM Kevin Locke <kevin@...inlocke.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@...inlocke.name>
Applied as 6.4-rc material, thanks!
Powered by blists - more mailing lists