Re: [PATCH v2] net: qrtr: Send HELLO message on endpoint register
From: Pranav Mahesh Phansalkar
Date: Thu Aug 20 2026 - 02:36:30 EST
On 8/18/2026 3:24 PM, Manivannan Sadhasivam wrote:
On Fri, Aug 07, 2026 at 07:23:04PM +0530, Pranav Mahesh Phansalkar wrote:
From: Chris Lew <christopher.lew@xxxxxxxxxxxxxxxx>What is a 'slave model'? Explain please.
HELLO is currently handled entirely by the name server (NS): it is
sent once as a broadcast when the NS initializes, and again as a
reply whenever the NS receives an inbound HELLO from a remote.
In a slave model, neither endpoint initiates a HELLO on its own;
Some chipsets attached over MHI operate as slaves: they wait for the
host to send HELLO first and never initiate. Since the host cannot tell
which remotes behave this way, if the host also only replies, both
sides wait on each other indefinitely and no HELLO is ever exchanged.
each side only replies to one it receives. Since both sides are waitingWhat about the 'say_hello()' called during qrtr_ns_init()?
on the other to speak first, no HELLO is ever sent, stalling further
communication.
That call fires once during qrtr module init, before any transport (mhi/smd/tun)
can register an endpoint, so qrtr_all_nodes is empty and it reaches no remote peer.
We have reviewed it and agree it can be removed as dead code in this series.
To fix this:From the internal QMUX documentation, I can see that a node acting as a slave
- Transfer HELLO handshake ownership to the core layer.
- Schedule a work item on endpoint registration to send a HELLO once
the name server is bound, retrying on failure.
- Enforce HELLO-first ordering by dropping non-HELLO packets until
the HELLO is confirmed sent, using bool hello_sent guarded by
ep_lock to make the gate check atomic with xmit().
- Skip nodes with nid == QRTR_EP_NID_AUTO in bcast_enqueue().
- Remove say_hello() from the name server's ctrl_cmd_hello() handler;
the core layer is now the sole sender of the outbound HELLO.
should only send HELLO packet only as a response to a HELLO packet, which
contradicts with that this patch is doing.
Since the driver cannot differentiate between master/slave mode, it currently
broadcasts HELLO during initialization and sends HELLO as a response to the
HELLO packet received.
Agreed — that is exactly why we are moving to sending HELLO at every
endpoint registration instead of relying on the one-time NS-init
broadcast or reply-on-receipt, neither of which reliably reaches a
slave-mode remote like the MHI WLAN case.
- Mani