On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <li.meng@xxxxxxx> 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@xxxxxxxxxxxxxx> > > > Reviewed-by: Mario Limonciello <mario.limonciello@xxxxxxx> > > > Reviewed-by: Huang Rui <ray.huang@xxxxxxx> > > > Reviewed-by: Perry Yuan <perry.yuan@xxxxxxx> > > > Signed-off-by: Meng Li <li.meng@xxxxxxx> > > > 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? Seriously, I'm not going to apply this patch so long as my comments above are not addressed.
