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] [thread-next>] [day] [month] [year] [list]
Message-ID: <b68435e3e44de0532fc1e0c2e7f7bf54@fw-web.de>
Date: Thu, 03 Jul 2025 13:01:40 +0200
From: "Frank Wunderlich (linux)" <linux@...web.de>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: frank-w@...lic-files.de, MyungJoo Ham <myungjoo.ham@...sung.com>,
 Kyungmin Park <kyungmin.park@...sung.com>, Chanwoo Choi
 <cw00.choi@...sung.com>, Georgi Djakov <djakov@...nel.org>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>, Vladimir Oltean
 <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Johnson Wang <johnson.wang@...iatek.com>, Arınç ÜNAL <arinc.unal@...nc9.com>, Landen Chao
 <Landen.Chao@...iatek.com>, DENG Qingfang <dqfext@...il.com>, Sean Wang
 <sean.wang@...iatek.com>, Daniel Golle <daniel@...rotopia.org>, Lorenzo
 Bianconi <lorenzo@...nel.org>, Felix Fietkau <nbd@....name>,
 linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v7 01/14] dt-bindings: net: mediatek,net: allow irq names

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@...nel.org>:
>>> On Sat, Jun 28, 2025 at 06:54:36PM +0200, Frank Wunderlich wrote:
>>>> From: Frank Wunderlich <frank-w@...lic-files.de>
>>>> 
>>>> 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

>> 
>>>> property. Also increase the maximum IRQ count to 8 (4 FE + 4 RSS),
>>> 
>>> Why? There is no user of 8 items.
>> 
>> MT7988 *with* RSS/LRO (not yet supported by driver
>> yet,but i add the irqs in devicetree in this series)
>> use 8 irqs,but RSS is optional and 4 irqs get working
>> ethernet stack.
> 
> That's separate change than fixing ABI and that user MUST BE HERE. You
> cannot add some future interrupts for some future device. Adding new
> device is the only reason to add more interrupts.

MT7988 is basicly new because there is no devicetree there yet...only 
driver and
this (incomplete) binding.

>> 
>> I hope this explanation makes things clearer...
> 
> 
> Commit msg must explain all this, not me asking.
> 
>> 
>>>> but set boundaries for all compatibles same as irq count.
>>> 
>>> Your patch does not do it.
>> 
>> I set Min/max-items for interrupt names below like
>> interrupts count defined.
> 
> No, you don't. It's all fluid and flexible - limited constraints.

i thought i can limit is by setting the MaxItems in the soc-spcific 
blocks below.
What reason does MaxItems have there if not this? of course if there is 
any Soc not
having a specific block it is open.But this is also the case for 
interrupts property
handles the same way before.

I only left it open on mt7988 (only set minitems because all 8 can be 
used, but 4 are required).

>> 
>>>> 
>>>> Signed-off-by: Frank Wunderlich <frank-w@...lic-files.de>
>>>> ---
>>>> v7: fixed wrong rebase
>>>> v6: new patch splitted from the mt7988 changes
>>>> ---
>>>>  .../devicetree/bindings/net/mediatek,net.yaml | 38 
>>>> ++++++++++++++++++-
>>>>  1 file changed, 37 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml 
>>>> b/Documentation/devicetree/bindings/net/mediatek,net.yaml
>>>> index 9e02fd80af83..6672db206b38 100644
>>>> --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
>>>> +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
>>>> @@ -40,7 +40,19 @@ properties:
>>>> 
>>>>    interrupts:
>>>>      minItems: 1
>>>> -    maxItems: 4
>>>> +    maxItems: 8
>>>> +
>>>> +  interrupt-names:
>>>> +    minItems: 1
>>>> +    items:
>>>> +      - const: fe0
>>>> +      - const: fe1
>>>> +      - const: fe2
>>>> +      - const: fe3
>>>> +      - const: pdma0
>>>> +      - const: pdma1
>>>> +      - const: pdma2
>>>> +      - const: pdma3
>>>> 
>>>>    power-domains:
>>>>      maxItems: 1
>>>> @@ -135,6 +147,10 @@ allOf:
>>>>            minItems: 3
>>>>            maxItems: 3
>>>> 
>>>> +        interrupt-names:
>>>> +          minItems: 3
>>>> +          maxItems: 3

