On 2/26/2026 9:53 PM, Bjorn Andersson wrote:
> 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.
>
Hi Jassi,
What is the next step for this patch? When it is expected to merge?
Thank You,
Tanmay
> Regards,
> Bjorn
>
>> Cheers!
>> Jassi
