Hi Konrad, You're right. These touch related FastRPC lifetime and bounds paths, and several of them depend on the same state cleanup. I grouped the follow-up fixes I still think are valid into a small series, and I'll keep any further FastRPC changes batched instead of sending more standalone threads.
Thanks, Yousef On Thu, 25 Jun 2026 09:40:53 +0200, Konrad Dybcio <[email protected]> wrote: > On 6/24/26 9:27 PM, Yousef Alhouseen wrote: > > fastrpc_rpmsg_remove() wakes pending invoke waiters when the rpmsg device > > is removed, but it does not release the send references taken before each > > request was submitted. Those references normally disappear only when a DSP > > reply arrives, which cannot be relied on after endpoint removal. > > > > Walk the channel IDR during removal, mark in-flight contexts completed, > > and schedule the send-reference put while waking waiters with -EPIPE. This > > prevents disconnected channels from pinning invoke contexts indefinitely. > > > > Signed-off-by: Yousef Alhouseen <[email protected]> > > --- > > You sent ~10 patches to fastrpc as separate threads, do they have > any sort of co-dependence? Can they be applied in random order? > > Generally if your changes are even vaguely related, it's best to > send them in a single series, if only to reduce the possibility of > a merge conflict > > Konrad