limited here to the same as interrupts.

>>>>          clocks:
>>>>            minItems: 4
>>>>            maxItems: 4
>>>> @@ -166,6 +182,9 @@ allOf:
>>>>          interrupts:
>>>>            maxItems: 1
>>>> 
>>>> +        interrupt-namess:
>>>> +          maxItems: 1
dito

>>>>          clocks:
>>>>            minItems: 2
>>>>            maxItems: 2
>>>> @@ -192,6 +211,10 @@ allOf:
>>>>            minItems: 3
>>>>            maxItems: 3
>>>> 
>>>> +        interrupt-names:
>>>> +          minItems: 3
>>>> +          maxItems: 3
dito and so on

>>>>          clocks:
>>>>            minItems: 11
>>>>            maxItems: 11
>>>> @@ -232,6 +255,10 @@ allOf:
>>>>            minItems: 3
>>>>            maxItems: 3
>>>> 
>>>> +        interrupt-names:
>>>> +          minItems: 3
>>>> +          maxItems: 3
>>>> +
>>>>          clocks:
>>>>            minItems: 17
>>>>            maxItems: 17
>>>> @@ -274,6 +301,9 @@ allOf:
>>>>          interrupts:
>>>>            minItems: 4
>>>> 
>>>> +        interrupt-names:
>>>> +          minItems: 4
>>>> +
>>>>          clocks:
>>>>            minItems: 15
>>>>            maxItems: 15
>>>> @@ -312,6 +342,9 @@ allOf:
>>>>          interrupts:
>>>>            minItems: 4
>>>> 
>>>> +        interrupt-names:
>>>> +          minItems: 4
>>> 
>>> 8 interrupts is now valid?
>>> 
>>>> +
>>>>          clocks:
>>>>            minItems: 15
>>>>            maxItems: 15
>>>> @@ -350,6 +383,9 @@ allOf:
>>>>          interrupts:
>>>>            minItems: 4
>>>> 
>>>> +        interrupt-names:
>>>> +          minItems: 4
>>> 
>>> So why sudenly this device gets 8 interrupts? This makes no sense,
>>> nothing explained in the commit msg.
>> 
>> 4 FrameEngine IRQs are required to be defined (currently 2 are used in 
>> driver).
>> The other 4 are optional,but added in the devicetree
> 
> 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.

>> to not run into problems supporting old devicetree
>> when adding RSS/LRO to driver.
> 
> This is not about driver, it does not matter for the driver. Binding 
> and
> DTS are supposed to be complete.

if i upstream the ethernet-node now with only 4 IRQS, we have to extend 
them later and
have to deal with only 4 IRQs in driver to be compatible with older DTS. 
So newer
kernel with RSS/LRO support cannot work with older DT.
To avoid this i add all related IRQs now (from DT perspective a new 
device - there is
no mt7988 device with ethernet node in devicetree yet).

>> 
>>> I understand nothing from this patch and I already asked you to 
>>> clearly
>>> explain why you are doing things. This patch on its own makes no 
>>> sense.

i tried to explain :(
i have a working dts for mt7988 and try to upstream it in this series 
and thats the
cause i have to update the binding. Imho i cannot increase the 
interrupt-count in SoC
specific block (e.g. setting count globally to 4 but to 8 for only 
mt7988).

I added interrupt-names to get it cleaner in driver (access via name 
instead of
index). And also in Devicetree we see the meaning of IRQs without 
looking through
driver. I see really no reason for not adding the interrupt names.

>>> Best regards,
>>> Krzysztof

regards Frank

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