On Wed Feb 11, 2026 at 9:04 AM JST, John Hubbard wrote: > The debug logging printed a flat "send: seq#" and "receive: seq#" for > all GSP RPC messages, with no distinction between async events from GSP > (like GspLockdownNotice or GspInitDone) and command responses (like > GetGspStaticInfo). > > Add driver-side tx_async_seq and rx_event_seq counters to independently > track async sends and async events. Move the receive debug log from > wait_for_msg() into receive_msg() where the message function is known. > Label all four message directions: > > GSP RPC: async send: seq# 0, function=GSP_SET_SYSTEM_INFO, length=0x3f0 > GSP RPC: async send: seq# 1, function=SET_REGISTRY, length=0xc5 > GSP RPC: async received: seq# 0, function=LOCKDOWN_NOTICE, length=0x51 > GSP RPC: async received: seq# 17, function=INIT_DONE, length=0x50 > GSP RPC: send: seq# 2, function=GET_GSP_STATIC_INFO, length=0x6c8 > GSP RPC: response received: seq# 2, function=GET_GSP_STATIC_INFO, > length=0x6c8 > > The async received seq# values are driver-counted for now. For command > responses, GSP echoes back the inner rpc.sequence that the CPU sent, so > the response seq# matches the send seq#. > > Cc: Maneet Singh <[email protected]> > Signed-off-by: John Hubbard <[email protected]>
I took a good look at it, but still don't understand the point of this patch. On top of the two sequence numbers we already have, this adds two more that are purely driver-internal and have no relation to the GSP. Async messages and events have no sequence numbers and we cannot refer the new counters against anything, so what do they help with?
