From: "Rafael J. Wysocki" <email@example.com> To: Viresh Kumar <firstname.lastname@example.org> Cc: "Rafael J. Wysocki" <email@example.com>, Takashi Iwai <firstname.lastname@example.org>, Kyle Meyer <email@example.com>, "Rafael J. Wysocki" <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, Linux PM <firstname.lastname@example.org>, email@example.com Subject: Re: [PATCH] acpi-cpufreq: Skip initialization if a cpufreq driver exists Date: Mon, 7 Jun 2021 13:02:46 +0200 [thread overview] Message-ID: <CAJZ5v0g-NMLa1UVYKpF2ehgk=6dJkKRonUY0AGw6HyRCDaQMmw@mail.gmail.com> (raw) In-Reply-To: <CAOh2x==tXk2Lt_f14_azHNYG2mZzMb9-1b2YUVj=+i=-JLemdg@mail.gmail.com> On Mon, Jun 7, 2021 at 9:26 AM Viresh Kumar <firstname.lastname@example.org> wrote: > > Hi Rafael, > > On Mon, May 24, 2021 at 7:47 PM Rafael J. Wysocki <email@example.com> wrote: > > On Sat, May 22, 2021 at 12:19 AM Kyle Meyer <firstname.lastname@example.org> 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.
next prev parent reply other threads:[~2021-06-07 11:03 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-21 22:19 Kyle Meyer 2021-05-21 22:19 ` Kyle Meyer 2021-05-24 14:16 ` Rafael J. Wysocki 2021-06-07 7:25 ` Viresh Kumar 2021-06-07 11:02 ` Rafael J. Wysocki [this message] 2021-06-07 11:14 ` Viresh Kumar -- strict thread matches above, loose matches on Subject: below -- 2021-05-18 19:34 kyle.meyer 2021-05-21 13:01 ` Rafael J. Wysocki
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAJZ5v0g-NMLa1UVYKpF2ehgk=6dJkKRonUY0AGw6HyRCDaQMmw@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] acpi-cpufreq: Skip initialization if a cpufreq driver exists' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.