lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hMAZxvuMWK3dNeOL9FRTrVW7j7PzCFwcp9+0K87y-L0A@mail.gmail.com>
Date:   Wed, 6 Dec 2023 22:13:00 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Meng Li <li.meng@....com>
Cc:     "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Huang Rui <ray.huang@....com>, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-acpi@...r.kernel.org, Shuah Khan <skhan@...uxfoundation.org>,
        linux-kselftest@...r.kernel.org,
        Nathan Fontenot <nathan.fontenot@....com>,
        Deepak Sharma <deepak.sharma@....com>,
        Alex Deucher <alexander.deucher@....com>,
        Mario Limonciello <mario.limonciello@....com>,
        Shimmer Huang <shimmer.huang@....com>,
        Perry Yuan <Perry.Yuan@....com>,
        Xiaojian Du <Xiaojian.Du@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Borislav Petkov <bp@...en8.de>,
        Oleksandr Natalenko <oleksandr@...alenko.name>
Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message that the
 highest perf has changed

On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@....com> wrote:
> >
> > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can be
> > emmitted to cause the the OSPM to re-evaluate the highest performance
>
> Typos above.  Given the number of iterations of this patch, this is
> kind of disappointing.
>
> > register. Add support for this event.
>
> Also it would be nice to describe how this is supposed to work at
> least roughly, so it is not necessary to reverse-engineer the patch to
> find out that.
>
> > Tested-by: Oleksandr Natalenko <oleksandr@...alenko.name>
> > Reviewed-by: Mario Limonciello <mario.limonciello@....com>
> > Reviewed-by: Huang Rui <ray.huang@....com>
> > Reviewed-by: Perry Yuan <perry.yuan@....com>
> > Signed-off-by: Meng Li <li.meng@....com>
> > Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values
> > ---
> >  drivers/acpi/processor_driver.c |  6 ++++++
> >  drivers/cpufreq/cpufreq.c       | 13 +++++++++++++
> >  include/linux/cpufreq.h         |  5 +++++
> >  3 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > index 4bd16b3f0781..29b2fb68a35d 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -27,6 +27,7 @@
> >  #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
> >  #define ACPI_PROCESSOR_NOTIFY_POWER    0x81
> >  #define ACPI_PROCESSOR_NOTIFY_THROTTLING       0x82
> > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED      0x85
> >
> >  MODULE_AUTHOR("Paul Diefenbaugh");
> >  MODULE_DESCRIPTION("ACPI Processor Driver");
> > @@ -83,6 +84,11 @@ static void acpi_processor_notify(acpi_handle handle, u32 event, void *data)
> >                 acpi_bus_generate_netlink_event(device->pnp.device_class,
> >                                                   dev_name(&device->dev), event, 0);
> >                 break;
> > +       case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED:
> > +               cpufreq_update_highest_perf(pr->id);
>
> And the design appears to be a bit ad-hoc here.
>
> Because why does it have anything to do with cpufreq?

Well, clearly, cpufreq can be affected by this, but why would it be
not affected the same way as in the ACPI_PROCESSOR_NOTIFY_PERFORMANCE
case?

That is, why isn't cpufreq_update_limits() the right thing to do?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