Semtech MHI driver is not compatible with other MHI devices

IoT Modules
1

We have a system running Fedora Core 40 with an EM9291 and a Qualcomm QCNFA765 based Wi-Fi adaptor. When we switch to the MBPL drivers (version R40), the Wi-Fi device stops working. When we switch back to the default drivers, the modem comes up, but many functions (including the AT interface) do not work. Switching the modem is USB mode is not an option.

Is there a way to get the Semtech mhi driver to work with the ath11k device?

$ sudo dmesg | grep ath11k
[    4.405172] ath11k_pci 0000:04:00.0: BAR 0 [mem 0x50400000-0x505fffff 64bit]: assigned
[    4.405189] ath11k_pci 0000:04:00.0: enabling device (0000 -> 0002)
[    4.405475] ath11k_pci 0000:04:00.0: MSI vectors: 32
[    4.405481] ath11k_pci 0000:04:00.0: wcn6855 hw2.1
[    4.405616] ath11k_pci 0000:04:00.0: failed to register to mhi bus, err = -22
[    4.405986] ath11k_pci 0000:04:00.0: failed to register mhi: -22
[    4.406433] ath11k_pci 0000:04:00.0: probe with driver ath11k_pci failed with error -22

$ sudo dmesg | grep mhi
[    3.442732] mhi: loading out-of-tree module taints kernel.
[    3.593062] mhi-pci-semtech 0000:05:00.0: MHI PCI device found: sierra-em929x
[    3.593068] mhi-pci-semtech 0000:05:00.0: BAR 0 [mem 0x51701000-0x51701fff 64bit]: assigned
[    3.593085] mhi-pci-semtech 0000:05:00.0: enabling device (0000 -> 0002)
[    3.593496] mhi mhi0: Requested to power ON
[    3.593504] mhi mhi0: Power on setup success
[    4.405616] ath11k_pci 0000:04:00.0: failed to register to mhi bus, err = -22
[    4.405986] ath11k_pci 0000:04:00.0: failed to register mhi: -22
2

how about doing modprobe again?

modprobe mhi
modprobe mhi_pcie_semtech

BTW, do you check with Qualcomm on this why their hardware cannot be worked?

3

This problem is that when we put the modem in USB mode it pulls PCIE_PERST_N low even though it’s an input. If this pin is shared with other device’s reset pins and caused issues.

4

why do you share this pin PCIE_PERST_N to other device’s reset pin?

I just measure this pin with multimeter in dev kit, it is 0.05V, so I believe it is in floating state.

5

We have a common reset to ensure all the devices are held in reset on reboot. There was nothing in the documentation to suggest this would not be valid. In the future we will change our design.

We observed PCIE_PERST_N is pulled low when the VBUS_SENSE is high and PCIE_DIS is high (USB mode.) We fixed the issue by cutting the trace that connected PCIE_PERST_N. In any case, the system is working in USB mode now.