Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Mon, 7 Jun 2021 13:02:46 +0200 | Subject | Re: [PATCH] acpi-cpufreq: Skip initialization if a cpufreq driver exists |
| |
On Mon, Jun 7, 2021 at 9:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > Hi Rafael, > > On Mon, May 24, 2021 at 7:47 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Sat, May 22, 2021 at 12:19 AM Kyle Meyer <kyle.meyer@hpe.com> wrote: > > > > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c > > > index 7e7450453714..e79a945369d1 100644 > > > --- a/drivers/cpufreq/acpi-cpufreq.c > > > +++ b/drivers/cpufreq/acpi-cpufreq.c > > > @@ -1003,7 +1003,7 @@ static int __init acpi_cpufreq_init(void) > > > > > > /* don't keep reloading if cpufreq_driver exists */ > > > if (cpufreq_get_current_driver()) > > > - return -EEXIST; > > > + return 0; > > > > > > pr_debug("%s\n", __func__); > > > > > > -- > > > > Applied as 5.14 material with some edits in the subject and changelog, thanks! > > I am not sure how this is supposed to work. If we return 0 from > acpi_cpufreq_init(), > then the driver will never be used, since it's acpi_cpufreq_init() > will never get > called again later.
Unless the module is unloaded and loaded again, that is.
> cpufreq drivers don't follow the generic device/driver model where a driver gets > probed again if a device appears and so this is broken.
It is broken anyway as per the changelog of this patch.
On systems with several hundred logical CPUs this really can be troublesome.
> Please revert this patch.
Well, you can argue that the problem at hand is outside the kernel and so it's not a kernel's business to address it.
After all, systemd-udevd could learn to avoid attempting to load the module again if it fails with -EEXIST, but I'm not sure how different that really would be from what this patch does, in practice.
| |