On Mon, Feb 23, 2026 at 9:29 AM Bjorn Andersson <[email protected]> wrote: > > On Mon, Feb 09, 2026 at 05:44:30PM -0600, [email protected] wrote: > > From: Jassi Brar <[email protected]> > > > > Clients sometimes need to know whether the mailbox TX queue has room > > before posting a new message. > > This is rather vague, could you be more specific? > > > Rather than exposing internal queue state > > through a struct field, provide a proper accessor function that returns > > the number of available slots for a given channel. > > > > This lets clients choose to back off when the queue is full instead of > > hitting the -ENOBUFS error path and the misleading "Try increasing > > MBOX_TX_QUEUE_LEN" warning. > > > > In the event that we're using the mailbox framework as a doorbell, I > presume that the queue is full of duplicate rings already - so backing > off it perfectly fine. > > But in the case where the client actually uses the interface to convey > data, what is the expected way for the client to know when to make > another attempt? > Whatever the client is currently using. It just backs off for another such signal when mbox_chan_tx_slots_available() returns 0. If a client submits periodically, it will back off for another period. If a client submits upon receiving ack packet for last submission, it will back off until it gets another ack packet.
Cheers! Jassi
