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] [thread-next>] [day] [month] [year] [list]
Message-ID: <554102c6-d597-4dc8-b760-3e2b9078e471@notapiano>
Date: Thu, 16 Jan 2025 10:18:54 -0300
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Zhang Rui <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Alexandre Mergnat <amergnat@...libre.com>,
	Balsam CHIHI <bchihi@...libre.com>, kernel@...labora.com,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org,
	Hsin-Te Yuan <yuanhsinte@...omium.org>,
	Chen-Yu Tsai <wenst@...omium.org>,
	Bernhard Rosenkränzer <bero@...libre.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	stable@...r.kernel.org
Subject: Re: [PATCH RESEND v2 1/5] thermal/drivers/mediatek/lvts: Disable
 monitor mode during suspend

On Tue, Jan 14, 2025 at 10:23:42AM +0100, Daniel Lezcano wrote:
> 
> Hi Nicolas,
> 
> On 13/01/2025 14:27, Nícolas F. R. A. Prado wrote:
> > When configured in filtered mode, the LVTS thermal controller will
> > monitor the temperature from the sensors and trigger an interrupt once a
> > thermal threshold is crossed.
> > 
> > Currently this is true even during suspend and resume. The problem with
> > that is that when enabling the internal clock of the LVTS controller in
> > lvts_ctrl_set_enable() during resume, the temperature reading can glitch
> > and appear much higher than the real one, resulting in a spurious
> > interrupt getting generated.
> > 
> > Disable the temperature monitoring and give some time for the signals to
> > stabilize during suspend in order to prevent such spurious interrupts.
> > 
> > Cc: stable@...r.kernel.org
> > Reported-by: Hsin-Te Yuan <yuanhsinte@...omium.org>
> > Closes: https://lore.kernel.org/all/20241108-lvts-v1-1-eee339c6ca20@chromium.org/
> > Fixes: 8137bb90600d ("thermal/drivers/mediatek/lvts_thermal: Add suspend and resume")
> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
> > ---
> >   drivers/thermal/mediatek/lvts_thermal.c | 36 +++++++++++++++++++++++++++++++--
> >   1 file changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c
> > index 07f7f3b7a2fb569cfc300dc2126ea426e161adff..a1a438ebad33c1fff8ca9781e12ef9e278eef785 100644
> > --- a/drivers/thermal/mediatek/lvts_thermal.c
> > +++ b/drivers/thermal/mediatek/lvts_thermal.c
> > @@ -860,6 +860,32 @@ static int lvts_ctrl_init(struct device *dev, struct lvts_domain *lvts_td,
> >   	return 0;
> >   }
> > +static void lvts_ctrl_monitor_enable(struct device *dev, struct lvts_ctrl *lvts_ctrl, bool enable)
> > +{
> > +	/*
> > +	 * Bitmaps to enable each sensor on filtered mode in the MONCTL0
> > +	 * register.
> > +	 */
> > +	static const u8 sensor_filt_bitmap[] = { BIT(0), BIT(1), BIT(2), BIT(3) };
> > +	u32 sensor_map = 0;
> > +	int i;
> > +
> > +	if (lvts_ctrl->mode != LVTS_MSR_FILTERED_MODE)
> > +		return;
> > +
> > +	if (enable) {
> > +		lvts_for_each_valid_sensor(i, lvts_ctrl)
> > +			sensor_map |= sensor_filt_bitmap[i];
> > +	}
> > +
> > +	/*
> > +	 * Bits:
> > +	 *      9: Single point access flow
> > +	 *    0-3: Enable sensing point 0-3
> > +	 */
> > +	writel(sensor_map | BIT(9), LVTS_MONCTL0(lvts_ctrl->base));
> > +}
> > +
> >   /*
> >    * At this point the configuration register is the only place in the
> >    * driver where we write multiple values. Per hardware constraint,
> > @@ -1381,8 +1407,11 @@ static int lvts_suspend(struct device *dev)
> >   	lvts_td = dev_get_drvdata(dev);
> > -	for (i = 0; i < lvts_td->num_lvts_ctrl; i++)
> > +	for (i = 0; i < lvts_td->num_lvts_ctrl; i++) {
> > +		lvts_ctrl_monitor_enable(dev, &lvts_td->lvts_ctrl[i], false);
> > +		usleep_range(100, 200);
> 
> From where this delay is coming from ?

That's empirical. I tested several times doing system suspend and resume on the
machines hooked to our lab and that was the minimum delay I could find that
still never resulted in the spurious readings.

Unfortunately the technical documentation I have access to never even mentioned
that this issue could arise, let alone what the timing constraints were, so this
had to be figured out empirically.

Thanks,
Nícolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