[PATCH net-next v2 1/2] dt-bindings: net: airoha: npu: Add EN7581-7996 support

[Andrew Lunn]

> 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 i'm wondering about is if the PCIe slots are hard coded in the
firmware.  If somebody builds a board using different slots, they
would then have different firmware? Or if they used the same slots,
but swapped around the Ethernet and the WiFi, would it need different
firmware?

So is the firmware name a property of the board?

If the PCIe slots are actually hard coded in the NPU silicon, cannot
be changed, then we might have a different solution, the firmware name
might be placed into a .dtsi file, or even hard coded in the driver?

> What do you think? Which one do you prefer?

I prefer to try to extract more information for the Airoha folks. What
actually defines the firmware? Does the slots used matter? Does it
matter what device goes in what slots? Is it all hard coded in
silicon? Is there only one true hardware design and if you do anything
else your board design is FUBAR, never to be supported?

     Andrew