linux-kernel - Re: [PATCH] drm/panthor: Ensure MCU is disabled on suspend

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: <30b8b782-1bf9-43bd-9022-67851ccef7a6@arm.com>
Date: Thu, 9 Oct 2025 09:42:08 +0100
From: Karunika Choo <karunika.choo@....com>
To: Boris Brezillon <boris.brezillon@...labora.com>,
 Ketil Johnsen <ketil.johnsen@....com>
Cc: Steven Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, nd@....com
Subject: Re: [PATCH] drm/panthor: Ensure MCU is disabled on suspend

On 08/10/2025 12:32, Boris Brezillon wrote:
> On Wed,  8 Oct 2025 12:51:11 +0200
> Ketil Johnsen <ketil.johnsen@....com> wrote:
> 
>> Currently the Panthor driver needs the GPU to be powered down
>> between suspend and resume. If this is not done, then the
>> MCU_CONTROL register will be preserved as AUTO, which again will
>> cause a premature FW boot on resume. The FW will go directly into
>> fatal state in this case.
>>
>> This case needs to be handled as there is no guarantee that the
>> GPU will be powered down after the suspend callback on all platforms.
>>
>> The fix is to call panthor_fw_stop() in "pre-reset" path to ensure
>> the MCU_CONTROL register is cleared (set DISABLE). This matches
>> well with the already existing call to panthor_fw_start() from the
>> "post-reset" path.
>>
>> Signed-off-by: Ketil Johnsen <ketil.johnsen@....com>
>> ---
>>  drivers/gpu/drm/panthor/panthor_fw.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
>> index 9bf06e55eaee..df767e82148a 100644
>> --- a/drivers/gpu/drm/panthor/panthor_fw.c
>> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
>> @@ -1099,6 +1099,7 @@ void panthor_fw_pre_reset(struct panthor_device *ptdev, bool on_hang)
>>  	}
>>  
>>  	panthor_job_irq_suspend(&ptdev->fw->irq);
>> +	panthor_fw_stop(ptdev);
> 
> Is this not preventing fast resets? My understanding was that
> MCU_CONTROL shouldn't be touched if the MCU was halted from the FW, but
> maybe I got that wrong. If it's just for the MCU crash case, we can
> have:
> 
> 	if (on_hang)
> 		panthor_fw_stop(ptdev);
> 

Hi Boris, I think as long as the FW is properly halted, we can safely
disable the MCU. In fact, because of the ptdev->reset.fast tracking, we
can call panthor_fw_stop() in both cases, as the flag allows us to
handle the resume path correctly.

As per Ketil's commit message, if we don't clear the HALT bit on L2
power on, the MCU can start booting the FW with the bit enabled, which
in certain cases can make it fail to boot. So this patch fixes that by
gating when the FW is allowed to boot.

I also believe this behaviour will be better aligned with the expected
behaviour from the FW of newer GPUs (Mali-G1 for example).

Kind regards,
Karunika

>>  }
>>  
>>  /**
>