State of multiple PCI(e) modules since 2022

[Mihai Moldovan]

Hi


I'm quite sorry for also raising the issue on this list, but this is where it 
was last discussed.

For the past 15 years (or longer), I've been using two ath9k-based cards in a 
machine, without issues. Granted, they didn't need external firmware, and didn't 
use a complicated layered PCI/MHI/QRTR/QMI setup.

It's time to upgrade, so I put a QCA6390 (ath11k) and a WCN7850 (ath12k) card 
into a machine, assuming that it will probably work as well (especially since 
they are driven by different drivers, although ath12k started as a fork of 
ath11k) and quickly noticed that... it doesn't.

Wrote to the ath12k mailing list[0], got zero responses.
Created a bug report on the kernel bug tracker[1], because it's arguably a bug, 
switched to the ath.git kernel because that's what other developers work with. 
Got zero response, of course. Started debugging this myself and came to the 
conclusion that the qrtr stuff tries to bind to both cards with the same 
parameters and everything fails.

This isn't made easier by the fact that the documentation for the whole 
MHI/QRTR/QMI stack is very sparse (e.g., MHI, mostly documented for 
Android-based SoCs, but there's hardly any explanation of what MHI states are, 
how they are transitioned and what it all does) to non-existent (e.g., QRTR!) 
and especially how they work together on top of each other is arcane magic.

Meanwhile, a different user created another bug report[2] for essentially the 
same issue and even this mailing list had another request regarding this just a 
few days ago[3].


So far, so suspicious. Unfortunately, I only noticed yesterday that this issue 
has been known for almost 2 years now! Robert Mako even hacked together 
something[4] to work around it, but that only worked by accident (the 
BHI_ERRDBG2 register is actually supposed to be read-only and only some hardware 
uses it in the first place, so it can't be regarded as a generic fix).

There were talks[5] about pursuing Qualcomm to modify the firmware, so that a 
special register can be used to communicate an instance ID based on the PCI 
domain number and the bus number, which currently works for some firmware (and 
hence modules) and doesn't work for others, but aside from an RFC, this hasn't 
gained any traction. To be fair, this patch looks more like a generic solution 
to the issue, although it does require special firmware support. It's not even 
all that difficult to port it from other firmware, given that it only requires 
reading a host register and exposing the capability.

I'll actually try to pull this patch into my kernel and also port it to ath12k 
to see if it would work with my QCA6390 + WCN7850 combination, but even if it 
does, it's incredibly frustrating that this issue has been known for so long, 
users are actually looking for solutions to it and there seems to be no movement 
on it. Even more frustrating is that inquiries regarding this are essentially 
all but ignored.

Sorry for the rant, but I really hope that I can get some traction for this again.



Mihai

[0] https://lists.infradead.org/pipermail/ath12k/2024-October/003915.html
[1] https://bugzilla.kernel.org/show_bug.cgi?id=219380
[2] https://bugzilla.kernel.org/show_bug.cgi?id=218480
[3] https://lists.infradead.org/pipermail/ath11k/2024-October/006467.html
[4] 
https://patchwork.kernel.org/project/linux-wireless/patch/20221105194943.826847-2-robimarko@gmail.com/
[5] 
https://patchwork.kernel.org/project/linux-wireless/patch/20230111170033.32454-1-kvalo@kernel.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241027/e9a2cb50/attachment.sig>