On Sat, Nov 27, 2021 at 11:59 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 11/26/21 16:56, Andy Shevchenko wrote: > > On Fri, Nov 26, 2021 at 04:21:09PM +0100, Hans de Goede wrote: ... > >> + /* > >> + * Some LPAT tables in the ACPI Device for the AXP288 PMIC for some > >> + * reason only describe a small temperature range, e.g. 27° - 37° > >> + * Celcius. Resulting in errors when the tablet is idle in a cool room. > >> + * > >> + * To avoid these errors clamp the raw value to be inside the LPAT. > >> + */ > > > >> + if (first.raw < last.raw) > > > > Wondering what that would mean if this condition is false. > > That the tables is in descending raw value order, rather then > in ascending one. Which quite a few LPAT tables actually are. > > The existing acpi_lpat_raw_to_temp() has been carefully written > to be able to handle both cases too. Thanks for explanation. Never thought that somebody can put tables in reversed order. ... > >> + raw = clamp(raw, first.raw, last.raw); > >> + else > >> + raw = clamp(raw, last.raw, first.raw); > > > > clamp_value() slightly better due to type checking. > > Quoting from include/linux/minmax.h : > > * This macro does strict typechecking of @lo/@hi to make sure they are of the > * same type as @val. See the unnecessary pointer comparisons. > */ > #define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi) > > So we already get strict type-checking from plain clamp() Pardon me, I was confused myself, it's actually other way around, so clamp() does require strict types, while clamp_val() for the cases when range is not of the same type as value. -- With Best Regards, Andy Shevchenko
