Re: [PATCH v2] net: ethernet: mtk_eth_soc: support named IRQs

["Frank Wunderlich (linux)" <linux@fw-web.de>]

Am 2025-06-15 10:57, schrieb Lorenzo Bianconi:
>> From: Frank Wunderlich <frank-w@public-files.de>
>> 
>> Add named interrupts and keep index based fallback for exiting 
>> devicetrees.
>> 
>> Currently only rx and tx IRQs are defined to be used with mt7988, but
>> later extended with RSS/LRO support.
>> 
>> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
>> Reviewed-by: Simon Horman <horms@kernel.org>
> 
> Hi Frank,
> 
> I guess my comments on v1 apply even in v2. Can you please take a look?

adding your comments (and mine as context) from v1 here:

Am 2025-06-15 10:57, schrieb Lorenzo Bianconi:
>> From: Frank Wunderlich <frank-w@public-files.de>

>> I had to leave flow compatible with this:
>> 
>> <https://github.com/frank-w/BPI-Router-Linux/blob/bd7e1983b9f0a69cf47cc9b9631138910d6c1d72/drivers/net/ethernet/mediatek/mtk_eth_soc.c#L5176>
> 
> I guess the best would be to start from 0 even here (and wherever it is
> necessary) and avoid reading current irq[0] since it is not actually 
> used for
> !shared_int devices (e.g. MT7988).  Agree?
> 
>> 
>> Here the irqs are taken from index 1 and 2 for
>>  registration (!shared_int else only 0). So i avoided changing the
>>  index,but yes index 0 is unset at this time.
>> 
>> I guess the irq0 is not really used here...
>> I tested the code on bpi-r4 and have traffic
>>  rx+tx and no crash.
>>  imho this field is not used on !shared_int
>>  because other irq-handlers are used and
>>  assigned in position above.
> 
> agree. I have not reviewed the code in detail, but this is why
> I think we can avoid reading it.

i areee, but imho it should be a separate patch because these are 2 
different changes

>> It looks like the irq[0] is read before...there is a
>>  message printed for mediatek frame engine
>>  which uses index 0 and shows an irq 102 on
>>  index way and 0 on named version...but the
>>  102 in index way is not visible in /proc/interrupts.
>> So imho this message is misleading.
>> 
>> Intention for this patch is that irq 0 and 3 on
>>  mt7988 (sdk) are reserved (0 is skipped on
>> !shared_int and 3 never read) and should imho
>>  not listed in devicetree. For further cleaner
>>  devicetrees (with only needed irqs) and to
>>  extend additional irqs for rss/lro imho irq
>>  names make it better readable.
> 
> Same here, if you are not listing them in the device tree, you can 
> remove them
> in the driver too (and adjust the code to keep the backward 
> compatibility).

afaik i have no SHARED_INT board (only mt7621, mt7628) so changing the 
index-logic will require testing on such boards too.

i looked a bit into it and see mt7623 and mt7622 have 3 IRQs defined 
(!SHARED_INT) and i'm not 100% sure if the first is also skipped (as far 
as i understood code it should always be skipped).

In the end i would change the irq-index part in separate patch once this 
is accepted to have clean changes and not mixing index with names (at 
least to allow a revert of second in case of regression).

Am 2025-06-15 11:26, schrieb Daniel Golle:
> In addition to Lorenzo's comment to reduce the array to the actually 
> used
> IRQs, I think it would be nice to introduce precompiler macros for the 
> irq
> array index, ie. once the array is reduce to size 2 it could be 
> something
> like
> 
> #define MTK_ETH_IRQ_SHARED 0
> #define MTK_ETH_IRQ_TX 0
> #define MTK_ETH_IRQ_RX 1
> #define __MTK_ETH_IRQ_MAX MTK_ETH_IRQ_RX
> 
> That would make all the IRQ code more readable than having to deal with
> numerical values.

makes sense, i will take this into the second patch.

I hope you can agree my thoughts about not mixing these 2 parts :)

regards Frank