linux-kernel - Re: [PATCH v1 1/5] dt-bindings: thermal: mediatek: make interrupt only required for current SoCs

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: <e31fcd9e9e5bb6e615eab98f73532dce@fw-web.de>
Date: Fri, 14 Nov 2025 18:12:49 +0100
From: "Frank Wunderlich (linux)" <linux@...web.de>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Daniel Golle <daniel@...rotopia.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Daniel Lezcano
 <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>, Lukasz Luba
 <lukasz.luba@....com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Matthias Brugger
 <matthias.bgg@...il.com>, Mason Chang <mason-cw.chang@...iatek.com>, Frank
 Wunderlich <frank-w@...lic-files.de>, Nícolas F. R. A. Prado <nfraprado@...labora.com>, Uwe Kleine-König <u.kleine-koenig@...libre.com>, Balsam CHIHI
 <bchihi@...libre.com>, linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v1 1/5] dt-bindings: thermal: mediatek: make interrupt
 only required for current SoCs

Hi,

i got respoonse from MTK...

Am 2025-10-27 11:43, schrieb AngeloGioacchino Del Regno:
> Il 26/10/25 13:21, Frank Wunderlich ha scritto:
>> From: Frank Wunderlich <frank-w@...lic-files.de>
>> 
>> Upcoming MT7987 does not have a IRQ we have to make interrupt-property 
>> only
>> required for current supported SoCs.
> 
> Hmm. Thermal sensor IP with no interrupt? Looks really strange.
> 
> This is odd, because LVTS always has multiple interrupts, and if this 
> doesn't
> actually feature any, it really feels like the hardware is broken 
> somehow.
> 
> MediaTek, can you please confirm whether the LVTS IP in MT7987 is 
> really
> like that, or can you please give the right interrupt number to Frank?
> 

the reason why the interrupt is disabled on MT7988/87 is because the 
original designer only
intended for customers to use HW reset, and did not plan for customers 
to use high/low offset
interrupts. However, in theory, this function can work.

see this part of driver-patch (3/5 "Add no-irq-mode for mt7987")

handling is divided into two cases: one is high/low offset, and the 
other is HW reset.

-	writel(0, LVTS_MONINT(lvts_ctrl->base));
-
+	if (lvts_data->irq_enable) {
+		writel(0, LVTS_MONINT(lvts_ctrl->base));
+	} else {
+		writel(BIT(16), LVTS_PROTCTL(lvts_ctrl->base));
+		writel(lvts_ctrl->hw_reset_raw_temp, LVTS_PROTTC(lvts_ctrl->base));
+	}

HW Reset:
In BL2, we set the thermal_ctl_en (bit 16) of WDT_REQ_MODE (0x1001C030) 
to 1 so that the WDT
can receive the HW reset signal from LVTS.
We also set thermal_ctl_irq (bit 16) of WDT_REQ_IRQ_EN (0x1001C034) to 1 
so that when the WDT
receives the LVTS HW reset signal, it will directly reset the IC.
LVTSMONCTRL, LVTSPROTCTL, and LVTSPROTTC are used to control the HW 
reset strategy and temperature.

High/Low Offset:
Since multiple sensors share the high/low offset settings, the high/low 
offset temperature will be
set when we echo the temperature to thermal_zoneX/trip_point_X (call 
lvts_set_trips function).
Whenever any sensor's temperature is higher or lower than the high/low 
offset, it will trigger an
IRQ (call lvts_irq_handle).

Currently we are discussing a way to verify this function works in 
hardware and then we can add
IRQ for mt7987 (which is same as on mt7988 where i did not know till now 
that IRQ is not known as
working - just ported driver + dts and checked temperature output and 
thermal-trip handling
regarding to fan). And if it works we could drop patches for 
no-irq-mode.

> Thanks,
> Angelo

regards Frank