Re: [PATCH v7 01/14] dt-bindings: net: mediatek,net: allow irq names

[Daniel Golle]

On Thu, Jul 03, 2025 at 01:01:40PM +0200, Frank Wunderlich (linux) wrote:
> Am 2025-07-02 08:27, schrieb Krzysztof Kozlowski:
> > On 01/07/2025 12:51, Frank Wunderlich wrote:
> > > Am 1. Juli 2025 08:44:02 MESZ schrieb Krzysztof Kozlowski
> > > <krzk@xxxxxxxxxx>:
> > > > On Sat, Jun 28, 2025 at 06:54:36PM +0200, Frank Wunderlich wrote:
> > > > > From: Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx>
> > > > > 
> > > > > In preparation for MT7988 and RSS/LRO allow the interrupt-names
> > > > 
> > > > Why? What preparation, what is the purpose of adding the names,
> > > > what do
> > > > they solve?
> > > 
> > > Devicetree handled by the mtk_eth_soc driver have
> > > a wild mix of shared and non-shared irq definitions
> > > accessed by index (shared use index 0,
> > > non-shared
> > > using 1+2). Some soc have only 3 FE irqs (like mt7622).
> > > 
> > > This makes it unclear which irq is used for what
> > > on which SoC. Adding names for irq cleans this a bit
> > > in device tree and driver.
> > 
> > It's implied ABI now, even if the binding did not express that. But
> > interrupt-names are not necessary to express that at all. Look at other
> > bindings: we express the list by describing the items:
> > items:
> >   - description: foo
> >   - ... bar
> 
> ok, so i need to define descriptions for all interrupts instead of only
> increasing the count. Ok, was not clear to me.
> 
> so something like this:
> 
> item0: on SoCs with shared IRQ (mt762[18]) used for RX+TX, on other free to
> be used
> item1: on non-shared SoCs used for TX
> item2: on non-shared SoCs used for RX (except RSS/LRO is used)
> item3: reserved / currently unused
> item4-7: IRQs for RSS/LRO

These descriptions match the current *software* use of those interrupts,
however, DT should describe the hardware and esp. item0 up to item3 could
be used in different ways in the future (by programming MTK_FE_INT_GRP
register differently).

I think using interrupt-names fe0...fe3 and pdma0...pdma3 is still the
best option, so the driver can request the interrupts by name which is
much more readable in the driver code and SoC's dtsi than relying on a
specific order.

> > 
> > There were only 4 before and you do not explain why all devices get 8.
> > You mentioned that MT7988 has 8 but now make 8 for all other variants!
> > 
> > Why you are not answering this question?
> 
> The original binding excluded the 4 RSS/LRO IRQs as this is an optional
> feature not
> yet available in driver. It is needed to get the full speed on the 10G
> interfaces.
> MT7988 is the first SoC which has 10G MACs. Older Socs like mt7986 and
> mt7981 can also
> support RSS/LRO to reduce cpu load. But here we will run into the "new
> kernel - old
> devicetree" issue, if we try to upstream this. Maybe we do not add this
> because these
> only have 2.5G MACs.

It might be important to note that

MT7621, MT7628: 1 IRQ
MT7622, MT7623: 3 IRQs (only two used by the driver for now)
MT7981, MT7986: 4 IRQs (only two used by the driver for now)

While older SoCs MT7981 and MT7986 have limited support for *either LRO
or RSS* in hardware, only MT7988 got 4 frame-engine IRQs like MT7981 and
MT7986 and an additional 4 IRQs for the 4 RX DMA rings on top of that,
so a total of 8, and can do both RSS and LRO.