[PATCH net-next v2 0/2] airoha: Add the en7581-npu-7996 support

[PATCH net-next v2 0/2] airoha: Add the en7581-npu-7996 support

[Lorenzo Bianconi]

This is a preliminary patch to enable MT76 NPU offloading for MT7996
(Eagle) chipset since it requires different binaries with respect to
the ones used for MT7992 on the EN7581 SoC.

---
Changes in v2:
- Introduce "airoha,en7581-npu-7996" compatible string to specify the
  firmware and drop "firmware-name" property
- Link to v1: https://lore.kernel.org/r/20260112-airoha-npu-firmware-name-v1-0-d0b148b6710f@kernel.org

---
Lorenzo Bianconi (2):
      dt-bindings: net: airoha: npu: Add EN7581-7996 support
      net: airoha: npu: Add en7581-npu-7996 compatible string

 .../devicetree/bindings/net/airoha,en7581-npu.yaml       |  1 +
 drivers/net/ethernet/airoha/airoha_npu.c                 | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
---
base-commit: cbe8e6bef6a3b4b895b47ea56f5952f1936aacb6
change-id: 20260107-airoha-npu-firmware-name-34e5002a1a3f

Best regards,
-- 
Lorenzo Bianconi <lorenzo@kernel.org>

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

[Lorenzo Bianconi]

Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
offloading for MT7996 (Eagle) chipset since it requires different
binaries with respect to the ones used for MT7992 on the EN7581 SoC.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
 Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
--- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
+++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
@@ -18,6 +18,7 @@ properties:
   compatible:
     enum:
       - airoha,en7581-npu
+      - airoha,en7581-npu-7996
       - airoha,an7583-npu
 
   reg:

-- 
2.52.0

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

[Krzysztof Kozlowski]

On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
> Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
> offloading for MT7996 (Eagle) chipset since it requires different
> binaries with respect to the ones used for MT7992 on the EN7581 SoC.
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
>  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> @@ -18,6 +18,7 @@ properties:
>    compatible:
>      enum:
>        - airoha,en7581-npu
> +      - airoha,en7581-npu-7996

This does not warrant new compatible. There is some misunderstanding and
previous discussion asked you to use proper compatible, not invent fake
one for non-existing hardware.  Either you have en7996-npu or
en7581-npu. Not some mixture.


Best regards,
Krzysztof

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

> On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
> > Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
> > offloading for MT7996 (Eagle) chipset since it requires different
> > binaries with respect to the ones used for MT7992 on the EN7581 SoC.
> > 
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> >  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> > index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
> > --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> > +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> > @@ -18,6 +18,7 @@ properties:
> >    compatible:
> >      enum:
> >        - airoha,en7581-npu
> > +      - airoha,en7581-npu-7996
> 
> This does not warrant new compatible. There is some misunderstanding and
> previous discussion asked you to use proper compatible, not invent fake
> one for non-existing hardware.  Either you have en7996-npu or
> en7581-npu. Not some mixture.

Hi Krzysztof,

We need to specify which fw binaries the airoha NPU module should load
according to the MT76 WiFi chipset is running on the board (since the NPU
firmware images are not the same for all the different WiFi chipsets).
We have two possible combinations:
- EN7581 NPU + MT7996 (Eagle)
- EN7581 NPU + MT7992 (Kite)

Please note the airoha NPU module is always the same (this is why is just
added the -7996 suffix in the compatible string). IIUC you are suggesting
to use the 'airoha,en7996-npu' compatible string, right?

Regards,
Lorenzo

> 
> 
> Best regards,
> Krzysztof
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Krzysztof Kozlowski]

On 14/01/2026 10:01, Lorenzo Bianconi wrote:
>> On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
>>> Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
>>> offloading for MT7996 (Eagle) chipset since it requires different
>>> binaries with respect to the ones used for MT7992 on the EN7581 SoC.
>>>
>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>> ---
>>>  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
>>> index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
>>> --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
>>> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
>>> @@ -18,6 +18,7 @@ properties:
>>>    compatible:
>>>      enum:
>>>        - airoha,en7581-npu
>>> +      - airoha,en7581-npu-7996
>>
>> This does not warrant new compatible. There is some misunderstanding and
>> previous discussion asked you to use proper compatible, not invent fake
>> one for non-existing hardware.  Either you have en7996-npu or
>> en7581-npu. Not some mixture.
> 
> Hi Krzysztof,
> 
> We need to specify which fw binaries the airoha NPU module should load
> according to the MT76 WiFi chipset is running on the board (since the NPU
> firmware images are not the same for all the different WiFi chipsets).
> We have two possible combinations:
> - EN7581 NPU + MT7996 (Eagle)
> - EN7581 NPU + MT7992 (Kite)
> 
> Please note the airoha NPU module is always the same (this is why is just
> added the -7996 suffix in the compatible string). IIUC you are suggesting
> to use the 'airoha,en7996-npu' compatible string, right?

