Re: State of multiple PCI(e) modules since 2022

[Mihai Moldovan <ionic@ionic.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2348 bytes --]

* On 10/29/24 17:39, Denis Kenzior wrote:
> This RFC might be of interest then:
> https://lore.kernel.org/all/20241018181842.1368394-1-denkenz@gmail.com/

Wow, thank you!

I've tried applying Kalle's RFC to ath11k (and noticed that it already is part 
of ath12k), force-enabled it and noticed that neither QCA6390 nor WNC7850 honor 
the value written to the magic register. Since the initial firmware/bootloader 
can't be easily updated, that approach isn't going to work for all supported 
hardware.

My idea was to implement an optional proxy mode into qrtr, which identifies 
messages from specific cards based on their PCI domain and bus number (which 
should work at least for MHI, no idea about AHB), and uses one socket to 
communicate with the device directly, and another socket that can be used as a 
proxy socket which reads from the "normal" socket and modifies messages based on 
the PCI data to replace the instance ID (and vice versa from driver back to the 
card/MHI interface).


Your approach of using auxiliary data looks way easier, cleaner and generally 
better and more promising.

I've applied your patch set and tried to resolve most nits that came up - 
although I've neither understood what to change to use {WRITE,READ}_ONCCE or 
where to remove locking, because the code referred to (BIND_ENDPOINT) doesn't 
even use locking. Although I essentially tested V1.5, feel free to add a me as 
Tested-By. It's successfully doing what it says it does.


Obviously that won't work out of the box for ath11k, because qmi_helpers is 
still using the "old" API that doesn't use specific endpoint binding. I'm having 
a hard time finding a way to make use of this feature in ath11k, though. We're 
at the "wrong" side of the socket in ath11k/qmi_helpers, so can't access any 
qrtr internals there. struct mhi_device is accessible from both ends, so I could 
write the QRTR endpoint id into its driver data, read it in ath11k and pass it 
down to qmi_helpers to bind to the specific endpoint. That certainly doesn't 
sound elegant and it's hard to argue why QRTR data should be part of struct 
mhi_device, and there is some potential for breakage because it would only be 
available after the qrtr-mhi interface was initialized/probed, but that's the 
only common ground I see.



Mihai

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]