linux-kernel - Re: [RFC PATCH] mailbox: omap-mailbox: Flush out pending msgs before entering 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] [day] [month] [year] [list]

Message-ID: <eef22cd5-c474-4144-af95-e306b701975d@ti.com>
Date: Thu, 30 Oct 2025 14:42:26 +0530
From: Beleswar Prasad Padhi <b-padhi@...com>
To: Francesco Dolcini <francesco@...cini.it>, Andrew Davis <afd@...com>
CC: Hari Nagalla <hnagalla@...com>, <jassisinghbrar@...il.com>,
	<linux-kernel@...r.kernel.org>, <hiagofranco@...il.com>, <u-kumar1@...com>
Subject: Re: [RFC PATCH] mailbox: omap-mailbox: Flush out pending msgs before
 entering suspend


On 30/10/25 14:29, Francesco Dolcini wrote:
> On Fri, Oct 24, 2025 at 09:08:09AM -0500, Andrew Davis wrote:
>> On 10/23/25 11:48 PM, Beleswar Prasad Padhi wrote:
>>> Hi Hari,
>>>
>>> On 23/10/25 22:48, Hari Nagalla wrote:
>>>> On 10/22/25 23:38, Beleswar Prasad Padhi wrote:
>>> Hmm, this was how it was until 2016 when commit
>>> 9f0cee984a25 ("mailbox/omap: check for any unread
>>> messages during suspend") was added. Do you
>>> suggest reverting 9f0cee984a25? Hope it doesn't
>>> break any existing usecases for OMAP platforms.
>> Checking for unread messages during suspend is still correct,
>> what we then do when we find them is the open question. We can:
>>
>>  * Not suspend (current situation)
>>  * Suspend anyway, deleting them but with a warning
> I would propose that we improve the current patch and just add a
> dev_warn when there are unread messages.


For systems which have FIFOs firewalled, this flushing
will result in exception. So we can't go with this.

>
> Andrew?
>
>>  * Save and restore them
> As of now our platforms (Toradex) are broken because of the changes in
> this series https://lore.kernel.org/all/20250908142826.1828676-1-b-padhi@ti.com/
> (now in mainline), and I would love to get it fixed sooner than later.


I've been working on this, and will send a DT patch
today to limit the num-fifos for each cluster.

Thanks,
Beleswar