No. I am suggesting you need to describe here the hardware. You said
this EN7581 NPU, so this is the only compatible you get, unless (which
is not explained anywhere here) that's part of MT799x soc, but then you
miss that compatible. Really, standard compatible rules apply - so
either this is SoC element/component or dedicated chip.



Best regards,
Krzysztof

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

[Christian Marangi]

On Wed, Jan 14, 2026 at 10:26:33AM +0100, Krzysztof Kozlowski wrote:
> On 14/01/2026 10:01, Lorenzo Bianconi wrote:
> >> On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
> >>> Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
> >>> offloading for MT7996 (Eagle) chipset since it requires different
> >>> binaries with respect to the ones used for MT7992 on the EN7581 SoC.
> >>>
> >>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >>> ---
> >>>  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>> index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
> >>> --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>> @@ -18,6 +18,7 @@ properties:
> >>>    compatible:
> >>>      enum:
> >>>        - airoha,en7581-npu
> >>> +      - airoha,en7581-npu-7996
> >>
> >> This does not warrant new compatible. There is some misunderstanding and
> >> previous discussion asked you to use proper compatible, not invent fake
> >> one for non-existing hardware.  Either you have en7996-npu or
> >> en7581-npu. Not some mixture.
> > 
> > Hi Krzysztof,
> > 
> > We need to specify which fw binaries the airoha NPU module should load
> > according to the MT76 WiFi chipset is running on the board (since the NPU
> > firmware images are not the same for all the different WiFi chipsets).
> > We have two possible combinations:
> > - EN7581 NPU + MT7996 (Eagle)
> > - EN7581 NPU + MT7992 (Kite)
> > 
> > Please note the airoha NPU module is always the same (this is why is just
> > added the -7996 suffix in the compatible string). IIUC you are suggesting
> > to use the 'airoha,en7996-npu' compatible string, right?
> 
> No. I am suggesting you need to describe here the hardware. You said
> this EN7581 NPU, so this is the only compatible you get, unless (which
> is not explained anywhere here) that's part of MT799x soc, but then you
> miss that compatible. Really, standard compatible rules apply - so
> either this is SoC element/component or dedicated chip.
> 
>

Hi Krzysztof,

just noticing this conversation and I think there is some confusion
here.

The HW is the following:

AN/EN7581 SoC that have embedded this NPU (a network coprocessor) that
require a dedicated firmware blob to be loaded to work.

Then the SoC can have various WiFi card connected to the PCIe slot.

For the WiFi card MT7996 (Eagle) and the WiFi card MT7992 (Kite) the NPU
can also offload the WiFi traffic.

A dedicated firmware blob for the NPU is needed to support the specific
WiFi card.

This is why v1 proposed the implementation with the firmware-names
property.

v2 introduce the compatible but I feel that doesn't strictly describe
the hardware as the NPU isn't specific to the WiFi card but just the
firmware blob.


I still feel v1 with firmware-names should be the correct candidate to
handle this.

Hope now the HW setup is more clear.

-- 
	Ansuel

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

[Krzysztof Kozlowski]

