Re: [PATCH 7/7] mailbox: goog-mba: Introduce the goog-mba mailbox driver

[Jassi Brar]

On Mon, Sep 28, 2026 at 4:41 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:

> > It is not the diff stat but about inserting a flag in the api to
> > introduce special case behavior. It is like adding one person to the
> > party introduces N-1 handshakes - the has_queue flag doesn't play well
> > with other configurations and may allow future platforms to abuse
> > has_queue to implement hacks.
>
> Can you elaborate more on this?
>
> 1. How does "has_queue" not play well with other configurations?
> Everything should behave the same if "has_queue" isn't set, right? Are
> you saying that it will make the code too hard to understand, or
> something?
>
has_queue doesn't fit with all tx-done-by poll/ack/irq in
blocking/non-blocking modes. And we can't say that flag is for only
one specific setup.  I can imagine people (poor LLMs) concocting weird
designs because that's what fits their first implementation attempt...
just because that flag is available.  And then people vehemently
defend their first implementation.


> 2. How does this allow future programs to abuse "has_queue"? Won't
> they need to submit mailbox controllers to the mailbox subsystem,
> meaning they'll have to go through you? If someone is using
> "has_queue" to do a hack, can't you just NAK them?
>
It is difficult to fight platform specific changes because people
can/do say "their special platform doesn't work that way". It is much
better to reduce the abuse surface area.

> ...but I guess the root of the problem is that it just seems
> unexpected to me that fw_xlate() is taking the same input "fw_node"
> and then is returning different mailboxes.

Why is that unexpected? xlate() doesn't have to consume any hint if
all channels are identical. Another obvious example is a controller
with just one channel.
I think you should go ahead with the v2.

Regards,
Jassi