linux-kernel - Re: [PATCH RESEND v3 4/9] thermal: mediatek: lvts: Add platform ops to support alternative conversion logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20251113162053.281093-1-laura.nao@collabora.com>
Date: Thu, 13 Nov 2025 17:20:53 +0100
From: Laura Nao <laura.nao@...labora.com>
To: daniel.lezcano@...aro.org
Cc: andrew-ct.chen@...iatek.com,
	angelogioacchino.delregno@...labora.com,
	arnd@...db.de,
	bchihi@...libre.com,
	colin.i.king@...il.com,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	frank-w@...lic-files.de,
	fshao@...omium.org,
	kernel@...labora.com,
	krzk+dt@...nel.org,
	lala.lin@...iatek.com,
	laura.nao@...labora.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-mediatek@...ts.infradead.org,
	linux-pm@...r.kernel.org,
	lukasz.luba@....com,
	matthias.bgg@...il.com,
	nfraprado@...labora.com,
	rafael@...nel.org,
	robh@...nel.org,
	rui.zhang@...el.com,
	srini@...nel.org,
	u.kleine-koenig@...libre.com
Subject: Re: [PATCH RESEND v3 4/9] thermal: mediatek: lvts: Add platform ops to support alternative conversion logic

Hi Daniel,

On 11/10/25 14:06, Daniel Lezcano wrote:
> On 10/16/25 16:21, Laura Nao wrote:
>> Introduce lvts_platform_ops struct to support SoC-specific versions of
>> lvts_raw_to_temp() and lvts_temp_to_raw() conversion functions.
>>
>> This is in preparation for supporting SoCs like MT8196/MT6991, which
>> require a different lvts_temp_to_raw() implementation.
>>
>> Reviewed-by: Fei Shao <fshao@...omium.org>
>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> Signed-off-by: Laura Nao <laura.nao@...labora.com>
>> ---
>>   drivers/thermal/mediatek/lvts_thermal.c | 27 ++++++++++++++++++++++---
>>   1 file changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c
>> index 4ef549386add..df1c0f059ad0 100644
>> --- a/drivers/thermal/mediatek/lvts_thermal.c
>> +++ b/drivers/thermal/mediatek/lvts_thermal.c
>> @@ -125,8 +125,14 @@ struct lvts_ctrl_data {
>>               continue; \
>>           else
>>   +struct lvts_platform_ops {
>> +    int (*lvts_raw_to_temp)(u32 raw_temp, int temp_factor);
>> +    u32 (*lvts_temp_to_raw)(int temperature, int temp_factor);
>> +};
>> +
>>   struct lvts_data {
>>       const struct lvts_ctrl_data *lvts_ctrl;
>> +    const struct lvts_platform_ops *ops;
>>       const u32 *conn_cmd;
>>       const u32 *init_cmd;
>>       int num_cal_offsets;
>> @@ -300,6 +306,7 @@ static int lvts_get_temp(struct thermal_zone_device *tz, int *temp)
>>       struct lvts_ctrl *lvts_ctrl = container_of(lvts_sensor, struct lvts_ctrl,
>>                              sensors[lvts_sensor->id]);
>>       const struct lvts_data *lvts_data = lvts_ctrl->lvts_data;
>> +    const struct lvts_platform_ops *ops = lvts_data->ops;
>>       void __iomem *msr = lvts_sensor->msr;
>>       u32 value;
>>       int rc;
>> @@ -332,7 +339,7 @@ static int lvts_get_temp(struct thermal_zone_device *tz, int *temp)
>>       if (rc)
>>           return -EAGAIN;
>>   -    *temp = lvts_raw_to_temp(value & 0xFFFF, lvts_data->temp_factor);
>> +    *temp = ops->lvts_raw_to_temp(value & 0xFFFF, lvts_data->temp_factor); 
>
> Don't do this in each functions. It does not help for the readability.
>
> May be something like:
>
> int lvts_raw_to_temp(u32 raw_temp, const struct lvts_ctrl_data)
> {
>     return data->ops->lvts_temp_to_raw(raw_temp, data->temp_factor);
> }
>
> or
>
> int lvts_raw_to_temp(u32 raw_temp, const struct lvts_ctrl_data)
> {
>     int temperature;
>
>     if (data->ops->lvts_temp_to_raw)
>         return data->ops->lvts_temp_to_raw(raw_temp, data->temp_factor);
>
>     temperature = ((s64)(raw_temp & 0xFFFF) * temp_factor) >> 14;
>         temperature += golden_temp_offset;
>
>         return temperature;
> }
>
> ... and get rid of all the lvts_platform_ops_v1
>
> (btw _v1 is confusing, it suggests there multiple versions of the same SoC)
>

Right, the first option looks more efficient. Since temp_offset is 
already part of lvts_data, the function would look like:

int lvts_raw_to_temp(u32 raw_temp, const struct lvts_data *lvts_data)
{
	return lvts_data->ops->lvts_raw_to_temp(raw_temp, lvts_data->temp_factor);
}

and the same pattern applies for temp_to_raw().

This change will require renaming the existing 
lvts_raw_to_temp()/lvts_temp_to_raw()/lvts_temp_to_raw_v2() 
implementations. I agree the current _v1 and _v2 suffixes aren’t very 
descriptive. Since lvts_temp_to_raw_v2() version is only used by MT8196,
it could be renamed to lvts_temp_to_raw_mt8196(), with the corresponding 
platform ops defined as lvts_platform_ops_mt8196. The base 
lvts_raw_to_temp()/lvts_temp_to_raw() are shared across the other SoCs,
so they could be renamed after the first supported platform (mt7988) and 
reused for all SoCs that share the same logic.

I'll send out a v4 with the proposed changes.

Thanks,

Laura

> [ ... ]
>