On 14/01/2026 11:09, Christian Marangi wrote:
> On Wed, Jan 14, 2026 at 10:26:33AM +0100, Krzysztof Kozlowski wrote:
>> On 14/01/2026 10:01, Lorenzo Bianconi wrote:
>>>> On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
>>>>> Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
>>>>> offloading for MT7996 (Eagle) chipset since it requires different
>>>>> binaries with respect to the ones used for MT7992 on the EN7581 SoC.
>>>>>
>>>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
>>>>> index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
>>>>> --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
>>>>> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
>>>>> @@ -18,6 +18,7 @@ properties:
>>>>>    compatible:
>>>>>      enum:
>>>>>        - airoha,en7581-npu
>>>>> +      - airoha,en7581-npu-7996
>>>>
>>>> This does not warrant new compatible. There is some misunderstanding and
>>>> previous discussion asked you to use proper compatible, not invent fake
>>>> one for non-existing hardware.  Either you have en7996-npu or
>>>> en7581-npu. Not some mixture.
>>>
>>> Hi Krzysztof,
>>>
>>> We need to specify which fw binaries the airoha NPU module should load
>>> according to the MT76 WiFi chipset is running on the board (since the NPU
>>> firmware images are not the same for all the different WiFi chipsets).
>>> We have two possible combinations:
>>> - EN7581 NPU + MT7996 (Eagle)
>>> - EN7581 NPU + MT7992 (Kite)
>>>
>>> Please note the airoha NPU module is always the same (this is why is just
>>> added the -7996 suffix in the compatible string). IIUC you are suggesting
>>> to use the 'airoha,en7996-npu' compatible string, right?
>>
>> No. I am suggesting you need to describe here the hardware. You said
>> this EN7581 NPU, so this is the only compatible you get, unless (which
>> is not explained anywhere here) that's part of MT799x soc, but then you
>> miss that compatible. Really, standard compatible rules apply - so
>> either this is SoC element/component or dedicated chip.
>>
>>
> 
> Hi Krzysztof,
> 
> just noticing this conversation and I think there is some confusion
> here.
> 
> The HW is the following:
> 
> AN/EN7581 SoC that have embedded this NPU (a network coprocessor) that
> require a dedicated firmware blob to be loaded to work.
> 
> Then the SoC can have various WiFi card connected to the PCIe slot.
> 
> For the WiFi card MT7996 (Eagle) and the WiFi card MT7992 (Kite) the NPU
> can also offload the WiFi traffic.
> 
> A dedicated firmware blob for the NPU is needed to support the specific
> WiFi card.
> 
> This is why v1 proposed the implementation with the firmware-names
> property.
> 
> v2 introduce the compatible but I feel that doesn't strictly describe
> the hardware as the NPU isn't specific to the WiFi card but just the
> firmware blob.
> 
> 
> I still feel v1 with firmware-names should be the correct candidate to
> handle this.

Yes. What you plug into PCI is not a part of this hardware, so cannot be
part of the compatible.

> 
> Hope now the HW setup is more clear.
> 


Best regards,
Krzysztof

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

[Christian Marangi]

On Wed, Jan 14, 2026 at 11:34:55AM +0100, Krzysztof Kozlowski wrote:
> On 14/01/2026 11:09, Christian Marangi wrote:
> > On Wed, Jan 14, 2026 at 10:26:33AM +0100, Krzysztof Kozlowski wrote:
> >> On 14/01/2026 10:01, Lorenzo Bianconi wrote:
> >>>> On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
> >>>>> Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
> >>>>> offloading for MT7996 (Eagle) chipset since it requires different
> >>>>> binaries with respect to the ones used for MT7992 on the EN7581 SoC.
> >>>>>
> >>>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >>>>> ---
> >>>>>  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
> >>>>>  1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>>>> index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
> >>>>> --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>>>> @@ -18,6 +18,7 @@ properties:
> >>>>>    compatible:
> >>>>>      enum:
> >>>>>        - airoha,en7581-npu
> >>>>> +      - airoha,en7581-npu-7996
> >>>>
> >>>> This does not warrant new compatible. There is some misunderstanding and
> >>>> previous discussion asked you to use proper compatible, not invent fake
> >>>> one for non-existing hardware.  Either you have en7996-npu or
> >>>> en7581-npu. Not some mixture.
> >>>
> >>> Hi Krzysztof,
> >>>
> >>> We need to specify which fw binaries the airoha NPU module should load
> >>> according to the MT76 WiFi chipset is running on the board (since the NPU
> >>> firmware images are not the same for all the different WiFi chipsets).
> >>> We have two possible combinations:
> >>> - EN7581 NPU + MT7996 (Eagle)
> >>> - EN7581 NPU + MT7992 (Kite)
> >>>
> >>> Please note the airoha NPU module is always the same (this is why is just
> >>> added the -7996 suffix in the compatible string). IIUC you are suggesting
> >>> to use the 'airoha,en7996-npu' compatible string, right?
> >>
> >> No. I am suggesting you need to describe here the hardware. You said
> >> this EN7581 NPU, so this is the only compatible you get, unless (which
> >> is not explained anywhere here) that's part of MT799x soc, but then you
> >> miss that compatible. Really, standard compatible rules apply - so
> >> either this is SoC element/component or dedicated chip.
> >>
> >>
> > 
> > Hi Krzysztof,
> > 
> > just noticing this conversation and I think there is some confusion
> > here.
> > 
> > The HW is the following:
> > 
> > AN/EN7581 SoC that have embedded this NPU (a network coprocessor) that
> > require a dedicated firmware blob to be loaded to work.
> > 
> > Then the SoC can have various WiFi card connected to the PCIe slot.
> > 
> > For the WiFi card MT7996 (Eagle) and the WiFi card MT7992 (Kite) the NPU
> > can also offload the WiFi traffic.
> > 
> > A dedicated firmware blob for the NPU is needed to support the specific
> > WiFi card.
> > 
> > This is why v1 proposed the implementation with the firmware-names
> > property.
> > 
> > v2 introduce the compatible but I feel that doesn't strictly describe
> > the hardware as the NPU isn't specific to the WiFi card but just the
> > firmware blob.
> > 
> > 
> > I still feel v1 with firmware-names should be the correct candidate to
> > handle this.
> 
> Yes. What you plug into PCI is not a part of this hardware, so cannot be
> part of the compatible.
> 

