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

[Daniel Lezcano]

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@xxxxxxxxxx>
> > Reviewed-by: Zhang Rui <rui.zhang@xxxxxxxxx>
> > Tested-by: srinivas pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx>
>
> Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>
> 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