[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f942223-8683-4808-8f7a-4f46e18f402d@lunn.ch>
Date: Mon, 28 Jul 2025 17:40:06 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jonas Karlman <jonas@...boo.se>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Alvin Šipraga <alsi@...g-olufsen.dk>,
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>,
Yao Zi <ziyao@...root.org>, Chukun Pan <amadeus@....edu.cn>,
Heiko Stuebner <heiko@...ech.de>, netdev@...r.kernel.org,
linux-rockchip@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] net: dsa: realtek: Add support for use of
an optional mdio node
> When it comes to having the switch being described as an interrupt
> controller in the DT is also very wrong, the switch only consume a
> single HW interrupt. The fact that the driver creates virtual irq for
> each port is purely a software construct and is not something that
> should be reflected in the DT.
I think that is not always clear cut. Switches can be considered SoC
of their own. They have multiple hardware blocks, which can be
described independent, just like a traditional SoC and its .dtsi
file. The switch blocks can then be connected together in the same way
SoCs are.
I've not looked at this particular switch driver, but the Marvell
switches have a similar single interrupt output pin connected to the
host SoC. Within the switch, there are at least two cascaded interrupt
controllers. We implement standard Linux interrupt controllers for
these. That allows us to use standard DT properties to link the
internal PHY interrupts to these interrupt controllers.
Andrew
Powered by blists - more mailing lists