Thanks for the quick response. Just to make sure Lorenzo doesn't get
confused, I guess a v3 would be sending v1 again (firmware-names
implementation series) with the review tag and we should be done with
this.

> > 
> > Hope now the HW setup is more clear.
> > 
> 
> 
> Best regards,
> Krzysztof

-- 
	Ansuel

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

[Andrew Lunn]

> > Yes. What you plug into PCI is not a part of this hardware, so cannot be
> > part of the compatible.
> > 
> 
> Thanks for the quick response. Just to make sure Lorenzo doesn't get
> confused, I guess a v3 would be sending v1 again (firmware-names
> implementation series) with the review tag and we should be done with
> this.

Since this is a PCI device, you can ask it what it is, and then load
the correct firmware based on the PCI vendor:product. You don't need
to describe the hardware in DT because it is enumerable.

   Andrew

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

[Christian Marangi]

On Wed, Jan 14, 2026 at 04:56:02PM +0100, Andrew Lunn wrote:
> > > Yes. What you plug into PCI is not a part of this hardware, so cannot be
> > > part of the compatible.
> > > 
> > 
> > Thanks for the quick response. Just to make sure Lorenzo doesn't get
> > confused, I guess a v3 would be sending v1 again (firmware-names
> > implementation series) with the review tag and we should be done with
> > this.
> 
> Since this is a PCI device, you can ask it what it is, and then load
> the correct firmware based on the PCI vendor:product. You don't need
> to describe the hardware in DT because it is enumerable.
> 

Hi Andrew,

I think it's problematic to create a bind between the NPU and
PCIe.

Do you have any hint on how it's possible to read the PCI
device attached? I'm not aware of any API that can be used
to enumerate what pcie devices is present on the device?

Considering how tightly integrated things are in this SoC
I still feel firmware-names is the most effective solution
for this. The WiFi offload is mostly optional and sadly
due to Airoha limitation, it's not possible to have separate
blob for the single feature/support.

-- 
	Ansuel

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

[Andrew Lunn]

On Wed, Jan 14, 2026 at 05:29:28PM +0100, Christian Marangi wrote:
> On Wed, Jan 14, 2026 at 04:56:02PM +0100, Andrew Lunn wrote:
> > > > Yes. What you plug into PCI is not a part of this hardware, so cannot be
> > > > part of the compatible.
> > > > 
> > > 
> > > Thanks for the quick response. Just to make sure Lorenzo doesn't get
> > > confused, I guess a v3 would be sending v1 again (firmware-names
> > > implementation series) with the review tag and we should be done with
> > > this.
> > 
> > Since this is a PCI device, you can ask it what it is, and then load
> > the correct firmware based on the PCI vendor:product. You don't need
> > to describe the hardware in DT because it is enumerable.
> > 
> 
> Hi Andrew,
> 
> I think it's problematic to create a bind between the NPU and
> PCIe.

