Message-ID: <20240607100603.660efc87@bootlin.com>
Date: Fri, 7 Jun 2024 10:06:03 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Simon Horman <horms@...nel.org>, Sai Krishna Gajula
 <saikrishnag@...vell.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, "David
 S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Lee Jones
 <lee@...nel.org>, Arnd Bergmann <arnd@...db.de>, Horatiu Vultur
 <horatiu.vultur@...rochip.com>, UNGLinuxDriver@...rochip.com, Andrew Lunn
 <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Russell King
 <linux@...linux.org.uk>, Saravana Kannan <saravanak@...gle.com>, Bjorn
 Helgaas <bhelgaas@...gle.com>, Philipp Zabel <p.zabel@...gutronix.de>, Lars
 Povlsen <lars.povlsen@...rochip.com>, Steen Hegelund
 <Steen.Hegelund@...rochip.com>, Daniel Machon
 <daniel.machon@...rochip.com>, Alexandre Belloni
 <alexandre.belloni@...tlin.com>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, netdev@...r.kernel.org,
 linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Allan
 Nielsen <allan.nielsen@...rochip.com>, Luca Ceresoli
 <luca.ceresoli@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 10/19] irqdomain: Introduce irq_domain_alloc() and
 irq_domain_publish()

On Thu, 06 Jun 2024 20:11:23 +0200
Thomas Gleixner <tglx@...utronix.de> wrote:

> Herve!
> 
> On Thu, Jun 06 2024 at 17:52, Herve Codina wrote:
> > On Wed, 05 Jun 2024 15:02:46 +0200
> > Thomas Gleixner <tglx@...utronix.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?

Yes, EPROBE_DEFER mecanism.
The race condition window leads to an other error code instead of the
expected EPROBE_DEFER.

> 
> >> 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.
> 

Will do that.

Best regards,
Hervé

Powered by blists - more mailing lists