Re: [PATCH v6 1/3] thermal/acpi: Add ACPI trip point routines

[Daniel Lezcano <daniel.lezcano@linaro.org>]

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@linaro.org>
>> Reviewed-by: Zhang Rui <rui.zhang@intel.com>
>> Tested-by: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
> 
> Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.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