But the NPU must already be bound to PCIe. How else does it know which
PCIe slot the WiFi card is on, so it can make use of it?

     Andrew

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Jan 14, Andrew Lunn wrote:
> On Wed, Jan 14, 2026 at 05:29:28PM +0100, Christian Marangi wrote:
> > On Wed, Jan 14, 2026 at 04:56:02PM +0100, Andrew Lunn wrote:
> > > > > Yes. What you plug into PCI is not a part of this hardware, so cannot be
> > > > > part of the compatible.
> > > > > 
> > > > 
> > > > Thanks for the quick response. Just to make sure Lorenzo doesn't get
> > > > confused, I guess a v3 would be sending v1 again (firmware-names
> > > > implementation series) with the review tag and we should be done with
> > > > this.
> > > 
> > > Since this is a PCI device, you can ask it what it is, and then load
> > > the correct firmware based on the PCI vendor:product. You don't need
> > > to describe the hardware in DT because it is enumerable.
> > > 
> > 
> > Hi Andrew,
> > 
> > I think it's problematic to create a bind between the NPU and
> > PCIe.
> 
> But the NPU must already be bound to PCIe. How else does it know which
> PCIe slot the WiFi card is on, so it can make use of it?

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). The NPU driver is
only responsible for loading the proper firmware binaries, configure NPU hw
registers and export APIs for other external chips (e.g. MT76).
IIUC your proposal, we should add a PCIe slot access in the NPU kernel driver in
order to enumerate PCIe Vendor/Device IDs during device probe and load the
proper firmware binaries, right? If so, this approach seems quite more complex
to me with respect of relying on firmware-name dts property (assuming
firmware-name is a suitable property for this scope). What do you think?

Regards,
Lorenzo

> 
>      Andrew

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andrew Lunn]

> 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?

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

Or is it simply hard coded in the NPU silicon which slot to use?

   Andrew

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

> > 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).

> 
> 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).

Regards,
Lorenzo

> 
> Or is it simply hard coded in the NPU silicon which slot to use?
> 
>    Andrew

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andrew Lunn]

On Wed, Jan 14, 2026 at 11:35:10PM +0100, Lorenzo Bianconi wrote:
> > > 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).
> 
> > 
> > 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?
If so, it most somehow know what PCIe slots these devices use?

   Andrew

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

> On Wed, Jan 14, 2026 at 11:35:10PM +0100, Lorenzo Bianconi wrote:
> > > > 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).
> > 
> > > 
> > > 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

> 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).

Regards,
Lorenzo

> 
>    Andrew

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]

> > On Wed, Jan 14, 2026 at 11:35:10PM +0100, Lorenzo Bianconi wrote:
> > > > > 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).
> > > 
> > > > 
> > > > 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
> 
> > 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
> 
> > 
> >    Andrew



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Benjamin Larsson]

On 17/01/2026 18:53, Lorenzo Bianconi 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 do you think? Which one do you prefer?
>
> Regards,
> Lorenzo

Please note that there might be nothing connected to the pcie bus thus 
nothing to enumerate and the mt76-driver might not be present. (Lots of 
fiber termination only products use this configuration).

For those cases I would prefer the v1 proposal.

MvH

Benjamin Larsson

Re: [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

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

[Benjamin Larsson]

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

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

> > 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?

As pointed out by Benjamin, the NPU is a generic Risc-V cpu cluster and it is
used to move packets from/to ethernet DMA rings to/from WiFi DMA rings without
involving the host cpu (similar to what we have for MTK with WED module).
I think the PCIe slot info is not necessary for the NPU to work since it is
configured by ethernet (airoha-eth) and wireless drivers (mt76) with DMA ring
addresses to use via the airoha npu ops APIs, NPU just moves data between the
DMA rings according to my understanding.

> 
> So is the firmware name a property of the board?

We need to run different binaries on the NPU based on the MT76 WiFi chip
available on the board since the MT76 DMA rings layout changes between MT76 SoC
revisions (e.g. Egle MT7996 vs Kite MT7992). In this sense, I agree, the
firmware name is a board property.

> 
> 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?

IIUC what you mean here, it seems the solution I proposed in v1 (using
firmware-name property), right?
In this case we can't hard code the firmware name in the NPU driver since
we can't understand the MT76 WiFi chip revision running on the board at
the moment (MT76 would need to provide this info during MT76 probe,
please take a look to the option 3 in my previous email).

> 
> > 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?

I think the firmware is defined by the board hw configuration (e.g. MT76
SoC revision) and not by the specific PCIe slot used.
I do not think we have these info hardcoded in the silicon since NPU is a
generic RiscV cpu (this has been confirmed by airoha folks).

Regards,
Lorenzo

> 
>      Andrew

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Christian Marangi]

