Received-SPF: pass (google.com: domain of linux-kernel+bounces-204861-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Thomas Gleixner <tglx@linutronix.de>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Simon Horman <horms@kernel.org>, Sai Krishna Gajula
 <saikrishnag@marvell.com>, Rob Herring <robh@kernel.org>, Krzysztof
 Kozlowski <krzk+dt@kernel.org>, Conor Dooley <conor+dt@kernel.org>, "David
 S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub
 Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Lee Jones
 <lee@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Horatiu Vultur
 <horatiu.vultur@microchip.com>, UNGLinuxDriver@microchip.com, Andrew Lunn
 <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King
 <linux@armlinux.org.uk>, Saravana Kannan <saravanak@google.com>, Bjorn
 Helgaas <bhelgaas@google.com>, Philipp Zabel <p.zabel@pengutronix.de>, Lars
 Povlsen <lars.povlsen@microchip.com>, Steen Hegelund
 <Steen.Hegelund@microchip.com>, Daniel Machon
 <daniel.machon@microchip.com>, Alexandre Belloni
 <alexandre.belloni@bootlin.com>, linux-kernel@vger.kernel.org,
 devicetree@vger.kernel.org, netdev@vger.kernel.org,
 linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Allan
 Nielsen <allan.nielsen@microchip.com>, Luca Ceresoli
 <luca.ceresoli@bootlin.com>, Thomas Petazzoni
 <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2 10/19] irqdomain: Introduce irq_domain_alloc() and
 irq_domain_publish()
In-Reply-To: <20240606175258.0e36ea98@bootlin.com>
References: <20240527161450.326615-1-herve.codina@bootlin.com>
 <20240527161450.326615-11-herve.codina@bootlin.com> <8734pr5yq1.ffs@tglx>
 <20240606175258.0e36ea98@bootlin.com>
Date: Thu, 06 Jun 2024 20:11:23 +0200
Message-ID: <87v82m0wms.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Herve!

On Thu, Jun 06 2024 at 17:52, Herve Codina wrote:
> On Wed, 05 Jun 2024 15:02:46 +0200
> Thomas Gleixner <tglx@linutronix.de> wrote:
>> On Mon, May 27 2024 at 18:14, Herve Codina wrote:
>> > To avoid a window where the domain is published but not yet ready to be  
>> 
>> I can see the point, but why is this suddenly a problem? There are tons
>> of interrupt chip drivers which have exactly that pattern.
>
> I thing the issue was not triggered because these interrupt chip driver
> are usually builtin compiled and the probe sequence is the linear one
> done at boot time. Consumers/supplier are probe sequentially without any
> parallel execution issues.
>
> In the LAN966x PCI device driver use case, the drivers were built as
> modules. Modules loading and drivers .probe() calls for the irqs supplier
> and irqs consumers are done in parallel. This reveals the race condition.

So how is that supposed to work? There is clearly a requirement that the
interrupt controller is ready to use when the network driver is probed, no?

>> Also why is all of this burried in a series which aims to add a network
>> driver and touches the world and some more. If you had sent the two irq
>> domain patches seperately w/o spamming 100 people on CC then this would
>> have been solved long ago. That's documented clearly, no?
>
> Yes, the main idea of the series, as mentioned in the cover letter, is to
> give the big picture of the LAN966x PCI device use case in order to have
> all the impacted subsystems and drivers maintainers be aware of the global
> use case: DT overlay on top of PCI device.
> Of course, the plan is to split this series into smaller ones once parts
> get discussed in the DT overlay on top of PCI use case and reach some kind
> of maturity at least on the way to implement a solution.

Fair enough.

> Thomas, do you prefer to have all the IRQ related patches extracted right
> now from this big picture series ?

I think the interrupt controller problem is completely orthogonal to the
PCI/DT issue.

So yes, please split them out as preparatory work which is probably also
not that interesting for the PCI/DT/net folks.

If the template approach holds, then the infrastructure change is
definitely worth it on its own and the actual driver just falls in place
and is off your backlog list.

Thanks,

        tglx