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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dfc4585f-f342-4900-8d20-6b149954f0ab@genexis.eu>
Date: Sun, 18 Jan 2026 01:02:51 +0100
From: Benjamin Larsson <benjamin.larsson@...exis.eu>
To: Andrew Lunn <andrew@...n.ch>, Lorenzo Bianconi <lorenzo@...nel.org>
Cc: Christian Marangi <ansuelsmth@...il.com>,
 Krzysztof Kozlowski <krzk@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH net-next v2 1/2] dt-bindings: net: airoha: npu: Add
 EN7581-7996 support

Hi.
On 17/01/2026 23:18, Andrew Lunn wrote:
>> 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?

You have to follow the reference design to get Airoha support. My guess 
is that everyone is following the reference designs thus there will only 
ever be one pcie configuration for each SoC to (Mediatek) Wifi-card pairing.

>   Or if they used the same slots,
> but swapped around the Ethernet and the WiFi, would it need different
> firmware?

NPU acceleration should be able to freely route packets to any port 
connected to the PSE. On the following link you can see an illustration 
of my current understanding of the AN7581 SoC: 
https://github.com/merbanan/air_tools

>
> 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
>
The NPU is a Risc-V cpu cluster. As such it should theoretically be 
possible to support any kind of configuration but if there only ever is 
one reference design my guess is that is the only officially supported one.

MvH

Benjamin Larsson