I'm trying to use a MT7916 from AsiaRF on a Raspberry Pi CM4 IO-Board with a PCIe to mPCIe adapter. I've exhausted all ideas I've had so far, where I'm always getting stuck at is this dmesg output:
[ 4.893376] mt7915e 0000:01:00.0: enabling device (0140 -> 0142)
[ 4.982712] page_pool_create() gave up with errno -22
[ 4.987914] mt7915e: probe of 0000:01:00.0 failed with error -22
What Ive done is flashing the latest development snapshot firmware (also tried stable in 32 and 64bit) and installed the kmod-mt7916-firmware and all dependencies that come with it (includes mt76).
I've also checked that there's enough current capabilities on the board.
The only thing left I can think of is the missing usb wiring on my adapter. Is a usb port needed for those cards?
The AMS1117 ldo on the left converts 3.3V from the pcie slot to 1.5V, but looking again at the pinout shows that the mt7916 card doesn't use it. The adapter is otherwise completely passive, so 3.3V comes from the IO-Board. According to the datasheet it is compliant with regular PCIe and does 3.3A on the 3.3V rail. From what I gather those currents are only relevant when transmitting full throttle, so shouldn't interfere with initialization in any case.
Oh great find, after I switched from stable to dev snapshot the error changed from -12 to -22, so it might be the same issue.
Theres at least one instance where it seemed to work: https://twitter.com/will_whang/status/1599637385477705729 (Scroll up for the thread)
I should try to get in touch
How sure are you that usb is not needed for initialization? Looking at the board in the twitter link, usb seems to be wired up and the card physically has the usb pins connected on the mPCIe connector. Might be worth a try as that really is the only difference electrically I can make out.
12 is ENOMEM. There are probably a number of reasons that could happen. For example in mt7915_mmio_probe() which is called at about the right time to match that log (right after enabling the PCI device). But the problem could also be somewhere else.
Unfortunately there isn't much debug output to collect from the driver. Personally I'd sprinkle a few extra debug printk's around the point in the probe where it fails to try to locate the exact point where it fails.