On Mon, Jan 19, 2026 at 12:07:55PM +0100, Lorenzo Bianconi 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? Or if they used the same slots,
> > but swapped around the Ethernet and the WiFi, would it need different
> > firmware?
> 
> As pointed out by Benjamin, the NPU is a generic Risc-V cpu cluster and it is
> used to move packets from/to ethernet DMA rings to/from WiFi DMA rings without
> involving the host cpu (similar to what we have for MTK with WED module).
> I think the PCIe slot info is not necessary for the NPU to work since it is
> configured by ethernet (airoha-eth) and wireless drivers (mt76) with DMA ring
> addresses to use via the airoha npu ops APIs, NPU just moves data between the
> DMA rings according to my understanding.
> 
> > 
> > So is the firmware name a property of the board?
> 
> We need to run different binaries on the NPU based on the MT76 WiFi chip
> available on the board since the MT76 DMA rings layout changes between MT76 SoC
> revisions (e.g. Egle MT7996 vs Kite MT7992). In this sense, I agree, the
> firmware name is a board property.
> 
> > 
> > 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?
> 
> IIUC what you mean here, it seems the solution I proposed in v1 (using
> firmware-name property), right?
> In this case we can't hard code the firmware name in the NPU driver since
> we can't understand the MT76 WiFi chip revision running on the board at
> the moment (MT76 would need to provide this info during MT76 probe,
> please take a look to the option 3 in my previous email).
> 
> > 
> > > 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?
> 
> I think the firmware is defined by the board hw configuration (e.g. MT76
> SoC revision) and not by the specific PCIe slot used.
> I do not think we have these info hardcoded in the silicon since NPU is a
> generic RiscV cpu (this has been confirmed by airoha folks).
> 

Just to make sure everything is clear and talking on this in very
simple words, there isn't anything ""hardcoded"" or strange.

For """""""reasons""""""" (I assume space constraints or NPU CPU
limitation) it's not possible to have a single NPU firmware to support
both WiFi card.

The NPU do simple task like configuring WED registers and handling DMA
descriptor/some WiFi offload. Such configuration is specific to the WiFi
card and it's not the same between MT7996 and MT7992.

This is why specific firmware is needed. The specific NPU firmware have
support for only ONE of the 2 WiFi card and doesn't support configuring
and handling stuff for the other. (the code is not built in the
firmware)

From the kernel side (in the MT76 code) we just instruct the NPU to
start offloading stuff (if present) and all the SoC feature for WiFi
offload are used. (WED, special DMA path, ...)

The possible combination that NPU can be used currently are the
following:
- Ethernet offload (all NPU firmware)
- Ethernet offload + WiFi MT7996 (NPU firmware with MT7996 support)
- Ethernet offload + WiFi MT7992 (NPU firmware with MT7992 support)

The NPU makes use of feature already present in the SoC and makes use of
reserved space in RAM for DMA handling so it really don't care of where
the WiFi card is present (this is what I mean with nothing is hardcoded)

I hope we are not getting annoying with insisting on the firmware-names
solution.

My personal taste on this is that hardcoding the name in the driver
seems a bit wrong and creating a way to dynamically select the firmware
based on what is present in the hardware would be great but would
introduce LOTS of COMPLEXITY for WiFi router that ship with a single
WiFi card and would have their own dedicated .dts

To make this generic enough an idea might be to have simple .dtsi with
prefilled firmware names.

- en7581-npu-mt7992.dtsi
- en7581-npu-mt7996.dtsi

But they would only contain a single node with a single string.

Hope this more practical explaination clears any doubt of the
implementation.

