[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6a073166-af3c-4867-6237-dca6e03633db@linaro.org>
Date: Mon, 23 Jan 2023 12:15:31 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org
Cc: rafael@...nel.org, srinivas.pandruvada@...ux.intel.com,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
rui.zhang@...el.com, christophe.jaillet@...adoo.fr,
Amit Kucheria <amitk@...nel.org>
Subject: Re: [PATCH v6 1/3] thermal/acpi: Add ACPI trip point routines
On 22/01/2023 23:08, Rafael J. Wysocki wrote:
> On Saturday, January 21, 2023 12:15:28 AM CET Daniel Lezcano wrote:
>> The ACPI specification describes the trip points, the device tree
>> bindings as well.
>>
>> The OF code uses the generic trip point structures.
>>
>> The ACPI has their own trip points structure and uses the get_trip_*
>> ops to retrieve them.
>>
>> We can do the same as the OF code and create a set of ACPI functions
>> to retrieve a trip point description. Having a common code for ACPI
>> will help to cleanup the remaining Intel drivers and get rid of the
>> get_trip_* functions.
>>
>> These changes add the ACPI thermal calls to retrieve the basic
>> information we need to be reused in the thermal ACPI and Intel
>> drivers.
>>
>> The different ACPI functions have the generic trip point structure
>> passed as parameter where it is filled.
>>
>> This structure aims to be the one used by all the thermal drivers and
>> the thermal framework.
>>
>> After this series, a couple of Intel drivers and the ACPI thermal
>> driver will still have their own trip points definition but a new
>> series on top of this one will finish the conversion to the generic
>> trip point handling.
>>
>> This series depends on the generic trip point added to the thermal
>> framework and available in the thermal/linux-next branch.
>>
>> https://lkml.org/lkml/2022/10/3/456
>>
>> It has been tested on a Intel i7-8650U - x280 with the INT3400, the
>> PCH, ACPITZ, and x86_pkg_temp. No regression observed so far.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>> Reviewed-by: Zhang Rui <rui.zhang@...el.com>
>> Tested-by: srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
>
> Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Also I'm not sure if this version has been tested and reviewed.
>
> There are still a few things to improve in it, but overall I think that
> something like the patch below would be better - it is fewer lines of code
> and less duplication.
I'm always in favor of the simplest code, in terms of line of code and
readability. I'm perfectly fine with your proposal.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists