quoted

On Wed, Jan 14, 2026 at 11:35:10PM +0100, Lorenzo Bianconi wrote:

quoted

quoted

quoted

In the current codebase the NPU driver does not need to access the WiFi PCIe
slot (or any other external device) since the offloading (wired and wireless)
is fully managed by the NPU chip (hw + firmware binaries).

Are you saying the NPU itself enumerates the PCI busses and finds the
WiFi device?  If it can do that, why not ask it which PCI device it is
using?

nope, we do not need any PCI enumeration in the NPU driver at the moment
(please see below).

quoted

Or this the PCI slot to use somehow embedded within the firmware?

in the current implementation the NPU driver does not need any reference to
WiFi or Ethernet devices. The NPU exports offloading APIs to consumer devices
(e.g. WiFi or Ethernet devices). In particular,
1- during NPU module probe, the NPU driver configures NPU hw registers and
   loads the NPU firmware binaries.
2- NPU consumers (ethernet and/or wifi devices) get a reference to the NPU
   device via device-tree in order to consume NPU APIs for offloading.
3- netfilter flowtable offloads traffic to the selected ethernet and/or WiFi
   device that runs the NPU APIs accessible via the NPU reference obtained via
   dts.

The issue here is the NPU firmware binaries for EN7581, loaded by the NPU
driver during NPU probe and used for offloading, depend on the WiFi chipset
(e.g. MT7996 or MT7992) available on the EN7581 board (we have two different
NPU binaries for MT7996 offloading and for MT7992 offloading).

Maybe i'm getting the NPU wrong, but i assumed it was directly talking
to the Ethernet and WiFi device on the PCIe bus, bypassing the host?

correct

quoted

If so, it most somehow know what PCIe slots these devices use?

I have low visibility on the NPU hw internals but I do not think there are
any registers in NPU mmio memory where we can read this info, but I will
confirm it (please remember the fw binaries are not load yet).

Airoha folks reported the NPU hw can't provide the PCIe Vendor/Device ID info
of the connected WiFi chip.
I guess we have the following options here:
- Rely on the firmware-name property as proposed in v1
- Access the PCIe bus from the NPU driver during probe in order to enumerate
  the PCIe devices and verify WiFi chip PCIe Vendor/Device ID
- During mt76 probe trigger the NPU fw reload if required. This approach would
  require adding a new callback in airoha_npu ops struct (please note I have
  not tested this approach and I not sure this is really doable).

What do you think? Which one do you prefer?

Regards,
Lorenzo

Regards,
Lorenzo

quoted

   Andrew