-- 
	Ansuel

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

[Andrew Lunn]

> > So is the firmware name a property of the board?
> 
> We need to run different binaries on the NPU based on the MT76 WiFi chip
> available on the board since the MT76 DMA rings layout changes between MT76 SoC
> revisions (e.g. Egle MT7996 vs Kite MT7992). In this sense, I agree, the
> firmware name is a board property.

O.K, lets go with v1 then. List the firmware filename in the board
.dts file.

     Andrew

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

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 3856 bytes --]

On Jan 14, Krzysztof Kozlowski wrote:
> On 14/01/2026 11:09, Christian Marangi wrote:
> > On Wed, Jan 14, 2026 at 10:26:33AM +0100, Krzysztof Kozlowski wrote:
> >> On 14/01/2026 10:01, Lorenzo Bianconi wrote:
> >>>> On Tue, Jan 13, 2026 at 09:20:27AM +0100, Lorenzo Bianconi wrote:
> >>>>> Introduce en7581-npu-7996 compatible string in order to enable MT76 NPU
> >>>>> offloading for MT7996 (Eagle) chipset since it requires different
> >>>>> binaries with respect to the ones used for MT7992 on the EN7581 SoC.
> >>>>>
> >>>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >>>>> ---
> >>>>>  Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml | 1 +
> >>>>>  1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>>>> index 59c57f58116b568092446e6cfb7b6bd3f4f47b82..96b2525527c14f60754885c1362b9603349a6353 100644
> >>>>> --- a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
> >>>>> @@ -18,6 +18,7 @@ properties:
> >>>>>    compatible:
> >>>>>      enum:
> >>>>>        - airoha,en7581-npu
> >>>>> +      - airoha,en7581-npu-7996
> >>>>
> >>>> This does not warrant new compatible. There is some misunderstanding and
> >>>> previous discussion asked you to use proper compatible, not invent fake
> >>>> one for non-existing hardware.  Either you have en7996-npu or
> >>>> en7581-npu. Not some mixture.
> >>>
> >>> Hi Krzysztof,
> >>>
> >>> We need to specify which fw binaries the airoha NPU module should load
> >>> according to the MT76 WiFi chipset is running on the board (since the NPU
> >>> firmware images are not the same for all the different WiFi chipsets).
> >>> We have two possible combinations:
> >>> - EN7581 NPU + MT7996 (Eagle)
> >>> - EN7581 NPU + MT7992 (Kite)
> >>>
> >>> Please note the airoha NPU module is always the same (this is why is just
> >>> added the -7996 suffix in the compatible string). IIUC you are suggesting
> >>> to use the 'airoha,en7996-npu' compatible string, right?
> >>
> >> No. I am suggesting you need to describe here the hardware. You said
> >> this EN7581 NPU, so this is the only compatible you get, unless (which
> >> is not explained anywhere here) that's part of MT799x soc, but then you
> >> miss that compatible. Really, standard compatible rules apply - so
> >> either this is SoC element/component or dedicated chip.
> >>
> >>
> > 
> > Hi Krzysztof,
> > 
> > just noticing this conversation and I think there is some confusion
> > here.
> > 
> > The HW is the following:
> > 
> > AN/EN7581 SoC that have embedded this NPU (a network coprocessor) that
> > require a dedicated firmware blob to be loaded to work.
> > 
> > Then the SoC can have various WiFi card connected to the PCIe slot.
> > 
> > For the WiFi card MT7996 (Eagle) and the WiFi card MT7992 (Kite) the NPU
> > can also offload the WiFi traffic.
> > 
> > A dedicated firmware blob for the NPU is needed to support the specific
> > WiFi card.
> > 
> > This is why v1 proposed the implementation with the firmware-names
> > property.
> > 
> > v2 introduce the compatible but I feel that doesn't strictly describe
> > the hardware as the NPU isn't specific to the WiFi card but just the
> > firmware blob.
> > 
> > 
> > I still feel v1 with firmware-names should be the correct candidate to
> > handle this.
> 
> Yes. What you plug into PCI is not a part of this hardware, so cannot be
> part of the compatible.

ack. So is it fine to use firmware-name property in this case as proposed in
v1?

Regards,
Lorenzo

