On Mon, Feb 23, 2026 at 06:35:16PM -0600, Jassi Brar wrote: > 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. >
Thanks for clarifying. Regards, Bjorn > Cheers! > Jassi
