On Tue, Jul 28, 2026 at 09:17:34AM +0530, Ekansh Gupta wrote: > On 27-07-2026 18:39, Shawn Guo wrote: > > The DSP firmware on Nord targets emits an unsolicited glink message > > during process teardown whose context field holds a fixed sentinel > > (0xABCDABCD) rather than the context of an outstanding invocation. > > fastrpc_rpmsg_callback() treats every inbound message as an invoke > > response, so the sentinel is masked and shifted like any real response > > ((0xABCDABCD & 0xFF0) >> 4 == 188) and looked up in the channel's > > context idr. > > > > This is not merely cosmetic. In the common case idr slot 188 is empty, > > the lookup fails, and the driver only logs a spurious "No context ID > > matches response" error on every teardown. But the context idr is shared > > by every protection domain and the listener thread on the channel and is > > filled cyclically over [1, FASTRPC_CTX_MAX]. If slot 188 holds a live > > context when the sentinel arrives, the sentinel's return value is written > > into that unrelated in-flight invocation and it is completed early. That > > is a latent, timing-dependent bug that just does not happen to trigger in > > current test runs. > > > > Drop the sentinel before it is ever turned into a context lookup. > > This removes both the log spam and the mis-completion race. A genuine > > response can never be masked: a real context is (idr_index << 4) | pd > > (at most 0xFF3) and can never equal the sentinel. > > > > Lemans and other targets are unaffected: their DSP firmware does not send > > this message, so the new check never fires. > > > Sharing more details for this context: > > On newer firmware, there is a support for DSP PD notification where DSP > sends PD state notifications on certain states as per user request. PD > exit notification is always sent by DSP which is with context id > 0xABCDABCD. As of today, DSP notification framework is not supported by > fastrpc lib or driver and it's safe to ignore this callback.
Ah, great information! I should have consulted you internally. I will update. > With this, > > Reviewed-by: Ekansh Gupta <[email protected]> Thank you, Ekansh! Shawn
