Re: [PATCH 4/4] wifi: ath12k: Connect to the QMI server belonging to the device owned by this driver

[Mihai Moldovan]

* On 9/18/26 18:51, Juha-Matti Tilli wrote:
> > But now, QRTR provides each MHI endpoint a unique node id which is
> > different from the node id announced by the device. So use the same id to
> > pick the correct server. Add a get_qrtr_node_id() HIF callback that returns
> > the node id derived from the MHI controller index and zero for transports
> > that do not assign one. In the new_server callback, skip any service whose
> > node id does not match. A node id of zero disables the check, so transports
> > that do not assign one keep their current behavior.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxxxxxxxx>
>
> CC'ing Mihai. He is known to have a platform with two ath12k cards,
> but he said he's been busy recently, so his testing input is uncertain.

I probably could change the setup to use 2 x ath12k modules, yes, but really I 
have always been testing with one module using ath11k and the other module using 
ath12k. Never tested two ath11k or ath12k at a time. There might be even more 
obstacles to getting that to work correctly.

My "test setup" is in the new flat where I don't have a proper networking setup, 
though, so... meh. Don't count on me testing it this year still.

The proposed code looks simple enough, though, and generally makes sense. It 
also does away with aux data on the qrtr socket, and if both endpoints can 
access the same MHI data, it probably makes sense to let them both determine the 
node ID via the shared MHI controller index (the important part here is that the 
node ID knowledge is not stored or passed through anywhere in a common qrtr data 
structure, but essentially becomes a "shared secret" that both end points 
determine individually, but also in a deterministic, matching way).

Since this changes the endpoint ID completely, this might even make the 
user-space qrtr tools work transparently with multiple devices, i.e., not 
requiring any changes to that part. That would be my hope at least. Definitely 
needs testing, though. It would be great if the user-space tools could directly 
communicate with the servers on the modules, but I'm not quite sure how the 
user-space tools would come to the correct node ID conclusion. This might be one 
drawback of the "shared knowledge" architecture - it might be difficult to make 
it work outside of the driver realm.


Indeed a cleaner and more simple approach, though.



Mihai