> 
> > 
> > Hope now the HW setup is more clear.
> > 
> 
> 
> Best regards,
> Krzysztof

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH net-next v2 2/2] net: airoha: npu: Add en7581-npu-7996 compatible string

[Lorenzo Bianconi]

Introduce "airoha,en7581-npu-7996" compatible string in order to
specify different firmware binaries if the EN7581 SoC is running MT7996
(Eagle) chipset.
This is a preliminary patch to enable MT76 NPU offloading for MT7996
(Eagle) chipset since it requires different binaries with respect to
the ones used for MT7992 on the EN7581 SoC.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
 drivers/net/ethernet/airoha/airoha_npu.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index 22f72c146065998d5450477f664ed308b1569aa3..0032a4801bca066f75f60154e6df0b41d11b899f 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -16,6 +16,8 @@
 
 #define NPU_EN7581_FIRMWARE_DATA		"airoha/en7581_npu_data.bin"
 #define NPU_EN7581_FIRMWARE_RV32		"airoha/en7581_npu_rv32.bin"
+#define NPU_EN7581_7996_FIRMWARE_DATA		"airoha/en7581_MT7996_npu_data.bin"
+#define NPU_EN7581_7996_FIRMWARE_RV32		"airoha/en7581_MT7996_npu_rv32.bin"
 #define NPU_AN7583_FIRMWARE_DATA		"airoha/an7583_npu_data.bin"
 #define NPU_AN7583_FIRMWARE_RV32		"airoha/an7583_npu_rv32.bin"
 #define NPU_EN7581_FIRMWARE_RV32_MAX_SIZE	0x200000
@@ -624,6 +626,17 @@ static const struct airoha_npu_soc_data en7581_npu_soc_data = {
 	},
 };
 
+static const struct airoha_npu_soc_data en7581_7996_npu_soc_data = {
+	.fw_rv32 = {
+		.name = NPU_EN7581_7996_FIRMWARE_RV32,
+		.max_size = NPU_EN7581_FIRMWARE_RV32_MAX_SIZE,
+	},
+	.fw_data = {
+		.name = NPU_EN7581_7996_FIRMWARE_DATA,
+		.max_size = NPU_EN7581_FIRMWARE_DATA_MAX_SIZE,
+	},
+};
+
 static const struct airoha_npu_soc_data an7583_npu_soc_data = {
 	.fw_rv32 = {
 		.name = NPU_AN7583_FIRMWARE_RV32,
@@ -637,6 +650,7 @@ static const struct airoha_npu_soc_data an7583_npu_soc_data = {
 
 static const struct of_device_id of_airoha_npu_match[] = {
 	{ .compatible = "airoha,en7581-npu", .data = &en7581_npu_soc_data },
+	{ .compatible = "airoha,en7581-npu-7996", .data = &en7581_7996_npu_soc_data },
 	{ .compatible = "airoha,an7583-npu", .data = &an7583_npu_soc_data },
 	{ /* sentinel */ }
 };
@@ -782,6 +796,8 @@ module_platform_driver(airoha_npu_driver);
 
 MODULE_FIRMWARE(NPU_EN7581_FIRMWARE_DATA);
 MODULE_FIRMWARE(NPU_EN7581_FIRMWARE_RV32);
+MODULE_FIRMWARE(NPU_EN7581_7996_FIRMWARE_DATA);
+MODULE_FIRMWARE(NPU_EN7581_7996_FIRMWARE_RV32);
 MODULE_FIRMWARE(NPU_AN7583_FIRMWARE_DATA);
 MODULE_FIRMWARE(NPU_AN7583_FIRMWARE_RV32);
 MODULE_LICENSE("GPL");

-- 
2.52.0

Re: [PATCH net-next v2 2/2] net: airoha: npu: Add en7581-npu-7996 compatible string

[Andrew Lunn]

On Tue, Jan 13, 2026 at 09:20:28AM +0100, Lorenzo Bianconi wrote:
> Introduce "airoha,en7581-npu-7996" compatible string in order to
> specify different firmware binaries if the EN7581 SoC is running MT7996
> (Eagle) chipset.
> This is a preliminary patch to enable MT76 NPU offloading for MT7996
> (Eagle) chipset since it requires different binaries with respect to
> the ones used for MT7992 on the EN7581 SoC.
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew